Análisis comparativo de los ciclos de vida del software

Para empezar, primero veamos la definición de un "modelo de ciclo de vida" según la ISO 12207-1:

“Es un marco de referencia que contiene los procesos, las actividades y las tareas involucradas en el desarrollo, la explotación y el mantenimiento de un producto de software, abarcando la vida del sistema desde la definición de los requisitos hasta la finalización de su uso”

Ahora bien, existen distintos tipos de modelo de ciclos de vida: cascada, en V, iterativo, incremental, en espiral, de prototipos, entre otros. 

Las principales diferencias entre distintos modelos de ciclo de vida están en:

• El alcance del ciclo dependiendo de hasta dónde llegue el proyecto correspondiente. Un proyecto puede comprender un simple estudio de viabilidad del desarrollo de un producto, o su desarrollo completo o en el extremo, toda la historia del producto con su desarrollo, fabricación y modificaciones posteriores hasta su retirada del mercado.

• Las características (contenidos) de las fases en que dividen el ciclo. Esto puede depender del propio tema al que se refiere el proyecto, o de la organización.

• La estructura y la sucesión de las etapas, si hay realimentación entre ellas, y si tenemos libertad de repetirlas (iterar).

Pero ahora vamos a tratar de describir y comparar brevemente cada uno de ellos, para así tener una mejor comprensión de estos ciclos de vida:

Modelo en cascada

Este modelo es un proceso de desarrollo estrictamente secuencial, es decir que el desarrollo se ve fluyendo hacia abajo sobre las fases que componen el ciclo de vida. Ahora bien, esto nos deja claro algunas cosas:

• Puede parecernos un modelo en el que todo está bien organizado, de apariencia simple y fácil de usar, pero en la vida real un proyecto rara vez sigue una secuencia lineal, lo cual hace que no sea práctico en la mayoría de los casos.
• Para que este modelo funcione adecuadamente, el cliente debe establecer al principio absolutamente todos los requisitos necesarios, de manera que mientras no se tenga todo establecido se provoca un gran atraso (innecesario en el caso de otros ciclos de vida).
• Los resultados se presentan de golpe ya que sólo son visibles cuando el producto está finalizado en su totalidad. Esto provoca una gran inseguridad por parte del cliente, el cual probablemente preferiría ir viendo los avances del producto en el transcurso de su desarrollo.
• Es un modelo pobre para proyectos complejos, largos, orientados a objetos y además genera grandes cantidades de riesgos e incertidumbres.

Modelo iterativo

Este es un modelo derivado del ciclo de vida en cascada. Entre algunos aspectos a considerar tenemos:

• Busca reducir el riesgo que surge durante la etapa de recogida de requisitos, por ello consiste en la iteración de varios ciclos de vida en cascada. Así que no hace falta que los requisitos estén totalmente definidos al inicio del desarrollo (uno de los grandes problemas del ciclo de vida en cascada), sino que se pueden ir refinando en cada iteración.
• Tiene la ventaja de gestionar mejor los riesgos y las entregas (entre otras cosas), ya que realiza el desarrollo en pequeños ciclos.
• Un inconveniente podría ser que surgieran problemas con la arquitectura si no se definen los requisitos necesarios desde el principio.
• La creación y entrega de prototipos es algo que ayuda bastante a conseguir la conformidad del cliente.

Modelo de desarrollo incremental

Este modelo combina elementos del ciclo de vida en cascada con la construcción de prototipos (algo similar al modelo iterativo). Aplica secuencias lineales de forma escalonada mientras en cada una de ellas produce un incremento del software. Entonces podemos decir que:

• Es un modelo más flexible que los anteriores, ya que se reduce el coste en el cambio de alcance y requisitos.
• Al igual que el anterior, es más fácil de gestionar riesgos y probar/depurar en una iteración más pequeña.
• Podrían surgir problemas con la arquitectura justamente por el mismo factor del anterior ciclo de vida: no todos los requisitos se reúnen al inicio.
• Cada fase es una iteración rígida y no se superponen con otras.
• Los errores en los requisitos se detectan tarde.

Modelo en V

Este modelo es un proceso que representa la secuencia de pasos en el desarrollo del ciclo de vida de un proyecto. 

• Su diferencia con el ciclo de vida en cascada es que éste, en lugar de ir de forma lineal (hacia abajo), las fases del proceso vuelven hacia arriba tras la fase de codificación, formando una V (de ahí el nombre).
• En cada fase hay entregables específicos.
• Suele funcionar bien en proyectos pequeños donde los requisitos son entendidos sin complicaciones.
• Tiene poca flexibilidad y ajustar el alcance es difícil y caro.
• No se producen prototipos del software, ya que éste se desarrolla únicamente en la fase de implementación.

Modelo de prototipos

Una vez se hace la recolección de requisitos, el desarrollador y el cliente encuentran y definen los objetivos globales para el software para que luego haga su aparición un diseño rápido que lleve a la construcción de un prototipo. Luego el cliente evalúa dicho prototipo, de manera que la iteración ocurre cuando el prototipo se pone a punto para satisfacer las necesidades del cliente.

• Al estar esperando la aprobación del cliente prototipo tras prototipo, hace que trabajar con este modelo de ciclo de vida sea un desarrollo lento.
• Reduce el riesgo de construir productos que no satisfagan las necesidades de los usuarios.
• El cliente reacciona mejor ante prototipos en los que puede experimentar.
• Permite introducir cambios en las iteraciones siguientes de cada ciclo.
• No presenta calidad ni robustez.

Modelo en espiral

Este modelo de desarrollo combina las características del modelo de prototipos y el modelo en cascada. Si bien, esto modelo no fue el primero en tratar el desarrollo iterativo, fue el primero en explicar las iteraciones.

• Este modelo está pensado para proyectos largos, caros y complicados.
• Trata de mejorar los ciclos de vida clásicos y prototipos.
• Al ser un modelo de ciclo de vida orientado a la gestión de riesgos se dice que uno de los aspectos fundamentales de su éxito radica en que el equipo que lo aplique tenga la necesaria experiencia y habilidad para detectar y catalogar correctamente los riesgos.
• Eliminar errores y alternativas no atractivas al comienzo.
• Permite iteraciones, vuelta atrás y finalizaciones rápidas.
• Al dividir el proyecto en ciclos, al final de cada uno existe un acuerdo para los cambios que hay que realizar en el sistema.
• Este modelo se adapta a cualquier tipo de actividad adicional.