En qué consiste el modelo en cascada

El modelo en cascada es un proceso de desarrollo secuencial, en el que

el desarrollo de software se concibe como  un conjunto de etapas que  se
ejecutan una tras otra. Se le denomina así por las posiciones que ocupan
las diferentes fases que componen el proyecto, colocadas una encima de
otra, y siguiendo un flujo de ejecución de arriba hacia abajo, como una
cascada.

Las etapas del modelo en cascada

 

El modelo de desarrollo en cascada se originó en la industria y la

construcción, donde los cambios a posteriori son caros y difíciles de
implementar. Cuando estás creando un producto material, realizar
cambios en lo ya construido es mucho más difícil que en un programa
informático. En el mundo del software, todavía no se habían implantado
otras metodologías de desarrollo por lo que se adaptó el modelo en
cascada que se utilizaba en otros sectores. 

Fases del modelo

El modelo de desarrollo en cascada sigue una serie de etapas de forma
sucesiva, la etapa siguiente empieza cuando termina la etapa anterior.

Las fases que componen el modelo son las siguientes:

Requisitos del software

En esta fase se hace un análisis de las necesidades del cliente para
determinar las características del software a desarrollar, y se especifica
todo lo que debe hacer el sistema sin entrar en detalles técnicos. Hay
que ser especialmente cuidadoso en esta primera fase, ya que en este
modelo no se pueden añadir nuevos requisitos en mitad del proceso de
desarrollo.

Por lo tanto, esta es la etapa en la que se lleva a cabo una descripción

de los requisitos del software, y se acuerda entre el cliente y la empresa
desarrolladora lo que el producto deberá hacer. Disponer de una
especificación de los requisitos permite estimar de forma rigurosa las
necesidades del software antes de su diseño. Además, permite tener
una base a partir de la cual estimar el coste del producto, los riesgos y
los plazos.

En el documento en el que se especifican los requisitos, se establece

una lista de los requerimientos acordados. Los desarrolladores
deben comprender de forma clara el producto que van a desarrollar.
Esto se consigue teniendo una lista detallada de los requisitos, y con una
comunicación fluida con el cliente hasta que termine el el tiempo de
desarrollo.

Diseño
En esta etapa se describe la estructura interna del software, y las
relaciones entre las entidades que lo componen.

Descompone y organiza el sistema en elementos que puedan elaborarse

por separado, aprovechando las ventajas del desarrollo en equipo. Como
resultado surge el SDD (Documento de Diseño del Software), que
contiene la descripción de la estructura relacional global del sistema y la
especificación de lo que debe hacer cada una de sus partes, así como la
manera en que se combinan unas con otras.

Es conveniente distinguir entre diseño de alto nivel o arquitectónico y

diseño detallado. El primero de ellos tiene como objetivo definir la
estructura de la solución (una vez que la fase de análisis ha descrito el
problema) identificando grandes módulos (conjuntos de funciones que
van a estar asociadas) y sus relaciones. Con ello se define la
arquitectura de la solución elegida. El segundo define los algoritmos
empleados y la organización del código para comenzar la
implementación.

Implementación
En esta fase se programan los requisitos especificados haciendo uso de
las estructuras de datos diseñadas en la fase anterior.La programación
es el proceso que lleva de la formulación de un problema de
computación, a un programa que se ejecute produciendo los pasos
necesarios para resolver dicho problema.

Al programar, tenemos que realizar actividades como el análisis de las

condiciones, la creación de algoritmos,  y la implementación de éstos en
un lenguaje de programación específico.

Un algoritmo es un conjunto de instrucciones o reglas bien definidas y

ordenadas que permiten llevar a cabo una actividad mediante pasos
sucesivos.
Verificación
Como su propio nombre indica, una vez se termina la fase de
implementación se verifica que todos los componentes del sistema
funcionen correctamente y cumplen con los requisitos.

El objetivo de las pruebas es el de obtener información de la calidad del

software, y sirven para: encontrar defectos o bugs, aumentar la calidad
del software, refinar el código previamente escrito sin miedo a romperlo
o introducir nuevos bugs, etc.

Instalación y mantenimiento 
Una vez se han desarrollado todas las funcionalidades del software y se
ha comprobado que funcionan correctamente, se inicia la fase de
instalación y mantenimiento. Se instala la aplicación en el sistema y se
comprueba que funcione correctamente en el entorno en que se va a
utilizar.

A partir de ahora hay que asegurarse de que el software funcione y hay

que destinar recursos a mantenerlo. El mantenimiento del software
consiste en la modificación del producto después de haber sido
entregado al cliente, ya sea para corregir errores o para mejorar
el rendimiento o las características.

El propósito de esta fase es mantener el valor del software a través del

tiempo. Esto puede hacerse añadiendo nuevos requisitos, corrigiendo
errores, renovando el aspecto visual, mejorando la eficiencia o
añadiendo nueva tecnología. El periodo de mantenimiento puede durar
años, por lo que es una fase clave del modelo en cascada.
Para llevar a cabo correctamente la fase de mantenimiento, se necesita
trazar un plan de antemano que nos prepare para todos los escenarios
que puedan producirse durante esta fase. Para evitar futuros conflictos
con el cliente, en el plan hay que especificar cómo los usuarios
solicitarán las modificaciones o la corrección de errores, hacer una
estimación del coste de la modificación de funcionalidades o corrección
de errores, quién se encargará del mantenimiento, durante cuanto
tiempo se dará soporte al software, etc.  

Ventajas e inconvenientes del desarrollo en cascada

Ventajas
 El tiempo que se pasa en diseñar el producto en las primeras fases
del proceso puede evitar problemas que serían más costosos
cuando el proyecto ya estuviese en fase de desarrollo.
 La documentación es muy exhaustiva y si se une al equipo un
nuevo desarrollador, podrá comprender el proyecto leyendo la
documentación.
 Al ser un proyecto muy estructurado, con fases bien definidas, es
fácil entender el proyecto.
 Ideal para proyectos estables, donde los requisitos son claros y no
van a cambiar a lo largo del proceso de desarrollo.
Inconvenientes
 En muchas ocasiones, los clientes no saben bien los requisitos que
necesitarán antes de ver una primera versión del software en
funcionamiento. Entonces, cambiarán muchos requisitos y
añadirán otros nuevos, lo que supondrá volver a realizar fases ya
superadas y provocará un incremento del coste.
 No se va mostrando al cliente el producto a medida que se va
desarrollando, si no que se ve el resultado una vez ha terminado
todo el proceso.  Esto cual provoca inseguridad por parte del
cliente que quiere ir viendo los avances en el producto
 Los diseñadores pueden no tener en cuenta todas las dificultades
que se encontrarán cuando estén diseñando un software, lo que
conllevará rediseñar el proyecto para solventar el problema.
 Para proyectos a largo plazo, este modelo puede suponer un
problema al cambiar las necesidades del usuario a lo largo del
tiempo. Si por ejemplo, tenemos un proyecto que va a durar 5
años, es muy probable que los requisitos necesiten adaptarse a los
gustos y novedades del mercado.
 Antecedentes [editar]

El modelo en cascada (o waterfall model en inglés) fue el primer método

ampliamente utilizado en la industria del software. Como enfoque tradicional, no es
repetitivo en contraste con los modelos ágiles con sprints simples, pero puede ser
complementado con bucles de retroalimentación y loopbacks. Todavía se utiliza
hoy en día en varias versiones si los requisitos y características de un software
pueden ser claramente definidos durante la fase conceptual.

Información general [editar]

La primera mención de un modelo en fases se remonta a Winston Royce. En su

ensayo "Managing the Development of Large Software Systems" (Gestión del
desarrollo de grandes sistemas de software) describió un método de desarrollo
para grandes proyectos de software, que se divide en fases ya en 1970. También
criticó este enfoque y propuso una alternativa que se asemeja a la creación de
prototipos. Royce se refería al "Nine Phase Stage-Wise Model" de Herbert
Benington, publicado en 1956. Mientras que Benington preveía nueve fases,
Royce las redujo a siete. El término modelo en cascada no fue utilizado por
ninguno de los dos. Su uso se basa en un libro de 1976, que trata principalmente
de los requisitos para software[1]

Cómo funciona [editar]

El modelo original en cascada consta de siete fases sucesivas:[2]

 Requisitos del sistema: La primera fase se ocupa de los requisitos que no

están relacionados con el producto digital en sí, sino más bien con aspectos
relevantes para la empresa como el precio y la disponibilidad. Aquí también se
especifican los aspectos de documentación y seguridad. En general, aquí se
mencionan los requisitos no funcionales.
 Requisitos de software: Los requisitos funcionales del software se definen
en la segunda fase. La pregunta sobre lo que el software debe ser capaz de hacer
se responde aquí y se aclara en "especificaciones", que también incluye los
resultados de la primera fase.
 Análisis de requerimientos: En la fase de análisis de requisitos, las
funciones del software se diseccionan y estructuran de modo que los elementos
funcionales individuales y las unidades funcionales puedan separarse entre sí. El
análisis de necesidades tiene por objeto examinar la viabilidad e importancia de
las funciones. Los resultados de esta fase son las especificaciones que contienen
los requisitos que hay que desarrollar.
 Diseño de programas: El diseño técnico se implementa ahora con la
ayuda de estas especificaciones de requisitos. Los componentes de esta fase
también incluyen decisiones sobre la arquitectura de la información y las
tecnologías aplicadas, tales como lenguajes de programación, bibliotecas de
clases y secuencias de programas. El resultado del diseño del programa se
registra generalmente en diagramas que describen el comportamiento teórico del
software.
 Implementación: Durante la implementación, las estructuras y los flujos de
trabajo se implementan teniendo en cuenta las condiciones marco y los objetivos
sistémicos. El diseño de software se convierte en un programa directamente
relacionado con un sistema operativo, uno o más lenguajes de programación y la
infraestructura. El resultado suele ser un software operativo, a menudo en versión
beta.
 Probando: La fase de implementación es seguida por la prueba de todos
los componentes de software, módulos y todo el sistema. También se comprueba
la integración en sistemas operativos específicos. Si se producen errores y
conflictos, deben repararse inmediatamente. Esto podría dar lugar a un aumento
de los costes globales, ya que los posibles errores pueden atribuirse a diferentes
fases y no siempre se producen en la fase anterior.
 Lanzamiento: El software se implementa después de la aceptación por
parte del cliente. Las actualizaciones y el mantenimiento pueden ser necesarios
antes de que el producto entre en una tienda o se entregue al cliente.

Varios equipos y expertos trabajan en estas etapas. Los contratistas, la gestión de

proyectos y los desarrolladores senior suelen participar hasta la fase de
implementación. Después de la implementación, los desarrolladores hacen el
trabajo, por lo que las pruebas del software se manejan frecuentemente por
separado, por ejemplo, por laboratorios de pruebas independientes. Expertos en
marketing y servicios participan en parte en su lanzamiento. En las grandes
empresas y corporaciones, se utiliza el método SDLC modificado y estructurado
con mayor precisión (ciclo de vida de desarrollo del sistema), que se basa en
el modelo en cascada.[3]. Existen también otras versiones de este modelo que,
por ejemplo, introducen elementos repetitivos en forma de bucles para detectar y
corregir errores y fallos en fases anteriores.

Beneficios / Desventajas [editar]

Algunas ventajas y desventajas del modelo en cascada:[4][5][6]

Ventajas[editar]
 Debido a la estructura lógica del modelo, a menudo se pueden evitar
errores conceptuales.
 El modelo conduce a una extensa documentación técnica, que es un alivio
para los nuevos programadores y desarrolladores y también es útil en la fase de
prueba.
 El progreso del proyecto puede ser monitoreado usando metas.
 El coste total puede estimarse con relativa precisión si no hay conflictos.

Desventajas[editar]
 Los conflictos, bugs y errores de programación a veces conducen a un
aumento de los costes y a una cantidad considerable de tiempo. Lo mismo se
aplica si los clientes no están satisfechos.
 Las especificaciones que se hacen inicialmente son a menudo difíciles de
entender para los clientes porque son más abstractas de lo que se supone que el
software debe hacer. Especialmente en proyectos subcontratados, esto puede ser
una desventaja decisiva, ya que la fecha de lanzamiento debe posponerse y el
mercado puede haber cambiado durante este tiempo.
 La entrega del software lleva más tiempo porque los departamentos no
trabajan simultáneamente y cada fase sólo puede comenzar cuando se ha
completado la fase anterior.

Importancia para la programación [editar]

El modelo en cascada es uno de los modelos de proceso más conocidos en el

desarrollo de software. Se ha utilizado con éxito durante décadas, pero ahora sólo
se utiliza para proyectos más pequeños en los que las especificaciones son claras.
Los inconvenientes antes mencionados, sin embargo, también llevaron a los
analistas y desarrolladores a diseñar modelos alternativos llamados desarrollo ágil
de software[7]. El principal problema del modelo en cascada es que los cambios y
revisiones no están necesariamente previstos por las secuencias lógicas. La
retroalimentación de los clientes, testers o probadores e ingenieros durante el
desarrollo, está en parte ausente, y la integración del software en un sistema
existente tiene lugar en un big bang. Estos inconvenientes pueden evitarse
modificando las fases del proyecto, como es el caso del Modelo en Espiral. Pero
desde hace algunos años, los métodos ágiles que utilizan otros elementos
estructurales son mucho más populares (por ejemplo, los roles y sprints con
Scrum o los principios extremos de programación). Por regla general, son más
económicos, conducen a resultados más rápidos y son más transparentes para los
clientes.

Modelo de Cascada
En ingeniería del software: el desarrollo en cascada, también llamado modelo en
cascada, es el enfoque metodológico que ordena rigurosamente las etapas de del En
Ingeniería de software el desarrollo en cascada, también llamado modelo en cascada,
es el enfoque metodológico que ordena rigurosamente las etapas del proceso para el
desarrollo de software, de tal forma que el inicio de cada etapa debe esperar a la
finalización de la etapa anterior.

Un ejemplo de una metodología de desarrollo en cascada es:

    Análisis de requisitos.

    Diseño del Sistema.

    Diseño del Programa.

    Codificación.

    Pruebas.

    Implantación.

    Mantenimiento.

De esta forma, cualquier error de diseño detectado en la etapa de prueba conduce

necesariamente al rediseño y nueva programación del código afectado, aumentando los
costes del desarrollo. La palabra cascada sugiere, mediante la metáfora de la fuerza de
la gravedad, el esfuerzo necesario para introducir un cambio en las fases más
avanzadas de un proyecto.

Si bien ha sido ampliamente criticado desde el ámbito académico y la industria, sigue

siendo el paradigma más seguido al día de hoy.

Análisis de requisitos

    En esta fase se analizan las necesidades de los usuarios finales del software para
determinar qué objetivos debe cubrir. De esta fase surge una memoria llamada SRD
(documento de especificación de requisitos), que contiene la especificación completa
de lo que debe hacer el sistema sin entrar en detalles internos.

  Es importante señalar que en esta etapa se debe consensuar todo lo que se requiere
del sistema y será aquello lo que seguirá en las siguientes etapas, no pudiéndose
requerir nuevos resultados a mitad del proceso de elaboración del software.

 
 Diseño del Sistema

            Descompone y organiza el sistema en elementos que puedan elaborarse por
separado, aprovechando las ventajas del desarrollo en equipo. Como resultado surge el
SDD (Documento de Diseño del Software), que contiene la descripción de la estructura
relacional global del sistema y la especificación de lo que debe hacer cada una de sus
partes, así como la manera en que se combinan unas con otras.

              Es conveniente distinguir entre diseño de alto nivel o arquitectónico y diseño
detallado. El primero de ellos tiene como objetivo definir la estructura de la solución
(una vez que la fase de análisis ha descrito el problema) identificando grandes módulos
(conjuntos de funciones que van a estar asociadas) y sus relaciones. Con ello se define
la arquitectura de la solución elegida. El segundo define los algoritmos empleados y la
organización del código para comenzar la implementación.

Diseño del Programa

              Es la fase en donde se realizan los algoritmos necesarios para el cumplimiento
de los requerimientos del usuario así como también los análisis necesarios para saber
que herramientas usar en la etapa de Codificación.

Codificación

               Es la fase en donde se implementa el código fuente, haciendo uso de

prototipos así como de pruebas y ensayos para corregir errores.

             Dependiendo del lenguaje de programación y su versión se crean las bibliotecas

y componentes reutilizables dentro del mismo proyecto para hacer que la
programación sea un proceso mucho más rápido.

Pruebas

            Los elementos, ya programados, se ensamblan para componer el sistema y se

comprueba que funciona correctamente y que cumple con los requisitos, antes de ser
entregado al usuario final.

Verificación
            Es la fase en donde el usuario final ejecuta el sistema, para ello el o los
programadores ya realizaron exhaustivas pruebas para comprobar que el sistema no
falle.

Mantenimiento

            Una de las etapas más críticas, ya que se destina un 75% de los recursos, es el
mantenimiento del Software ya que al utilizarlo como usuario final puede ser que no
cumpla con todas nuestras expectativas.

Ventajas del Modelo de Cascada Pura

1.-Se utiliza correctamente para ciclos en los que se tiene una decisión estable del
producto.

2.-Puede constituir una elección correcta para el desarrollo rápido.

3.-ayuda a minimizar los gastos de la planificación porque permite realizarla sin

problemas.

4.-Funciona bien

5.-Evita una fuente común de errores importantes.

6.-Presenta el proyecto con una estructura que ayuda a minimizar el esfuerzo inútil.

Desventajas del Modelo de Cascada Pura

1.--Dificultad para especificar claramente los requerimientos al comienzo del

proyecto(no permite flexibilidad en los cambios).

2.-Para un proyecto de desarrollo rápido, el modelo de cascada puede suponer una

cantidad excesiva de documentación.

3.-Si se intenta mantener la flexibilidad, la actualización de la especificación se puede

convertir en un trabajo a tiempo completo.

4.-No es imposible volver atrás utilizando el modelo de cascada pura, pero si difícil.

5.-Genera pocos signos visibles de progreso hasta el final.

 El modelo en cascada: desarrollo secuencial de software
El término “waterfall model” hace referencia a un procedimiento secuencial que permite
representar un proyecto en base a unas fases que se suceden entre sí.

Índice
1. ¿Qué es el modelo en cascada?
2. ¿Cómo funciona el modelo en cascada?
3. Procedimientos alternativos al modelo en cascada

¿Qué es el modelo en cascada?

El desarrollo en cascada (en inglés, waterfall model) es un procedimiento lineal que se
caracteriza por dividir los procesos de desarrollo en sucesivas fases de proyecto. Al contrario
que en los modelos iterativos, cada una de estas fases se ejecuta tan solo una vez. Los
resultados de cada una de las fases sirven como hipótesis de partida para la siguiente. El
waterfall model se utiliza, especialmente, en el desarrollo de software.

¿Cómo funciona el modelo en cascada?

El desarrollo del modelo se atribuye al teórico de la informática Winston W. Royce. Sin
embargo, Royce no es el inventor de este modelo. Muy al contrario, en su ensayo de 1970
titulado Managing the Development of Large Software Systems, el teórico presenta
una reflexión crítica acerca de los procedimientos lineales. A modo de alternativa, Royce
presenta un modelo iterativo incremental en el que cada una de las fases se basa en la
anterior y verifica los resultados de esta.

Royce propone un modelo compuesto por siete fases que se ha de ejecutar en diversas
vueltas (iteraciones):

1. Requisitos de sistema
2. Requisitos de software
3. Análisis
4. Diseño
5. Implementación
6. Prueba
7. Servicio

El procedimiento popularmente conocido como waterfall model se basa en las fases definidas
por Royce, pero solo prevé una iteración.

En el ensayo publicado por Royce, el término no aparece en ningún momento.

 Hecho
El modelo en cascada se popularizó a través de la norma estadounidense DoD-STD-2167.
Esta norma se basa en una versión extremadamente simplificada del procedimiento
desarrollado por Royce, que no fue lo suficientemente analizado por los autores. Tal y como
reconoció con el paso del tiempo David Maibor, uno de sus autores, el motivo fue la falta de
compresión de los modelos iterativos incrementales.
En la práctica, se aplican diversas versiones del modelo. Los más habituales son los
modelos que dividen los procesos de desarrollo en cinco fases. En ocasiones, las fases 1, 2 y
3 definidas por Royce se integran en una sola fase de proyecto a modo de análisis de los
requisitos.

1. Análisis: planificación, análisis y especificación de los requisitos.

2. Diseño: diseño y especificación del sistema.
3. Implementación: programación y pruebas unitarias.
4. Verificación: integración de sistemas, pruebas de sistema y de integración.
5. Mantenimiento: entrega, mantenimiento y mejora.

La siguiente imagen explica por qué el procedimiento lineal se denomina metodología en

cascada.

El modelo en cascada de cinco niveles, basado en las propuestas de Winston W. Royce,

divide los procesos de desarrollo en las siguientes fases de proyecto: análisis, diseño,
implementación, verificación y mantenimiento. El gráfico incluye una de las ampliaciones del
modelo planteadas por Royce: la verificación de los resultados de cada una de las fases
tomando en consideración las exigencias y especificaciones formuladas en el paso anterior.
En las ampliaciones de la metodología en cascada se añaden funciones iterativas al modelo
básico como, por ejemplo, los saltos hacia atrás, que permiten comparar los resultados de
cada una de las fases con las hipótesis obtenidas en la fase anterior, de modo que se puedan
verificar.

Las fases del desarrollo en cascada

En este modelo, las diferentes fases de un proceso de desarrollo se suceden una detrás de
otra como en una cascada. Cada una de las fases concluye con un resultado provisional
(hito) como, por ejemplo, un catálogo de requisitos en forma de pliego de condiciones, la
especificación de una arquitectura de software o una aplicación a nivel alfa o beta.

Análisis
Todo proyecto de software comienza con una fase de análisis que incluye un estudio de
viabilidad y una definición de los requisitos. En el estudio de viabilidad se evalúan los costes,
la rentabilidad y la factibilidad del proyecto de software. El estudio de viabilidad da como
resultado un pliego de condiciones (una descripción general de los requisitos), un plan y una
estimación financiera del proyecto, así como una propuesta para el cliente, si fuera necesario.

A continuación, se realiza una definición detallada de los requisitos, incluyendo un análisis

de la situación de salida y un concepto. Mientras que los análisis de salida se encargan de
describir la problemática en sí, el concepto ha de definir qué funciones y características debe
ofrecer el producto de software para cumplir con las correspondientes exigencias. La
definición de los requisitos da como resultado un pliego de condiciones, una descripción
detallada de cómo se han de cumplir los requisitos del proyecto, así como un plan para la
prueba de aceptación, entre otros.

Por último, la primera fase del waterfall model incluye un análisis de la definición de los
requisitos en el que los problemas complejos se dividen en pequeñas tareas secundarias y
se elaboran las correspondientes estrategias de resolución.

Diseño
La fase de diseño sirve para formular una solución específica en base a las exigencias, tareas
y estrategias definidas en la fase anterior. En esta fase, los desarrolladores de software se
encargan de diseñar la arquitectura de software, así como un plan de diseño detallado del
mismo, centrándose en componentes concretos, como interfaces, entornos de trabajo o
bibliotecas. La fase de diseño da como resultado un borrador preliminar con el plan de diseño
del software, así como planes de prueba para los diferentes componentes.

Implementación
La arquitectura de software concebida en la fase de diseño se ejecuta en la fase de
implementación, en la que se incluye la programación del software, la búsqueda de
errores y las pruebas unitarias. En la fase de implementación, el proyecto de software se
traduce al correspondiente lenguaje de programación. Los diversos componentes se
desarrollan por separado, se comprueban a través de las pruebas unitarias y se integran
poco a poco en el producto final. La fase de implementación da como resultado un producto
de software que se comprueba por primera vez como producto final en la siguiente fase
(prueba alfa).
Prueba
La fase de prueba incluye la integración del software en el entorno seleccionado. Por norma
general, los productos de software se envían en primer lugar a los usuarios finales
seleccionados en versión beta (pruebas beta). Las pruebas de aceptación desarrolladas en
la fase de análisis permiten determinar si el software cumple con las exigencias definidas con
anterioridad. Aquellos productos de software que superan con éxito las pruebas beta están
listos para su lanzamiento.

Servicio
Una vez que la fase de prueba ha concluido con éxito, se autoriza la aplicación
productiva del software. La última fase del modelo en cascada incluye la entrega,
el mantenimiento y la mejora del software.

Pros y contras del modelo en cascada

Esta metodología permite estructurar la organización de forma clara en aquellos proyectos
de desarrollo en los que las diversas fases de proyecto se diferencian claramente entre sí.
Como cada una de las fases concluye con un hito, el proceso de desarrollo es muy fácil de
comprender. El punto clave del modelo reside en la documentación de todos y cada uno de
los pasos de proceso. Los conocimientos adquiridos se registran en pliegos de requisitos o
borradores preliminares.

En teoría, el desarrollo en cascada pretende crear los requisitos previos para una ejecución
rápida y rentable de los proyectos a través de una cuidada planificación previa. Sin
embargo, la utilización del modelo en la práctica es controvertida. Por una parte, en el
desarrollo de software las fases de proyecto no suelen estar claramente diferenciadas entre sí.
Es precisamente en los proyectos de software más complejos donde los desarrolladores se
suelen enfrentar al hecho de que los diversos componentes de una misma aplicación se
encuentran en diferentes fases de desarrollo al mismo tiempo. Por otra parte, la secuencia
lineal del waterfall model no suele coincidir con la realidad.

En sentido estricto, el modelo en cascada no prevé la realización de ajustes a lo largo del

proyecto. Sin embargo, un proyecto de software en el que todos los detalles del desarrollo se
definieran al comienzo, solo podría concluir con éxito si desde el principio se invirtiera una
gran cantidad de tiempo y dinero en análisis y diseño. A todo esto, se añade que los proyectos
de software de más envergadura se suelen prolongar durante varios años y, de no adaptarse
a los avances más actuales, obtendrían resultados que ya estarían obsoletos en el
momento de su aplicación.

Resumen de las ventajas y desventajas del modelo en cascada

Ventajas Inconvenientes

✔ Una estructura sencilla gracias a unas fases de ✘ Por norma general, los proyectos más complejos o
proyecto claramente diferenciadas. de varios niveles no permiten su división en fases de
proyecto claramente diferenciadas.

✔ Buena documentación del proceso de desarrollo ✘ Poco margen para realizar ajustes a lo largo de
 Ventajas Inconvenientes

a través de unos hitos bien definidos. proyecto debido a un cambio en las exigencias.

✔ Los costes y la carga de trabajo se pueden ✘El usuario final no se integra en el proceso de
estimar al comenzar el proyecto. producción hasta que no termina la programación.

✔ Aquellos proyectos que se estructuran en base al ✘En ocasiones, los fallos solo se detectan una vez
modelo en cascada se pueden representar finalizado el proceso de desarrollo.
cronológicamente de forma sencilla.

La metodología en cascada se suele emplear, especialmente, en aquellos proyectos cuyos

requisitos y procesos se pueden describir de forma precisa durante la fase de planificación, en
los que cabe suponer que las hipótesis no van a sufrir una gran variación durante el
transcurso del proyecto. Los procedimientos estrictamente lineales se adaptan, así,
especialmente bien a proyectos de software pequeños, sencillos y claramente
estructurados. A esta misma conclusión llegó Royce en los años 1970. Por este motivo, la
alternativa al procedimiento lineal que propuso, y que más tarde se conocería como waterfall
model, incluía tres ampliaciones principales:

Verificación tras cada fase de proyecto

Según Royce, los resultados de cada una de las fases de proyecto se deben comparar y
verificar inmediatamente con los documentos elaborados previamente. Es decir,
inmediatamente después de desarrollar un módulo, por ejemplo, se debería garantizar que
este cumple con las exigencias definidas con anterioridad sin esperar a que concluya el
proceso de desarrollo.

Al menos, dos iteraciones

Según Royce, el modelo se debería ejecutar en, al menos, dos ocasiones: primero
para elaborar un prototipo y, a continuación, para desarrollar el producto de software en
sí.

Pruebas que incluyen al usuario final

La tercera ampliación del modelo en cascada propuesta por Royce en su ensayo es una
medida que, a día de hoy, se ha convertido en un procedimiento estándar en el desarrollo de
productos: la inclusión del usuario final en el proceso de producción. Royce propone incluir al
usuario en tres momentos diferentes del proceso de desarrollo de software: durante la
planificación del software en la fase de análisis, entre el diseño del software y su
implementación y en la fase de prueba que precede al lanzamiento del software.

Procedimientos alternativos al modelo en cascada

Debido a la secuencia estrictamente lineal de las fases sucesivas de proyecto, el modelo en
cascada se adaptaría, en el mejor de los casos, a proyectos de software de poca
envergadura. Por el contrario, los procesos complejos de varios niveles serían difícilmente
representables con este modelo. Por este motivo, con el paso del tiempo han ido surgiendo
enfoques alternativos.

Mientras que algunos modelos, como el modelo en espiral o el modelo en V, se consideran

una evolución del waterfall model clásico, algunos métodos, como la programación
extrema, el desarrollo ágil de software o el desarrollo iterativo, se centran en un enfoque
completamente diferente y suelen permitir una adaptación a los cambios más recientes o a las
exigencias más actuales.