Durante el análisis y el diseño técnico del software es habitual el uso de diagramas y gráficos para ayudar a aterrizar, documentar y comunicar adecuadamente las soluciones planteadas.
Transmitir conceptos o ideas no es sencillo. Para una adecuada comprensión por parte del receptor resulta útil expresar una misma idea o concepto de diferentes maneras. Por ejemplo, el término “modelo descriptivo” puede resultar excesivamente académico o abstracto para una persona con formación técnica básica, por ello complementarlo con el término “archivo de configuración”, más concreto, ayuda a asegurar que el mensaje es entendido correctamente. Emplear diagramas puede facilitar la correcta comprensión de los sistemas, de la misma manera que ofrecer diferentes explicaciones ayuda a entender conceptos e ideas. Los diagramas hacen uso de un lenguaje basado en dibujos para expresar un sistema de otra forma. Así, los diagramas ofrecen otro punto de vista al receptor que le ayudan a eliminar ambigüedades y despejar dudas para entender inequívocamente el sistema que se pretende comunicar. Un adecuado lenguaje visual hace digeribles ideas complejas, de esta manera los diagramas enriquecen la colaboración entre los actores.
Idealmente las relaciones entre los elementos de un diagrama plasman rigurosamente la información a transmitir ganando eficacia comunicativa. La velocidad con la que el receptor del diagrama entienda la información es clave dentro de los propósitos del diagrama.
🔎 ¿Cómo explica un ingeniero la planificación de un proyecto? ¡Con un diagrama!
Henry Laurence Gantt fue un ingeniero mecánico estadounidense conocido por el desarrollo del Diagrama de Gantt en la década de 1910. Los diagramas de Gantt permiten de forma rápida y sencilla transmitir las fechas e hitos de un proyecto.
Esta representación gráfica permite al receptor una rápida comprensión de la posible coordinación de trabajos y consecución de hitos.
🔎 ¿Cómo explica un ingeniero la receta de chipirones en su tinta? ¡Con un diagrama!
El Colegio de Ingenieros Industriales de Gipuzkoa publicó el libro de recetas de cocina “Así cocino yo, la cocina de cada día” que hace uso de diagramas de flujo como este:
De la misma forma que programar en un determinado lenguaje, por ejemplo Java, permite adquirir conocimientos básicos sobre el paradigma orientado a objetos perfectamente aplicables a otros lenguajes como C# o Python, dibujar determinados diagramas, por ejemplo diagramas de casos de uso o de actividades, permite adquirir conocimientos básicos sobre formalismos y comunicación gráfica perfectamente aplicables a otros tipos de diagramas como diagramas BPMN o diagramas de modelado C4.
Dibujar un buen diagrama es similar a redactar un buen párrafo. Los diagramas deben ser auto explicativos y concisos, no debe ser necesario un “manual de instrucciones” para entenderlos. El lenguaje empleado por el diagrama debe ser coherente, sin lugar a malentendidos ni sorpresas.
🔎 Este diagrama no es claro ni conciso:
Las cajas Leire, HCI y Prokirur son productos software, ¿A qué producto pertenece la base de datos que guarda “Entradas LEQ”?
Las flechas parecen indicar un flujo de datos, por ejemplo, una “entrada consolidada” viaja de Leire a Prokirur, entonces ¿qué significa la flecha “Abrir pantalla”? ¿Las flechas simbolizan movimiento de datos o son acciones de usuario?
Un usuario parece introducir en Leire una Entrada LEQ, ¿qué es lo que introduce el otro usuario en HCI?
Los diagramas subrayan algunos detalles, pero no tantos como para ocultar la idea principal que se pretende desarrollar, “los árboles no deben ocultar el bosque”. Un buen diagrama debe acotar su nivel de abstracción, no debe tratar de explicar generalidades y detalles a la vez. El alcance de un diagrama debe ser lo suficientemente grande para resultar significativo y lo suficientemente pequeño para resultar comprensible. El diseñador debe establecer la cantidad de detalles que debe comunicar el diagrama sin dificultad al lector la comprensión de la idea transmitida.
🔎 Este diagrama abarca demasiado. Pretende transmitir tanto información general (de grano grueso) como son las relaciones entre productos y componentes, como información de detalle (de grano fino), como bases de datos, procesos batch y tecnologías de desarrollo. El receptor se pierde en los detalles, únicamente se le transmite complejidad (y que la base de datos “TIS” es un elemento “central”).
Las ingenierías habitualmente recurren a ciertos tipos de diagramas para ayudar a expresar problemas o plantear soluciones. Con el uso estos diagramas se estandarizan, convirtiéndose en patrones bien conocidos por la industria. Todo ello no impide al ingeniero de software experimentado hacer uso de diagramas no estándar si ellos resultan útiles para transmitir una idea o documentar ciertos conceptos. Antes de “inventar” un nuevo tipo de diagrama no estandarizado, es aconsejable que el ingeniero sea buen conocedor de abundantes formalismos y estándares sobre esquemas y diagramas.
Existen herramientas gráficas online que facilitan al ingeniero la elaboración de estos diagramas partiendo de plantillas previamente configuradas. Un ejemplo es draw.io.
Referencias:
• K.Beck; "Extreme Programming Explained", Addison-Wesley Professional, 1999
• F.Brooks; "The Mythical Man-Month: Essays on Software Engineering", Addison-Wesley, 1975
• R.C. Martin "Arquitectura Limpia", Anaya, 2018
• J. Palacio; "Flexibilidad con Scrum", 2008.
• H. Kniberg; "SCRUM y XP desde las trincheras", InfoQ, 2007
• R.Jeffries; "The Nature of Software Development", Pragmatic Bookshelf, 2015
• I. Sommerville; “Ingeniería del Software”, Addison Wesley, 2005
• R. Pressman; “Ingeniería del Software: Un enfoque práctico”; McGraw-Hill, 2005.
• B. W. Boehm, "Software Engineering Economics", Prentice Hall,1981
• L. Artola, “Software Economics”, LeanPub, 2020
• T. Winters y H. Wright, “Software Engineering at Google”, O’Reilly, 2020
• J.Garzas; https://www.javiergarzas.com/