CASCADA Reid Holmes Traducción: Jorge Pincay Ponce
1
Hay diversos modelos disponibles para la estructuración del desarrollo de productos de software, pero pueden dividirse en dos categorías de alto nivel. • •
Tradicional incluye cosas como cascada y espiral, La más moderna que incluye procesos como XP, TDD y Scrum.
Es importante tener en cuenta que no hay un solo proceso como verdad absoluta y que el proceso que cualquier equipo elige seguir va a variar según sus propias limitaciones, experiencia y lo que debe suceder dentro del producto en sí. En este artículo revisaremos un poco más a detalle al modelo conocido como Cascada (Waterfall), que se considera una metodología de desarrollo de software clásica y que ha sido adaptada de campos de ingeniería más tradicionales. Esta metodología va de un paso al siguiente al siguiente en el proceso de desarrollo de software sin dar un paso atrás. Por lo tanto, si seguimos esta metodología debemos asegurarnos de que cada paso sea terminado hasta su finalización antes de continuar con la siguiente fase del proyecto.
La metodología empieza con una fase de refinamiento de requisitos, donde se va a reunir todos los requisitos para el sistema y una vez que todo está unido construimos un documento de especificación completo, con el cual pasamos al diseño. En la fase de diseño, vamos a “consumir” el documento de especificación y diseñar el sistema, es decir sus componentes: clases, métodos, campos y todas las diferentes partes del sistema. Y una vez que esté listo, pasaremos a la implementación. En la fase de implementación, tomaremos toda esta documentación de diseño y se le daremos al equipo de desarrollo, quienes la usarán para escribir el código en el sistema y prepararlo para la verificación.
2 En la fase verificación se tomará la especificación definida anteriormente y se presentará un conjunto de planes de prueba, para usarlo y verificar que la implementación sea correcta. Y una vez que tenemos una implementación en funcionamiento, el sistema “se transmitirá” de manera intermitente al equipo de mantenimiento que “evolucionará” el sistema a través del tiempo. Ahora, una gran desventaja de este proceso es que llegamos al final sin saber si el sistema construido es realmente útil en la práctica, incluso en ocasiones el tiempo de desarrollo del producto software pudo haber sido largo. Otro desafío del modelo Cascada es que la resistencia a retroceder a una etapa anterior puede ser realmente problemática en la práctica. Por ejemplo, si cambian las condiciones comerciales, no vamos a querer retroceder, dar un paso atrás y cambiar los requisitos, lo que puede ser realmente perjudicial para el producto final… Por lo visto, el modelo de cascada es extremadamente resistente al cambio. Ahora bien, es bueno destacar algunos aspectos positivos y es que debido a que todas las fases del modelo de Cascada son muy distintas, es fácil entender lo que realmente está sucediendo en el desarrollo del sistema en cualquier momento dado. Otro detalle agradable es que en este modelo hay una transferencia clara y explícita entre cada una de estas fases, así, cuando pasamos de la especificación de los requisitos al diseño, sabemos exactamente lo que contiene ese documento resultante explícitamente firmado para que el equipo de diseño lo reciba. De la misma forma en que pasamos del diseño a la implementación con un documento completo y bien pensado. La claridad entre cada una de las fases es agradable, sin embargo, eso mismo es lo que hace que sea muy difícil volver a “visitar” una fase terminada para por ejemplo cambiar el diseño o los requisitos en el proceso. En conclusión, hay una compensación que hace que Cascada sea un desafío para muchos sistemas modernos en donde se quiere ser más ágiles y receptivos ante las necesidades de los clientes y usuarios.