Los desarrollos o modelos en cascada como RUP (Rational Unified Process) y Métrica v3 eran las metodologías de desarrollo software más ampliamente usadas en la industria hasta los años 2000. Se les llamaba así, en cascada, porque este enfoque metodológico ordena de forma rigurosa las etapas del proceso de desarrollo de modo que una no podía comenzar hasta concluir la anterior. Estas etapas quedaban así dispuestas de forma que, casi sugiriendo gravedad, el desarrollo iba “cayendo” de una fase a otra.
Las fases del modelo en cascada son más o menos así:
Análisis de requisitos
Diseño del sistema
Codificación
Pruebas
Implementación
Mantenimiento
Pero ¿qué sucedía si había un error en el diseño o se entendió mal un requisito? ¿Y si al unir todas las piezas juntas en la fase de codificación, se percibe que durante las pruebas no se integran bien? Es una fase muy tardía y ahora habría que comenzar todo el trabajo desde el principio o rehacer buena parte de lo que ya se ha hecho.
En mis años trabajando para Administraciones Públicas me tocó sufrir particularmente Métrica 3. Era una metodología definida por el Consejo Superior de Informática del Gobierno de España por lo que era habitual que se exigiese en numerosos contratos públicos pero ¿Lograba mejores proyectos? Sinceramente creo que no. Sólo soluciones mastodónticas, poco flexibles y con toneladas de documentación.
Probablemente nadie se leyó nunca todos esos tomos de documentación, los hojearían a lo sumo para comprobar que se decían cosas coherentes y no era sólo relleno. Y no los culpo, creo que quién debía revisar todos esos papeles intentaba hacer bien su trabajo, pero leer documentos no les iba a ayudar a saber si se había hecho un buen producto. Era mejor dedicar ese tiempo a entrar en la aplicación, probarla, usarla y ver si de verdad era útil o no.
Esas toneladas de papel tampoco eran útiles en el momento del desarrollo. Se creaban al inicio del proyecto se pasaban a los programadores y ahí comenzaban a surgir dudas, cambios, incoherencias. Se intentaba mantener la documentación actualizada pero no era práctico. Siempre resultaba mejor un boceto rápido y una conversación con el analista o con el cliente. La documentación terminaba siempre actualizada a posteriori, después de haberse tomado una decisión y haber sido puesta en práctica en el desarrollo.
En la imagen puede verse parte del ya popular chiste sobre los malentendidos en la gestión de requisitos software donde cada participante entiende lo que hay que hacer de manera distinta.
Fuente: CVR/IT
Es muy popular este chiste sobre la toma de requisitos en el software, pero es sólo un chiste ¿o no? ¿Y si el software pasa la fase de pruebas porque todos los requisitos están implementados y llega a la fase de operaciones y mantenimiento? Para entonces los usuarios finales habrán comenzado a usarlo y pueden estar pensando “Esto no es lo que yo les dije, no me entendieron bien”, “Esto no es lo que necesito”. Ya es demasiado tarde. Se ha invertido una cantidad enorme de tiempo y dinero en poner en producción un software con las ideas que se explicaron verbalmente al analista quizás uno o dos años antes. Ahora se comprueba que no cumple las funciones para las que fue pensado ¿Qué sentido tiene hacer las cosas así?
Referencias:
- Metodologías en los 80 y en los 90 de Javier Garzás.
