El modelo en cascada (waterfall) es un modelo de proceso secuencial que divide un proyecto en fases consecutivas, desde los requisitos hasta la operación. Cada fase empieza solo cuando la anterior ha entregado su resultado. Winston W. Royce describió esta secuencia en siete pasos en la conferencia IEEE WESCON de 1970 y él mismo calificó de arriesgada su forma pura.
¿Qué es el modelo en cascada?
El modelo en cascada es un modelo de proceso lineal en el que un proyecto recorre sus fases una sola vez y en un orden fijo. El resultado de una fase es la entrada de la siguiente. En un diagrama de Gantt esto forma la escalera típica que da nombre al modelo.
Cuatro elementos convierten un proyecto en un modelo en cascada:
- Fases con inicio y fin claros, por ejemplo diseño o pruebas.
- Entregables de cada fase, como la especificación de requisitos, la especificación de diseño o el informe de pruebas.
- Hitos al final de cada fase, en los que el cliente o la dirección del proyecto aprueban el resultado. Más información en la entrada del glosario sobre hitos en la gestión de proyectos.
- Dependencias final a inicio entre fases: la fase 2 empieza cuando termina la fase 1.
¿De dónde viene la metodología en cascada?
La metodología en cascada procede de la ingeniería de software. Winston W. Royce la presentó en 1970 en su artículo Managing the Development of Large Software Systems (Proceedings IEEE WESCON, agosto de 1970, páginas 1 a 9). Su figura 2 muestra siete pasos: requisitos del sistema, requisitos del software, análisis, diseño del programa, codificación, pruebas y operación.
Royce consideraba peligrosa esta secuencia pura. Justo debajo de la figura escribió: «I believe in this concept, but the implementation described above is risky and invites failure» (creo en este concepto, pero la implementación descrita es arriesgada e invita al fracaso). Su argumento: las pruebas al final son el primer momento en que el sistema se comporta de verdad. Si ahí aparece un fallo de diseño, el proyecto vuelve al principio, y Royce calcula entonces hasta un 100 por ciento de desviación en plazo o costes.
Como remedio recomendó cinco añadidos: diseñar el programa primero, documentar el diseño, hacerlo dos veces (primero como piloto), planificar y supervisar las pruebas, e implicar formalmente al cliente. Royce nunca usa la palabra «cascada». Según lo que se sabe hoy, aparece por primera vez en 1976 en un artículo de Thomas E. Bell y T. A. Thayer en la 2.ª International Conference on Software Engineering, que cita a Royce.
¿Cuáles son las fases del modelo en cascada?
En la práctica, el modelo en cascada suele tener seis fases: requisitos, diseño, implementación, pruebas, puesta en marcha y mantenimiento. Royce distinguía siete pasos; los manuales suelen unir los requisitos del sistema y los del software. Lo decisivo es el entregable de cada fase.
| Fase | Entregable | Hito al final de la fase |
|---|---|---|
| 1 Requisitos | Especificación de requisitos: ¿qué debe hacer el sistema? | Requisitos aprobados |
| 2 Diseño | Especificación de diseño y arquitectura: ¿cómo se construye? | Diseño aprobado |
| 3 Implementación | Sistema completo y funcional | Congelación del código |
| 4 Pruebas | Informe de pruebas, errores corregidos | Aceptación concedida |
| 5 Puesta en marcha | Sistema instalado, usuarios formados | Puesta en producción |
| 6 Mantenimiento | Corrección de errores y actualizaciones | Fin del contrato o sustitución |
¿Cómo es un proyecto en cascada? Un ejemplo
Una empresa de software desarrolla para una promotora inmobiliaria un portal de clientes, en el que los compradores consultan acabados y fechas de obra. La promotora paga un precio cerrado y los requisitos quedan fijados antes de firmar el contrato. El proyecto dura 18 semanas hasta la puesta en producción.
Portal de clientes como proyecto en cascada
Seis fases, cinco hitos, todas las fases vinculadas final a inicio
Tres cifras del ejemplo muestran cómo calcula el modelo:
- Retraso: si la promotora aprueba los requisitos una semana tarde, la puesta en producción pasa de la semana 18 a la 19. Todas las fases están en la ruta crítica, así que cualquier retraso mueve la fecha final.
- Peso de las fases: la implementación ocupa 8 de 18 semanas (44 por ciento); las pruebas, solo 3 semanas (17 por ciento).
- Retroceso: si las pruebas de la semana 15 revelan un fallo de diseño, el equipo repite diseño (3 semanas), implementación (8 semanas) y pruebas (3 semanas). Son 14 semanas; la puesta en producción pasa de la semana 18 a la 32, es decir, un 78 por ciento más tarde. Ese es exactamente el riesgo del que advertía Royce.
¿Existe una plantilla para un proyecto en cascada?
Sí. Para Merlin Project hay dos plantillas gratuitas que reflejan un proyecto por fases con hitos. La plantilla Desarrollo de software divide un desarrollo en fases de evaluación, concepción, especificación, desarrollo, pruebas y entrega; hitos de decisión como «Especificación terminada» separan las fases. La plantilla Hogar unifamiliar aplica la misma lógica a un cronograma de obra, desde el anteproyecto hasta la estructura.
Plantilla en cascada para Merlin Project
La plantilla contiene las fases típicas de un proyecto de desarrollo con hitos entre ellas. Descargue el archivo, borre las fases que no necesite y añada sus actividades. La plantilla está disponible en español, inglés, alemán y francés.
Abrir la plantilla Desarrollo de software
¿Empieza sin Merlin Project? Copie la estructura del ejemplo como tabla. Cada fila es una actividad o un hito, y la columna «Predecesora» define la dependencia final a inicio:
| N.º | Actividad | Tipo | Duración | Predecesora |
|---|---|---|---|---|
| 1 | Recoger requisitos | Actividad | 3 semanas | ninguna |
| 2 | Requisitos aprobados | Hito | 0 | 1 |
| 3 | Diseño y especificación | Actividad | 3 semanas | 2 |
| 4 | Diseño aprobado | Hito | 0 | 3 |
| 5 | Implementación | Actividad | 8 semanas | 4 |
| 6 | Congelación del código | Hito | 0 | 5 |
| 7 | Pruebas de sistema y aceptación | Actividad | 3 semanas | 6 |
| 8 | Aceptación concedida | Hito | 0 | 7 |
| 9 | Puesta en marcha y formación | Actividad | 1 semana | 8 |
| 10 | Puesta en producción | Hito | 0 | 9 |
| 11 | Mantenimiento | Actividad | continuo | 10 |
¿Cuándo conviene la metodología en cascada y cuándo no?
La metodología en cascada conviene cuando los requisitos están fijados antes del inicio y apenas cambian durante la ejecución. Casos típicos son la construcción, los proyectos con licencias administrativas y los contratos a precio cerrado. En una casa, el tejado va después de los muros porque la estructura no admite otro orden.
La cascada encaja cuando
- cliente y equipo pueden fijar por escrito los requisitos antes de empezar,
- las autoridades, los auditores o el contrato exigen aprobaciones en puntos fijos,
- se ha pactado un precio cerrado o una fecha fija,
- las dependencias físicas imponen el orden (primero cimientos, luego muros).
La cascada no encaja cuando
- los requisitos surgen de la opinión de los usuarios,
- el equipo debe mostrar pronto una versión intermedia que funcione,
- el mercado o la tecnología cambian durante el proyecto,
- una prueba tardía obliga a un retroceso caro, como en el ejemplo.
Cascada, ágil o híbrido: ¿cuál es la diferencia?
La cascada planifica todo el proyecto por adelantado y entrega al final; los métodos ágiles como Scrum planifican en ciclos cortos y entregan un resultado utilizable tras cada ciclo. La gestión híbrida combina ambos: fases e hitos como marco, trabajo ágil dentro de una fase.
| Criterio | Cascada | Ágil (p. ej. Scrum) | Híbrido |
|---|---|---|---|
| Planificación | Todo el proyecto antes de empezar | Por sprint, un mes como máximo | Fases al inicio, tareas por fase |
| Cambios | Mediante solicitud formal | En cualquier momento vía backlog | Dentro de la fase |
| Participación del cliente | En los hitos | En cada revisión del sprint | En hitos y revisiones |
| Entrega | Una vez al final | Tras cada sprint | Por fase o versión |
| Vista típica | Diagrama de Gantt | Tablero Kanban | Gantt y Kanban vinculados |
Cómo montan los equipos esta combinación lo explica el artículo sobre la gestión de proyectos híbrida.
Cómo planificar un proyecto en cascada en Merlin Project
Merlin Project refleja la estructura en cascada en la vista División del trabajo: el esquema a la izquierda, el diagrama de Gantt a la derecha. Para reproducir el ejemplo:
- Abra Visualización > División del trabajo > Entrada y cree cada fase como grupo. Con Ctrl+Cmd+→ aumenta la sangría de las actividades bajo su fase.
- Añada un hito al final de cada fase con Insertar > Hito (Cmd+Alt+M). En el diagrama de Gantt aparece como un rombo.
- Seleccione fases e hitos en su orden y elija Estructura > Vincular > Final - Inicio (Ctrl+Cmd+L). Merlin Project vincula la selección una tras otra.
- Active Visualización > Mostrar ruta crítica para resaltar la cadena que fija la puesta en producción.
- El día de la aprobación, introduzca esa fecha en el campo Fecha de referencia de los ajustes del proyecto. Desde entonces, la vista Comparación planificado/real (tiempo) muestra cada desviación frente a esta línea base.
Fases e hitos en la División del trabajo
El ejemplo de la documentación de Merlin muestra una mudanza de oficina en tres fases. Tras cada grupo hay un hito y las flechas del diagrama de Gantt muestran las dependencias final a inicio.
Línea base sin pasos extra
Merlin Project guarda todo el historial del proyecto en el documento. Por eso no tiene que guardar una línea base a mano: basta una fecha en el campo Fecha de referencia, y unas barras de referencia grises muestran el periodo planificado en ese momento. Más detalles en la lección sobre la comparación planificado/real.
En la fase de implementación compensa la vía híbrida. Pulse F2 para mostrar la vista de detalles y elija allí el tablero Kanban. Si selecciona la fase arriba, el tablero de abajo muestra solo sus actividades. Arrastre una tarjeta de «Tareas pendientes» a «Listo» y Merlin Project fija el progreso de la actividad en el 100 por ciento; la barra del diagrama de Gantt lo refleja al instante.
Cascada arriba, Kanban abajo
Arriba está el plan de fases con hitos; abajo, el tablero Kanban de la fase seleccionada. Ambas vistas muestran las mismas actividades y cada cambio aparece de inmediato en las dos.
Si tiene alguna pregunta sobre este artículo del blog o desea debatirlo, esperamos su contribución en nuestro foro.
Preguntas frecuentes
¿Cuál es un ejemplo del modelo en cascada?
Un portal de clientes con requisitos fijos: requisitos (3 semanas), diseño (3 semanas), implementación (8 semanas), pruebas (3 semanas) y puesta en marcha (1 semana) se suceden una tras otra. Cada fase termina con un hito como «Requisitos aprobados». La puesta en producción llega tras 18 semanas. La construcción de una vivienda unifamiliar sigue la misma lógica.
¿Cuáles son las etapas del modelo en cascada?
En la práctica suelen ser seis: requisitos, diseño, implementación, pruebas, puesta en marcha y mantenimiento. Winston W. Royce enumeró siete pasos en 1970 porque separaba los requisitos del sistema y los del software. Cada fase entrega un resultado verificable, como la especificación de requisitos o el informe de pruebas.
¿Cuáles son las desventajas del modelo en cascada?
Los errores de diseño aparecen tarde, en la fase de pruebas, y obligan a repetir fases enteras. Los cambios de requisitos exigen una solicitud formal y el cliente ve el producto solo al final. En el ejemplo del artículo, un retroceso al diseño retrasa la entrega 14 semanas, un 78 por ciento.
¿Existe una plantilla gratuita de metodología waterfall?
Sí. La plantilla «Desarrollo de software» para Merlin Project contiene fases con hitos de decisión, y la plantilla «Hogar unifamiliar», un cronograma de obra por fases. Ambas se descargan gratis en la sección de plantillas. Merlin Project se puede probar 30 días gratis.
¿Quién creó el modelo en cascada?
La secuencia se remonta a Winston W. Royce, que la describió en 1970 en «Managing the Development of Large Software Systems». El propio Royce calificó de arriesgada la forma pura y recomendó retroalimentación y una ejecución piloto. El nombre «cascada» lo usaron primero Thomas E. Bell y T. A. Thayer en 1976.
¿Es ágil el modelo en cascada?
No. El modelo en cascada planifica todo el proyecto antes de empezar y entrega una sola vez al final. Los métodos ágiles como Scrum planifican en sprints de un mes como máximo (Scrum Guide 2020) y entregan tras cada sprint. Los enfoques híbridos usan las fases en cascada como marco y trabajan de forma ágil dentro de cada fase.
