Prácticamente desde el comienzo de la historia de desarrollo de software, la comparación con la construcción civil ha sido ampliamente utilizada para describir este tipo de proyecto. Sin embargo, son trabajos de naturalezas muy distintas.
Aunque hayan evolucionado a lo largo de los siglos, los proyectos de construcción existen desde hace décadas en la historia de la humanidad.
Y, en términos generales, su forma de ejecución se ha mantenido igual: una larga fase de definiciones y especificaciones al principio que tiene como resultado un plan, seguida de su fase de ejecución.
Parece natural que un ser humano compare otros tipos de trabajo con uno que le sea familiar.
Los métodos tradicionales de desarrollo de software buscaron algo similar con el modelo en cascada y sus fases secuenciales de recopilación y análisis de requisitos, especificación, desarrollo y pruebas.
Incluso hoy en día es común utilizar las expresiones “ingeniería o ingeniero de software”, “arquitectura o arquitecto de software”. E incluso “construcción de software”, todos provenientes de la analogía de la construcción civil.
¿Por qué no funcionan los métodos tradicionales de desarrollo de software?
El libro Wicked Problems, Righteous Solutions (DeGrace & Stall, 1990 apud. Sutherland, 2004) ya describía en 1990 las razones por las que los métodos tradicionales de desarrollo de software no funcionan, partiendo de sus prerrogativas básicas:
- los requisitos no se entienden completamente antes de que comience el proyecto;
- los usuarios solo saben exactamente lo que quieren después de ver una versión inicial del producto;
- los requisitos cambian con frecuencia durante el proceso de desarrollo;
- las nuevas herramientas y tecnologías hacen que las estrategias de desarrollo sean impredecibles.
Sabemos, por lo tanto, que comparar proyectos de desarrollo de software con proyectos de construcción civil no tiene sentido. La analogía simplemente no va.
