El blog de eLafo

Si tomáramos el proceso de desarrollo de software y lo destiláramos hasta quedarnos con su esencia, uno podría concluir que éste no consiste en otra cosa sino en capturar un conjunto de requisitos funcionales escritos en leguaje humano y traducirlos a un lenguaje que pueda entender una máquina, la cuál se encargaría de ponerlos en marcha.

Podría también concluir que cada vez que se añade, elimina o modifica un requisito tendriamos un sistema completamente nuevo, independiente del que existiera anteriormente. En cada momento de su historia, el software no sería otra cosa más que el conjunto de requisitos que lo conforman en ese mismo momento traducidos a algún tipo de lenguaje “máquina”.

Podría además asumir que el histórico es irrelevante. Lo que importa es cuáles son los requisitos hoy, independientemente de cuáles fueran ayer. O, dicho de otra forma, desde un punto de vista puramente teórico, cada vez que se introdujera un cambio en las especificaciones del sistema deberíamos ser perfectamente capaces de reconstruirlo desde cero.

Sin embargo, como toda teoría que se precie, ésta tiene sus limitaciones cuando se intenta aplicar en el mundo real®.

Llevo las últimas semanas enfrascado en entender de forma más profunda en qué consiste eso que llamamos calidad. Y más concretamente en qué consiste la calidad del software y cómo podemos aumentar la calidad de un proyecto software.

Éste es el primero de una serie de posts que he decidido empezar a escribir y dice así:

No he encontrado evidencia ahí fuera de que el TDD mejore ni la productividad ni la calidad del desarrollo de software. De hecho creo que no se puede conseguir porque el desarrollo de software es algo tan complejo que no tenemos la capacidad para realizar experimentos fiables.