Diseño software: después de 60 años aún no sabemos si esencial o es inútil
Por unos adorado y por otros odiado, ese es el diseño software. Llevamos desde que nació la ingeniería software, más de 60 años, dándole vueltas, sin ponernos de acuerdo sobre si es útil o no.
Ninguna ingeniería clásica, ni la construcción de aviones, puentes, tostadoras, ni la arquitectura, la construcción de edificios, etc., ninguna tiene la mínima duda de que antes de construir el producto hay que diseñarlo. Pero no es así en el caso del software, donde el diseño, algo tan obvio y esencial en otras disciplinas, es una tarea, y un producto, sobre el que aún no tenemos un consenso sobre sí es imprescindible o es algo inútil.
Los comienzos de la ingeniería del software intentaron imitar la manera de construir de otras disciplinas, aquellas que crean cosas físicas, y por ello el diseño software se convirtió en una pieza clave, que apoyaban muchos de los primeros e importantes métodos para crear software. El diseño “top down”, los métodos de Yourdon,
Jackson, etc. Posteriormente, el movimiento de los patrones de diseño y los arquitectónicos, y otras famosas metodologías, como RUP, y notaciones, como UML, continuaron apoyando a la figura del diseño como algo esencial.
Pero también desde hace muchos años existe otra visión, la visión adaptativa de crear software, los ciclos de vida iterativos, incrementales, en espiral, etc., que relajan esa visión del diseño como pieza esencial, siempre previa a la construcción. No lo eliminan, pero sí que relajan el detalle y minuciosidad de la tarea de diseñar, y entienden que el diseño es principalmente el propio código.
Y todo ello hasta nuestros días, donde continúa el debate, sin una única respuesta. En años más recientes, la agilidad, y la visión de que el diseño es el código, han continuado apostando porque una fase de diseño previa a la construcción no es algo crítico a la hora de desarrollar.
Pero también hoy, áreas tan potentes en investigación como el MDD (te dejo un post sobre qué es esto del MDD), estrategia de desarrollo software que persigue la generación automática del código desde especificaciones de alto nivel, apuestan por el diseño como pieza clave y esencial, previa a la construcción, desde el que se puede crear el código, haciendo de este último algo menos relevante en comparación con el diseño.
Para seguir dándole vueltas al tema, te dejo un post relacionado de hace un tiempo… Qué es más importante mantener… ¿el diseño o el código?
6 Respuestas to “Diseño software: después de 60 años aún no sabemos si esencial o es inútil”
Trackbacks/Pingbacks
- Bitacoras.com - Información Bitacoras.com...Valora en Bitacoras.com: Por unos adorado y por otros odiado, ese es el diseño software. Llevamos desde que nació ...
- Poner comentarios en el código… ¿es una buena práctica o es típico en software de mala calidad? - Javier Garzás | Javier Garzás - [...] los que podemos encontrar posturas tan separadas (véase, como uno de tantos ejemplos, aquello del diseño software: después de ...
por experiencia propia, saltarse la fase de diseño sólo es posible en proyectos sencillos o pequeños.
Cuando el proyecto es muy grande y la complejidad muy elevada, saltarse la fase de diseño es garantía de código imposible de entender y de mantener, de incidencias, de incumplimiento de requisitos de usuarios… Creo que sólo algunos auténticos cracks son capaces de trabajar en proyectos así sin diseño. Al menos es mi experiencia…
Coincido en que poderse se puede hacer… pero con un equipo de desarrollo bueno bueno bueno, por lo que la realidad se acaba imponiendo y al final, aun siendo proyecto ágiles, se suele meter fase de diseño, p.e. los famosos sprint 0 de Scrum y que en FDD se detallan muy bien.
Saludos!
Soy de las que piensa que, saltarse la etapa de diseño, despues de que sabes “realmente” en que consiste el diseño de software, duele bastante.
Particularmente pienso que pocos llegan a saber en que consiste en realidad el diseño detallado, en la mayoria de empresas con dificultad llegan a adoptar todas las practicas de la etapa de análisis, y dificilmente construyen algunos artefactos de arquitectura y diseño. Independiente de si se hace o no de forma interativa e incremental, el diseño detallado compensa un poco el hecho de que no todos los desarrolladores tengan las mimas habilidades, puesto que un arquitecto y un buen diseñador guian la construcción y se aseguran de que todos esten siguiendo los lineamientos.
Por otro lado, si el diseño refleja realmente el sistema construido, tratar de encontrar un problema en el mantenimiento es muchisimo más fácil que tratar de desenredar un monton de codigo construido como cada uno quizo y sin seguir indicaciones, por lo que no das mantenimiento a una estructura, si no a una colcha de retazos.
Complementando los puntos de vista, desde el punto de vista más ágil, la duda vendría de los costes que supone mantener un diseño detallado
Hola Javier! Muchas felicidades por tu web, hace tiempo que la sigo y me parece muy interesante.
A medida que avanzo en mi carrera profesional, sigo ahondando en la idea de que el Software es una ingeniería cuyas particularidades hacen que las cosas se hagan de distinta forma, a diferencia de otras ingenierías clásicas.
Me gustaría empezar diciendo que, en el caso ideal (i.e. Todo está claro y definido), que haya unas especificaciones claras, hacen que el proyecto tenga unas probabilidades muy altas de terminar siendo un éxito.
Desafortunadamente, existen limitaciones en tiempo y en dinero. Las empresas buscan la forma de minimizar los costes, y obtener el producto/servicio lo antes posible (para no perder la “oportunidad” de mercado). Entonces, se buscan metodologías que “agilicen” el proceso, a costa de “recortar” en todo aquello que no sea estrictamente necesario para empezar a programar. Los “fallos” en software no suelen ser tan críticos como en otras disciplinas, y esa percepción “externa” (de la gente que no es experta en software, y que muchas veces es la que toma las decisiones) contribuye a que esas metodologías se hagan populares entre las empresas, y sean el pan de cada día.
El diseno en Software se parece en algunos aspectos a la seguridad en los aviones. Los aviones tienen sistemas redundantes para entrar en acción en caso de que haya problemas con el sistema principal, que estadísticamente hablando, no son muy frecuentes. Mantener esos sistemas ahí hace muchos viajes sin incidentes se encarezcan. Mantener un buen diseno también es algo caro, pero en caso de problemas (i.e. Cambio de personas en el equipo, inconsistencias o incompletitud, etc.) puede evitar que el proyecto fracase. Por eso en proyectos de cierta envergadura, no te la juegas a crear el sistema sin que todo esté MUY claro. Lo mismo pasa con el avión, puedes jugártela a ir sin ningún sistema redundante, pero al más mínimo fallo estás acabado…
Saludos,
Santiago
Mi pequeño granito de arena al respecto. Por experiencia propia, el diseño detallado (muy bien descrito a través de metodologías del estilo RUP) sólo lo recomendaría para proyectos software de envergadura, con equipos grandes o distribuidos (+20 desarrolladores), o con requisitos no funcionales muy críticos (p.ej. para el control de infraestructuras donde haya riesgos para la seguridad o las personas). Es en estos casos donde es muy importante describir muy bien la arquitectura software del sistema, y detallar las distintas funcionalidades de sus componentes, de forma que no haya problemas luego a la hora de integrar los distintos subsistemas.
Sin embargo, en la mayoría de los proyectos del ámbito empresarial, de menor tamaño y con equipos más pequeños (aunque pueden estar distribuidos), y donde el requerimiento de minimizar el tiempo de desarrollo y coste es muy importante (aunque sin mermar la calidad -debería), lo que funciona son los procesos iterativos, evolutivos, en los que en cada etapa se realiza una pequeña fase de diseño, y que se va revisando o completando en sucesivas etapas. Este diseño podríamos describirlo como más light, y su finalidad no es detallar toda la funcionaliad, sino servir como guía para el desarrollo, y para tomar decisiones antes de ponerse a codificar.Por ejemplo: un diseño podría ser la relación de clases de un módulo o componente y los principales atributos y métodos, pero a la hora de codificar, se definirían métodos auxiliares, el código de los métodos e incluso nuevas relaciones que se detecten necesarias.
En la iteración 0, se definiría la arquitectura software del sistema, pero se iría detallando a medida que fueran avanzando las distintas iteraciones, y con el feedback del cliente o las necesidades del proyecto.
Otro tema es el MDD, en el que por su naturaleza sí puede definirse el diseño detallado de un sistema, ya que todo el código se genera automáticamente a partir de dicho diseño, y por tanto diseño y código están sincronizados. Pero tampoco evitaría que se utilizaran únicamente los modelos como guía, se generara parcialmente el código del sistema, y se codificaran las partes más comlejas directamente (el estado actual de las herramientas MDD ya permiten hacer esto).
En resumen: por mi propia experencia, el diseño software es esencial, pero debe considerarse desde un punto de vista práctico, evitando ser purista. Lo que sí es cierto es que no hay un consenso en qué se debería considerar diseño software: ¿los modelos UML (clases, estados, etc.)? ¿el modelo de datos? ¿la arquitectura software? ¿los mockups? Existen distintos artefactos, y unos son priorizados frente a otros dependiendo de la metodología de desarrollo que use cada equipo y la experiencia del equipo.