Se puede definir el ciclo de vida de un proyecto (ciclo de vida del software) como: conjunto de fases o etapas, procesos y actividades requeridas para ofertar, desarrollar, probar, integrar, explotar y mantener un producto software.
Al principio, el desarrollo de una aplicación era un proceso individualizado, carente de planificación donde únicamente se hacía una codificación y prueba/depuración del código a desarrollar. Pero pronto se detectaron muchos inconvenientes:
- Dependencia total de la persona que programó.
- Se desconoce el progreso y la calidad del proyecto.
- Falta de flexibilidad ante cambios.
- Posible incremento del coste o incluso imposibilidad de completarlo.
- Puede no reflejar las necesidades del cliente.
De ahí surgió la necesidad de hacer desarrollos más estructurados, aportando valor añadido y calidad al producto final, apareciendo el concepto de ciclo de vida del software.
Algunas ventajas que se consiguen son:
- En las primeras fases, aunque no haya líneas de código, invertir en pensar el diseño es avanzar en la construcción del sistema, pues facilitará la codificación.
- Asegura un desarrollo progresivo, con controles sistemáticos, que permite detectar defectos con mucha antelación.
- El seguimiento del proceso permite controlar los plazos de entrega retrasados y los costes excesivos.
- La documentación se realiza de manera formal y estandarizada simultáneamente al desarrollo, lo que facilita la comunicación interna entre el equipo de desarrollo y la de éste con los usuarios.
- Aumenta la visibilidad y la posibilidad de control para la gestión del proyecto.
- Supone una guía para el personal de desarrollo, marcando las tareas a realizar en cada momento.
- Minimiza la necesidad de rehacer trabajo y los problemas de puesta a punto.
Diversos autores han planteado distintos modelos de ciclos de vida, pero los más conocidos y utilizados son los citados a continuación:
- Modelo en Cascada
Es el modelo de vida clásico del software.
Se pasa de unas etapas a otras sin retorno posible, cualquier error en las fases iniciales ya no será subsanable aunque sea detectado más adelante.
Este escaso margen de error lo hace prácticamente imposible de utilizar. Sólo es aplicable en pequeños desarrollos.
Todos los requisitos son planteados para hacer un único recorrido del proyecto.
Características:
-Requiere conocimiento previo y absoluto de los requerimientos del sistema.
-No hay retornos en las etapas: si hay algún error durante el proceso hay que empezar desde el principio.
-No permite modificaciones ni actualizaciones del software.
-Es un modelo utópico.
- Modelo en Cascada con Realimentación
Es uno de los modelos más utilizados. Proviene del modelo anterior, pero se introduce una realimentación entre etapas, de forma que podamos volver atrás en cualquier momento para corregir, modificar o depurar algún aspecto. No obstante, si se prevén muchos cambios durante el desarrollo no es el modelo más idóneo.
Es el modelo perfecto si el proyecto es rígido (pocos cambios, poco evolutivo) y los requisitos están claros.
Características:
-Es uno de los modelos más utilizados.
-Se puede retornar a etapas anteriores para introducir modificaciones o depurar errores.
-Idóneo para proyectos más o menos rígidos y con requisitos claros.
-Los errores detectados una vez concluido el proyecto pueden provocar que haya que empezar desde cero.
- Modelos Evolutivos
Son más modernos que los anteriores. Tienen en cuenta la naturaleza cambiante y evolutiva del software.
Distinguimos dos variantes:
- Modelo Iterativo Incremental
Está basado en el modelo en cascada con realimentación, donde las fases se repiten y refinan, y van propagando su mejora a las fases siguientes.
Cada iteración cubre una parte de los requisitos requeridos, generando versiones parciales y crecientes para el producto software en desarrollo. Cada versión obtenida será el punto de partida para la siguiente iteración.
Los incrementos a considerar en cada vuelta ya vienen establecidos desde las etapas iniciales.Características:
-Actualmente, no se ponen en el mercado los productos completos, sino versiones.
-Permite una evolución temporal.
-Vemos que se trata de varios ciclos en cascada que se repiten y se refinan en cada incremento.
-Las sucesivas versiones del producto son cada vez más completas hasta llegar al producto final.
- Modelo en Espiral
Es una combinación del modelo anterior con el modelo en cascada. En él, el software se va construyendo repetidamente en forma de versiones que son cada vez mejores, debido a que incrementan la funcionalidad en cada versión. Es un modelo bastante complejo.
Características:
-Se divide en 6 zonas llamadas regiones de tareas: Comunicación con el cliente, Planificación, Análisis de riesgos, Representación de la aplicación, Codificación y explotación y Evaluación del cliente.
-Se adapta completamente a la naturaleza evolutiva del software.
-Reduce los riesgos antes de que sean problemáticos.
3.3.- Modelos ágiles
Se trata de modelos que están ganando gran presencia en los desarrollos software. Muy centrados en la satisfacción del cliente, muestran gran flexibilidad a la aparición de nuevos requisitos, incluso durante el desarrollo de la aplicación. Al tratarse de metodologías evolutivas, el desarrollo es incremental, peros incrementos son cortos y están abiertos al solapado de unas fases con otras. La comunicación entre los integrantes del equipo de trabajo y de éstos con el cliente son constantes. Un ejemplo de metodología ágil es Scrum.
- Modelo Iterativo Incremental