La complejidad del software y su presencia en todas partes

«Los tontos ignoran la complejidad. Los pragmáticos la padecen.  Algunos pueden evitarla. Los genios la hacen desaparecer». Estas  palabras las pronunció Alan Perlis, uno de los pioneros de la  informática, quien probablemente observaría consternado la complejidad  de los sistemas de software actuales. Aunque quizá no se consideren a sí  mismos genios, un equipo de investigadores financiado con fondos  comunitarios está sometiendo esta complejidad a control aplicando un  método alternativo de ingeniería de software orientado a la creación de  sistemas más seguros, económicos y robustos.

 El software no solo se ha hecho más complejo, sino que ahora está  en todas partes: en el coche, en el contador del consumo eléctrico y en  la central donde se genera la energía, en aviones, trenes, bancos y  hospitales. Hace posible el funcionamiento de sistemas críticos en los  que un solo error puede tener consecuencias desastrosas. El elevado  riesgo de que se produzcan fallos como consecuencia de la creciente  complejidad del software no es el único problema; la complejidad también  encarece los costes. De hecho, llevar a cabo pruebas de software para  la detección de errores supone actualmente en torno a la mitad del  presupuesto de producción y hasta el 70 % de los gastos posteriores al  lanzamiento.

La raíz de este problema es que los procesos de  ingeniería de software tradicionales no están diseñados debidamente para  gestionar la ingente complejidad y diversidad de los sistemas de  software actuales.

«Fíjese, por ejemplo, en un coche moderno.  Integra cientos de elementos de software que sirven desde para controlar  la calidad del sonido hasta para activar el control de crucero. A  medida que se incorporan más y más elementos y funciones en estos  sistemas, los ingenieros advierten de que la complejidad está escapando a  su control y les preocupa no ser capaces de ofrecer las garantías de  calidad que se exigen», explica Alexander Romanovsky, profesor de  informática en la Universidad de Newcastle, en el Reino Unido. «Y esta  complejidad se encuentra en todas partes y en todas las cosas: los  fabricantes de automóviles, trenes, aviones, etc. dedican buena parte de  su tiempo y recursos, hasta la mitad incluso, al desarrollo de  software: en última instancia, todos los sectores industriales producen  software.»

La pregunta es: ¿serían estos sectores capaces de  hallar una forma mejor de producir software, en especial para sistemas  críticos?

Los investigadores que participaron en el proyecto  «Industrial deployment of advanced system engineering methods for high  productivity and dependability» ( Deploy),  financiado con 12,4 millones de euros por la Comisión Europea y  coordinado por el profesor. Romanovsky, creen que sí. Su propuesta se  basa en métodos de la ingeniería formal que, gracias en buena medida a  los esfuerzos realizados por los integrantes del equipo, están  comenzando a ganar aceptación entre las empresas y los ingenieros como  una forma más eficiente y práctica de desarrollar sistemas de software  complejos. Los procesos de Deploy ya se han utilizado para desarrollar  software de seguridad crítico para líneas de metro y trenes lanzadera de  aeropuertos.

A diferencia de los enfoques tradicionales de la  ingeniería de software, los métodos formales están fundamentados en  modelos y análisis matemáticos y permiten el razonamiento en múltiples  niveles de abstracción para posibilitar un flujo de ingeniería  sistemático desde la especificación de los requisitos hasta la  implantación, las pruebas y el despliegue, pasando por el modelado de  arquitecturas y el diseño detallado. Para este proyecto, el equipo  continuó la evolución de «Event-B», un método formal para el modelado y  análisis de sistemas desarrollado por primera vez en el marco del  proyecto «Rigorous open development environment for complex systems»  (Rodin), financiado con fondos comunitarios, y respaldado por «Rodin  tools», un entorno de desarrollo integrado.

Animar a los ingenieros a pensar de forma diferente

«Para  los ingenieros, se trata de un cambio muy trascendental. Por lo  general, cuando emprenden un proyecto, están acostumbrados a comenzar a  desarrollar el software, añadir elementos, ampliarlo, y después realizar  gran parte del trabajo más difícil: la implantación, verificación,  pruebas, etc., al final. La ingeniería formal invierte ese proceso: la  parte difícil es la inicial, ya que se comienza resumiendo los  requisitos del sistema y se continúa con un proceso de desarrollo  riguroso, lógico y matemático», explica el profesor Romanovsky.

La  ventaja es que los errores se detectan al comienzo de la fase de  desarrollo y este método riguroso y lógico permite ceñir la complejidad a  límites predefinidos; todo ello reduce la necesidad de que se lleven a  cabo pruebas en las etapas finales. En última instancia, esta  metodología produce sistemas más robustos y fiables, y posiblemente con  un coste mucho menor que si se utilizaran los métodos de ingeniería  tradicionales.

Aparentemente, podría tratarse de una situación  beneficiosa en todos los sentidos, pero entraña una importante  dificultad: los ingenieros no suelen ser matemáticos.

«Los  métodos de la ingeniería formal requieren un conocimiento matemático que  la mayoría de los ingenieros acostumbrados a emplear los enfoques  tradicionales no poseen, y dado que el proceso es tan distinto, también  se necesita un cambio de mentalidad. Por otra parte, no resulta sencillo  convencer a una empresa que lleva diez o treinta años desarrollando  software de una determinada manera de que lo haga de otra forma», señala  el profesor Romanovsky.

El proyecto Deploy, probablemente el  mayor despliegue de ingeniería de software formal jamás realizado a  nivel industrial, ha logrado avances muy importantes de cara a superar  estos obstáculos.

Por ejemplo, durante la colaboración con el  socio del proyecto SAP, el equipo implantó procesos formales de forma  transparente para que los ingenieros pudieran seguir utilizando  lenguajes de programación específicos de su ámbito a la hora de  desarrollar software de empresa crítico, que después se traducían  automáticamente a Event-B con la supervisión de especialistas en  ingeniería formal.

En Siemens, cuyos ingenieros ya contaban con  una amplia experiencia en modelado formal, se ha utilizado Event-B para  desarrollar software que se emplea actualmente en las redes de metro de  Barcelona y París, así como en otros lugares para el control ferroviario  y de sistemas de señalización. Con Bosch, se utilizó este método para  desarrollar sistemas de control de crucero y de arranque-parada para  automóviles. Y con Space Systems Finland, otro socio del proyecto, el  proceso se ha utilizado para desarrollar componentes de la sonda  espacial BepiColombo de la Agencia Espacial Europea para sistemas de  control de altitud y órbita.

Mientras, el socio francés Systerel  utiliza Event-B en una serie de sistemas ferroviarios y aeroespaciales.  Los investigadores del proyecto Deploy han creado dos empresas  derivadas del mismo, Rodin Tools y Formal Mind, para comercializar las  herramientas y ampliar el despliegue. También se han implicado en un  proyecto complementario financiado con fondos titulado «Advanced design  and verification environment for cyber-physical system engineering»  (Advance).

El despliegue con éxito y el uso continuo de los  métodos de la ingeniería formal en las empresas participantes en el  proyecto constituyen un ejemplo claro que podrán seguir otras compañías  en su búsqueda de nuevas formas de gestionar la complejidad.

«Sin  duda alguna, estamos dando a la industria materia de reflexión acerca  de los métodos de ingeniería actuales y de las ventajas de adoptar un  enfoque formal en determinadas circunstancias», afirma el profesor  Romanovsky.

Las herramientas así como la extensa información  sobre Event-B y el apoyo que prestan los socios del proyecto Deploy  también podrían ayudar a convencer a los ingenieros a emprender  proyectos de ingeniería formal.

«A largo plazo, los sistemas de  software no dejarán de ganar en complejidad; tal y como hemos  demostrado, la ingeniería formal es un modo de hacer frente a ese  problema», concluye el profesor Romanovsky.