Por qué no existe un proceso racional de diseño de software

Tobias Mayer señaló un artículo clásico en el scrumdesarrollo grupo en la actualidad. Parnas ha creado muchos artículos que ahora se consideran clásicos en la literatura del desarrollo de software. Este señala muchas de las razones por las que el desarrollo de software es un proceso empírico que requiere un enfoque de inspección y adaptación en contraposición a un diseño inicial riguroso.

Parnas, David L. y Clements, Paul (1986) Un proceso de diseño racional: Cómo y por qué fingirlo. IEEE Transactions

Guardo una copia de la recopilación de artículos de Parnas para recordar que muchos aspectos de lo que hacemos con el Scrum fueron señalados por destacados pensadores de la informática hace 20-30 años. La mayoría de la gente que se dedica al software hoy en día no ha leído ninguno de estos artículos, y por eso seguimos cometiendo errores tontos. Por supuesto, Scrum fue creado por personas que habían leído estos artículos para formalizar lo que se sabía que funcionaba.

Hoffman, Daniel y Weiss, David (2001) Fundamentos del software: Collected Papers de David L. Parnas. Addison-Wesley Professional.

Hay empresas que creen que la cascada les funciona bien y que los proyectos se entregan a tiempo y dentro del presupuesto (el presupuesto es alto, el tiempo es largo y la satisfacción del cliente es baja). Es importante darse cuenta de que han creado una ilusión de proceso predecible. Cuando se mira bajo las sábanas y se habla con las personas que realmente hacen el trabajo, siempre se descubre que se aplican los principios de Parnas.

¿POR QUÉ UN "PROCESO" DE DISEÑO DE SOFTWARE SERÁ SIEMPRE UNA IDEALIZACIÓN?

Nunca veremos un proyecto de software que proceda de forma "racional". A continuación se enumeran algunas de las razones:

(1) En la mayoría de los casos, las personas que encargan la construcción de un sistema informático no saben exactamente lo que quieren y son incapaces de decirnos todo lo que saben.
(2) Aunque conociéramos los requisitos, hay muchos otros datos que necesitamos saber para diseñar el software. Muchos de los detalles sólo los conocemos a medida que avanzamos en la implementación. Algunas de las cosas que aprendemos invalidan nuestro diseño y debemos dar marcha atrás. Dado que intentamos minimizar el trabajo perdido, el diseño resultante puede ser uno que no sería fruto de un proceso de diseño racional.
(3) Aunque conociéramos todos los datos relevantes antes de empezar, la experiencia demuestra que los seres humanos somos incapaces de comprender en su totalidad la plétora de detalles que hay que tener en cuenta para diseñar y construir un sistema correcto. En el proceso de diseño del software intentamos separar las preocupaciones para trabajar con una cantidad de información manejable. Sin embargo, hasta que no hayamos separado las preocupaciones, estaremos abocados a cometer errores.
(4) Aunque pudiéramos dominar todos los detalles necesarios, todos los proyectos, salvo los más triviales, están sujetos a cambios por razones externas. Algunos de esos cambios pueden invalidar decisiones de diseño anteriores. El diseño resultante no es el que se habría producido mediante un proceso de diseño racional.
(5) Los errores humanos sólo pueden evitarse si se puede evitar el uso de humanos. Incluso después de separar las preocupaciones, se cometerán errores.
(6) A menudo cargamos con ideas de diseño preconcebidas, ideas que inventamos, adquirimos en proyectos relacionados o de las que oímos hablar en clase. A veces emprendemos un proyecto para probar o utilizar una idea favorita. Puede que esas ideas no se deriven de nuestros requisitos mediante un proceso racional.
(7) A menudo se nos anima, por razones económicas, a utilizar software desarrollado para algún otro proyecto. En otras situaciones, puede que nos animen a compartir nuestro software con otro proyecto en curso. Puede que el software resultante no sea el ideal para ninguno de los dos proyectos, es decir, no es el software que desarrollaríamos basándonos únicamente en sus requisitos, pero es lo suficientemente bueno y ahorrará esfuerzos.

Por todas estas razones, la imagen del diseñador de software derivando su diseño de forma racional y sin errores a partir de una declaración de requisitos es bastante irreal. Ningún sistema se ha desarrollado nunca de esa manera, y probablemente ninguno lo hará jamás.