ing de sistemas

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. Estasdiferencias 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 lostextos 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ássignificativas 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ñoy 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
existandos 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. Queuna 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 atratar 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 construir por iteraciones y el uso de prototipos incrementales.
A la mayoría delos diseños de las ingenierías clásicas, arquitecturas, etc., no les sucede
esto porque pueden hacer un mayor uso de las matemáticas, en software no es así. Y
aunque se pretenda emular ese modo de fabricación, en software no funciona bien, y
debemos tener muy claro que es casi imposible cerrar un diseño a la primera para pasarlo
a codificación sin tener que modificarlo. Así que, salvo que sedescubra algo nuevo, el
sueño de construir software igual que en una cadena de montaje se construyen coches…
no es realista.
Dos razones por las que fabricar software no es lo mismo que fabricar coches o construir casas (2/2)
Archivado en gestión de proyectos en Feb.08, 2011 por jgarzas

2 – La diferente distribución de los costes del proyecto.
Por lo general, realizar un cambio en el...