Modelos De Vida Del Ciclo Del Software

Para facilitar una metodología común entre el cliente y la compañía de software, los modelos de ciclo de vida se han actualizado para reflejar las etapas de desarrollo involucradas y la documentación requerida.

Modelo cascada

           Ventajas:

• Es un modelo sencillo y disciplinado
• Es fácil aprender a utilizarlo y comprender su funcionamiento
• Está dirigido por los tipos de documentos y resultados que deben obtenerse al final de cada etapa
• Ha sido muy usado y, por tanto, está ampliamente contrastado
• Ayuda a detectar errores en las primeras etapas a bajo costo
• Ayuda a minimizar los gastos de planificación, pues se realiza sin problemas

Desventajas:
• Los proyectos raramente siguen el proceso lineal tal como se definía originalmente el ciclo de vida
• Es difícil que el cliente exponga explícitamente todos los requisitos al principio
• El cliente debe tener paciencia pues obtendrá el producto al final del ciclo de vida
• No refleja exactamente cómo se programa realmente el sistema, en el que suele haber un gran componente iterativo
• Puede resultar complicado regresar a etapas anteriores (ya acabadas) para realizar correcciones
• El producto final obtenido puede que no refleje todos los requisitos del usuario

Modelo espiral

Ventajas:
• Incorpora muchas de las ventajas de los otros ciclos de vida
• Conjuga la naturaleza iterativa de los prototipos con los aspectos controlados y sistemáticos del modelo clásico
• Proporciona el potencial para el desarrollo rápido de versiones incrementales
• Puede adaptarse y aplicarse a lo largo de la vida del software
• Es un enfoque realista del desarrollo del software
• Permite aplicar el enfoque de construcción de prototipos en cualquier momento para reducir riesgos
• Reduce los riesgos antes de que se conviertan en problemáticos
• Controla muy bien los riesgos y mientras más iteraciones se realicen, menos riesgos habrá
• Monitoriza y controla los riesgos continuamente

Desventajas:
• Puede resultar difícil convencer a algunos clientes de que el enfoque evolutivo es controlable
• Solo resulta aplicable para proyectos de gran tamaño
• Supone una carga de trabajo adicional, no presente en otros ciclos de vida
• Requiere una considerable habilidad para la evaluación y resolución del riesgo, y se basa en esta habilidad para el éxito
• Si un riesgo importante no es descubierto y gestionado, indudablemente surgirán problemas
• Es bastante complicado de realizar y su complejidad puede incrementarse hasta hacerlo impracticable
• El modelo no se ha utilizado tanto como otros, por lo que tendrán que pasar años antes de que determine con certeza la eficacia de este modelo.

Modelo V

Ventajas:
• La relación entre las etapas de desarrollo y los distintos tipos de pruebas facilitan la localización de fallos
• Es un modelo sencillo y de fácil aprendizaje
• Hace explícito parte de la iteración y trabajo que hay que revisar
• Especifica bien los roles de los distintos tipos de pruebas a realizar
• Involucra al usuario en las pruebas

Desventajas:
• Es difícil que el cliente exponga explícitamente todos los requisitos
• El cliente debe tener paciencia pues obtendrá el producto al final del ciclo de vida
• Las pruebas pueden ser caras y, a veces, no lo suficientemente efectivas
• El producto final obtenido puede que no refleje todos los requisitos del usuario

Modelo prototipado  

Ventajas:
• Permite la construcción del sistema con requisitos poco claros o cambiantes
• El cliente recibe una versión del sistema en muy poco tiempo, por lo que lo puede evaluar, probar e, incluso, empezar a utilizarlo
• Se pueden introducir cambios en las funcionalidades del sistema en cualquier momento
• Involucra al usuario en la evaluación de la interfaz de usuario
• Se reduce el riesgo y la incertidumbre sobre el desarrollo
• Genera signos visibles de progreso, que se utilizan cuando existe una demanda en la velocidad del desarrollo
• Permite entender bien el problema antes de la implementación final

Desventajas:
• El cliente puede quedar convencido con las primeras versiones y, quizás, no vea la necesidad de completar el sistema o rediseñarlo con la calidad necesaria
• Requiere trabajo del cliente para evaluar los distintos prototipos y traducirlo en nuevos requisitos
• Requiere un tiempo adicional para definir adecuadamente el sistema
• No se sabe exactamente cuánto será el tiempo de desarrollo ni cuantos prototipos se tienen que desarrollar
• Si un prototipo fracasa, el coste del proyecto puede resultar muy caro