Ignacio Trejos Zelaya| TEC y Cenfotec| itrejos@ucenfotec.ac.cr

Los ingenieros informáticos costarricenses aprenden rápidamente y muy bien los elementos de las tecnologías digitales, la programación de computadoras en lenguajes de alto nivel y la resolución de problemas, pero en su formación se ha dado poco énfasis a prepararlos para trabajar de manera metódica y disciplinada, siguiendo procesos formales y sistemáticos de software que incluyan actividades explícitas de modelado en el análisis, la especificación, el diseño, la construcción, la prueba y el mantenimiento de software.

Apenas en esta década empezaron a surgir cursos de pruebas o de control de calidad del software en los currículos universitarios de carreras informáticas en Costa Rica.  La integración de software aparece ocasionalmente en los planes de estudio, pero la ‘cenicienta’ sigue siendo el ­mantenimiento de software – y este es un fenómeno mundial.

Una de las dificultades del software es su inmaterialidad – no está sometido a leyes físicas.  Es difícil observarlo, apreciarlo y medirlo.  Entre 1964 y 1972, M. Lehman estudió con L. Belady la evolución de sistemas complejos de software en IBM, lo que les llevó a formular algunas leyes empíricas como estas:

• Cambio continuo: Un sistema de software que se usa en un ambiente real necesariamente deberá ser modificado continuamente o perderá vigencia – se volverá cada vez menos útil y satisfactorio para sus usuarios.
• Complejidad creciente: A medida que un sistema de software evoluciona, su estructura tiende a crecer en complejidad. Es necesario dedicar esfuerzo adicional deliberadamente orientado a preservar o reducir su complejidad.
• Autorregulación: La evolución de los programas siguen procesos autorregulados. Las características de esos sistemas, tales como tamaño, tiempo entre entregas y la cantidad de errores documentados, son estadísticamente semejantes para cada versión sucesiva del sistema.

Hacemos sistemas intensivos en software como si lo único que importara fuese la primera entrega y puesta en producción del producto o del servicio.  El desarrollo de software no se detiene en ese momento, sino que continúa durante la vida útil del sistema, hasta que éste sea retirado (posiblemente sustituido por un sistema de software más moderno o capaz).

Una vez que un sistema es puesto en operación, inevitablemente deberá ser modificado para continuar siendo útil: sea porque hay nuevos requerimientos de los usuarios o del negocio, porque el entorno regulatorio ha cambiado, porque es forzoso corregir defectos que no fueron detectados antes de ponerlo en operación, porque es necesario ajustarlo a cambios en la plataforma operativa, integrarlo con otras aplicaciones o moverlo a nuevos ambientes.  Quizás sea requerido mejorar su rendimiento, crearle nuevas interfaces de usuario para canales móviles o web, o  hasta remozar su apariencia, sensación y usabilidad.

La evolución y el mantenimiento de software son importantes porque las empresas e instituciones han ido digitalizando cada vez más sus procesos de negocios, sus servicios a clientes y sus relaciones con otras organizaciones, al punto que pueden hacerse totalmente dependientes de sus sistemas informatizados.

La mayoría de las organizaciones grandes que tienen más de 25 años de existir necesitan continuar invirtiendo en sus sistemas de información para que estos sigan permitiéndoles funcionar y dándoles valor.

A pesar de formar parte del Cuerpo de Conocimientos de la Ingeniería del Software desde sus primeros borradores (hace más de 20 años), el mantenimiento de software es percibido por la mayoría de los profesionales y las organizaciones como una actividad de segunda categoría.  La mayoría de las empresas prefieren dedicar a sus profesionales en software al desarrollo de nuevos sistemas, no al mantenimiento de los ya existentes.  Aunque la realidad en las empresas grandes sea que se dedican más recursos económicos al mantenimiento de los sistemas basados en software, observamos que son raras las organizaciones que desarrollan nuevos sistemas diseñados para evolucionar o soportar el cambio.

La mantenibilidad es un importantísimo atributo de calidad de los sistemas de software.  El Glosario de Terminología de Ingeniería  del Software del IEEE define así la mantenibilidad: “La facilidad con la que un sistema o componente de software puede ser modificado para corregir fallas, mejorar su rendimiento u otros atributos, o adaptarse a un ambiente modificado”.

La mantenibilidad es directamente proporcional a la facilidad con la que se pueda comprender el producto software (qué hace, cómo trabaja, porqué funciona como lo hace, con qué se relaciona), la facilidad con la que se pueda encontrar qué necesita ser cambiado o sustituido, la facilidad con la que puedan realizar las modificaciones y comprobar que los cambios son correctos y que no se introducen nuevos defectos.

Las revisiones estáticas (caminatas, revisiones técnicas, inspecciones) son de las actividades de control  de calidad más provechosas para detectar problemas y deficiencias, más temprano, a menor costo y con mayor cobertura que las pruebas dinámicas.  Curiosamente, no se las practica mucho en nuestro medio.  Además, es infrecuente que el equipo de revisión tenga un participante que aporte el punto de vista de los responsables del mantenimiento del software cuando se evalúa el diseño arquitectónico, la estructura modular, las dependencias, los estándares de construcción (programación) y la posible evolución de los requerimientos del sistema de información.

Si los autores del sistema original no fueren los responsables de su mantenimiento, inevitablemente estos últimos deberán enfrentar una curva de aprendizaje para comprender el sistema, sus componentes y su contexto antes de hacerle cambios – lo cual tomará tiempo.  Si los cambios se realizan en forma descuidada y poco modular, el sistema irá degradando su estructura y eso hará aún más difíciles las modificaciones y los ajustes en el futuro.  A esto agreguemos que, cuando se desarrolla un nuevo sistema, la documentación no necesariamente existe y, si existiere, puede no estar acorde con la construcción – pues a medida que se ajustan los programas, se descuida la documentación – por lo que acaba siendo una caricatura de una realidad cuya forma habrá sufrido alteraciones difíciles de reconocer.  Esto dificultará aún más la comprensión del sistema a aquellos que se encarguen de darle mantenimiento.

Un reciente editorial del periódico La Nación, titulado ‘Debilidad informática en la Caja’, está dedicado al sistema de información encargado de la planilla para pagar a los empleados de la Caja Costarricense de Seguro Social (CCSS).  El presidente de la CCSS, Dr. Román Macaya, reportó que el personal capaz de realizar los cambios en el software de planillas no cree poder concluir antes de marzo del año 2021.  La Nación cita al Dr. Macaya: “Solo cuatro funcionarios de la entidad, próximos a jubilarse, dominan el lenguaje de programación sobre el que está sustentado el sistema actual de pago de salarios”.  Es probable que el lenguaje sea COBOL, el cual ya no se enseña en la mayoría de las universidades costarricenses (y muy poco en el resto del mundo); en el TEC dejamos de enseñarlo poco antes de entrar al presente siglo.

Entre las décadas de 1960 y 1990, antes del advenimiento de Java, COBOL fue el lenguaje dominante para escribir programas para sistemas de información empresariales. Enfrentamos, entonces, una situación de escasez mundial de profesionales conocedores de tecnologías sobre las que se sustentan sistemas que se mantienen vigentes, pero envejecen inexorablemente.

No creo que sea la primera vez que la Caja enfrente algo así.  Hace más de 25 años recuerdo que debieron hacer ajustes a su sistema de planilla para poder generar cheques de pago por más de 999.999 colones a los médicos.  Hace un poco más de 20 años, muchas organizaciones costarricenses estaban revisando sus sistemas para asegurar que podrían enfrentar el manejo de fechas al sobrevenir el cambio de siglo en enero del 2000 (Y2K).

Hace 10 años se calculaba que había entre 200.000 y 250.000 millones de líneas de código escritas en COBOL para sostener sistemas de información en organizaciones públicas y privadas alrededor del mundo.  Se ha estimado que mundialmente hay más de un millón de programadores que trabajan en COBOL; pero el 52% de ellos tiene edades entre los 50 y los 60 años y el 34% está entre los 40 y los 50 años.

Compañías como Micro Focus desarrollaron herramientas para migrar aplicaciones escritas en COBOL desde macro-computadoras (‘mainframes’) hacia microcomputadoras basadas en Windows.  Eso no es suficiente para que nuevos ingenieros sean capaces de dar mantenimiento a sistemas heredados escritos en COBOL.  Requerirán estudiar los sistemas para comprender su funcionalidad, hacer ingeniería reversa para determinar su estructura, analizar el impacto de los cambios propuestos, hacer reingeniería en busca de dar estructura modular a las partes de manera que la ‘lógica’ de procesamiento quede confinada en componentes reconocibles, bien documentados y más mantenibles en el futuro.  Además, será necesario probar tanto las partes modificadas como las no alteradas, poner el sistema y sus componentes en gestión de configuraciones.

Puede ser que una organización considere migrar sus sistemas de software, con sus datos, hacia nuevas plataformas; el Club de Investigación Tecnológica publicó un excelente informe de investigación sobre esta materia en agosto del 2002 (Declan Good. ‘Legacy Transformation’, traducido como ‘Transformación de Aplicaciones Legacy’).

La empresa nacional Artinsoft (hoy Mobilize.net) tiene 25 años de estar desarrollando tecnología y métodos innovadores para reestructurar aplicaciones de software y migrarlas desde una plataforma hacia otra – de manera casi completamente automatizada.

Es importante aprender de la historia, para no continuar repitiendo errores.  El COBOL, el RPG y el Business Basic de ayer nos dan dolores de cabeza hoy. Los sistemas empresariales que hemos venido desarrollando en lenguajes como Java, Visual Basic, PHP o C# nos darán dolores de cabeza en el futuro si no actuamos hoy previsoramente.

Algunas empresas del ámbito financiero-bancario han venido trabajando, desde hace más de 10 años, en la reestructuración y la reescritura de sus aplicaciones de software.  Por ejemplo, BAC Credomatic dio el contexto para dos investigaciones de Maestría en Computación del TEC: Componentizar en servicios reutilizables aplicaciones monolíticas bajo una Arquitectura Orientada a Servicios y el Diseño de patrones de arquitectura de aplicaciones para realizar consumo de servicios.  Asimismo, el Banco Central de Costa Rica rediseñó hace un par de décadas varios sistemas dispersos que había construido para administrar títulos valores (bonos), de manera que fueran parametrizables y soportaran los ajustes que se fueran necesitando en ese dominio de negocios.  Otras organizaciones costarricenses han rejuvenecido o reemplazado sus sistemas con la ayuda de empresas de software especializadas.

En 1992, Ward Cunningham enunció la metáfora de la ‘deuda técnica’: decidir entre obtener beneficios de corto plazo por liberar software inmaduro y pobremente estructurado, contra los costos de lidiar con darle mantenimiento en los plazos medianos y largos.

La metáfora nos lleva a pensar en términos económicos: comparar los costos y beneficios de una salida rápida contra el ‘interés’ y la ‘amortización’ de una ‘deuda’ que en el futuro conllevará reparar y mejorar software con características pobres, que van contra su mantenibilidad y utilidad.

Salir temprano al mercado con un producto funcional puede ser deseable y beneficioso, pero la metáfora llama a imaginar los costos de mejorar un producto que va a evolucionar como consecuencia de su propio éxito. Por ello, es importante tener temprano el punto de vista de quienes pueden reconocer los problemas potenciales, para evitar postergar las correcciones a los problemas estructurales, de documentación, de seguridad, de rendimiento, u otros.  De otra manera, incurriríamos en endeudamientos semejantes a los de los préstamos o tarjetas de crédito a los que uno no puede hacerles frente.  La deuda técnica mal manejada puede llevarnos a pagar altísimos intereses en el futuro, a perder competitividad o incluso a enfrentar la quiebra (como fue el caso de Ashton-Tate a inicios de la década de 1990).