En esta entrada, continuando con la anterior, voy a exponer unos ejemplos de ciclos de vida de productos comerciales. Son unas breves notas para destacar las diferencias de planificación entre distintos fabricantes.
Ejemplos del ciclo de vida
 |
No todos los fabricantes tienen un ciclo de vida como el expuesto en la Parte II
Cada fabricante especifica los periodos de tiempo de sus productos y aporta, como hemos dicho anteriormente, su nomenclatura y lenguaje particular en las ediciones comerciales. Es necesario conocer y familiarizarnos con el vocabulario empleado en las aplicaciones y programas que empleamos en nuestro negocio. A veces, la terminología puede causar equivocaciones entre los interlocutores cuando se refieren a unos productos en los términos de otros fabricantes.
Cada fabricante especifica los periodos de tiempo de sus productos y aporta, como hemos dicho anteriormente, su nomenclatura y lenguaje particular en las ediciones comerciales. Es necesario conocer y familiarizarnos con el vocabulario empleado en las aplicaciones y programas que empleamos en nuestro negocio. A veces, la terminología puede causar equivocaciones entre los interlocutores cuando se refieren a unos productos en los términos de otros fabricantes.
Sin planificación del ciclo de vida
Hay fabricantes que no tienen planificado ningún ciclo de vida. Las versiones salen sin previo aviso. En este caso, es una tarea obligada mantener una consulta periódica con el fabricante o sus socios distribuidores para conocer lo antes posible la existencia de una nueva versión. Suele ocurrir que estas consultas queden en suspenso. Sin la asignación concreta a un responsable para que la realice, puede que la versión no se actualice conforme a los requerimientos del fabricantes, siendo una situación grave cuando se trata de solucionar vulnerabilidades de seguridad.
Desarrollo de productos en líneas beta y comerciales
Productos con versiones de urgente instalación.
Red Hat nos ofrece otro interesante ejemplo. Además de las versiones importantes y subversiones de ésta, denominadas Release Major y Minior respectivamente ofrece un tercer campo denominado Asynchronus.
Los números de las Release Major y Minor siempre están presentes. La identificación numérica de Asynchronous Release es aquella que soluciona un fallo o una vulnerabilidad de seguridad. Éstas son de urgente instalación. El detalle de la política de actualizaciones de Red Hat puede consultarse aquí Update policies y la página de soporte soporte
Modelos de ciclos de vida bien establecidos
La denominación “roadmap” hace referencia a un ciclo de vida previamente planificado. Cuando sale el producto al mercado su calendario de revisiones está establecido y la fecha de “expiración” anunciada. Veamos brevemente como lo resuelve Oracle, Cisco y un enlace para conocer el de Windows. Hay que tomar nota de los vocablos y nombres que utilizan los fabricantes para designar sus productos y las líneas de soporte y mantenimiento.
Oracle Database
La compañía Oracle ha cambiado recientemente la nomenclatura y el roadmap de liberación de versiones de Oracle Database. Las versiones tienen los siguientes campos:
Cada 3 meses (Quarter) habrá una actualización de versión con nuevas funcionalidades denominadas Release Updates: RU18.1, RU18.2, RU18.3 etc. No obstante, para cada versión trimestral se publicarán revisiones con mejoras en la seguridad y soluciones de los fallos. Estas se llaman revisiones o Release Update Revision, RUR y añaden un nuevo número seguido del anterior. RUR18.1.1, RUR18.1.2, RUR18.2.1, RUR18.3.1, RUR18.3.2 etc.
Cada RU finaliza en la RUR x.x.2, por ejemplo la 18.3.0 en la 18.3.2. A partir de aquí hay que saltar a la versión 19.3.0. Oracle asegura que mantendrá los mismos niveles de seguridad y correcciones en las versiones.
Con este calendario Oracle facilita que los clientes puedan programar las actualizaciones con las operaciones del negocio. Los clientes podrán ir actualizando de RU en RU a lo largo del año o por el contrario mantenerse en una versión y actualizar sus revisiones RUR. Mas detalles en MOS, My Oracle Support.
Cisco
Tiene una política y un ciclo de actualizaciones bastante riguroso y a la vez complejo. Para un mismo producto lanza varios tipos de “Release” diferenciándose en la duración del período de mantenimiento o soporte técnico.
Con este calendario Oracle facilita que los clientes puedan programar las actualizaciones con las operaciones del negocio. Los clientes podrán ir actualizando de RU en RU a lo largo del año o por el contrario mantenerse en una versión y actualizar sus revisiones RUR. Mas detalles en MOS, My Oracle Support.
Cisco
Tiene una política y un ciclo de actualizaciones bastante riguroso y a la vez complejo. Para un mismo producto lanza varios tipos de “Release” diferenciándose en la duración del período de mantenimiento o soporte técnico.
- Early Deployment (ED). Productos software que proporcionan nuevas funcionalidades y nuevo soporte a los equipos hardware. Son versiones de vida corta permiten a los clientes desplegar últimas funcionalidades y nuevos módulos o plataformas hardware. Incorporan versiones con la corrección de fallos.
- Maintenance Deployment (MD). Corresponde a versiones de software que proporcionan soporte de mantenimiento y corrección de errores. Proporcionan estabilidad y larga vida. El soporte técnico proporciona versiones periódicas de mantenimiento (Maintenance Release, MR).
- Deferral (DF) El propósito de Deferral Advisory es anunciar la eliminación de una versión de software e introducir una de reemplazo. Es el momento para que los clientes migren a la versión de reemplazo, tal como explicamos en la figura 1 de la parte II
Los hitos principales de las releases son:
- Primer envío al cliente (First Customer Shipment, FCS): el día en que el lanzamiento está disponible por primera vez para los clientes en Cisco.com
- Fin de las ventas (EoS): el día en que el producto no se puede solicitar ni se incluye en la fabricación de equipos de Cisco. Seis meses antes se anunció esta fecha.
- Fin del mantenimiento del software (End of Software Maintenance, EoSW): corresponde al día en que la ingeniería de Cisco deja de proporcionar soporte a un producto. Antes de este hito, hay soluciones alternativas como versiones compatibles o nuevos productos.
- Fin de soporte a vulnerabilidades y seguridad (End-of-vulnerability and security support, EoVS). Desde la fecha de finalización del mantenimiento software hasta éste día, Cisco se compromete a sacar una nueva versión que solucione problemas de seguridad si fuese necesario.
- Último día de soporte, (Last day of support, LoS). Después del hito EoVS será el Technical Assistant Center de Cisco (TAC) el que proporciona soporte a los clientes. Hasta el día LoS
El soporte se extiende durante dos periodos de tiempo.
- La Fase de Mantenimiento se extiende desde FCS hasta EoSM
- La Fase de Seguridad Opcional desde EoSM hasta EoVS.
El programa de mantenimiento de las releases se ofrece de dos modos según el tiempo de duración del soporte técnico. Así tenemos Releases con soporte estándar (Standard-Support) y Releases con soporte extendido (Extended-Support).
El soporte estándar dura en total 18 meses, correspondiendo 12 meses a la primera fase y 6 meses a la segunda. El soporte extendido dura 48 meses, siendo la primera fase de 36 meses y la segunda de 12 meses. El cliente debe adquirir el software de Cisco en las releases cuyo soporte estándar o extendido se adecue a sus necesidades.
No obstante, Cisco ofrece una prolongación del periodo de soporte (48 meses adicionales en soporte estándar y 36 meses para el extendido) a través de contratos con el Centro de Asistencia Técnica, TAC.
Durante la fase de mantenimiento, Cisco saca versiones cada 3 ó 6 meses para corregir errores que hayan ido apareciendo.
Sistemas operativos Windows
Dado su amplio uso, aquí hay un enlace con el ciclo de vida de los productos Windows
Hoja de datos del ciclo de vida de Windows
Con esto damos por finalizado un breve repaso a los ciclos de vida que hemos tomado como ejemplo.
Es necesario conocer en qué situación se encuentra actualmente nuestro software, la versión, la fecha de instalación y las condiciones del mantenimiento. Por otro lado, hay que informarse de los hitos que tendrán lugar en los próximos meses de estos productos.
En la próxima entrega veremos como las características de los servicios TIC en algunos negocios imponen sus propias recomendaciones o nomas a la hora de efectuar actualizaciones de las versiones software. Factores que se deben tener en cuenta en la elaboración de la política y puede dar lugar a que existan variantes muy diferentes o haya que considerar políticas en plural.
L. F. Real
