Fred Brooks comenta:
Gran parte del procedimiento actual de adquisición de software se basa en la suposición de que se puede especificar un sistema satisfactorio de antemano, obtener ofertas para su construcción, mandarlo construir e instalarlo. Creo que esta suposición es fundamentalmente errónea, y que muchos problemas de adquisición de software se derivan de esa falacia. Por lo tanto, no pueden solucionarse sin una revisión fundamental que permita el desarrollo iterativo y la especificación de prototipos y productos.
Desarrollo incremental: hacer crecer, no construir, el software. Aún recuerdo la sacudida que sentí en 1958 cuando escuché por primera vez a un amigo hablar de construir un programa, en lugar de escribirlo. En un abrir y cerrar de ojos, amplió toda mi visión del proceso del software. El cambio de metáfora fue poderoso y preciso. Hoy comprendemos que la construcción de software se parece a otros procesos de construcción y utilizamos libremente otros elementos de la metáfora, como las especificaciones, el ensamblaje de componentes y el andamiaje.
La metáfora del edificio ha dejado de ser útil. Es hora de cambiar de nuevo. Si, como creo, las estructuras conceptuales que construimos hoy en día son demasiado complicadas para especificarlas con precisión de antemano, y demasiado complejas para construirlas sin fallos, entonces debemos adoptar un enfoque radicalmente distinto.
Recurramos a la naturaleza y estudiemos la complejidad en los seres vivos, en lugar de limitarnos a las obras muertas del hombre. Aquí encontramos construcciones cuya complejidad nos sobrecoge. Sólo el cerebro es más complejo que un mapa, más poderoso que una imitación, rico en diversidad, autoprotector y autorrenovable. El secreto es que se cultiva, no se construye.
Lo mismo debe ocurrir con nuestros sistemas de software. Hace algunos años, Harlan Mills propuso que cualquier sistema de software debería crecer mediante un desarrollo incremental [10]. [10] Es decir, primero hay que hacer que el sistema funcione, aunque no haga nada útil excepto llamar al conjunto adecuado de subprogramas ficticios. Luego, poco a poco, debe ser desarrollado, con los subprogramas a su vez siendo desarrollados - en acciones o llamadas a stubs vacíos en el nivel inferior.
He visto resultados espectaculares desde que empecé a recomendar esta técnica a los constructores de proyectos en mi clase de Laboratorio de Ingeniería de Software. Nada en la última década ha cambiado tan radicalmente mi propia práctica o su eficacia. El enfoque requiere un diseño descendente, ya que se trata de un crecimiento descendente del software. Permite retroceder fácilmente. Se presta a los primeros prototipos. Cada función añadida y cada nueva disposición para datos o circunstancias más complejos crece orgánicamente a partir de lo que ya existe.
Los efectos en la moral son sorprendentes. El entusiasmo salta cuando hay un sistema en marcha, aunque sea sencillo. Los esfuerzos se redoblan cuando aparece en la pantalla la primera imagen de un nuevo sistema de software gráfico, aunque sólo sea un rectángulo. Siempre se tiene, en cada etapa del proceso, un sistema que funciona. Me parece que los equipos pueden crear entidades mucho más complejas en cuatro meses de lo que pueden construir.
Brooks, Frederick P., "No Silver Bullet: Essence and Accidents of Software Engineering", Computer, Vol. 20, No. 4 (abril de 1987) pp. 10-19.
Spanish 
English 
French