Fred Brooks comenta:
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. Hence, they cannot be fixed without fundamental revision--revision that provides for iterative development and specification of prototypes and products.
Incremental development--grow, don't build, software. I still remember the jolt I felt in 1958 when I first heard a friend talk about building a program, as opposed to writing one. In a flash he broadened my whole view of the software process. The metaphor shift was powerful, and accurate. Today we understand how like other building processes the construction of software is, and we freely use other elements of the metaphor, such as specifications, assembly of components, and scaffolding.
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.
So it must be with our software-systems. Some years ago Harlan Mills proposed that any software system should be grown by incremental development. [10] That is, the system should first be made to run, even if it does nothing useful except call the proper set of dummy subprograms. Then, bit by bit, it should be fleshed out, with the subprograms in turn being developed--into actions or calls to empty stubs in the level below.
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 (April 1987) pp. 10-19.
Spanish 
English 
French