Modelos de Ciclo de Vida del Software

Definición: Un ciclo de vida del software es el conjunto de fases, actividades y tareas que se llevan a cabo desde la concepción de un sistema software hasta su retirada. Define cómo se organiza y gestiona el desarrollo.

Tabla Resumen

Modelo	Idea básica	Ventajas	Inconvenientes	Cuándo se usa
Cascada	Fases secuenciales: requisitos → análisis → diseño → implementación → pruebas → mantenimiento	Simple, ordenado, fácil de documentar	Muy rígido, difícil volver atrás, mala adaptación a cambios	Proyectos con requisitos muy claros y estables
En V	Variante del cascada donde cada fase de desarrollo se asocia a una fase de prueba	Mucho control y verificación, buen enfoque de calidad	Sigue siendo rígido, poco flexible ante cambios	Sistemas críticos, entornos muy regulados
Prototipos	Se crean versiones preliminares para refinar requisitos con el usuario	Ayuda a entender necesidades, mejora la comunicación	Puede generar expectativas irreales, riesgo de mala estructura	Cuando los requisitos no están claros al inicio
Incremental	El sistema se desarrolla en partes funcionales entregadas progresivamente	Entregas parciales útiles, permite priorizar, facilita cambios	Requiere buena planificación de incrementos	Cuando se quiere entregar valor pronto
Iterativo	El sistema se va refinando en ciclos sucesivos	Permite mejorar progresivamente, detectar errores antes	Puede ser más complejo de gestionar	Proyectos donde se aprende durante el desarrollo
Espiral	Combina iteración con análisis de riesgos en cada vuelta	Muy útil para proyectos complejos y con riesgo	Costoso, complejo, exige experiencia	Grandes proyectos con incertidumbre o alto riesgo
RAD	Desarrollo rápido con reutilización y herramientas CASE	Rapidez de construcción, fuerte orientación al usuario	No apto para proyectos muy grandes o complejos	Aplicaciones de gestión con plazos cortos
Ágil	Iterativo e incremental con entregas frecuentes y adaptación al cambio	Flexible, feedback continuo, valor temprano	Requiere mucha implicación del cliente	Entornos cambiantes, requisitos evolutivos

Clasificación por Tipo

MODELOS CLÁSICOS (secuenciales)
├── Cascada
└── En V

MODELOS EVOLUTIVOS (iterativos/incrementales)
├── Prototipos
├── Incremental
├── Iterativo
└── Espiral

MODELOS ÁGILES / RÁPIDOS
├── RAD
└── Ágil (Scrum, XP, Kanban...)

Modelos Clásicos

Cascada (Waterfall)

Requisitos → Análisis → Diseño → Implementación → Pruebas → Mantenimiento

Origen: Royce (1970)
Las fases son estrictamente secuenciales: no se pasa a la siguiente hasta completar la anterior
Toda la documentación queda muy bien definida
⚠️ Problema clave: Si se detecta un error en pruebas, hay que retroceder varias fases, lo que resulta muy costoso

Modelo en V

Requisitos del sistema ──────────────────► Pruebas de aceptación
  Requisitos software ──────────────────► Pruebas de sistema
    Diseño arquitectónico ──────────────► Pruebas de integración
      Diseño detallado ────────────────► Pruebas unitarias
                     IMPLEMENTACIÓN

Cada fase de desarrollo tiene su correspondiente fase de verificación/validación
Enfatiza la trazabilidad entre especificación y pruebas
Muy usado en sistemas safety-critical: aeronáutica, médico, defensa

Modelos Evolutivos

Prototipos

Requisitos incompletos
        ↓
   [Prototipo rápido]
        ↓
   Evaluación usuario  ←──── ciclo hasta que
        ↓                    el usuario aprueba
   Refinar prototipo
        ↓
Sistema final (rediseñado)

Existen dos variantes:
Prototipo desechable: se tira tras definir requisitos
Prototipo evolutivo: el prototipo se convierte en el producto final
⚠️ Riesgo de "Frankenstein": que el prototipo acabe siendo el producto sin rediseño

Incremental

Versión 1: [Núcleo básico]
Versión 2: [Núcleo básico + Módulo A]
Versión 3: [Núcleo básico + Módulo A + Módulo B]
...
Versión N: [Sistema completo]

El sistema se descompone en incrementos (subsistemas funcionales)
Cada incremento añade funcionalidad sobre el anterior
Los primeros incrementos incluyen la funcionalidad más crítica o de mayor valor

Iterativo

Iteración 1: requisitos → diseño → impl → pruebas  → v1 (parcial)
Iteración 2: requisitos → diseño → impl → pruebas  → v2 (mejorada)
...
Iteración N: ...  → vN (sistema completo y refinado)

Diferencia con incremental: en el iterativo se trabaja sobre el sistema completo pero mejorándolo ciclo a ciclo; en el incremental se añaden partes nuevas
En la práctica, muchos modelos combinan ambos enfoques

Espiral (Boehm, 1988)

Cada ciclo de la espiral tiene 4 cuadrantes:

         PLANIFICACIÓN
        /              \
       /                \
ANÁLISIS DE   ←→   DESARROLLO Y
  RIESGOS            VALIDACIÓN
       \                /
        \              /
         EVALUACIÓN CLIENTE

Planificación: objetivos, restricciones, alternativas
Análisis de riesgos: identificar y resolver los riesgos más críticos
Desarrollo y validación: construir y probar el producto
Evaluación del cliente: el cliente evalúa y se planifica el siguiente ciclo

⚠️ La gestión de riesgos es el eje central del modelo
Cada vuelta de la espiral produce un producto más completo

Modelos Ágiles / Rápidos

RAD (Rapid Application Development)

Modelado de negocio → Modelado de datos → Modelado de procesos
        ↓
  Generación de aplicación (herramientas CASE, componentes reutilizables)
        ↓
  Pruebas y entrega (ciclo muy corto: 60-90 días)

Hace uso intensivo de herramientas CASE y reutilización de componentes
Orientado a sistemas de información y aplicaciones de gestión
⚠️ No es adecuado cuando la aplicación no puede ser modularizada o requiere alto rendimiento

Ágil

No es un modelo único sino una familia de metodologías basadas en el Manifiesto Ágil (2001)
Metodologías principales: Scrum, XP (Extreme Programming), Kanban, SAFe

Valores del Manifiesto Ágil:

Se valora más...	...que
Individuos e interacciones	Procesos y herramientas
Software funcionando	Documentación exhaustiva
Colaboración con el cliente	Negociación de contratos
Respuesta ante el cambio	Seguir un plan

Ciclo Scrum (ejemplo):

Product Backlog → Sprint Planning → [Sprint 1-4 semanas] → Incremento entregable
                        ↑                                          ↓
                        └──────────── Sprint Retrospective ────────┘

⚠️ Requiere alta implicación del cliente y equipo con buena comunicación

Comparativa: Rígidos vs Evolutivos vs Ágiles

Criterio	Cascada / En V	Espiral / Iterativo	Ágil / RAD
Requisitos	Fijos desde el inicio	Pueden evolucionar	Cambian continuamente
Entregas	Una al final	Varias progresivas	Frecuentes (sprints)
Documentación	Muy extensa	Media	Ligera
Gestión del riesgo	Baja	Alta (Espiral)	Media-Alta
Participación cliente	Al inicio y al final	En cada iteración	Continua
Tamaño proyecto	Medio-Grande	Grande	Pequeño-Mediano
Coste del cambio	⚠️ Muy alto	Medio	Bajo

⚠️ Conceptos Clave para el Examen

Verificación: ¿Estamos construyendo el producto correctamente? (cumple especificaciones)
Validación: ¿Estamos construyendo el producto correcto? (satisface necesidades del usuario)
Hito: Punto de control al final de cada fase que determina si se puede continuar
Baseline: Conjunto de productos de trabajo aprobados en un hito que sirve de base para fases posteriores
Herramientas CASE: Computer-Aided Software Engineering — apoyan el desarrollo automatizando tareas

Resumen en 3 Puntos

1. Modelos clásicos (Cascada, En V): Secuenciales y rígidos. Aptos solo cuando los requisitos están completamente definidos desde el inicio. El Modelo en V añade verificación sistemática en cada fase.

2. Modelos evolutivos (Prototipos, Incremental, Iterativo, Espiral): Permiten adaptarse al cambio construyendo el sistema de forma progresiva. El modelo en Espiral es el más robusto para proyectos con alto riesgo, ya que incorpora análisis de riesgos en cada ciclo.

3. Modelos ágiles/rápidos (RAD, Ágil): Priorizan la entrega de valor de forma continua y la colaboración con el cliente. Son los más extendidos actualmente en proyectos con requisitos cambiantes, aunque exigen alta implicación del equipo y del cliente.