Definicion

Un prototipo es una versión preliminar de un sistema con fines de demostración o evaluación de ciertos requisitos. Se puede considerar que cada mini-proyecto del desarrollo en espiral tiene como producto final la obtención de un prototipo que recoge y muestra su desarrollo. Es decir, el uso de un modelo de desarrollo en espiral basado en prototipo, se fundamenta en terminar cada ciclo de la espiral con un prototipo que muestre que se han obtenido los requisitos que se marcaron al principio de cada ciclo.
El uso de los prototipos implica un método menos formal de desarrollo, donde su fundamento es hacer comprender las especificaciones del producto final.
Un prototipo usado durante un desarrollo software de estas características puede formar parte del producto final o bien puede ser desechado.
Las fases que se dan en la construcción de los distintos prototipos de un desarrollo son:
1. Identificación de Requisitos que debe de cumplir el prototipo.
2. Diseñar e implementar el prototipo.
3. Utilizar el prototipo con el fin de probar que cumple los requisitos para los que fue diseñado.
4. Revisar y mejorar el prototipo.
Como se puede observar, las fases de la construcción de prototipos incrementales se pueden solapar con las del modelo de desarrollo en espiral, por lo tanto y como conclusión, en este proyecto se desarrollará un prototipo en cada ciclo del modelo en espiral que se va a seguir. En cada ciclo se obtendrá, como resultado de la fase de diseño e implementación, un nuevo prototipo.

es un estilo de programación orientada a objetos en el cual, las "clases" no están presentes, y la re-utilización de procesos (conocida como herencia en lenguajes basados en clases) se obtiene a través de la clonación de objetos ya existentes, que sirven de prototipos, extendiendo sus funcionalidades. Este modelo es conocido como orientado a prototipos, o programación basada en instancias.
El original (y el más canónico) ejemplo de lenguaje prototipado es el lenguaje Self, desarrollado por David Ungar y Randall Smith. Sin embargo el paradigma sin clases está comenzando a popularizarse y ya ha sido implementado en lenguajes de programación como Java Script, Cecil, Newton Script, Ío, MOO, REBOL y varios otros.

Los modelos de orientación a objetos son dos: el más clásico o conocido, basado en clases, y el modelo basado en prototipos, de mayor difusión en el ámbito de la investigación. Este modelo se centra en una mayor flexibilidad (que poco a poco se filtra a los lenguajes basados en clases), descartando elementos rígidos como las clases y apostando por un mundo de objetos más uniforme. Este incremento de flexibilidad favorece el desarrollo rápido de aplicaciones y es muy útil en educación.

Modelo Basado En Clases

En lenguajes basados en clases los objetos pueden ser de dos tipos generales, las clases y las instancias. Las clases definen la disposición y la funcionalidad básicas de los objetos, y las instancias son objetos "utilizables" basados en los patrones de una clase particular. En este modelo, las clases actúan como colecciones de comportamiento (métodos) y estructuras que son iguales para todas las instancias, mientras que las instancias llevan los datos de los objetos. La distinción del papel se basa así sobre todo en una distinción entre la estructura y el comportamiento en un lado, y el estado en el otro.
Los entusiastas de la programación basada en prototipos a menudo argumentan que los lenguajes basados en clases animan un modelo del desarrollo que se centra primero en la taxonomía y las relaciones entre las clases. En cambio, la programación basada en prototipos intenta animar al programador que se centre en el comportamiento de un cierto sistema de ejemplos y después de clasificar estos objetos en objetos arquetipos que se utilizan más adelante en una manera similar a las clases. Como tal, muchos sistemas basados en prototipos animan la alteración de prototipos durante tiempo de ejecución, mientras que solamente muy pocos sistemas orientados a objeto, basados en clase (como el primer sistema orientados al objetos dinámicos, Smalltalk) permiten que las clases sean alteradas durante la ejecución de un programa.
Mientras que basan la amplia mayoría de sistemas basados en prototipos se hacen con lenguajes de programación interpretados y de tipos de datos dinámicos, es importante precisar que los sistemas de tipos de datos estáticos son técnicamente factibles. El lenguaje de programación de Omega que es basado en prototipos es un ejemplo de tal sistema, aunque según el Web site de Omega, Omega no es exclusivamente de tipos de datos estáticos, pero su "compilador puede elegir utilizar el tipo de dato estático donde es posible esto y puede mejorar la eficacia del programa.”

Ventajas

Este modelo es útil cuando el cliente conoce los objetivos generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento o salida.
También ofrece un mejor enfoque cuando el responsable del desarrollo del software está inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debería tomar la interacción humano-máquina.
La construcción de prototipos se puede utilizar como un modelo del proceso independiente, se emplea más comúnmente como una técnica susceptible de implementarse dentro del contexto de cualquiera de los modelos del proceso expuestos. Sin importar la forma en que éste se aplique, el paradigma de construcción de prototipos ayuda al desarrollador de software y al cliente a entender de mejor manera cuál será el resultado de la construcción cuando los requisitos estén satisfechos. De esta manera, este ciclo de vida en particular, involucra al cliente más profundamente para adquirir el producto.

Inconvenientes

El usuario tiende a crearse unas expectativas cuando ve el prototipo de cara al sistema final. A causa de la intención de crear un prototipo de forma rápida, se suelen desatender aspectos importantes, tales como la calidad y el mantenimiento a largo plazo, lo que obliga en la mayor parte de los casos a reconstruirlo una vez que el prototipo ha cumplido su función. Es frecuente que el usuario se muestre reacio a ello y pida que sobre ese prototipo se construya el sistema final, lo que lo convertiría en un prototipo evolutivo, pero partiendo de un estado poco recomendado.
En aras de desarrollar rápidamente el prototipo, el desarrollador suele tomar algunas decisiones de implementación poco convenientes (por ejemplo, elegir un lenguaje de programación incorrecto porque proporcione un desarrollo más rápido). Con el paso del tiempo, el desarrollador puede olvidarse de la razón que le llevó a tomar tales decisiones, con lo que se corre el riesgo de que dichas elecciones pasen a formar parte del sistema final.

Conclusiones

A pesar de que tal vez surjan problemas, la construcción de prototipos puede ser un paradigma efectivo para la ingeniería del software. La clave es definir las reglas del juego desde el principio; es decir, el cliente y el desarrollador se deben poner de acuerdo en:
Que el prototipo se construya y sirva como un mecanismo para la definición de requisitos.
Que el prototipo se descarte, al menos en parte.
Que después se desarrolle el software real con un enfoque hacia la calidad.