El modelo en cascada: de­sa­rro­llo se­cue­n­cial de software

El término “waterfall model” hace re­fe­re­n­cia a un pro­ce­di­mie­n­to se­cue­n­cial que permite re­pre­se­n­tar un proyecto en base a unas fases que se suceden entre sí.

El de­sa­rro­llo en cascada (en inglés, waterfall model) es un pro­ce­di­mie­n­to lineal que se ca­ra­c­te­ri­za por dividir los procesos de de­sa­rro­llo en sucesivas fases de proyecto. Al contrario que en los modelos ite­ra­ti­vos, cada una de estas fases se ejecuta tan solo una vez. Los re­su­l­ta­dos de cada una de las fases sirven como hipótesis de partida para la siguiente. El waterfall model se utiliza, es­pe­cia­l­me­n­te, en el de­sa­rro­llo de software.

El de­sa­rro­llo del modelo se atribuye al teórico de la in­fo­r­má­ti­ca Winston W. Royce. Sin embargo, Royce no es el inventor de este modelo. Muy al contrario, en su ensayo de 1970 titulado Managing the De­ve­lo­p­me­nt of Large Software Systems, el teórico presenta una reflexión crítica acerca de los pro­ce­di­mie­n­tos lineales. A modo de al­te­r­na­ti­va, Royce presenta un modelo iterativo in­cre­me­n­tal en el que cada una de las fases se basa en la anterior y verifica los re­su­l­ta­dos de esta.

Royce propone un modelo compuesto por siete fases que se ha de ejecutar en diversas vueltas (ite­ra­cio­nes):

1. Re­qui­si­tos de sistema
2. Re­qui­si­tos de software
3. Análisis
4. Diseño
5. Im­ple­me­n­ta­ción
6. Prueba
7. Servicio

El pro­ce­di­mie­n­to po­pu­la­r­me­n­te 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.

En las am­plia­cio­nes de la me­to­do­lo­gía en cascada se añaden funciones ite­ra­ti­vas al modelo básico como, por ejemplo, los saltos hacia atrás, que permiten comparar los re­su­l­ta­dos de cada una de las fases con las hipótesis obtenidas en la fase anterior, de modo que se puedan verificar.

En este modelo, las di­fe­re­n­tes fases de un proceso de de­sa­rro­llo se suceden una detrás de otra como en una cascada. Cada una de las fases concluye con un resultado pro­vi­sio­nal (hito) como, por ejemplo, un catálogo de re­qui­si­tos en forma de pliego de co­n­di­cio­nes, la es­pe­ci­fi­ca­ción de una ar­qui­te­c­tu­ra de software o una apli­ca­ción a nivel alfa o beta.

Todo proyecto de software comienza con una fase de análisis que incluye un estudio de via­bi­li­dad y una de­fi­ni­ción de los re­qui­si­tos. En el estudio de via­bi­li­dad se evalúan los costes, la re­n­ta­bi­li­dad y la fa­c­ti­bi­li­dad del proyecto de software. El estudio de via­bi­li­dad da como resultado un pliego de co­n­di­cio­nes (una de­s­cri­p­ción general de los re­qui­si­tos), un plan y una es­ti­ma­ción fi­na­n­cie­ra del proyecto, así como una propuesta para el cliente, si fuera necesario.

A co­n­ti­nua­ción, se realiza una de­fi­ni­ción detallada de los re­qui­si­tos, in­clu­ye­n­do un análisis de la situación de salida y un concepto. Mientras que los análisis de salida se encargan de describir la pro­ble­má­ti­ca en sí, el concepto ha de definir qué funciones y ca­ra­c­te­rí­s­ti­cas debe ofrecer el producto de software para cumplir con las co­rre­s­po­n­die­n­tes exi­ge­n­cias. La de­fi­ni­ción de los re­qui­si­tos da como resultado un pliego de co­n­di­cio­nes, una de­s­cri­p­ción detallada de cómo se han de cumplir los re­qui­si­tos del proyecto, así como un plan para la prueba de ace­p­ta­ción, entre otros.

Por último, la primera fase del waterfall model incluye un análisis de la de­fi­ni­ción de los re­qui­si­tos en el que los problemas complejos se dividen en pequeñas tareas se­cu­n­da­rias y se elaboran las co­rre­s­po­n­die­n­tes es­tra­te­gias de re­so­lu­ción.

La fase de diseño sirve para formular una solución es­pe­cí­fi­ca en base a las exi­ge­n­cias, tareas y es­tra­te­gias definidas en la fase anterior. En esta fase, los de­sa­rro­lla­do­res de software se encargan de diseñar la ar­qui­te­c­tu­ra de software, así como un plan de diseño detallado del mismo, ce­n­trá­n­do­se en co­m­po­ne­n­tes concretos, como in­te­r­fa­ces, entornos de trabajo o bi­blio­te­cas. La fase de diseño da como resultado un borrador pre­li­mi­nar con el plan de diseño del software, así como planes de prueba para los di­fe­re­n­tes co­m­po­ne­n­tes.

La ar­qui­te­c­tu­ra de software concebida en la fase de diseño se ejecuta en la fase de im­ple­me­n­ta­ción, en la que se incluye la pro­gra­ma­ción del software, la búsqueda de errores y las pruebas unitarias. En la fase de im­ple­me­n­ta­ción, el proyecto de software se traduce al co­rre­s­po­n­die­n­te lenguaje de pro­gra­ma­ción. Los diversos co­m­po­ne­n­tes se de­sa­rro­llan por separado, se co­m­prue­ban a través de las pruebas unitarias y se integran poco a poco en el producto final. La fase de im­ple­me­n­ta­ción da como resultado un producto de software que se comprueba por primera vez como producto final en la siguiente fase (prueba alfa).

La fase de prueba incluye la in­te­gra­ción del software en el entorno se­le­c­cio­na­do. Por norma general, los productos de software se envían en primer lugar a los usuarios finales se­le­c­cio­na­dos en versión beta (pruebas beta). Las pruebas de ace­p­ta­ción de­sa­rro­lla­das en la fase de análisis permiten de­te­r­mi­nar si el software cumple con las exi­ge­n­cias definidas con an­te­rio­ri­dad. Aquellos productos de software que superan con éxito las pruebas beta están listos para su la­n­za­mie­n­to.

Una vez que la fase de prueba ha concluido con éxito, se autoriza la apli­ca­ción pro­du­c­ti­va del software. La última fase del modelo en cascada incluye la entrega, el ma­n­te­ni­mie­n­to y la mejora del software.

Esta me­to­do­lo­gía permite es­tru­c­tu­rar la or­ga­ni­za­ción de forma clara en aquellos proyectos de de­sa­rro­llo en los que las diversas fases de proyecto se di­fe­re­n­cian cla­ra­me­n­te entre sí. Como cada una de las fases concluye con un hito, el proceso de de­sa­rro­llo es muy fácil de co­m­pre­n­der. El punto clave del modelo reside en la do­cu­me­n­ta­ción de todos y cada uno de los pasos de proceso. Los co­no­ci­mie­n­tos ad­qui­ri­dos se registran en pliegos de re­qui­si­tos o bo­rra­do­res pre­li­mi­na­res.

En teoría, el de­sa­rro­llo en cascada pretende crear los re­qui­si­tos previos para una ejecución rápida y rentable de los proyectos a través de una cuidada pla­ni­fi­ca­ción previa. Sin embargo, la uti­li­za­ción del modelo en la práctica es co­n­tro­ve­r­ti­da. Por una parte, en el de­sa­rro­llo de software las fases de proyecto no suelen estar cla­ra­me­n­te di­fe­re­n­cia­das entre sí. Es pre­ci­sa­me­n­te en los proyectos de software más complejos donde los de­sa­rro­lla­do­res se suelen enfrentar al hecho de que los diversos co­m­po­ne­n­tes de una misma apli­ca­ción se en­cue­n­tran en di­fe­re­n­tes fases de de­sa­rro­llo 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 rea­li­za­ción de ajustes a lo largo del proyecto. Sin embargo, un proyecto de software en el que todos los detalles del de­sa­rro­llo se de­fi­nie­ran al comienzo, solo podría concluir con éxito si desde el principio se in­vi­r­tie­ra 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 en­ve­r­ga­du­ra se suelen prolongar durante varios años y, de no adaptarse a los avances más actuales, ob­te­n­drían re­su­l­ta­dos que ya estarían obsoletos en el momento de su apli­ca­ción.

La me­to­do­lo­gía en cascada se suele emplear, es­pe­cia­l­me­n­te, en aquellos proyectos cuyos re­qui­si­tos y procesos se pueden describir de forma precisa durante la fase de pla­ni­fi­ca­ción, en los que cabe suponer que las hipótesis no van a sufrir una gran variación durante el tra­n­s­cu­r­so del proyecto. Los pro­ce­di­mie­n­tos es­tri­c­ta­me­n­te lineales se adaptan, así, es­pe­cia­l­me­n­te bien a proyectos de software pequeños, sencillos y cla­ra­me­n­te es­tru­c­tu­ra­dos. A esta misma co­n­clu­sión llegó Royce en los años 1970. Por este motivo, la al­te­r­na­ti­va al pro­ce­di­mie­n­to lineal que propuso, y que más tarde se conocería como waterfall model, incluía tres am­plia­cio­nes pri­n­ci­pa­les:

Según Royce, los re­su­l­ta­dos de cada una de las fases de proyecto se deben comparar y verificar in­me­dia­ta­me­n­te con los do­cu­me­n­tos ela­bo­ra­dos pre­via­me­n­te. Es decir, in­me­dia­ta­me­n­te después de de­sa­rro­llar un módulo, por ejemplo, se debería ga­ra­n­ti­zar que este cumple con las exi­ge­n­cias definidas con an­te­rio­ri­dad sin esperar a que concluya el proceso de de­sa­rro­llo.

Según Royce, el modelo se debería ejecutar en, al menos, dos ocasiones: primero para elaborar un prototipo y, a co­n­ti­nua­ción, para de­sa­rro­llar el producto de software en sí.

La tercera am­plia­ción del modelo en cascada propuesta por Royce en su ensayo es una medida que, a día de hoy, se ha co­n­ve­r­ti­do en un pro­ce­di­mie­n­to estándar en el de­sa­rro­llo de productos: la inclusión del usuario final en el proceso de pro­du­c­ción. Royce propone incluir al usuario en tres momentos di­fe­re­n­tes del proceso de de­sa­rro­llo de software: durante la pla­ni­fi­ca­ción del software en la fase de análisis, entre el diseño del software y su im­ple­me­n­ta­ción y en la fase de prueba que precede al la­n­za­mie­n­to del software.

Debido a la secuencia es­tri­c­ta­me­n­te 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 en­ve­r­ga­du­ra. Por el contrario, los procesos complejos de varios niveles serían di­fí­ci­l­me­n­te re­pre­se­n­ta­bles con este modelo. Por este motivo, con el paso del tiempo han ido surgiendo enfoques al­te­r­na­ti­vos.

Mientras que algunos modelos, como el modelo en espiral o el modelo en V, se co­n­si­de­ran una evolución del waterfall model clásico, algunos métodos, como la pro­gra­ma­ción extrema, el de­sa­rro­llo ágil de software o el de­sa­rro­llo iterativo, se centran en un enfoque co­m­ple­ta­me­n­te diferente y suelen permitir una ada­p­ta­ción a los cambios más recientes o a las exi­ge­n­cias más actuales.