domingo, 10 de abril de 2011

CICLO DE VIDA EVOLUTIVO

MODELOS DE CICLO DE VIDA EVOLUTIVO:




Como el modelo de desarrollo incremental, el modelo de desarrollo evolutivo (algunas veces denominado como prototipado evolutivo) construye una serie de grandes versiones sucesivas de un producto. Sin embargo, mientras que la aproximacn incremental presupone que el conjunto completo de requerimientos es conocido al comenzar, el modelo evolutivo asume que los requerimientos no son completamente conocidos al inicio del proyecto.
En el modelo evolutivo, los requerimientos son cuidadosamente examinados, y sólo esos que son bien comprendidos son seleccionados para el primer incremento. Los desarrolladores construyen una implementacn parcial del sistema que recibe sólo estos requerimientos.
El sistema es entonces desarrollado, los usuarios lo usan, y proveen retroalimentación a los desarrolladores. Basada en esta retroalimentación, la especificación de requerimientos es actualizada, y una segunda versión del producto es desarrollada y desplegada. El proceso se repite indefinidamente.
Note que el desarrollo evolutivo es 100% compatible con el modelo cascada. El desarrollo evolutivo no demanda una forma específica de observar el desarrollo de algún incremento. Así, el  modelo  cascada  puede  ser  usado  para  administrar  cada  esfuerzo  de  desarrollo. Obviamente, el desarrollo incremental y evolutivo puede ser combinado también.
Todo lo que uno tiene que hacer es construir un subconjunto de requerimientos conocidos (incremental), y comprender al principio que muchos nuevos requerimientos es probable que aparezcan cuando el sistema sea desplegado o desarrollado.




El desarrollo de software en forma evolutiva requiere un especial cuidado en la manipulación

de documentos, programas, datos de test, etc. desarrollados para distintas versiones del software. Cada paso debe ser registrado, la documentacn debe ser recuperada con facilidad,
los cambios deben ser efectuados de una manera controlada.

CARACTERISTICAS:

  • Construcción de una implementación parcial que cubre los requisitos conocidos, para ir aprendiendo el resto y, paulatinamente, incorporarlos al sistema.
  • Reduce el riesgo y aumenta la probabilidad de éxito.
  • No se conocen niveles apropiados de calidad y documentación.
  • Problemas de gestión de configuración.  
Construir software para que pueda ser modificado fácilmente es un “arte desconocido”



No hay comentarios:

Publicar un comentario