Conforme me informaba sobre modelos ágiles (algo que por cierto nunca acaba) me preguntaba sobre el papel que juegan las actividades y artefactos de diseño de software: cuándo resulta irrelevante, innecesario o cuando sí aportan valor.
Tradicionalmente, en la industria del software un producto inicial del software es su diseño, que debe ser guía para la construcciones de los cimientos y posteriores estructuras de código en un software.
Big Design Up Front
Los más acérrimos, consideran que el diseño debe ser profundamente claro y detallado antes de iniciar los esfuerzos de construcción, por lo cual esta fase de un proyecto tomaba tiempo considerable de análisis, retrasando las entregas.
A este fenómeno de diseñar a la perfección, le llaman Big Design Upfront, siendo ampliamente criticado en los últimos años por quienes adoptan marcos de trabajo ágiles, pero apoyado por los proponentes del modelo de desarrollo en cascada.
El dilema principal radica en cuál es el momento más adecuado para poner en práctica el diseño de software: ¿Antes o durante el proceso de construcción del software? Ellos consideran que el esfuerzo se concentra más al inicio y con lujo de detalle.
Emergent Design
El diseño emergente es la propuesta más respaldada en los entornos ágiles para el diseño de software, pues considera que el proceso de análisis y diseño emergirá cuando sea necesario para entregar los incrementos de cada sprint.
El fundamento principal para optar por Emergent Design, es el mismo que sienta las bases del modelo ágil: El cambio continuo. Aún cuando los requerimientos de software no cambien, en los últimos años la tecnología y la gente sí lo ha hecho, cada vez con más frecuencia.
Al finalizar el proceso de desarrollo y entregar los resultados finales, quedará un diseño simple y conforme a lo que fue realmente necesario, que puede evolucionar con el tiempo siguiendo el mismo método.
El Propósito
No debe olvidarse que, el propósito del diseño de software es principalmente comunicar, de forma técnica, las diferentes estructuras y comportamientos de un software, para facilitar su estudio, construcción y mantenimiento, así como la orquestación de los esfuerzos de construcción.
En la academia suele ser admirada y recomendada ampliamente la notación UML, que comprende diferentes diagramas y modelos aplicable a distintos niveles del diseño de un software. Esto no significa, que sea necesario diagramar absolutamente todo lo que esté allí definido.
En el tanto los ingenieros logren comprender el diseño y construir el software de forma organizada, el propósito habrá sido cumplido. Por tanto, el diseño sólo debe cubrir aquello que sea necesario comunicar y bajo el medio más efectivo y óptimo para hacerlo.
Actualidad
Por la forma en que se construyen aplicaciones de software hoy día, es común la adopción de frameworks, APIs, librerías y convenciones para facilitar los esfuerzos de construcción. El diseño de estos componentes está previamente definido.
Un desarrollador simplemente debe comprender la arquitectura de estos frameworks y apegarse a las convenciones recomendadas para que su diseño se mantenga consistente, y por tanto, sea fácil de asimilar por alguien más que domine el mismo framework.
Así, muchos aspectos del diseño se reducen a definir la arquitectura del software, sus componentes, bosquejos de pantalla, estructuras de datos, flujogramas, entre otros elementos estrictamente necesarios para comprender y avanzar.
Modelo C4
Simon Brown, es un consultor independiente en desarrollo especializado en arquitectura de software. Hace dos años, Simon propuso un modelo para diseño de software que fuera simple, fácil de navegar y que comunique con más eficiencia.
De acuerdo con Brown, la notación UML es compleja, las relaciones entre diagramas son ambiguas o indeterminadas, los niveles de abstracción se mezclan y existe una evidente omisión de las tecnologías de implementación, entre otras deficiencias que encuentra en la práctica.
Así, sugirió la adopción de un modelo de arquitectura que pretende corregir estos vicios, al que llamó Modelo C4, por los cuatro diagramas que lo componen. Basta con definir los siguientes cuatro diagramas, relacionados entre sí y navegables en profundidad como si fuese un mapa:
- Contexto: Visualiza el sistema en la organización, su relación con distintos actores que pueden ser usuarios y otros sistemas.
- Contenedores: Visualiza la división del sistema en entornos de ejecución o almacenamiento, reflejando mejor la infraestructura.
- Componentes: Visualiza internamente las piezas que componen un contenedor en particular, como aplicaciones o servicios.
- Clases: Consiste en un diagrama de clases UML para aquellos casos donde sí sea necesario llegar a ese nivel.
En la práctica he usado recientemente el Modelo C4 para explicar con mucha facilidad la composicion de un sistema, tanto al negocio, administradores de plataforma como desarrolladores de software, según corresponda.
Más Recursos
Si bien el Modelo C4 aborda principalmente la arquitectura, existen muchos otros aspectos del diseño de software que no están representados en él, principalmente en lo que respecta a comportamiento, experiencia de usuario y estructuras de datos.
La adición de estos otros artefactos de diseño es totalmente válida en el tanto agregue valor al proceso de comprensión y orquestación de los esfuerzos de desarrollo, y no está sujeta a un medio o formato en particular, sino aquel que resulte más práctico.
El mismo autor del Modelo C4, creó un libro llamado El Arte de Visualizar la Arquitectura de Software, que amplía mucho más en el uso de bosquejos de pantalla, diagramas de dominio, flujogramas y un vocabulario de entendimiento común y práctico.
Conclusión
Todo software es relativamente distinto, con niveles de complejidad variables y estará orientado a diferentes usos y entornos, pero siempre habrá un nivel de diseño mínimo, ya sea de entendimiento común con solo ver su código, o que requiera representaciones visuales más esclarecedoras.
En un modelo ágil, el sentido común debe prevalecer para lograr el propósito esperado del Diseño de Software, mientras las liberaciones incrementales entregan valor y se construyen los cimientos del software. Sin duda, los esfuerzos iniciales requerirán un poco más de análisis.
El diseño no está sujeto a notaciones, medios, formatos o artefactos específicos, será la conveniencia que permitirá que el diseño emerja de acuerdo a lo que es necesario en un momento dado. El equipo de desarrollo deberá considerar en sus sprints el esfuerzo correspondiente.
