Diseño planificado y Evolutivo
Escrito por Martin Fowler
Traducido por Carmen Vidal ( Paradigma Tecnológico)
Para este artículo voy a describir dos estilos de cómo se hace el diseño en el desarrollo de software. Quizás el más común es el diseño evolutivo. Esencialmente, el diseño evolutivo quiere decir que el diseño del sistema crece mientras se implemente el sistema. El diseño es parte de los procesos de programación y según el programa se desarrolla el diseño cambia.
En su uso habitual, el diseño evolutivo es un desastre. El diseño termina siendo la agregación de un manojo de decisiones tácticas tomadas en el momento, cada una de las cuales hace el código más difícil de cambiar. Se podría argumentar de muchas formas que esto no es diseño, de hecho esto por lo general conduce a un diseño pobre. Como Kent dijo, el diseño está ahí para permitir cambiar el software fácilmente a largo plazo. Como el diseño se deteriora, entonces se necesita la capacidad de hacer cambios con eficacia. Se tiene el estado de entropía de software, con el tiempo el diseño se pone de mal en peor.
No sólo hace esto el software más difícil de cambiar, esto también hace los errores más fácil de reproducirse y a la vez más difícil encontrar y seguramente para resolver. Esto es la pesadilla “codificar y arreglar”, donde los errores se hacen exponencialmente más caros de arreglar según el proyecto avanza.
El Diseño Planificado es contrario a esto, y contiene una noción nacida de otras ramas de ingeniería. Si quiere construir una perrera, solamente necesita conseguir agrupar madera y conseguir una forma en pico. Sin embargo si quiere construir un rascacielos, no puede trabajar así – simplemente se derrumbará antes de usted consiga llegar a la mitad.
Entonces comenzará con dibujos de la ingeniería, hechos en una oficina de ingeniería como en la que trabaja mi esposa en el centro Boston. Como ella hace el diseño, ella resuelve todas las cuestiones, en parte por análisis matemático, pero sobre todo usando normas de construcción. Las normas de construcción son reglas sobre como se diseñan estructuras basadas en la experiencia de lo que funciona(y algunas matemáticas subyacentes). Una vez que el diseño está hecho, entonces su compañía de ingeniería puede dar el diseño de otra empresa para que lo construya.
El diseño planificado en el software debería funcionar de la misma forma. Los diseñadores resuelven las cuestiones importantes por adelantado. Ellos no tienen que escribir el código porque no construyen el software, ellos lo diseñan. Entonces pueden usar una técnica de diseño como el UML que se aisla de algunos detalles de la programación y permite a los diseñadores trabajar a un nivel más abstracto. Una vez que el diseño está hecho ellos pueden dárselo a un grupo separado (o aún una empresa separada) para que lo construyan. Ya que los diseñadores piensan a una escala más grande, ellos pueden evitar la serie de decisiones tácticas que conducen a la entropía del software. Los programadores pueden seguir las directrices del diseño y, por medio de que ellos sigan el diseño, tener un sistema bien construido.
El acercamiento de diseño planificado ha estado vigente desde los años 70, y mucha gente lo ha usado. Es mejor en muchas cosas, que codificar y arreglar el diseño evolutivo. Pero esto tiene algunos defectos. El primer defecto es que es imposible estudiar detenidamente todas las cuestiones con las cuales te enfrentas cuando se programa. Entonces es inevitable que programando te encuentres cosas que cuestiones el diseño. Sin embargo, si los diseñadores han terminado y están en otro proyecto, ¿ qué pasa? Los programadores comienzan a codificar alrededor del diseño y la entropía aparece. Incluso si el diseñador no se ha ido, requiere tiempo para clarificar las cuestiones de diseño, cambiar los dibujos, y luego cambiar el código. Hay por lo general una mayor presión de tiempo. De ahí entropía (otra vez).
Además hay a menudo un problema cultural. Los diseñadores son hechos diseñadores debido a la habilidad y la experiencia, pero están tan ocupados trabajando en el diseño, que no tienen tiempo para programar. Sin embargo los instrumentos y herramientas de desarrollo de software cambian de forma rápida. Cuando no se codifica más, se pierden los cambios que ocurren en el fluir de la tecnología y también se pierde el respeto por los que realmente codifican.
Esta tensión entre constructores y diseñadores pasa en la construcción también, pero es más intenso en el software. Es intenso porque hay una diferencia clave. En la construcción de hay una división más clara en habilidades entre los que diseñan y los que construyen, pero en el software esto no es así. Cualquier programador que trabaja en altos ambientes de diseño tiene que ser muy experto. Bastante experto como para hacer preguntas de los diseños al diseñador, especialmente cuando el diseñador está menos informado sobre las realidades del día a día de la plataforma de desarrollo.
Now these issues could be fixed. Maybe we can deal with the human tension. Maybe we can get designers skillful enough to deal with most issues and have a process disciplined enough to change the drawings. There's still another problem: changing requirements. Changing requirements are the number one big issue that causes headaches in software projects that I run into.
Ahora estas cuestiones podrían ser fijadas. Tal vez podemos tratar con la tensión humana. Tal vez podemos conseguir a diseñadores bastante expertos como para tratar con la mayor parte de cuestiones y tener un proceso los suficientemente disciplinado como para cambiar los dibujos. Hay todavía otro problema: cambio de requerimientos. El cambio de requerimientos es la mayor causa de dolores de cabeza en los proyectos de software en los que he estado.
Un modo de tratar con requerimientos que se cambian es construir con flexibilidad el diseño de modo que ser pueda cambiar fácilmente con el cambio de requerimientos. Sin embargo esto requiere la perspicacia de qué cambios se esperan. Un diseño puede estar pensado para tratar con los cambios, pero mientras esto servirá para cambios de requerimientos previstos, esto no ayudará (y puede doler) para cambios imprevistos. Entonces tiene que entender los requerimientos bastante bien como para separar las áreas cambiables, y mi experiencia me dice que esto es muy difícil.
Algunos de estos problemas de requerimientos son debido a requerimientos que no han sido comprendidos suficientemente.
Entonces mucha gente se centra en procesos de ingeniería de requerimientos para conseguir mejores requerimientos con la esperanza de que esto prevenga la necesidad de cambiar el diseño más tarde. Pero incluso esta dirección no lleva a ninguna cura. Muchos cambios de requerimientos imprevistos ocurren debido a cambios del negocio. Aquellos no pueden ser prevenidos, incluso con un cuidadoso proceso de ingeniería de requerimientos.
Entonces todo esto hace que el diseño planificado parezca imposible. Seguramente estos son desafíos grandes. Pero no me inclino a decir que el diseño planificado es peor que el diseño evolutivo comúnmente practicado de la forma “codificar y arreglar “. De verdad prefiero el diseño planificado al " codificar y arreglar ". Sin embargo soy consciente de los problemas del diseño planificado y busco una nueva dirección.
