Modelos Tradicionales de Desarrollo

Los modelos tradicionales o predictivos de desarrollo de software organizan el ciclo de vida del proyecto de forma estructurada, fundamentándose en una planificación exhaustiva inicial, una fuerte documentación formal y una secuencia rigurosa de fases.

Aunque el auge de los marcos ágiles ha reducido su uso en aplicaciones web de consumo, los modelos tradicionales continúan siendo el estándar indispensable en sistemas críticos de alta seguridad (aeronáutica, dispositivos médicos, automoción y software nuclear).

1. El Modelo en Cascada (Waterfall) #

Propuesto originalmente por Winston Royce en 1970, es el modelo secuencial clásico:

1[ 1. Requisitos ] ──► Especificación de requisitos de software (SRS)
2            │
3            ▼
4    [ 2. Análisis & Diseño ] ──► Arquitectura, diagramas ER y UML
5            │
6            ▼
7    [ 3. Implementación ] ──► Codificación y programación
8            │
9            ▼
10    [ 4. Pruebas & Verificación ] ──► Testing integral del sistema
11            │
12            ▼
13    [ 5. Despliegue & Mantenimiento ] ──► Puesta en producción y soporte

• Principio rector: Cada fase debe completarse, revisarse y firmarse formalmente antes de comenzar la siguiente ("como el agua que desciende por una cascada y no puede volver a subir").
• Ventajas: Estructura clara y predecible; fácil de presupuestar para licitaciones públicas y contratos cerrados.
• Desventajas: Gran inflexibilidad frente a cambios; el cliente no ve software funcionando hasta los meses finales del proyecto, lo que dispara el riesgo de descubrir discrepancias de requisitos demasiado tarde.

2. El Modelo en V: Verificación y Validación #

El Modelo en V extiende la filosofía del modelo en cascada, estableciendo una correspondencia directa entre cada fase de diseño (lado izquierdo de la V) y su correspondiente nivel de pruebas (lado derecho de la V):

1FASE DE DISEÑO (Verificación)                             FASE DE TESTING (Validación)
2  ┌───────────────────────────┐                             ┌───────────────────────────┐
3  │ Requisitos de Usuario     │◄───────────────────────────►│ Pruebas de Aceptación     │
4  └─────────────┬─────────────┘                             └─────────────▲─────────────┘
5                ▼                                                         │
6  ┌───────────────────────────┐                             ┌─────────────┴─────────────┐
7  │ Diseño de la Arquitectura │◄───────────────────────────►│ Pruebas de Sistema & Carga│
8  └─────────────┬─────────────┘                             └─────────────▲─────────────┘
9                ▼                                                         │
10  ┌───────────────────────────┐                             ┌─────────────┴─────────────┐
11  │ Diseño Detallado Módulos  │◄───────────────────────────►│ Pruebas de Integración     │
12  └─────────────┬─────────────┘                             └─────────────▲─────────────┘
13                ▼                                                         │
14  ┌───────────────────────────┐                             ┌─────────────┴─────────────┐
15  │ Codificación del Software │────────────────────────────►│ Pruebas Unitarias         │
16  └───────────────────────────┘                             └───────────────────────────┘

• Verificación: "¿Estamos construyendo el producto correctamente?" (Revisar que el software cumpla la especificación técnica).
• Validación: "¿Estamos construyendo el producto correcto?" (Comprobar que el software satisfaga la necesidad real del usuario).
• Caso de uso óptimo: Dispositivos médicos implantables o aviónica, donde cada requisito debe contar con una prueba formal automatizada con trazabilidad del 100%.

3. El Modelo de Prototipado y el Modelo en Espiral #

Modelo de Prototipado #

Construye rápidamente versiones preliminares (Mockups interactivos o maquetas funcionales) para validar la interfaz y los requisitos con el cliente antes de acometer la arquitectura final:

• Prototipos Desechables (Throwaway): Se descartan tras validar la idea; el software final se programa desde cero con arquitectura limpia.
• Prototipos Evolutivos: El prototipo se refina y amplía incrementalmente hasta convertirse en el producto final.

Modelo en Espiral de Barry Boehm #

Combina la naturaleza iterativa del prototipado con los aspectos controlados de la cascada, incorporando el análisis formal de riesgos en cada ciclo de la espiral:

1. Determinación de objetivos y restricciones.
2. Análisis y resolución de riesgos técnicos.
3. Desarrollo y validación del incremento.
4. Planificación del siguiente ciclo con el cliente.

4. Cuadro Comparativo de Modelos Tradicionales #