En esta parte voy a dedicar unas líneas a explicar los contenidos más importantes que deben figurar en el documento de política de actualización del software. Algunos son imprescindibles pero otros serán solo informativos.
Información para el documento
Disponemos de la siguiente información.
- Inventario de las aplicaciones informáticas de la organización, sus funciones importancia para el negocio.
- Los ciclos de vida que los fabricantes dan a sus productos, el calendario (roadmap) de lanzamientos y la duración de la fase de mantenimiento.
- Las restricciones que impone el tipo de negocio a los cambios del software.
- Los contratos de mantenimiento con terceras empresas y sus implicaciones en estos cometidos.
Con la información anterior construiremos las directrices de la política. Ésta, por un lado, será la base para desarrollar los procedimientos técnicos, escenarios de pruebas, test de verificación, etc. Por otro lado, será el proceso de la gestión del cambio quien asuma la acción dentro de la gestión del servicio y cómo afecta a éste (sirva como referente lo que recomienda ITIL al respecto).
Contenido destacado en el documento
En el documento se incluirá los siguientes apartados principales.
- El alcance del documento. Enumera qué software, equipos y sistemas son los destinatarios de la política descrita en el documento. La compañía selecciona según su funcionamiento conjunto, modelo de equipos, servicios en los que interviene, etc.
- Se dedicará un apartado a explicar las reglas que rigen la nomenclatura y numeración de las versiones que se utiliza en el documento. Estas normas son comunes en toda la compañía y están autorizadas y aprobadas por la dirección. Es conveniente explicar la relación entre ésta y la utilizada por los fabricantes para evitar la confusión.
- Es interesante recoger una una breve explicación del ciclo de vida del pruducto. Puede añadirse en un anexo al final del documento los enlaces a las páginas web de los fabricantes.
- Destacar la situación actual del software de la compañía con respecto a su ciclo de vida.
- Lista de tareas previas que deben ser verificadas (“checklist”) antes de iniciar la propia actualización. Todas tendrán sus procedimientos descritos para ejecutarlas. Por ejemplo:
o Verificación de los requisitos hardware y software necesarios para la correcta instalación.
o Backup de todo firmware, sistemas operativos, programas, aplicaciones y sus respectivas configuraciones que puedan verse afectadas.
o Documentos de los fabricantes de los procedimientos de actualización de sus productos. Disponibles para su consulta.
o Comprobación de equipamiento adicional: comunicación, servidores, acceso remoto, copias de seguridad. Aquí quisiera hacer un inciso importante. Si un equipo remoto está en un acceso difícil habrá que considerar el posible desplazamiento de técnicos para solucionar problemas
in situ.
o Procedimientos de vuelta atrás en caso de poder realizarse la instalación o recuperar las funcionalidades.
o Otras considereaciones dependientes de cada sistema.
Estos dos últimos apartados los voy a dedicar en las siguientes secciones dada su importancia en la política, puesto que es la razón de ser de la misma, el motivo por el cual se redacta.
- Criterios para autorizar la actualización de versiones.
- Proyecto de actualización
Criterios para autorizar la actualización
Para autorizar la actualización del software se realizará teniendo en cuenta una serie de criterios. Los criterios más destacados son los siguientes:
- Consecuencia del seguimiento de la versión lanzada por el fabricante:
- Aparición de nuevas funciones que desee implantar la compañía.
- Determinados equipos se actualizan periódicamente, y esta versión es una de ellas.
- La versión aporta corrección de errores que afectan a las configuraciones usadas.
- El fabricante impone un cambio de versión que es imprescindible:
- Actualización de Urgencia para la corrección de errores graves.
- Eliminación de una versión cuando alcanza el fin del ciclo (
End of Live).
- División de una versión en dos líneas diferentes con evolución divergente.
Podemos comprobar que todos son impuestos por el fabricante excepto el primero. Se deja la opción de no actualizar a una versión lanzada. Puede ocurrir que en futuras versiones haya que instalar todas las anteriores. La decisión de actualizar o no una versión, un paquete o un parche, será asumida por la propia compañía, estará justificada y autorizada.
Proyecto de actualización
El proceso de actualización se tratará como un proyecto, más o menos complejo, de la compañía. Como tal, debe cubrir todos los requisitos para su realización. Depederá del tipo de software, sus características e importancia. El proyecto no será el mismo para la instalación de un parche en un sistema operativo en unos pocos ordenadores que la renovación de una aplicación crítica e insustituible, que será clave en la pervivencia del negocio.
El proceso debe superar una serie de fases hasta que la nueva versión alcance la funcionalidad completa sobre todos los equipos y sistemas del entorno de producción que la deban incorporar. Las fases de un despliegue de una actualización las podemos resumir en las siguientes.
- Elección de la versión que se va actualizar. La primera tarea es la lectura de los manuales o boletines sobre las características de la versión lanzada. La segunda será la consulta de las dudas no resueltas con los fabricantes y los proveedores. Debemos obtener la información suficiente para saber si debemos afrontar o no la actualización de una nueva versión. En esta fase se analizan los criterios expuestos anteriormente. El resultado será un informe motivado con la autorización o no de la nueva versión.
- Pruebas de validación. Esta fase se realiza en un entorno de pruebas. La ejecución de un Plan de Pruebas verificará la instalación y el correcto funcionamiento. Esta fase podrá incorporar pruebas de rendimiento, carga de trabajo, estrés, etc. y todas aquellas que se consideren oportunas para comprobar la solidez del software. El resultado de esta fase es la homologación de la nueva versión; es decir, que ésta se podrá trasladar a los equipos y sistemas del entorno de producción con los cambios de configuración o ajustes necesarios.
- Instalación de la versión homologada en equipos de producción de acuerdo con una Prueba Piloto. Habrá que tener en cuenta los periodos de mantenimiento para actuar sin afectar a los servicios. La Prueba Piloto seleccionará los primeros equipos sobre los que se probará. Tendrá encuenta los escenarios más variados y complejos. La prueba realizará una monitorización exhaustiva de los equipos y sistemas. Determinará sobre que parámetros se efectuará, los rangos de las medidas y los umbrales para la detección de anomalías. Este seguimiento se realizará durante un tiempo: dias, semanas, meses ...
- La versión actualizada se Certifica que funciona en el entorno de producción.
- Despliegue de la versión certificada en todos los equipos. La Prueba Piloto puede exigir una monitorización similar a otros equipos o sistemas durante otro periodo.
Próximos pasos y final
El documento de política debe adecuarse a los distintos tipos de sistemas que tiene la compañía.
Como últimas palabras expongo aquellas que mencionó un director de Calidad de una importante consultora internacional:
" Escribe lo que vas hacer, y haz lo que hayas escrito "
Resume un trabajo pensado, elaborado, concienzudo y previendo las posibles incidencias que puedan ocurrir. Condiciones que no siempre se imponen en el mundo actual
L. F. Real
