Las aventuras del Modelo en Cascada
Dedicado a algunos profesores de universidad
Muchos hemos estado ahí: hemos finalizado nuestro curso de “Desarrollo de Proyectos Informáticos”, “Taller de Desarrollo”, “Diseño de Sistemas” o alguno similar. Ha sido una tarea ardua de casi cinco meses, pero felizmente, no estamos solos.
Junto a nuestro equipo, nos acompaña un documento. El nuestro es extenso: casi cuatrocientas páginas. No hemos podido desarrollar mucho de la aplicación en sí — tal vez algunos formularios y un sistema de inicio de sesión. Pero eso no está mal. Otros grupos solo pudieron armar bocetos de sus vistas en Excel. Lo realmente importante es que tenemos el documento completo.
¿Y qué podría salir mal? Hemos analizado cuidadosamente los requisitos, armado artefacto tras artefacto y señalizado cada condicional en flujos y diagramas de secuencia. Sólo queda convertir eso en realidad y, claro está, eso es sólo un mero detalle de implementación.
Sin embargo, algo no llega a aterrizar bien. A veces, algunas de las personas entrevistadas cambiaron su impresión a mediados de nuestro proceso de análisis. No hay tiempo de actualizar todos los gráficos y especificaciones de nuestros casos de uso, así que lo resolveremos como ajustes que se harán luego de la versión inicial. Es cierto: el software ya no sería tan útil para lo que realmente necesitan, pero eso debieron tenerlo en cuenta la primera vez.
Finalmente, hemos seguido la teoría que nos explicaron nuestros profesores. Evidentemente debemos analizar todo para luego poder diseñar esa solución. Hacer un paso luego del otro para crear software es lo que nos separa de los animales en el bosque. No podrían estar equivocados.
¿O sí?
El proceso de desarrollo en cascada
Hablar en absolutos es una tarea complicada, pero conocer algo de historia nos podría ayudar a entender un poco los temas que alguna vez nos enseñaron. Porque hay una teoría en particular que marcó nuestra industria y buena parte de adopción, se basó simplemente, en un error de lectura.
Se pueden rastrear los inicios de lo que se conoce como desarrollo en cascada a un paper publicado en 1970 por el Dr. Winston W. Royce. Titulado “Managing the Development of Large Software Systems”, el documento nos describe su visión sobre el desarrollo de software en base a la experiencia de casi 9 años, y nos plantea las ventajas de un proceso de creación de software basado en etapas. El proceso en Waterfall (en cascada). Son ocho páginas que podemos leer si seguimos el enlace anterior, y donde encontramos, entre otros, el siguiente gráfico:
Es un gráfico familiar. Casi toda persona que ha estudiado un curso de los antes mencionados lo ha visto, y lo ha memorizado para alguna calificación.
Una parte de nuestra carrera se ha construido en base a esas ideas y muchos profesores te mirarían mal si comentas que tal vez se podrían saltar alguno de ellos. Eso no se hace.
Antes de presentar ese gráfico, el paper realmente introduce el modelo de esta manera:
Difícilmente alguien se negaría a esta representación. Un proyecto (pequeño) fácilmente se podría llevar a cabo con un ciclo corto de análisis y luego un proceso de implementación.
Si leemos un poco más, encontraremos una cita interesante:
I believe in this concept, but the implementation described above is risky and invites failure.
¿Realmente el paper que describe como funcionaría el modelo en Cascada estaría criticándolo? Algo cercano a eso. La intención original del Dr. Winston es presentar un modelo que existía, y comentar sobre los problemas que identificaba, además de cómo potencialmente resolverlos.
Por ejemplo, prontamente nos describe que el gráfico secuencial que hemos estudiado, no siempre se realiza de esa forma en la vida real:
Esa es una visión más real a lo que podemos ver en nuestro día a día. Los requisitos cambian, y debemos variar la forma en que nuestro programa se comporta, o muchas veces introducimos errores que para ser resueltos requieren una reestructuración de nuestra arquitectura.
Un punto más interesante aún es que el paper realmente nos describe sugerencias a este modelo, que podríamos identificar como ideas de lo que ahora se conoce como parte del pensamiento ágil. Por ejemplo:
Without question, the biggest user of project resources, whether it be manpower, computer time, or management judgment, is the test phase. It is the phase of greatest risk in terms of dollars and schedule. It occurs at the latest point in the schedule when backup alternatives are least available, if at all.
E incluso podemos visualizar la innovadora idea de involucrar al cliente en el proceso:
For some reason what a software design is going to do is subject to wide interpretation even after previous agreement. It is important to involve the customer in a formal way so that he has committed himself at earlier points before final delivery. To give the contractor free rein between requirement
definition and operation is inviting trouble.
Y, finalmente, una cita que a mi parecer describe realmente su opinión sobre Waterfall:
The required design changes are likely to be so disruptive that the
software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modified, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a 100%-percent overrun in schedule and/or costs.
Evidentemente Winston Royce no era un desarrollador de métodos ágiles. Varias ideas que describe podrían no ser tomadas como tal en este día. Pero lo importante es identificar que, desde su incepción, realmente había una crítica a un modelo que finalmente se volvió uno de los más enseñados, y probablemente aplicados en distintos ámbitos. ¿Qué pasó entonces?
Back to the past
¿Cómo un documento que define correcciones a un modelo se vuelve la raíz de ese mismo modelo, usado irónicamente para sustentarlo?
Tratar de explicar eso nos obliga a seguir regresando al pasado y a las oficinas del Departamento de Defensa de Estados Unidos. En esas épocas, las necesidades de estandarizar los procesos informáticos en las diversas áreas que la componían, obligó al DoD a investigar formas de creación de software.
Una de los documentos revisados es justamente el que nos trae a este artículo. Entre revisión y revisión, el documento fue pasado entre mano y mano, siendo leía la primera página (aquella que comenta los puntos positivos del modelo), revisada la segunda (donde encontramos nuestro famoso gráfico) y finalmente, pasada a la siguiente persona hasta que, eventualmente, se convierte en el proceso aceptado y utilizado por toda la institución.
Su adopción no duró mucho. En 1986 se genera un borrador de nuevas indicaciones donde se aboga por dejar de emplear el modelo Waterfall y buscarse enfocar más en uno que incluya procesos de prototipado rápido. Pero el daño ya estaba hecho. Pronto, las universidades tomaron el modelo y se impuso en diversas clases. Organizaciones lo adoptaron también y se volvió un requisito para el software que debería ser creado y presentado, expandiéndose así a las empresas que lo construían, hasta finalmente llegar a nuestros salones.
Where do we go from here?
¿Qué significa esto? Conocemos ahora un poco mejor la historia de lo que usamos, y sería genial que eventualmente las ideas reales de Winston Royce llegue a nuestras aulas, presentando el modelo en cascada como lo que es, con sus desventajas, e incorporando otros más como parte de la currícula.
Ahora podemos revisar nuestro documento como lo que es: una fotografía en el tiempo de las necesidades de un proyecto, que podrían o no mantenerse a lo largo de éste.
Y más importante aún, ahora sabemos que, finalmente, siempre es bueno cuestionar todo lo que aprendemos, leemos y usamos. Hay contextos para todo. Un enfoque secuencial y en cascada podría funcionar perfectamente en un ambiente donde las necesidades son fijas y nunca cambiantes, y es importante cerrar una fase antes de ir a una siguiente. Los contextos científicos se podrían beneficiar de esto.
De esa forma, aceptar ciegamente algo nunca es una buena idea. Aunque te lo digan tus profesores. O este artículo. Nunca podremos estar seguros sin investigar bien si estamos ante una genial idea, o el resultado de un pequeño error de lectura que cambió — un poco— una industria.
