En informática los sistemas no son estáticos, van cambiando con el tiempo de acuerdo a las condiciones cambiantes de los mercados, a los clientes,a las normativas del sector, a los procesos de las empresas, y en fin a una serie variable de circunstancias, que hacen que se tenga que hacer mantenimiento de software de una u otra manera para adaptarse a estos cambios.
Es aquí don de el mantenimiento de software se vuelve una necesidad imperativa para las empresas, pues ya han hecho una inversión en un sistema, tienen mucha información sobre él, y gran parte de sus procesos de negocio se soportan sobre esos programas; resultando menos costoso, en teoría, hacerle modificaciones al software actual, que hacer un sistema nuevo.
Ese mantenimiento de software puede ser un asunto complicado de manejar, tanto para las empresas propietarias de los sistemas, como para las empresas de desarrollo de software bajo las siguientes circunstancias:
- El desarrollador del sistema es el único que conoce el software, y es el único que le hace modificaciones sobre él. Esta dependencia del fabricante original, es un riesgo bastante grande, porque si el fabricante deja de funcionar, o tiene alguna desavenencia con nosotros, no tenemos entonces quién le haga cambios a las plataformas.
- Los derechos patrimoniales de la aplicación no están correctamente radicados y legalizados en la agencia de Derechos de Autor nacional.
- El software base, como sistemas operativos, servidores web, motores de bases de datos, y otros componentes del sistema se han vuelto obsoletos, y ya no son soportados por el hardware de nueva generación.
- Carecemos del código fuente de la aplicación para hacer las modificaciones respectivas y volverlo a compilar.
- No existe una documentación técnica del sistema, que nos indique cómo está constituido desde sus arquiectura general, los módulos que lo componen, el software base que usa, las restricciones que tiene, el lenguaje de programación con el que fue creado, el modelo de la base de datos, las clases que maneja, cómo intercambia información con otros sistemas, el framework de programación que se manejó, comentarios sobre el código, diccionario de base de datos, modelo E-R, etc.
- No se tiene el control del impacto que puede causar un cambio en el sistema, porque no se conoce en su totalidad la arquitectura, siendo un riesgo que se corre cuando el desarrollador es nuevo con el sistema.
- Si el desarrollador que va a efectuar el mantenimiento de software es nuevo con la plataforma, necesita de un tiempo variable para estudiar en detalle el código fuente, la base de datos, el intercambio de información, los protocolos usados en el intercambio de datos, y la interacción de los diferentes actores con el sistema.
- No se lleva una trazabilidad de los cambios realizados en el sistema, cómo afectaron a los requerimientos originales, o cómo afecataron a otras partes del software.
- No se tiene un historial de las principales fallas del sistema, como las solicitudes que hicieron los usuarios en el tiempo, para considerar también las posibles fallas preexistentes de la plataforma.
Sabiendo entonces que tarde o temprano vamos a necesitar hacerle mantenimiento a nuestros sistemas, debemos considerar desde un principio los siguientes aspectos, para no depender al 100% del fabricante original:
- Planear una documentación técnica básica del sistema que se va a desarrollar, incluyendo:
- las historias de usuario originales,
- el control de cambios sobre las historias de usuario,
- la arquitectura general,
- el diagrama modular del sistema,
- el sistema operativo, motor de base de datos, web server, lenguaje de programación y frameworks usados;
- las clases y funciones diseñadas en el sistema,
- modelo entidad relación y diccionario de la base de datos,
- flujo de intercambio de datos, incluyendo protocolos entre sistemas, sus salidas y entradas,
- limitaciones y restricciones del sistema original,
- control de versiones de código y de base de datos,
- comentarios en archivos y funciones principales del código,
- manuales de usuario y administrador.
Toda esta información le va a permitir al desarrollador tomar menos tiempo en el estudio y entendimiento del sistema, evaluar los riesgos e impactos que los cambios tienen sobre la plataforma, para así poder empezar a planear la estrategia de cambios sobre el software.
- Legalizar los derechos morales y patrimoniales del software, con lo que tendremos a disposición el código fuente para ser modificado, distribuido y comercializado.
- Llevar un control de cambios adecuado durante el proceso de desarrollo, como en su fase de producción, para conocer las diferentes modificaciones que se le han realizado al sistema, cómo cambiaron los requerimientos originales y cómo afectaron a otros componentes.
- Registrar todas las peticiones o reportes de fallas de los clientes en un sistema de mesa de ayuda, para poder conocer las principales fallas o peticiones de los usuarios; para poder conocer las principales fallas o restricciones que tiene el sistema.
- Considerar actualizaciones de sistemas operativos y demás software base del sistema, para que no se vayan a quedar obsoletos en poco tiempo con el avance del hardware. Si definitivamente el software termina amarrado con un hardware obsoleto, se debe pensar en hacer una migración del sistema a plataformas actualizadas, o en su caso más grave, a desarrollarlo nuevamente, o migrar a un software comercial existente.
En algunos casos se puede estar usando software open source, por eso es bueno conocer hasta qué punto se pueden realizar modificaciones sobré él.
Muy pocas empresas se atreven a hacerle mantenimiento a software existente, y más si es un desarrollo a la medida, porque es alta la incertidumbre y desconocimiento del sistema, y más aun si no se cuenta con documentación técnica adecuada del sistema desarrollado, para poder así cuantificar a ciencia cierta el esfuerzo y el tiempo que se le debe dedicar para estudiar, aprender, planificar y finalmente modificar las plataformas existentes.
