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?

0 comentarios en “Diseño software: después de 60 años aún no sabemos si esencial o es inútil”

  1. Pingback: Bitacoras.com

  2. 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…

  3. 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!

  4. 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.

  5. 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

  6. 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.

  7. Pingback: 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

  8. Muy interesante entrada. Aprovecho para felicitarle por su blog, que he descubierto recientemente y me parece excelente.
    Siendo psicólogo e ingeniero informático, me he encontrado que en ambas disciplinas -tan aparentemente alejadas- se da un fuerte anhelo por convertir sus quehaceres e intereses en «científicos» e «ingenieriles», un anhelo que no siempre es exitoso. Los psicólogos, al menos muchos psicólogos, suspiran por convertir sus análisis y predicciones en algo tan exacto como la física, la ciencia «más pura» en la que les gustaría parecerse; los informáticos -algunos informáticos- sueñan con procesos de construcción y desarrollo de software racionales, medibles y previsibles. Sin embargo, Donald Knuth llamó a su obra «El arte de la programación de ordenadores».
    El otro día comentaba con colegas desarrolladores de software lo que podría considerarse un caso más específico del problema general que describe su entrada. Estos colegas desempeñan su labor profesional en una empresa de serivicios informáticos que trabaja con un gran cliente, una entidad financiera.
    Hablábamos del concepto «factoría de software» y comentábamos cómo el cliente, o al menos la dirección estratégica, llevaba años, ya casi una década, tratando de implantar ese producto. Sin embargo, me informaban de que los problemas con la «factoría» son enormes.
    Desde el primer momento, a pesar de las directrices «desde arriba», los equipos de software del propio cliente han evitado cuando han podido encargar la construcción de sus programas a la factoría. Cuando, obligados, no les ha quedado más remedio que hacerlo -por ejemplo, porque se midiera el número de solicitudes, y se vinculara la retribución variable o los presupuestos a esta métrica-, los resultados han sido muy deficientes. Lo que devuelve la factoría, en general, no funciona. O, si lo hace, es a base de hacerles llegar unas especificaciones tan detalladas, de tan bajo nivel, que cuesta exactamente el mismo esfuerzo construir uno mismo el programa que hacer un pseudocódigo tan completo como el necesario… incluso, lo segundo cuesta más, porque si uno mismo hace el programa puede ver el resultado sobre la marcha y realizar las correcciones oportunas, mientras que si se queda en la etapa anterior, tiene que imaginárselo todo («diseñarlo»). No solo eso: una vez terminada la «pieza», es preciso someterla a un plan de pruebas exhaustivo, mucho más que si fuera de producción propia, porque, de lo contrario, la experiencia demuestra que no funcionará. En este escenario, se dan situaciones perversas en las que algunos equipos hacen los encargos a factoría porque están obligados a ello, ¡pero paralelamente construyen ellos mismos los programas que necesitan! Lo que llega de Factoría simplemente se desecha, con mayor o menor grado de paripé (fingir que se prueba, devolverlo alguna vez).
    Es una situación kafkiana y, me temo, no ajena al concepto «per se» de ingeniería del software.
    La idea misma del software como cadena de montaje es, si se piensa, problemática. Se puede concebir una fábrica de tuercas y tornillos. Una tuerca es idéntica a otra tuerca, y es bueno y útil tener una manera replicable industrialmente que nos permita producir millones de ellas con el menor coste posible. Para eso invertimos en infraestructuras y procesos. En el caso del software esto, sencillamente, no es así. Rara vez un programa -clase, objeto, función, rutina- es idéntico a otro. Y si necesitamos «producir» millones de ejemplares de un mismo programa, en realidad, no tenemos ninguna necesidad de infraestructuras ni procesos aparatosos. Copiar y pegar es suficiente.
    Hay otra contradicción inherente a la idea «factoría de software» que, en mi opinión, condena al concepto al fracaso. Se pretende que el cliente, o quien quiera que se responsabilice de las etapas previas a la construcción, generen una especificaciones tan inequívocas y completas que no sea necesario que el «obrero» en la factoría introduzca ningún tipo de inteligencia en su parte del proceso. Él solo debe hacer lo que se le dice. Es más: si pone algo de su parte, si aporta algún tipo de inteligencia, en realidad está poniendo en riesgo el resultado, porque su iniciativa seguramente no coincidirá con la que está tomando el «diseñador». Esto parece razonable. El problema es que para generar ciegamente un código fuente directamente derivado de unas especificaciones suficientemente precisas… no se necesita una persona ni un equipo. No se necesita una organización. Basta una herramienta que genera código. Si el obrero de la factoría debe ser un compilador, ¿por qué no usar un compilador? Es más, un compilador hace ese trabajo mejor que un humano.
    Lo cual, obviamente, nos devuelve al punto de partida. Y esa es la razón por la que quienes se ven obligados a utilizar los servicios de una factoría de software se ven a veces en la kafkiana situación de hacer las dos cosas, encargar y diseñar el programa a terceros para cumplir el expediente, y construirlo ellos mismos para conseguir algo que funcione.

  9. Sólo hace falta seguir unas semanas al autor para ver que apuesta por metodologías ágiles. Y ya sabemos que en dichas metodologías el diseño pierde mucho peso.
    Artículo sesgado. Creo yo.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Share This
Ir arriba