Modelo en cascada
El modelo en cascada es un enfoque clásico de desarrollo de software que sigue una
secuencia lineal y rígida de etapas. A continuación, se complementa la información con
base en su metodología:
1. Origen y Contexto Histórico
Creador: Winston W. Royce (1970), aunque su artículo original mencionaba la necesidad de
iteraciones, la versión popularizada omitió este aspecto.
Estandarización: Adoptado por el Departamento de Defensa de [Link]. en 1985 (norma
DOD-STD-2167) para proyectos gubernamentales, lo que impulsó su uso masivo.
Crítica Temprana: Royce ya advirtió que el modelo puro (sin retroalimentación entre fases)
era riesgoso para proyectos complejos.
2. Fases del Modelo en Cascada
Cada fase debe completarse al 100% antes de pasar a la siguiente:
Análisis de Requisitos:
Objetivo: Entender las necesidades del usuario y definir qué debe hacer el software.
Actividades:
Entrevistas con stakeholders.
Documentación detallada de requisitos funcionales y no funcionales.
Estudio de viabilidad técnica y económica.
Diseño del Sistema:
Objetivo: Traducir requisitos en una estructura técnica.
Actividades:
Diseño de arquitectura (diagramas de componentes, flujo de datos).
Elección de tecnologías (lenguajes, bases de datos).
Planificación de interfaces de usuario.
Implementación (Codificación):
Objetivo: Programar el software según el diseño.
Actividades:
Desarrollo de módulos.
Integración de componentes.
Pruebas unitarias básicas.
Verificación (Pruebas):
Objetivo: Validar que el software cumple con los requisitos.
Actividades:
Pruebas de integración, rendimiento y usabilidad.
Corrección de errores (bugs).
Entrega al cliente para validación final.
Mantenimiento:
Objetivo: Garantizar el funcionamiento continuo y adaptar el software a cambios.
Tipos de Mantenimiento:
Correctivo: Arreglar fallos no detectados en pruebas.
Evolutivo: Añadir nuevas funcionalidades.
Preventivo: Optimizar el código para evitar futuros errores.
3. Características Clave
Linealidad Estricta: No hay vuelta atrás. Si se detecta un error en una fase avanzada, es
costoso corregirlo.
Documentación Exhaustiva: Cada fase genera documentos detallados (ej. especificaciones
de requisitos, diagramas de diseño).
Roles Definidos: Cada fase es responsabilidad de un equipo específico (analistas,
diseñadores, programadores, testers).
4. Ventajas
Predictibilidad: Permite estimar costos y plazos desde el inicio.
Claridad en Procesos: Ideal para proyectos con requisitos estables y bien entendidos.
Facilidad de Gestión: Al dividirse en etapas, es sencillo medir el progreso.
5. Desventajas
Inflexibilidad: Los cambios en requisitos o errores tardíos son difíciles de gestionar.
Retrasos en Detección de Errores: Las pruebas ocurren al final, lo que aumenta costos de
corrección.
Poca Participación del Usuario: El cliente solo interviene al inicio (análisis) y al final
(entrega).
6. ¿Dónde se Usa Hoy?
Aunque criticado, sigue siendo relevante en:
Proyectos Pequeños o Medianos: Con requisitos claros y estables (ej. sistemas de nómina).
Industrias Reguladas: Medicina, aeronáutica o gobierno, donde la documentación es
obligatoria.
Contratos con Entregables Definidos: Cuando el cliente exige un plan detallado antes de
iniciar.
8. Reflexión Crítica
¿Por qué se sigue usando?: Su estructura es intuitiva para equipos tradicionales y clientes
que prefieren planes fijos.
Lecciones de Royce: En su artículo original, Royce proponía iteraciones entre fases, pero
esto se ignoró en la implementación popular.
Ejemplo Práctico:
Si construyes una casa, el modelo en cascada sería como definir todos los planos antes de
colocar un ladrillo. Si decides añadir una habitación después de empezar la construcción,
sería muy costoso.
Video de donde salió la información: [Link]
si=0_cpz8eommUbM4ol
Apóyate del video para las diapositivas
