En el marco de la COBIT el mantenimiento de los sistemas de información o específicamente del software –programas- corresponde al proceso AI6 Administrar Cambios [1]. Al igual que en el articulo anterior el desarrollo de éste consistirá en responder a preguntas, en este caso ellas son: ¿Qué es el Mantenimiento?, ¿Qué implicancias tiene el Mantenimiento?, ¿Qué esperan los Usuarios del Mantenimiento?, ¿Cómo caracterizar un buen Mantenimiento? y ¿Cómo se organiza el Soporte?
¿Qué es el Mantenimiento?
Una definición es: “Mantenimiento es la modificación de un sistema con el objeto de corregir una falla –bug– o de mejorar la performance o, es la adaptación del sistema a un cambio de ambiente o, por que se necesita agregar una nueva función”. [2]
En ingeniería de software, mantenimiento de software es el proceso de mejoramiento y optimización del software que está en uso, también incluye la reparación de sus defectos. El mantenimiento de software es una de las fases del proceso de desarrollo de software, y es la que sigue a la puesta en operación de un sistema. En la fase mantenimiento de software se generan los cambios necesarios para corregir los defectos y deficiencias que se detectan durante la utilización de los sistemas como asimismo la adición de nuevas funcionalidades que mejoran el uso y alcance funcional. [3]
¿Qué implicancias tiene el Mantenimiento?
Sabemos que, dada su naturaleza, cualquier programa o software tiene una probabilidad mayor que cero de tener una falla, muchas veces estas pasan desapercibidas, pues las condiciones que las gatillan no se dan en la operación habitual, sin embargo en la eventualidad que dichas condiciones se den, el programa o software fallará. A este tipo de falla se le denomina bug (bicho) y la acción de eliminarlos es el debugging y los programas para detectarlos son los debuggers. [4]
En la práctica la probabilidad que un bug tenga una consecuencia grave para una empresa es baja, sobre todo cuando el software es provisto por empresas especializadas, como ser los fabricantes de ERP, sistemas contables, liquidadores de remuneraciones, etc. Y, estos fabricantes proveen la solución para sus clientes con contratos de mantenimiento de licencias. Obviamente, asumo que el software se está usando de acuerdo a la especificación del fabricante.
Para el caso de programas desarrollados por la propia empresa, es decir por él área de Informática o por desarrollos contratados, con el perdón de los colegas, la probabilidad de falla es más alta; debido a que las prácticas de la ingeniería de software y, en particular, el control de calidad no se aplican con la misma rigurosidad que en las empresas desarrolladores de software. Este es un hecho y, tiene explicaciones razonables que nos las trataré en este artículo. Esta realidad tiene como efecto que las áreas de Informáticas terminan dedicando la mayor cantidad de sus recursos a la tarea de mantenimiento y, dentro de esta a la corrección de fallas o errores. Con lo cual se dá la paradoja que al final las área de Informáticas que hacen desarrollos propios, terminan dedicadas principalmente al mantenimiento, por más que se diga lo contrario.
El mantenimiento en lo que respecta a la adición de nuevas funcionalidades tiene una connotación de riesgo, debido a que toda modificación de un software implica una probabilidad mayor que cero de generar fallas propias o que afecten las partes antiguas del programa que estaban funcionando correctamente. Luego, el tema del testing o control de calidad de la modificaciones introducidas, cobra especial relevancia y, los ejecutivos deben poner especial atención, que tanto las áreas usuarias como el área Informática planifiquen y ejecuten actividades de testing que den un grado razonable de seguridad.
Los párrafos anteriores nos permiten establecer que el mantenimiento del software o programas puede implicar un riesgo para el negocio de una empresa es por ello, que al igual que para el Soporte, tenemos que frameworks como la COBIT e ITIL incluyen la gestión del Mantenimiento o de las Ordenes de Cambio en los procedimientos que definen como relevantes para un área Informática.
Qué esperan los Usuarios del Mantenimiento?
En el artículo anterior «El Soporte: Gestión de Mesa de Servicios e Incidentes” dije que los usuarios esperan operar en un ambiente perfecto, es decir que sea estable y siempre tenga un comportamiento predecible. En la práctica esto no es posible, ya que el software es alterado en su operar, sea por fallas propias de la programación, es decir bugs, o bien porque el negocio cambia y, se precisa agregar nuevas funcionalidades. A continuación vuelvo a mostrar gráficamente la relación de los Usuarios con el Área Informática la podemos representar de la siguiente manera:
En mi opinión lo que realmente esperan los Usuarios del Mantenimiento es que sus programas funcionen tan bien que nunca se vean expuestos a un incumplimiento de obligaciones porque el programa falló o no cuenta con las funciones necesarias. En este sentido un área de Mantenimiento eficaz generará en los Usuarios la confianza que una falla será reparada oportunamente y que la adición de nuevas funciones será fluida y no provocará catástrofes
¿Cómo caracterizar un buen Mantenimiento?
Asumo que los Usuarios el aspecto que más considerar es el relacionado con la corrección de fallas o bugs, es decir defectos de programación o parametrización, y para los Ejecutivos el factor relevante es la capacidad de generar respuestas rápidas y oportunas a los requerimiento de nuevas funciones.
- Desde la perspectiva de un Usuario.
- Facilidad para reportar el requerimiento.
- Prontitud en la solución del problema.
- Efectividad técnica.
- Seguridad en el servicio, no queda botado.
- Capacidad de generar soluciones alternativas –by pass– mientras se resuelve la falla.
- Empatía.
- Formalidad.
- Seguimiento.
- Consideración con su opinión.
- Desde la perspectiva de los Ejecutivos
- Capacidad de entendimiento de los requerimientos.
- Sintonía con las necesidades del negocio.
- Capacidad de Diseño.
- Respuesta rápida y oportuna.
- Información actualizada del estado de avance.
- Calidad, es decir la introducción de las nuevas funciones hará lo que se supone debe hacer y no afectará a lo que ya está funcionando bien.
- Desde la perspectiva de Sistemas
- Niveles de Servicios Acordados y Publicados (tiempos, horarios, etc.)
- Entendimiento del requerimiento.
- Conocimientos informáticos y de los procesos de negocios.
- Procedimiento de testing..
- Un punto único de entrada de las solicitudes de mantenimiento u ordenes de cambio
- Infraestructura técnica adecuada. Ambientes separados para el desarrollo, testing y producción.
- Base de Conocimiento.
- Buena voluntad.
¿Cómo se organiza el Mantenimiento?
Ahora hago un Copy / Paste de lo que propone para el Mesa de Servicios la COBIT para el proceso “AI6 Administrar cambios” [2].
Todos los cambios, incluyendo el mantenimiento de emergencia y parches, relacionados con la infraestructura y las aplicaciones dentro del ambiente de producción, deben administrarse formalmente y controladamente. Los cambios (incluyendo procedimientos, procesos, sistema y parámetros del servicio) se deben registrar, evaluar y autorizar previo a la implantación y revisar contra los resultados planeados después de la implantación. Esto garantiza la reducción de riesgos que impactan negativamente la estabilidad o integridad del ambiente de producción
Control sobre el proceso TI de:
Administrar el cambio,
que satisface el requisito de negocio de TI para:
responder a los requerimientos del negocio de acuerdo con la estrategia de negocio, mientras se reducen los defectos y la repetición de trabajos en la prestación del servicio y en la solución ,
enfocándose en:
controlar la evaluación de impacto, autorización e implantación de todos los cambios a la infraestructura de TI, aplicaciones y soluciones técnicas, minimizando errores que se deben a especificaciones incompletas de la solicitud y detener la implantación de cambios no autorizados,
Instalación y operación de un servicio de una mesa de servicios:
– La definición y comunicación de los procedimientos de cambio, que incluyen cambios de emergencia.
– La evaluación, la asignación de prioridad y autorización de cambios.
– Seguimiento del estatus y reporte de los cambios y reporte de tendencias.
y se mide con:
– El número de interrupciones o errores de datos provocados por especificaciones inexactas o una evaluación de impacto incompleta.
– La repetición de aplicaciones o infraestructura debida a especificaciones de cambio inadecuadas.
– El porcentaje de cambios que siguen procesos de control de cambio formales.
Los objetivos de control detallados son:
AI6.1 Estándares y procedimientos para cambios. Establecer procedimientos de administración de cambio formales para manejar de manera estándar todas las solicitudes (incluyendo mantenimiento y parches) para cambios a aplicaciones, procedimientos, procesos, parámetros de sistema y servicio, y las plataformas fundamentales.
AI6.2 Evaluación de impacto, priorización y autorización. Garantizar que todas las solicitudes de cambio se evalúan de una estructurada manera en cuanto a impactos en el sistema operacional y su funcionalidad. Esta evaluación deberá incluir categorización y priorización de los cambios. Previo a la migración hacia producción, los interesados correspondientes autorizan los cambios.
AI6.3 Cambios de emergencia. Establecer un proceso para definir, plantear, evaluar y autorizar los cambios de emergencia que no sigan el proceso de cambio establecido. La documentación y pruebas se realizan, posiblemente, después de la implantación del cambio de emergencia.
AI6.4 Seguimiento y reporte del estatus de cambio. Establecer un sistema de seguimiento y reporte para mantener actualizados a los solicitantes de cambio y a los interesados relevantes, acerca del estatus del cambio a las aplicaciones, a los procedimientos, a los procesos, parámetros del sistema y del servicio y las plataformas fundamentales.
AI6.5 Cierre y documentación del cambio. Siempre que se implantan cambios al sistema, actualizar el sistema asociado y la documentación de usuario y procedimientos correspondientes. Establecer un proceso de revisión para garantizar la implantación completa de los cambios.
Referencias
[1] Cobit 4.0 Español, http://www.isaca.org/Content/NavigationMenu/Members_and_Leaders/COBIT6/Obtain_COBIT/CobiT4_Espanol.pdf
[2] http://www.bitpipe.com/tlist/Systems-Maintenance.html
[3] Software Maintenance http://en.wikipedia.org/wiki/Software_maintenance
[4] http://en.wikipedia.org/wiki/Computer_bug