Prototipo evolutivo: Los prototipos evolutivos, como indica su nombre, evolucionan

de una iteración a la siguiente. Aunque inicialmente no se controla la calidad de la

producción, el código suele revisarse a medida que evoluciona el producto. Para que
la revisión sea gestionable, suelen diseñarse más formalmente y probarse de una
manera más o menos formal, incluso en los primeros estadios. A medida que el
producto evoluciona, la prueba se formaliza y, a veces, el diseño también.

Ventajas:

 Es ideal para sistemas que no tienen bien definidos los requerimientos.

 La especificación se puede mostrar de forma creciente

Desventajas:

 La estructura suele ser deficiente

 El progreso no es visible
 Sistemas pobremente estructurados

Entrega evolutiva: Para proyectos que requieren un progreso visible, el modelo de

entrega evolutiva es una buena opción. Se desarrolla una versión de producto, se
muestra al cliente y se refina el producto en función de la realimentación del cliente.

Es similar a la creación de prototipos evolutiva y de alguna manera tiene los mismos

conceptos utilizados en la entrega por etapas.

Ventajas:

Con el modelo de entrega evolutiva, es fácil conocer las necesidades de los clientes
debido a la serie de pruebas que se llevarán a cabo durante toda la duración del
proyecto. Habrá una comprensión clara de las cosas que deben cambiarse, así como
las que deben conservarse. No necesita mantenerse a sí mismo ni a su equipo
adivinando porque los comentarios que recibe sobre los prototipos le mostrarán todo lo
que necesita saber sobre los requisitos de su mercado objetivo.

Lo que es más importante, el modelo de entrega evolutiva contribuye en gran medida

al éxito de un producto o servicio porque se crea sobre la base de lo que se ha
probado y probado. Con la mayoría de los posibles problemas ya abordados, la
eficiencia aumentará significativamente.

Desventajas:

Al igual que con cualquier modelo que requiera conceptos de prueba y error, el modelo
de entrega evolutiva plantea un problema en su capacidad de ajustarse a un
cronograma. El tiempo que se necesita para planificar y diseñar los prototipos será
sustancial y las repeticiones del ciclo a veces tomarán demasiado tiempo para
finalizar. No hay una línea de tiempo establecida e incluso si la hay, será difícil
cumplirla.

Otra cosa que vale la pena mencionar es que el uso de este modelo requerirá que
personas altamente calificadas lo administren para que se puedan lograr mejores
resultados. El proyecto requerirá un alto grado de experiencia analítica, ya que podría
aprovecharse. Debe contratar a personas que puedan brindar a pesar de las
complejidades.
Diseño por planificación: El modelo de ciclo de vida de diseño por planificación es
similar al modelo de ciclo de vida de entrega por etapas, en el que se planifica
desarrollar el producto en etapas sucesivas. La diferencia radica que no siempre se
conoce al principio si se tendrá el producto para la última entrega. Se pueden tener
cinco etapas planificadas. Pero sólo se llega a la tercera etapa debido a que se tiene
una fecha límite inamovible. Este modelo de ciclo de vida puede ser una estrategia
válida para asegurar que se tiene un producto listo a entregar en una fecha
determinada. Si se debe tener absolutamente el software funcionando a tiempo para
una presentación comercial, o para final de año, o para cualquier otra fecha
inamovible, esta estrategia garantiza que se tendrá algo. Esta estrategia es
particularmente útil para las partes del producto que no se quieren realizar en el
camino crítico.

 Sashimi (Cascada con fases solapadas): El ciclo de vida tipo Sashimi podría ser
considerado como una variación del ciclo de vida en cascada puro, en el cual las
diferentes etapas pueden ser solapadas, permitiendo así aumentar la eficiencia
mediante la retroalimentación entre las etapas.

Ventajas:

• No requiere tanta documentación como el ciclo de vida de cascada ya que es

continuo.

• Su planificación es sencilla.

Desventajas:

• Más difícil controlar el progreso del proyecto debido a que los finales de fase ya no
son un punto de referencia claro.
• La dificultad de reconocer todos los requerimientos desde un inicio.