Dos razones por las que fabricar software no es lo mismo que fabricar coches o construir casas

Dos razones por las que fabricar software no es lo mismo que fabricar coches o construir casas (1/2)

Archivado en gestión de proyectos en Feb.07, 2011 por jgarzas

Construir software no es igual que construir un puente, un edificio o un coche. Y

difícilmente llegará a serlo. Porque el producto final, el software, tiene diferencias muy

sustanciales con estos productos físicos. Estas diferencias hacen que el proceso de

construcción sea diferente. Y obviar estas diferencias puede implicar importantes

problemas a la hora de desarrollar, planificar, gestionar, etc., un proyecto software.

Diferenciar el cómo se construye el software de cómo se construyen los productos físicos

es además uno de los pilares de las metodologías ágiles. Y un tema del que se ha escrito

mucho; uno de los textos que personalmente más me gustaron cuando lo leí hace tiempo

es “la nueva metodología” de Fowler, del que se extraen muchas ideas de este post. Y

también se ha debatido bastante (de hecho, la idea de este post viene de un comentario

de @joserra_biko), con posturas a favor y en contra.

Y aunque seguro que habrá muchas más razones, os dejo dos, las dos que en mi opinión

son más significativas del porqué fabricar software no es lo mismo que fabricar coches o

construir casas: La diferente separación entre diseño y construcción y la diferente

distribución de los costes del proyecto.

1 - La diferente separación entre diseño y construcción

En ingeniería software, a diferencia de en la arquitectura u otras ingenierías tradicionales,

no se puede separar tan claramente la fase de diseño y de la de construcción. Las

ingenierías clásicas precisan mucho de un diseño previo a la construcción, el disponer de

los planos del arquitecto siempre antes de empezar el edificio. Los planos para construir

son precisos. Y los realizan personas ajenas a la fase de construcción (los arquitectos). La

construcción tiene poco componente intelectual y mucho manual. Y todo esto hace que

existan dos actividades claramente diferenciadas: el diseño y la construcción.

Desde sus orígenes, la ingeniería del software intentó perseverantemente emular a las

ingenierías clásicas. Tener una fase de diseño muy separada de la codificación. Que la

codificación no comenzase hasta que terminase el diseño. Que el diseño concluya con

unos planos precisos que guíen totalmente la construcción. Que una vez que se hace un

diseño este no se modifique. De hecho, notaciones para “planos” como UML y ciclos de

vida como el cascada puro (donde cada fase se hace una sola vez y no se pasa a la

siguiente fase hasta que se termina la previa) nacieron con este objetivo.

Pero en software está demostrado que es muy difícil especificar en la una única y primera

fase de diseño todas las cuestiones a tratar en la programación. Por la complejidad de

muchas de las reglas de negocio que automatizamos cuando construimos software es muy

difícil saber qué software se quiere hasta que se trabaja en su implementación. De ahí que

en software diseño y construcción se solapen, y que por ello que muchas veces se

recomiende

...