Cuando empiezas a preparar un proyecto serio, una de las primeras decisiones clave es elegir la metodología de gestión que vas a seguir. No es un detalle menor: de esa elección dependen la planificación, la forma de trabajar con el cliente, la documentación, los plazos y hasta el tipo de errores que vas a sufrir a mitad de camino.
Dentro de ese abanico, la metodología Waterfall o en cascada sigue siendo una de las más conocidas. Aunque se hable mucho de Agile, Scrum o Kanban, la cascada continúa muy viva en sectores donde la estabilidad, la previsibilidad y la documentación exhaustiva son más importantes que la flexibilidad absoluta. En esta guía completa te explico, paso a paso, qué es Waterfall, de dónde viene, cómo se estructura, cuándo tiene sentido usarla, en qué se diferencia de Agile y cómo encaja hoy en la gestión moderna de proyectos.
Qué es la metodología Waterfall o en cascada
La metodología Waterfall es un modelo de desarrollo lineal y secuencial en el que un proyecto avanza fase a fase, sin retrocesos sistemáticos. El nombre de “cascada” viene precisamente de esa imagen: cada etapa vierte sus resultados sobre la siguiente, como el agua que cae de un escalón a otro, y una vez se ha bajado un peldaño resulta muy difícil volver a subir.
En la práctica, esto significa que el ciclo de vida del proyecto se recorre una sola vez de principio a fin: primero se recogen todos los requisitos, después se diseña la solución, luego se implementa, se verifica y finalmente se pone en servicio y se mantiene. Cada fase debe quedar completamente cerrada y aprobada antes de iniciar la siguiente, con entregables formales y criterios de salida bien definidos.
Este enfoque parte de una premisa muy clara: los requisitos del proyecto se pueden conocer y documentar por adelantado con suficiente precisión como para convertirlos en una “línea base” relativamente inamovible. Esa línea base guía todo el diseño, el desarrollo y la verificación, y cualquier modificación posterior se trata como un cambio excepcional, costoso y sujeto a control formal.
Origen y evolución del modelo Waterfall
La idea de organizar el trabajo en fases secuenciales no nació en el software. Procede de sectores tradicionales de ingeniería como la construcción, la obra civil o la industria pesada, donde iterar sobre el producto terminado puede ser directamente inviable o peligrosísimo. Si levantas un puente o una presa, necesitas tener clarísimo qué vas a hacer antes de poner el primer ladrillo.
En el ámbito del desarrollo de software, uno de los antecedentes se remonta a junio de 1956, cuando Herbert D. Benington presentó un modelo de fases para grandes sistemas. Sin embargo, la descripción que se considera clásica del modelo en cascada se atribuye a Winston W. Royce en un artículo de 1970 sobre la gestión de grandes desarrollos de software. Años más tarde, en 1976, Bell y Thayer popularizaron el término “waterfall” y citaron a Royce como referencia.
Lo curioso es que el propio Royce advertía de que un modelo estrictamente secuencial, sin ningún tipo de retroalimentación, era arriesgado. Proponía incluir iteraciones entre fases adyacentes y prototipos para reducir ese riesgo. Con el tiempo, lo que cuajó en la industria fue una versión simplificada, casi rígida, donde cada fase se completaba por completo antes de pasar a la siguiente, y así se consolidó el estereotipo que hoy todos asociamos con la cascada.
Gracias a su lógica clara y su facilidad para planificar, Waterfall se adoptó rápidamente no solo en software, sino también en sectores como la construcción, la ingeniería o cualquier entorno regulado donde el alcance esté bien definido y haya poca tolerancia a la improvisación.
Cómo funciona la metodología Waterfall
En un proyecto gestionado con enfoque en cascada, las fases se suceden en un orden lineal muy estricto. Una fase no arranca hasta que se da por cerrada la anterior y, en teoría, no se vuelve atrás salvo que aparezca un problema muy grave o un cambio contractual.
En su versión más clásica, el ciclo de vida Waterfall se compone de cinco, seis o incluso siete etapas. La diferencia suele estar en si se separa o se agrupa el despliegue y el mantenimiento, pero la lógica que hay detrás es la misma: avanzar sin solapar fases y con entregables formales en cada paso.
Fases de la metodología en cascada
Para entender bien Waterfall, conviene repasar con calma cada una de sus fases. No son compartimentos estancos, pero sí actúan como eslabones de una cadena donde la salida de una etapa alimenta la entrada de la siguiente.
1. Requisitos
La fase de requisitos es el corazón de cualquier proyecto en cascada. Aquí el objetivo es capturar todas las necesidades y restricciones del cliente y del negocio, tanto funcionales (qué debe hacer el sistema) como no funcionales (rendimiento, seguridad, normativas, etc.).
En esta etapa se realizan entrevistas, talleres y análisis con usuarios y expertos de dominio para que nada se quede fuera. El resultado es un documento de especificación de requisitos muy detallado que se revisa y se firma por todas las partes. Ese documento se convierte en la línea base contractual y técnica que regirá el resto del proyecto.
En el enfoque Waterfall clásico, el cliente participa sobre todo en este momento inicial. Después, su presencia disminuye drásticamente hasta la fase de validación o aceptación. Por eso es tan crítico que la captura de requisitos sea lo más exhaustiva y clara posible: cualquier omisión o ambigüedad se amplificará en las fases siguientes y será muy costosa de corregir.
2. Análisis
Con los requisitos ya fijados, el equipo entra en una fase de análisis donde se estudia la viabilidad técnica y funcional de todo lo solicitado. Se construye un modelo conceptual del sistema, se identifican dependencias, se aclaran reglas de negocio complejas y se preparan las bases para el diseño posterior.
Esta etapa permite traducir el lenguaje de negocio a un lenguaje más técnico, sin llegar todavía al detalle de la arquitectura. En muchos proyectos, el análisis y los requisitos se solapan en el tiempo, pero en cascada suelen representarse como una etapa diferenciada con sus propios entregables.
3. Diseño o concepción
La fase de diseño convierte el “qué” en “cómo”. A partir de los requisitos congelados, el equipo de arquitectura y diseño define la estructura completa de la solución. En software esto se divide a menudo en diseño de alto nivel (arquitectura, módulos, interfaces, tecnologías) y diseño detallado (algoritmos, bases de datos, esquemas de interfaz, etc.).
En otros sectores, esta fase equivale a los planos constructivos, cálculos estructurales, esquemas eléctricos o listas de materiales. El objetivo es que la implementación posterior sea, en esencia, una traducción fiel del diseño, sin necesidad de reinterpretar requisitos.
En proyectos complejos, el plan de proyecto y las dependencias se plasman en herramientas como el diagrama de Gantt y otras herramientas de gestión del tiempo, que encaja muy bien con la mentalidad secuencial de la cascada: tareas encadenadas, hitos muy claros y un calendario de entregas bien definido.
4. Implementación o desarrollo
Una vez completado el diseño, comienza la fase de implementación. Aquí es donde el equipo de desarrollo, construcción o integración se dedica a construir el producto exactamente según lo diseñado. En software, por ejemplo, es el momento de escribir código, configurar sistemas, montar infraestructuras, etc.
Paradójicamente, en muchos proyectos en cascada esta fase es más corta que la de requisitos y diseño, porque buena parte del esfuerzo se ha invertido ya en pensar y documentar. La idea es minimizar la improvisación: las decisiones clave ya se han tomado y lo que toca es ejecutar.
Aunque puede haber revisiones internas y pruebas unitarias, la metodología Waterfall tradicional reserva la verificación formal para la fase siguiente, una vez que el sistema completo está integrado.
5. Verificación, pruebas y validación
Cuando el sistema está construido, llega el momento de comprobar si realmente hace lo que debe. Aquí es importante diferenciar entre verificación y validación, dos conceptos que en cascada se tratan con bastante rigor.
La verificación consiste en asegurarse de que el producto se ha construido correctamente: se contrasta el sistema contra las especificaciones de diseño y se ejecutan pruebas de unidad, integración y sistema para buscar fallos técnicos, y cuando hay APIs implicadas se usan herramientas como la guía de Postman para el testeo de APIs. Se responde a la pregunta: “¿hemos construido el sistema según el diseño?”
La validación, por su parte, se centra en comprobar que el producto es el correcto: que satisface los requisitos y las necesidades del usuario tal y como se recogieron al principio. Se responde a la pregunta: “¿este sistema resuelve realmente el problema de negocio?”.
En esta fase se realizan pruebas de aceptación con el cliente. Si se detectan errores, se corrigen; si aparecen desviaciones respecto a lo que el cliente esperaba, puede tocar rehacer parte del trabajo. Como esos problemas se descubren tarde, el coste de corrección suele ser alto en tiempo y dinero, uno de los grandes inconvenientes de la cascada en entornos cambiantes.
6. Despliegue o arranque
Superadas las pruebas formales y la aceptación del cliente, el producto pasa a despliegue o puesta en producción. En software puede implicar instalar el sistema en los entornos definitivos, migrar datos, formar a los usuarios e integrar el nuevo sistema con otros ya existentes, para lo que es útil saber cómo gestionar APIs.
En otros sectores, es el momento en el que se inaugura una instalación, se entrega una planta industrial o se pone en marcha una infraestructura. En cascada, este hito marca el fin del proyecto de desarrollo y el inicio de la fase de mantenimiento.
7. Mantenimiento
Tras el arranque, comienza una fase de mantenimiento que en muchos casos es la más larga del ciclo de vida. Se encarga de corregir errores que se han colado, adaptar el sistema a cambios puntuales del entorno (normativas, sistemas externos, hardware) y realizar mejoras menores.
En la filosofía Waterfall pura, los cambios grandes que afectan de lleno a la arquitectura o a los requisitos suelen abordarse como nuevos proyectos en cascada, con su propio ciclo de requisitos, diseño, implementación y validación. La documentación generada en fases anteriores se convierte aquí en el salvavidas del equipo de soporte, que puede no ser el mismo que diseñó el sistema original.
El papel central de la documentación en Waterfall
Si hay algo que define a la metodología en cascada, además de la secuencia de fases, es la importancia de la documentación como columna vertebral del proyecto. Cada etapa genera entregables formales sujetos a revisión y aprobación: especificaciones de requisitos, diseños, planes de prueba, informes de verificación, manuales de operación, etc.
Esta documentación no es un capricho burocrático; en muchos sectores es un requisito regulatorio o contractual. Permite demostrar qué se acordó, cómo se diseñó, cómo se implementó y cómo se verificó todo. Además, facilita la trazabilidad completa desde un requisito hasta el código que lo implementa y la prueba que lo valida.
Plan de proyecto y línea base
El plan de proyecto en un entorno Waterfall es una auténtica carta de navegación. Define el alcance, el cronograma detallado, los recursos, los hitos, los riesgos y los criterios de aceptación de cada fase. Suele representarse con diagramas de Gantt muy elaborados y un calendario de revisiones formales al final de cada etapa.
Una vez aprobado, el plan se congela como línea base. Cualquier desviación significativa (en alcance, coste o plazo) se gestiona mediante solicitudes de cambio y procesos de control, normalmente revisados por un comité de proyecto. Esta rigidez aporta mucha previsibilidad, algo muy valorado en contratos de precio fijo o programas con penalizaciones por retrasos.
Especificación de requisitos como documento clave
Entre toda la documentación, la especificación de requisitos suele ser el documento con más peso contractual. Recoge qué debe hacer el sistema, bajo qué restricciones, con qué nivel de calidad y cómo debe interactuar con otros elementos.
En cascada es habitual que esta fase consuma entre un 20 % y un 30 % del esfuerzo total del proyecto. Puede parecer mucho, pero cuando el coste de equivocarse es alto, resulta más barato invertir tiempo en aclarar qué se quiere que reconstruir medio sistema al final.
Trazabilidad y registros de prueba
Otra característica típica de Waterfall son las matrices de trazabilidad, que vinculan cada requisito con los elementos de diseño que lo implementan y con los casos de prueba que lo verifican. Mantener estas matrices exige disciplina, pero son oro puro en auditorías y certificaciones.
Los planes de prueba, los guiones, los resultados y las actas de revisión constituyen un cuerpo de evidencias que demuestra que el sistema ha sido probado de forma sistemática. En sectores como el farmacéutico, el aeronáutico o el ferroviario, estos registros son obligatorios y deben conservarse durante años.
Documentar sí, burocracia no
Una crítica habitual a la cascada es que genera toneladas de papel que nadie lee. Y a veces es así, no nos vamos a engañar. Por eso es importante distinguir entre documentación que aporta valor (la que ayuda a entender decisiones, a demostrar cumplimiento o a mantener el sistema) y burocracia que solo sirve para rellenar formularios.
El gestor de un proyecto en cascada debe tener criterio para podar lo superfluo y centrarse en documentos que respondan preguntas clave: quién pidió qué, por qué se diseñó de esa manera y cómo se comprobó que funciona. Si un documento no ayuda a responder nada de eso ni hace falta para pasar una auditoría, probablemente sobra.
Ventajas de la metodología Waterfall
La cascada no es la panacea, pero en los contextos adecuados tiene una serie de puntos fuertes difíciles de igualar. Estos son los más destacados.
En primer lugar, ofrece una estructura clara, lógica y muy ordenada. El proyecto se recorre de manera secuencial, con fases que no se solapan y con hitos muy definidos. Esto facilita mucho la asignación de recursos y el seguimiento del progreso, porque siempre se sabe en qué etapa se está.
En segundo lugar, permite una planificación y estimación muy precisas cuando los requisitos son estables. Como todo se define antes de empezar, es más sencillo calcular costes, tiempos y necesidades de personal. Esto encaja de maravilla con contratos de precio cerrado, licitaciones públicas y proyectos donde el cliente necesita saber desde el principio cuánto va a pagar y cuándo recibirá el resultado.
En tercer lugar, la cascada genera documentación exhaustiva y trazabilidad completa. Cada fase deja un rastro de entregables revisados y aprobados, algo muy valorado en entornos regulados y de alta criticidad, donde la ausencia de papeles puede ser un problema legal o de seguridad.
Además, al estar tan bien delimitadas las fases, es más fácil medir el avance del proyecto y reportarlo a la dirección. Se pueden usar técnicas como el valor ganado y compararlas con la línea base de forma bastante objetiva.
Por último, para algunos clientes resulta cómodo que, tras la fase inicial de requisitos, no tengan que involucrarse de forma continua. En Waterfall su participación suele concentrarse al principio (para definir qué quieren) y al final (para validar lo que se ha entregado). Para organizaciones con poco tiempo o sin cultura de colaboración continua, esto puede ser una ventaja.
Limitaciones y riesgos del enfoque en cascada
La cara B de todo lo anterior es que el modelo Waterfall sufre muchísimo cuando el contexto exige flexibilidad y adaptación al cambio. Sus principales desventajas son bien conocidas.
La más evidente es su falta de flexibilidad. Congelar los requisitos al inicio y avanzar sin mirar atrás hace muy complicado introducir cambios razonables a mitad del proyecto. Cualquier ajuste importante puede arrastrar modificadores de diseño, reimplementaciones y repetición de pruebas, con el consiguiente impacto en tiempo y presupuesto.
Otro problema es la entrega tardía de valor. En cascada, el cliente no ve un producto funcional hasta las fases finales. Si al llegar ahí descubre que lo entregado no encaja con lo que realmente necesita (porque el contexto ha cambiado, han aparecido competidores nuevos o han surgido ideas mejores), poco se puede hacer sin desandar mucho camino.
También existe una fuerte dependencia de la calidad de los requisitos iniciales. Si el cliente no tiene claro qué quiere, o si el equipo no consigue capturarlo bien, la cascada se convierte en una trampa cara: se invierte mucho en planificar algo que luego hay que deshacer.
A esto se suma la escasez de retroalimentación continua. Como el cliente se implica de forma limitada durante el desarrollo, se pierden oportunidades de ajustar la solución sobre la marcha y de detectar pronto problemas de usabilidad o de encaje con el negocio.
Por último, cuando se usa fuera de contexto, la cascada puede generar una falsa sensación de control. Tener un Gantt precioso y montones de documentos aprobados no garantiza que el sistema vaya a integrarse bien o a rendir como se espera. Muchos fallos solo afloran al final, cuando es más caro reaccionar.
Waterfall en el desarrollo de software
En el mundo del software, Waterfall fue durante años el modelo dominante, sobre todo en grandes sistemas para la administración, defensa, banca o telecomunicaciones. La secuencia “requisitos-diseño-código-pruebas-mantenimiento” encajaba con la mentalidad de ingeniería de la época.
Con el tiempo se vio que en la mayoría de productos digitales los requisitos cambian constantemente. El mercado se mueve rápido, la tecnología no para de evolucionar y los usuarios descubren lo que de verdad quieren solo cuando empiezan a usar algo concreto. En ese entorno, descubrir un error de concepto en la fase final de pruebas supone tirar a la basura mucho trabajo.
Por eso la mayoría de equipos de software orientados a producto han adoptado enfoques ágiles e iterativos (Scrum, Kanban, Lean, etc.), que permiten entregar incrementos frecuentes, validar hipótesis de negocio y ajustar el rumbo con rapidez.
Aun así, la cascada sigue teniendo su hueco en software cuando el alcance está muy acotado y la estabilidad es prioritaria: sistemas de misión crítica (médicos, militares, aeronáuticos), integraciones con contratos cerrados, desarrollos para entornos altamente regulados o migraciones de sistemas muy antiguos donde las reglas de negocio están perfectamente documentadas.
Cuándo tiene sentido usar la metodología en cascada
Elegir entre Waterfall y Agile no va de modas, va de contexto. Hay situaciones en las que la cascada es una elección muy sensata y otras en las que es directamente un suicidio metodológico.
Proyectos con requisitos estables y bien conocidos
La casuística ideal para Waterfall es aquella en la que los requisitos son claros, completos y poco propensos a cambiar. Por ejemplo, migrar un sistema legado a una nueva plataforma manteniendo la misma funcionalidad, replicar una planta industrial ya probada en otra ubicación, o implantar un ERP con un alcance cerrado por contrato.
En estos casos, la organización suele conocer muy bien el dominio y los riesgos. La cascada permite aprovechar esa experiencia, planificar al detalle y optimizar el uso de recursos con muy pocas sorpresas.
Entornos regulados y de alta criticidad
Industria aeroespacial, ferroviaria, energía nuclear, dispositivos médicos… Son sectores donde la trazabilidad absoluta y la documentación exhaustiva son obligatorias. Las agencias reguladoras exigen ver planes secuenciales, revisiones de diseño, registros de pruebas y una justificación completa de cada decisión técnica.
En estos dominios, la documentación ligera y la experimentación constante de algunos enfoques ágiles encajan mal con las exigencias de certificación. La cascada proporciona el andamiaje documental necesario para superar auditorías formales y hitos de validación regulatoria.
Contratos de precio fijo y externalización
Cuando un proveedor firma un contrato de precio cerrado, necesita minimizar las incertidumbres. El modelo en cascada encaja bien porque el alcance se negocia, se documenta y se congela antes de comprometer el esfuerzo. Cualquier cambio posterior tiene su proceso formal y suele ir asociado a renegociar coste y plazos.
En proyectos de outsourcing donde los equipos están dispersos y la comunicación informal es limitada, la cascada reduce ambigüedades sustituyendo conversaciones constantes por especificaciones bien detalladas.
Cultura organizativa poco tolerante a la incertidumbre
Hay organizaciones muy jerárquicas, con presupuestos anuales fijos y una obsesión por la previsibilidad. En estos entornos, intentar implantar Agile a golpe de manual suele acabar en un “híbrido raro” donde no se disfruta de las ventajas de ninguno de los dos modelos.
La cascada se ajusta mejor a estructuras donde se valora tener un plan sólido desde el principio, con informes lineales de progreso y revisiones formales. Aquí el director de proyecto actúa como guardián de la línea base, más que como facilitador de iteraciones.
Integración de múltiples proveedores y grandes programas
En proyectos gigantes con varios contratistas (por ejemplo, automoción, construcción naval o grandes infraestructuras), la cascada sirve como lenguaje común para coordinar interfaces. Cada proveedor desarrolla su subsistema contra especificaciones de interfaz congeladas, y las pruebas de integración se planifican con mucha antelación.
Si cada equipo trabajara con prioridades cambiantes y sprints independientes sin un marco superior, la integración sería un caos. El enfoque secuencial facilita definir puntos de integración claros y controlar mejor la cadena de suministro.
Cuándo NO es buena idea aplicar Waterfall
Tan importante como saber dónde brilla la cascada es identificar las situaciones en las que conviene descartarla sin dudar. Algunos escenarios típicos:
Cuando el cliente no sabe bien qué necesita y se espera aprender a base de prueba y error, forzar un modelo secuencial solo va a generar frustración y sobrecostes. Se va a invertir mucho tiempo en documentar algo que cambiará pronto.
Si el mercado cambia por semanas o meses (startups, productos digitales innovadores, proyectos de experiencia de usuario), esperar hasta el final para validar la solución es una temeridad. En estos casos, resultan más adecuados enfoques iterativos e incrementales que permitan pilotar, medir y ajustar.
Además, si los plazos son tan agresivos que no permiten una fase de requisitos rigurosa, intentar seguir Waterfall acaba derivando en una versión de la cascada sin controles reales, donde la documentación se hace deprisa y corriendo solo para “cumplir el expediente”. Eso es lo peor de ambos mundos.
Agile vs Waterfall: diferencias clave
La comparación entre Waterfall y Agile aparece en prácticamente cualquier debate de gestión de proyectos. No son buenos o malos por sí mismos; simplemente responden a filosofías distintas.
Waterfall propone un enfoque lineal y secuencial: primero se define todo, luego se diseña, se implementa, se prueba y se entrega. Agile, en cambio, divide el trabajo en ciclos cortos e iterativos (sprints) donde se planifica, diseña, desarrolla y prueba un pequeño conjunto de funcionalidades en cada iteración.
En cascada, el alcance se fija al principio y los cambios son excepciones costosas. En Agile, se asume que el cambio es la norma y el producto va evolucionando sprint a sprint, ajustando el backlog según la retroalimentación de usuarios y negocio.
Respecto a la implicación del cliente, Waterfall concentra su participación al inicio y al final del proyecto. Agile la reparte a lo largo de todo el ciclo de vida, con revisiones frecuentes y producto potencialmente entregable al final de cada sprint.
En cuanto al tiempo de salida al mercado, los proyectos en cascada suelen entregar valor al final del recorrido. Agile permite lanzar versiones tempranas (MVPs) que se refinan con el tiempo.
En la práctica, muchas organizaciones optan por enfoques híbridos, como el conocido “Water-Scrum-Fall”: planificación y diseño general en modo cascada, desarrollo diario con Scrum, y despliegue/entrega nuevamente bajo un paraguas más predictivo.
El papel del gestor de proyectos en Waterfall
El director de proyecto en un entorno en cascada tiene un rol distinto al de un Scrum Master o un Agile Coach. Aquí se espera que sea un planificador meticuloso y controlador del progreso, más que un facilitador de equipos autoorganizados.
Entre sus responsabilidades clave están mantener la línea base del proyecto, coordinar las revisiones de fase, gestionar riesgos, controlar cambios, velar por el cumplimiento de plazos y presupuesto, y comunicar el estado a la dirección con informes formales. En proyectos grandes, suele trabajar mano a mano con un líder técnico que garantice la calidad del diseño y de las decisiones de arquitectura.
Para quienes quieren especializarse en este tipo de gestión, certificaciones como PMP del PMI o normas específicas de sectores regulados (por ejemplo, DO‑178C en aeroespacial) afianzan precisamente estas competencias orientadas a ciclos de vida predictivos y fuertemente documentados.
Metodologías híbridas y convivencia con enfoques ágiles
La realidad es que hoy casi ningún proyecto serio es 100 % cascada o 100 % ágil. Lo habitual es encontrar combinaciones en las que la cascada actúa como paraguas contractual, mientras que en el interior se aplican ciclos iterativos para reducir riesgo en partes concretas.
Por ejemplo, puede definirse la arquitectura general y las interfaces con metodología en cascada, pero desarrollar ciertos subsistemas con iteraciones cortas y prototipado. Mientras se respeten las interfaces y los hitos de integración, la mezcla puede funcionar muy bien.
Algo parecido ocurre en procesos de transformación digital: una organización puede migrar su núcleo transaccional (estable y regulado) con Waterfall, mientras desarrolla aplicaciones frontales para el cliente final con equipos ágiles. Lejos de ser contradictorio, es una forma inteligente de asignar la herramienta adecuada a cada problema.
También existen transiciones desde Waterfall hacia Agile en las que la gestión de recursos y habilidades del equipo requiere un cambio cultural importante. Empezar aplicando enfoques ágiles en proyectos pequeños permite que los equipos se acostumbren a la planificación dinámica y a la retroalimentación continua sin poner en riesgo programas críticos.
En definitiva, la metodología Waterfall sigue siendo una pieza muy vigente en la gestión de proyectos siempre que se entienda bien cuál es su fortaleza: previsibilidad, estructura y trazabilidad. Cuando se aplica en dominios con requisitos estables, alta exigencia regulatoria o contratos de precio fijo, puede ser la opción más segura y eficiente, sobre todo combinada con dosis razonables de iteración y sentido común.
