secciones

Sobre el desarrollo iterativo de software

En el desarrollo “en cascada” (Waterfall) del software se analizan los requerimientos de los usuarios, se diseña el producto, se programa y finalmente se entrega el producto terminado a los usuarios del mismo. Este es el sistema tradicional de desarrollo, el que se enseña en las universidades, y el utilizado en muchas metodologías “oficiales” como “Metrica” (metodología que se exige en algunos concursos con la administración pública).

El desarrollo iterativo e incremental de software, por contra, se caracteriza por planificar el desarrollo de un programa en “partes”, completando toda la funcionalidad requerida poco a poco, en distintas entregas a los usuarios finales. En “Iterative and Incremental and Development: A Brief History” (pdf, 143kb), se analiza la historia de este sistema (considerado hoy en día por casi todos como mejor que el sistema “en cascada”) desde sus primeras apariciones en los años 50.

Aparte de este repaso histórico, el artículo acusa claramente al desarrollo “en cascada” de ser uno de los principales culpables del alto número de proyectos de software fallidos:

Much of present-day software acquisition procedure rests upon the assumption that one can specify a satisfactory system in advance, get bids for its construction, have it built, and install it. I think this assumption is fundamentally wrong, and that many software acquisition problems spring from that fallacy.

Tanto es así que el propio Departamento de Defensa de los EEUU, uno de los mayores compradores de proyectos de software, ha reconocido estos fallos:

Of a total $37 billion for the sample set, 75% of the projects failed or were never used, and only 2% were used without extensive modification.

Y actualmente (en una normativa del año 2000) recomienda utilizar sistemas iterativos:

There are two approaches, evolutionary and single step [waterfall], to full capability. An evolutionary approach is preferred. … [In this] approach, the ultimate capability delivered to the user is divided into two or more blocks, with increasing increments of capability…software development shall follow an iterative spiral development process in which continually expanding software versions are based on learning from earlier development.

Visto esto ¿porqué no se enseñan métodos iterativos en las universidades españolas como los preferidos? y ¿porqué las contrataciones en la administración pública española se siguen haciendo siguiendo un modelo “en cascada”?

2 Comentarios
mariscal
mariscal
13 diciembre 2003, 23:48 — #1
Bueno, el caso de Métrica versión 3, me atrevería a asegurar que se debe a los contactos que tienen sus creadores.

En cuanto a los métodos y metodologías, pues bueno. Es evidente que muchos proyectos fracasan por los problemas derivados de un diseño completo por anticipado, que luego repercuten durante el resto del ciclo de vida de esa aplicación.

¿Que porqué no se enseña? Pues no lo sé, pero sí sé que en la mía es porque ellos inventaron Métrica ;-)
Juanjo Navarro
16 diciembre 2003, 18:02 — #2
Un par de enlaces que no han salido en el comentario de mariscal (nota mental: añadir una opción de previsualización al comentario):

Métrica versión 3: http://www.csi.map.es/csi/metrica3/index.html

Universidad Carlos III de Madrid: http://www.uc3m.es/

Comentarios cerrados para este artículo

Anterior: Weblogs sobre programación Siguiente: Desarrollo iterativo según Martin Fowler