Ingeniería Model Driven e Inteligencia Artificial
En contraposición a la programación tradicional manual, la utilización de modelos y la inteligencia artificial son temas de actualidad en la ingeniería de software moderna. Quien prueba, quien comienza a trabajar en un ambiente MDE (Model Driven Engineering), ya no sale de este contexto. No quiere retroceder. Volver atrás, a la programación manual, significa perder productividad, agilidad, la capacidad de cambiar la forma de cómo se trabaja a su alrededor, perder tiempo. En el fondo, perder calidad de vida, y no solamente profesional.
Está claro que la complejidad del software no ha dejado de aumentar. El número de niveles que soportan un sistema de información (hardware, sistema operativo, SGBD, comunicaciones, browsers, programación), el número de tecnologías diferentes que son necesarias para su funcionamiento, la evolución rápida y acelerada de estas tecnologías, la dimensión y el número de componentes que componen una solución, los requisitos no funcionales (como eficiencia, capacidad de ser testado o experiencia de uso), las interacciones con otros sistemas… Desarrollar software es hoy en día una actividad muy compleja y altamente profesionalizada.
Como mencionó Vasco Amaral, profesor de NOVA-FCT, superar la complejidad es la razón de ser de la Ingeniería de Software.
Y esta misión de la Ingeniería de Software todavía tiene un desafío mayor: las partes interesadas (los stakeholders) del software – aquellos que lo usan, que se basan en él para tomar decisiones, o que recurren a él para ejercer sus derechos (usuarios, gestores, ciudadanos) – quieren cada vez más, estar presentes en el diseño e incluso en la producción de la propia solución.
Hoy en día, la Ingeniería de Software está atrasada con respecto a otras ingenierías, en la utilización de Modelos. Sin duda podemos esperar, y durante muchos años, que la construcción de un edificio esté precedida por un plan detallado del mismo. La Ingeniería Civil tiene esta práctica totalmente instaurada, pero la Ingeniería de Software no. El Modelo, que equivaldría al plan, una gran parte de las veces no existe o está incorporado y es difícil de aislar en el propio código del software.
Este atraso no se debe a la juventud de la ingeniería de software que, aunque más reciente que otras ingenierías, existe desde los años 60 del siglo pasado. Seis décadas son tiempo más que suficiente para generalizar una buena práctica si su beneficio fuese considerado y reconocido.
En la realidad, la ingeniería del software se quedó rezagada frente a sus congéneres en los últimos 30 años en el área de la utilización de modelos.
Una pequeña historia, totalmente real demuestra eso. En el año 1980 surgieron, en paralelo, los sistemas CAD (Computer Aided Design), CAM (Computer Aided Manufacturing) e CASE (Computer Aided Software Engineering). Una vez pasados 30 años, todos los alumnos de Ingeniería Civil (y de Arquitectura) aprenden a usar CAD en la Universidad, todos ellos usan CAD, incluso para proyectos fuera de la disciplina donde lo aprendieron, y cuando llegan a las empresas, continúan usando CAD en todas las actividades que desarrollan. Con CASE no ocurre nada de esto. Pregunten a un estudiante actual de Ingeniería Informática lo que significan las siglas CASE y ni siquiera lo sabrán. El último libro publicado sobre CASE fue en el año 2003.
Inteligencia Artificial aplicada al desarrollo de software
Ocurrió lo mismo en relación a la inteligencia artificial aplicada al desarrollo de software. Era un tema que reunía un elevado número de investigadores en la década de los ochenta, en torno a motores de inferencia, lenguajes específicos como PROLOG o LISP, de sistemas periciales (Expert Systems). Defendían, por ejemplo, la primacía de la programación declarativa frente a la procedimental, lo que en esa altura ya estaba muy cerca de la inteligencia artificial y la utilización de modelos.
Hace 30 años, las expectativas en relación a la ingeniería de software y a la inteligencia artificial eran muy altas. Herbert Simon, Premio Nobel de Economía previó unos años antes, en 1956: “Machines will be capable, within twenty years, of doing any work a man can do”.
En los últimos años, la inteligencia artificial volvió a estar de moda, de hecho, hay un hype a su alrededor, lo que implica recursos financieros y jóvenes talentos dirigidos hacia esta área. Lo cual es estupendo. Sin embargo, el desarrollo del software fue apartado de los temas que eran objeto de la inteligencia artificial. Parece que existe una especie de bullying que aparta a los sistemas expertos reservando la IA para la robótica, el procesamiento del lenguaje natural y para machine learning. Este último no se desvía mucho de lo que hace no muchos años se llamó métodos cuantitativos o métodos de previsión.
Participación de Quidgest
Quidgest fue, desde su creación en 1988 pionera en la utilización de la inteligencia artificial y el modelado.
Curiosamente, por este orden. Primero, la inteligencia artificial con la creación de un sistema pericial para evaluar inversiones agrícolas, ALFAIA, desarrollado en PROLOG. En 1989, ALFAIA permitió dar un salto en la productividad y de los técnicos involucrados que pasaron a evaluar una media de 0.6 proyectos por día para conseguir evaluar unos 25 proyectos al día. Una productividad y calidad fundamentada de la decisión que sería envidiable a día de hoy en el análisis de concesión de créditos por parte de las instituciones bancarias. El entusiasmo del espíritu pionero de Hélder Coelho fue una fuente de inspiración para Quidgest en este desafío.
La bestia del aumento drástico de la productividad mediante el uso de tecnologías de información ya estaba instalada de manera definitiva e irremediable en Quidgest. Definitivamente queríamos tener un papel relevante en la revolución tecnológica de nuestro tiempo y en la transformación digital de la sociedad. En 1990 el modelado aplicado siguió al desarrollo de software mediante Genio. El primer paso consistió en generar de forma automática el software resultante de ese modelo. Al igual que un corredor de maratón, Genio desarrolla constantemente su capacidad a través de los avances ya sean en el modelo, o la generación automática correspondiente. Las enseñanzas de Ana Lucas y la belleza y simplicidad de los conceptos que nos transmitió sobre las bases de datos fueron fundamentales para comenzar este camino, el cual hoy continuamos recorriendo. ALFAIA y Genio, los sistemas pioneros de Quidgest ya eran declarativos (en línea con MDE) y ya utilizaban motores de inferencia (como la inteligencia artificial). Ambos permitían aumentos de productividad enormes ya en aquel entonces.
Retroceso de la Ingeniería de Software
Pero poco a poco, en la industria e incluso en la investigación académica quedamos aislados. Los proyectos que no salieron bien y aquellos con resultados por debajo de las expectativas trajeron un descenso generalizado en relación a la utilización de modelos y de inteligencia artificial en el desarrollo de software. Tal y como suele ocurrir en el mundo de las tecnologías, a la excitación inicial le sigue una gran desilusión. Apenas una docena de empresas en todo el mundo persistió en esta línea de trabajo. Quidgest fue una de ellas.
Tres factores contribuirán a este retroceso de la Ingeniería del software:
- La ausencia de una disciplina de desarrollo en una lógica de calidad total,
- El estudio de procesos como base para el diseño del software,
- Y UML. A los cuales se une, aunque no vamos a tratarlo aquí, la presión inexistente hacia la industria de software actual, los altos precios practicados y la falta de eficiencia.
En cuanto a la disciplina de desarrollo. El proyecto Caravela fue un proyecto emblemático del IST, al inicio de los años 90 permitía (además, exigía) que tras la generación del código alguién colocase los cabos sueltos de manera que se garantizase que la solución iría a funcionar.Esta mala práctica, en absoluta contradicción con las buenas prácticas de calidad impedía que los problemas se resolviesen desde el origen y quedasen perfectamente disponibles para futuros usos.Se creaba aquello denominado “Technological Debt” que al igual que el resto de las deudas, solo tiende a acumularse. Nótese, que la ignorancia de la industria del software tradicional en relación a los conceptos de Calidad sigue siendo flagrante.Hoy en día, este el único sector de actividad en el que el control de calidad (el denominado “Quality Assurance”) está separado de la producción. El Caravela recibía más atención que su contemporaneo Genio (donde esta falta de disciplina no está permitida), lo cual es una pena, porque su falta de éxito perduró más en el imaginario académico que el éxito de la solución de Quidgest.
En cuanto al predomínio de los procesos, en contraposición a la estrutura de datos como base para la construcción de software, hubo un breve periodo, cuando emergieron los SGBD relacionales en los años ochenta, en el que la estrutura de los datos y el flujo de los procesos construía el primer paso para la concepción del software. Obviamente, cualquier software tiene tanto datos como procesos. Pero el orden por el cual entran en creación (o en el “Design Thinking”) no es relevante. El modelado, durante ese período era data-driven y no process-driven. Los MRP/ERP de los años setenta y la mayoría de los proyectos de software a partir de mediados de la década de los noventa, iniciaron su desarrollo mediante el estudio de procesos. Incluso SCRUM, siendo dudoso el que deba ser considerado Agile. Ahora no existe, en la recopilación de procesos, nada que se pueda equiparar en simplicidad y formalismo matemático al modelo relacional que soporta la estructuración de las bases de datos. Partiendo de los procesos, el salto para el modelado y la inteligencia artificial es mucho más difícil e incierto. De forma adicional, la recopilación de procesos, contrariamente a lo que ocurre con la de datos, es un trabajo que no acaba. Rentable para los consultores, pero desesperadamente largo para quien necesita el software.
Finalmente, UML (Unified Modelling Language). La asociación de modelo a UML puede ser responsable por la retirada de muchos estudiantes y jóvenes ingenieros de software en relación al Model Driven Development (MDD). MDD y UML no son sinónimos ni mucho menos. Quidgest es un gran defensor del MDD y un crítico de casi todo en UML. En UML solo son relevantes, aunque pueden simplificarse, los modelos que estructuran datos. Pero la amalgama que resultó de la unificación vino a dar igualdad de tratamiento, vino a dar el mismo estatus, a un conjunto de diagramas que son relevantes y solo estorban. El problema principal es que UML no consigue hacer de puente entre los requisitos y la solución: acepta todo lo que se coloca en el papel, la realidad es demasiado compleja para ser representada, la actualización de la documentación no está garantizada. Varias maneras de suplir estas lagunas fundamentales del UML han sido ensayadas por la Academia, pero no han sido continuadas por la industria. Concluyó que el problema está realmente en el UML y que sus debilidades son inherentes a él. El modelado necesario para el desarrollo de software no puede usar la planta de la ingeniería civil como referencia. No es únicamente un dispositivo independiente que se consulta durante la construcción. Una de las innovaciones más significativas de Genio (de Quidgest) en relación al UML, es que Genio nace en la dirección opuesta, del software hacia el modelo. Y este es un cambio considerable de paradigma.
