Mantenimiento de Software, Todos lo hacemos, pero nadie se acuerda

La industria de desarrollo de software mantiene una evolución constante. Antes podíamos ver que los ingenieros en sistemas computacionales, electrónica, o incluso otra especialidad contaban con todos los conocimientos necesarios para desarrollar y entregar un software. Sin embargo, la creciente complejidad del software y las tecnologías y procesos necesarios para su desarrollo y mantenimiento ha provocado que los profesionistas tengan que especializarse. Dentro de estas especializaciones encontramos algunas como la programación, el levantamiento y análisis de requerimientos, el diseño de aplicaciones, el diseño de base de datos, las pruebas de software, y recientemente una actividad que es por mucho, una de las mas importantes y menos valoradas de la industria: el mantenimiento de software. Según la terminología ANSI-IEEE, el mantenimiento del software es: “la modificación de un producto software después de su entrega al cliente o usuario para corregir defectos, para mejorar el rendimiento u otras propiedades deseables, o para adaptarlo a un cambio de entorno”. En este artículo exploraremos los aspectos fundamentales de esta actividad.Frente a la considerable velocidad con que se ha desarrollado la ingeniería de hardware, el desarrollo del software ha sufrido un retraso histórico en cuanto a la elaboración y disposición de tecnologías (metodologías y herramientas). Esto evidentemente merma la calidad de los sistemas liberados y corriendo en ambientes de producción. La complejidad del proceso de producción de software se intenta abordar mediante la descomposición en diversas etapas. Esta descomposición recibe el nombre de “Ciclo de Vida del Software”. Los diversos modelos de ciclo de vida típicamente plantean distintas fases derivadas del modelo de cascada, tales como:
• Análisis y Definición de Requerimientos
• Diseño
• Programación
• Prueba
• Despliegue
• Operación y mantenimiento.

 

Las tareas de mantenimiento son las últimas en realizarse en el ciclo de vida clásico del software. Sin embargo, considerando el total de la duración del ciclo de vida, la etapa de mantenimiento es la que más tiempo dura, ya que elaborar un sistema mediano típicamente lleva de 6 meses a 1 año, y posteriormente el sistema en producción podrá correr durante varios años durante los cuales el sistema debe ser soportado y mantenido. De la misma forma, aun cuando el mantenimiento de software es la última etapa del ciclo de vida del software, las actividades de mantenimiento no son las menos importantes. Muy al contrario, el mantenimiento del software se ha convertido en el principal componente en cuanto a costo y recursos invertidos en las organizaciones de TI. Esta aseveración responde principalmente a la relación entre el número de sistemas desarrollados anualmente por la industria, comparado con el número de sistemas en funcionamiento que hacen trabajar a las empresas.

Dentro de las actividades del mantenimiento de software ocurre un fenómeno muy interesante, que es algo que denominaremos como la barrera del mantenimiento de software, y que en pocas palabras es la incapacidad en la que se ven sumergidas las organizaciones para poder iniciar nuevos proyectos debido al enorme desvió de recursos necesarios para soportar sistemas que son parte de la operación diaria. Se estima que esta barrera se alcanza cuando más de un 90 % de los recursos se encuentran dedicados a soportar aplicaciones.

Prácticamente todos los profesionistas de sistemas hemos escuchado el comentario de que somos como los bomberos, apagando fuegos. Bueno, pues precisamente ésta es la razón de traer este tema a reflexión. El mantenimiento de software debe ser una actividad planeada por el área de tecnologías de información de una organización, que debe contar con recursos dedicados y capacitados para desempeñarla.

Dividiremos entonces nuestra plática en 2 temas importantes: los problemas del mantenimiento de software y las soluciones a estos problemas.

Problemas del Mantenimiento de Software
La problemática del mantenimiento de software se resume en realizar el mantenimiento de forma tan rigurosa y controlada que no se deteriore la calidad del sistema como resultado de este proceso. Por la naturaleza del software, existen problemas relacionados con el mantenimiento de software que están claramente identificados y sobre los cuales hablaré a continuación:

La existencia de los llamados “legacy code” (código heredado).
Con el paso de los años se ha ido produciendo un volumen muy grande de software en las empresas. En la actualidad, la mayor parte de éste software está formado por código antiguo “heredado”; es decir, código de aplicaciones desarrolladas hace algún tiempo, con técnicas y herramientas en desuso y probablemente por personas que ya no pertenecen a la empresa ni al grupo responsable en este momento del mantenimiento del software. La situación se complica porque el código heredado ha sido objeto de múltiples actividades de mantenimiento. La opción de desechar este software y reescribirlo para adaptarlo a las nuevas necesidades tecnológicas o a los cambios en la especificación no es viable en la mayoría de las ocasiones, debido a la gran carga financiera que supuso el desarrollo del software original y la necesidad económica de su amortización.

Problemas inherentes al mantenimiento del software.
A pesar de toda la estandarización y modelos de procesos que busquemos adoptar, el desarrollo de software es en el fondo un proceso creativo. Es así que en el software siempre encontraremos patrones no uniformes de programación, ya que dependiendo de su habilidad, creatividad y experiencia, los programadores generan código de maneras innumerables. Asimismo, es muy común encontrarse con aplicaciones de software desarrolladas sin seguimiento a metodologías, procesos, ni lineamientos, que se refleja en código mal escrito, mal documentado, y por lo tanto difícil de mantener.

Efectos secundarios o laterales no previstos ni deseados.
Estos efectos se dan como consecuencias a las modificaciones no controladas a las aplicaciones de software, que a su vez representan problemas para el mantenimiento posterior del software. Existen tres tipos de efectos secundarios y se definen por su impacto en las diferentes áreas de una aplicación de software:
a. Efectos secundarios en el código, en donde el código sufre modificaciones como rediseños, eliminación de procedimientos o subprogramas, modificación de macros o dll’s, cambios para mejorar el desempeño, etc...
b. Efectos secundarios en los datos, esto al impacto de los cambios en los datos de las aplicaciones, tales como modificaciones en catálogos, formularios, cambios en los parámetros de los programas, etcétera.
c. Efectos secundarios en la documentación, en donde generalmente después de un cambio en la aplicación, la documentación no es actualizada y esto genera problemas en la “mantenibilidad” del software.

Soluciones a los problemas de mantenimiento de software
Existen diversas estrategias y acciones que podemos llevar a cabo para resolver o mitigar los diferentes problemas descritos anteriormente, y que pueden servirnos de guía sobre la manera en que las organizaciones deben de enfrentar el mantenimiento de software. Entre las principales estrategias están:
Código mantenible.
Como ya lo mencionamos anteriormente, la manera de estructurar un programa depende de la creatividad y habilidad de los programadores, sin embargo existen prácticas que contribuyen a mejorar la facilidad de mantenimiento del código. Estas prácticas se resumen a continuación:
• Código documentado: Los diferentes segmentos de código que se escriben deben contener comentarios objetivos que expliquen de forma adecuada el funcionamiento de éstos. Cada programa, clase y método debe incluir documentación sobre su propósito, funcionamiento, entradas y salidas esperadas
• Banderas de cambio: es una práctica poco utilizada en la industria, y se refiere a la habilidad de establecer un mecanismo de identificación de cambios a lo largo de la vida de una aplicación. Es decir, si debido a una modificación el día de hoy cambiamos un par de líneas de código, es importante marcar esas líneas con alguna bandera que nos permita identificar en el futuro la razón por la que se modificó el código. Esto nos permite tener una visión de las versiones y justificaciones que pudieron haber inyectado un error a la aplicación.
• Documentación actualizada: esta práctica es poco ejercida debido a que el tiempo y la forma de documentación no es suficiente en los proyectos de desarrollo. Sin embargo, me refiero primordialmente a tener las especificaciones de las aplicaciones actualizadas, no al manual de usuario que si bien es de mucha ayuda, es de más ayuda tener documentación técnica actualizada, tal como diseños, diagramas, diccionarios de datos, etc…

Equipo dedicado de mantenimiento de software
A pesar de la importancia que ya vimos que tiene el mantenimiento de software, muchas organizaciones no justifican la asignación de un equipo dedicado exclusivamente al mantenimiento de software. Sin embargo, es primordial tener identificadas a las personas que realizarán esta actividad, y no solo identificadas, sino también capacitadas y calificadas para realizar estas actividades. La justificación para tener a este equipo es muy sencilla, simplemente basta con cuantificar el costo que tiene que un sistema de producción deje de funcionar, o que genere problemas en su uso debido a un bug.

Conclusión
El mantenimiento de software es un área que recibe poca atención, pero no por ello deja de ser sumamente importante, especialmente cuando se considera la cantidad de recursos que se le destinan. Existen muchos aspectos sobre el mantenimiento de software sobre los que vale la pena ahondar, y espero poder hacerlo en futuras ocasiones.

Acerca del autor
Jose M. Esquivel es Ingeniero en sistemas computacionales egresado de la Universidad Autonoma de Guadalajara. Actualmente trabaja para Jabil de Mexico como Ingeniero de soluciones empresariales dando soporte a los sistemas de la compañia asi como impartiendo la clase de “Pruebas y Mantenimiento de Software” a nivel licenciatura en la Universidad del Valle de Atemajac. Anteriormente laboró en IBM como ingeniero de pruebas, Ingeniero de desarrollo, arquitecto de producto para clientes como Motorla y Chrysler, entre otros.