La Política de Actualización del Software (II)

En la primera parte pudimos comprobar cómo la ausencia de un parche puede provocar un gran daño económico a la compañía, paralizando sus operaciones, perdiendo datos o bloqueando el acceso a la información. Pero tampoco se pueden instalar las actualizaciones del software sin una gestión adecuada teniendo en cuenta cuándo, cómo, dónde y una sutil pregunta: por qué.

En esta segunda se van a conocer los elementos que hay que tener en cuenta para desarrollar la política de actualización del software.

Elementos de la política de actualización del software

Nos adentramos en la gestión, nada trivial, de la “Política de actualización del software”. Cada vez que se anuncian nuevas versiones, actualizaciones, parches, paquetes, etc., su instalación se pospone para que no afecte a las operaciones diarias del servicio. Hasta que una catástrofe alerta de su urgencia.
La adecuada gestión de las actualizaciones merece una planificación que permita preverlas teniendo en cuenta las condiciones del servicio. No siempre será posible conseguir la deseada planificación porque a su vez, dependerá de la que hagan los fabricantes sobre el ciclo de vida de sus propios productos software.

La política es la expresión de las reglas del juego. Conocidas éstas, vamos a buscar los mejores métodos y procedimientos para ejecutar las tareas y solucionar los problemas que puedan presentarse. Dentro de las especificaciones de la política es dónde debe plantearse cómo gestionar la actualización de los sistemas informáticos.

Vamos a dedicar unas líneas a explicar qué debemos considerar en la elaboración de la política de actualización. Estos son:

• El inventario de programas y aplicaciones.
• El ciclo de vida de los productos software.
• El uso de los programas y aplicaciones en el negocio.
• El servicio de mantenimiento de los sistemas informáticos.

 

El inventario de programas y aplicaciones

 

Lo primero que debemos “poner sobre la mesa” es el inventario de activos software. Este inventario además de la lista de programas y aplicaciones debe tener en cuenta las relaciones entre ellos.
La información contenida en el inventario debe responder a las siguientes preguntas.

• ¿Qué software tenemos?: ¿denominación?, ¿versión?, etc.
• ¿Quién es su fabricante o distribuidor?, o ¿es desarrollo propio?
• ¿Cómo está licenciado? ¿qué otros tipos de licencia ofrece el fabricante?
• ¿Para qué se utiliza en la compañía?, ¿es vital en el negocio?
• ¿Quién los utiliza?, ¿qué departamentos, personal, etc.?
• ¿Quién lo mantiene?, ¿estás contratado el mantenimiento a terceros?
• ¿Es fácilmente sustituible?, ¿hay otros productos similares en el mercado?

En cuanto a las relaciones entre los sistemas:

• ¿En qué servidor o plataformas hardware está instalado el software?
• ¿Sobre qué sistema operativo corren?, ¿están en máquinas virtuales?, ¿están en la “nube”?
• ¿Qué otras aplicaciones comparten el mismo servidor? (este es un punto importante y frecuentemente no se tiene en cuenta. Cualquier fallo de un programa puede comprometer a otros que comparten el mismo equipo)

Indudablemente el inventario tiene que estar actualizado. Lo que está instalado en los equipos debe coincidir con lo documentado. Por desgracia no siempre es así. Muchas empresas tienen arrinconados equipos conectados a la intranet sin ningún control de acceso, aplicaciones obsoletas a las que se continúan pagando el soporte o aparatos enchufados sin conocer realmente para qué se emplean.
Con la información detallada del inventario se identifican las aplicaciones, los equipos y otros elementos que se pueden desechar, ahorrando costes y reduciendo elementos de riesgo. Este es el primer beneficio de un correcto inventario.

Pero aún hay más:

• El inventario se necesita para comenzar un análisis de riesgos en la compañía. Es más, si algunos elementos inventariados formasen parte de los procesos que manipulan determinados tipos de datos, habrá que realizar la Evaluación de Impacto que obliga el Reglamento Europeo de Protección de Datos Personales.
• A partir de esta información es más fácil establecer la política de acceso de los
  usuarios, la creación de perfiles adecuados a cada departamento o grupo y la asignación de privilegios según a qué aplicaciones puedan tener acceso o no.
• Todo lo anterior nos encamina para seguir aplicando, aunque sea poco a poco, recomendaciones y buenas prácticas de seguridad de la información. 

Miremos donde miremos, el inventario no sólo es necesario sino imprescindible. Existen en el mercado aplicaciones especializadas para el mantenimiento más automatizado del inventario. Pero lo importante es tener los datos puestos al día.

 

El ciclo comercial del software

 

Conocido el software funcional en la compañía, debemos informarnos sobre el ciclo de vida (en la etapa comercial) que proporciona el fabricante. Aquí  realizo un inciso aclaratorio. Desde el punto de vista de los fabricantes hacia sus clientes, suelen llamar “ciclo de vida” a toda la etapa comercial del producto y así lo encontraremos en la documentación. Conviene distinguir del ciclo de vida en su sentido más amplio y completo, aquél que incluye las fases de diseño, desarrollo, verificación que tienen lugar en la factoría software, previas a la distribución y comercialización. En este contexto, cuando mencionemos el ciclo de vida nos referimos a la etapa comercial (o la distribución de un producto terminado).

El ciclo de vida ocupa el intervalo desde que el fabricante lo saca al mercado hasta su retirada definitiva. Tiene una serie de hitos que conviene conocer. Forman el “Roadmap” o itinerario de revisiones, recompilaciones y correcciones del producto. No existe un consenso en la nomenclatura. Los nombres pueden ser: “release”, versión, subversión, variante, paquete, parche, etc. La denominación también varía con respecto a la magnitud del cambio, desde la corrección de errores hasta inclusión de nuevas funciones.

La figura 1 muestra un esquema sencillo del ciclo de vida. El fabricante pone en venta un producto con su nombre comercial y una versión inicial. Esta fecha marca el comienzo del soporte técnico o mantenimiento al producto. Durante este periodo el fabricante soluciona fallos y añade pequeñas mejoras que se identifican con cambios en la numeración de las versiones. Algunos identifican al producto principal como la Versión Mayor o “Release” (1, 2,  etc.) y el resto de versiones se enumeran de forma correlativa después de un punto (1.0, 1.1, 1,2, 2.1 etc.) o se añade la fecha de salida al mercado.

Las Versiones Mayores hacen referencias a nuevos productos o grandes cambios. Muchas están asociadas a modificaciones en diseño hardware, la incorporación de estándares o nuevas soluciones técnicas.

Transcurridos unos años el fabricante anuncia el fin del soporte técnico y la venta del producto. Cuando esto ocurre, los clientes deben comenzar a planificar su reemplazo. Es posible que el fabricante proponga un nuevo producto que sustituya al existente. Los manuales técnicos informan del grado de compatibilidad del nuevo producto con el sustituido con respecto la plataforma hardware, la configuración o la integración otros dispositivos. Es imprescindible contrastar estos datos con los presentes en nuestros sistemas antes de proceder a cualquier cambio o modificación.
Si no existiese compatibilidad, los costes asociados a la actualización se incrementarán al tener que añadir otros recursos no previstos: productos adicionales, procedimientos más complejos, mayor duración, reclutar personal cualificado o necesitar un rediseño del sistema.

Para conocer los hitos y seguir el ciclo de vida de los productos es imprescindible suscribirse a la difusión de noticias RSS (Really Simple Syndication) o a las “Newsletter” o Boletines que algunos fabricantes publican periódicamente. El objetivo es alinear el calendario de mantenimiento de los sistemas informáticos de la compañía con el lanzamiento (a veces periódico) de las versiones software de los fabricantes.


En la siguiente entrada veremos algunos ejemplos.

L. F. Real