...

• Peticiones de lanzamiento de incremento de versión (PL versión).  Aplican sobre todas las aplicaciones centralizadas que deben tener desarrollo y evolución, es decir, versiones en las que se incluyan evolutivos y correctivos.
• Peticiones de lanzamiento para modificación/configuración de software base (PL sistemas). Aplican sobre todas las plataformas centralizadas sobre las que se quieren hacer cambios menores, es decir, sin que sea necesaria una petición de plataforma.
• Peticiones de lanzamiento para modificaciones de datos (PL datos). Aplican sobre las aplicaciones centralizadas sobre las que se requieren peticiones o incidencias de datos que requieren implantación.
• Peticiones de lanzamiento para cambios de configuración (PL configuración). Aplican sobre todas las aplicaciones centralizadas sobre las que se requieren peticiones de configuración.

PL de incremento

...

versión 

Roles

(*)  En la documentación usaremos la palabra solicitante queriendo indicar que las acciones las puede realizar  Solicitante puede ser tanto el Responsable de producto (y cualquier jefe como cualquier usuario que tenga rol de Jefe de proyecto del área de Proyectos) como proyectos, mientras que sólo podrá ser el proveedor (de desarrollo)de la aplicación sobre la que se requiere el despliegue.

(**)  A efectos del flujo en la herramienta, los permisos del Responsable de Sistemas son los mismos que los que tiene cualquier jefe de proyectos del área de Sistemas

(***) A efectos del flujo en la herramienta, dicho rol no posee acciones

Ciclo de vida 

Cuando el proveedor acaba un desarrollo y necesita hacer un despliegue  en unos de los entornos de la STIC, entrega el código para que el proveedor de sistemas que gestiona la plataforma donde va a hacerse el despliegue, lo ejecute en los entornos solicitados por el proveedor, siempre bajo la supervisión del Responsable de Producto.

Por tanto, será necesario saber la normativa de gestión de entregas y qué requerimientos debe cumplir el proveedor para que el código que ha desarrollado pueda ser desplegado satisfactoriamente:

• Debe estar clara la entrega que se quiere desplegar, Siempre va a constar de cuatro dígitos, donde los tres primeros vienen dados por el código de la versión. Por tanto, debe existir una versión en estado "En resolución"  para determinar los tres primeros dígitos. El cuarto dígito se informará de forma secuencial teniendo en cuenta que para una versión no puede haber más de una petición de lanzamiento abierta.
• El proveedor debe entregar el código siguiendo la normativa establecida por el área de Gobernanza (https://ws001.sspa.juntadeandalucia.es/unifica/web/gobernanza/gestion-de-entregas)
• El proveedor debe realizar el procedimiento de Instalación y desinstalación (PID), es decir, debe describirse el proceso de despliegue sobre la plataforma que previamente se habrá construido o modificado siguiendo el proceso de Gestión de Plataformas.
• No es posible solicitar una PL sin que la OCA realice una verificación del código entregado. Básicamente, la verificación de la entrega consta de las siguientes tareas:
  • Verificación estructura correcta del repositorio GIT
  • Verificación campos del fichero Readme.md
  • Verificación Cumplimiento de la Normativa Oracle
  • Verificación uso correcto de  Gitflow
  • Verificación estructura de los archivos pom.xml y build.xml
  • Compilaciones JENKINS
  • Verificación y validación de calidad estática del código

Mientras la OCA no ejecute su verificación es imposible avanzar con la PL. Ahora bien, el veredicto de la OCA puede ser conforme o no conforme. En cualquier caso, a excepción de que la no conformidad se deba a que la compilación en JENKINS falla, será posible seguir con el despliegue del código.

La verificación que hace la OCA del código y la PL están relacionadas y tienen un vínculo común, la entrega, de forma que para una entrega sólo es válida una SVE y una PL, a menos que la PL se cancelara y no llegara a ejecutarse.

Hay que tener en cuenta que además de la entidad en la que la OCA verifica el código (SVE=Servicio de Verificación de entrega), el proceso de gestión de lanzamientos se articula en JIRA con dos tipos de entidades:

• PL:  es la contenedora del alcance de la PL, sobre la que revisará la documentación (PID), se solicitarán y generarán implantaciones.
• PL hija: una subtarea de la PL por cada  instalación en una Plataforma, entorno, grupo lógico o conjunto de grupos lógicos. Cada una de estas entidades puede contener una o más ejecuciones, la primera siempre correspondiente a una instalación. El hecho de que no se acepte la solución por parte del peticionario, puede llevar a ejecutar una desinstalación, marcha atrás o reinstalación que serán controladas en la PL Hija como ejecuciones de la misma.

Por otra parte, cualquier PL incremento versión puede tener dos tipo:

• Normal: tienen un plazo de ejecución entre 24 y 48 horas.
• Urgente: En este caso la PL debe ejecutarse en el menor tiempo posible, no pudiendo asumirse el plazo de ejecución normal. Hay que tener en cuenta que la ejecución urgente de una PL incrementa los costes de gestión incurridos por este lanzamiento y supone un mayor riesgo de indisponibilidad del servicio. Los motivos por los que puede ser necesaria una PL urgente son:
• Hay que solucionar una incidencia lo antes posible
• Hay que instalar lo antes posible para cumplir cronograma de la STIC
• Hay que instalar lo antes posible para cumplir necesidades impuestas por el SAS 

Requisitos para el ciclo de vida de la PL incremento versión:

• La gestión de cambios debe siempre hacerse en una aplicación.
• Debe determinarse claramente la entrega que se quiere implantar.
• La entrega debe constar de 4 dígitos, los tres primeros vienen dados por el código de la versión que incluye los evolutivos y correctivos. La versión debe estar en estado En resolución.
• El código debe entregarse en el GITLAB siguiendo la normativa del área de Gobernanza.
• El proveedor debe realizar el PID (Procedimineto de instalación y desinstalación)
• Es requisito imprescindible para crear una PL que la OCA haya hecho la verificación del código a entregar, que se modelará en otra entidad, el Servicio de Verificación de Entrega (SVE).
• Para el caso de las PLUs, NO será necesario que previamente haya una SVE.
• El peticionario siempre debe solicitar la implantación en uno o varios entornos y en una o varias plataformas. No es obligatorio que indique los grupos lógicos.

...

Ciclo de vida 

Cuando el proveedor acaba un desarrollo y necesita hacer un despliegue  en unos de los entornos de la STIC, entrega el código para que el proveedor de sistemas que gestiona la plataforma donde va a hacerse el despliegue, lo ejecute en los entornos solicitados por el proveedor, siempre bajo la supervisión del Responsable de Producto.

Por tanto, será necesario saber la normativa de gestión de entregas y qué requerimientos debe cumplir el proveedor para que el código que ha desarrollado pueda ser desplegado satisfactoriamente:

• Debe estar clara la entrega que se quiere desplegar, Siempre va a constar de cuatro dígitos, donde los tres primeros vienen dados por el código de la versión. Por tanto, debe existir una versión en estado "En resolución"  para determinar los tres primeros dígitos. El cuarto dígito se informará de forma secuencial teniendo en cuenta que para una versión no puede haber más de una petición de lanzamiento abierta.
• El proveedor debe entregar el código siguiendo la normativa establecida por el área de Gobernanza (https://ws001.sspa.juntadeandalucia.es/unifica/web/gobernanza/gestion-de-entregas)
• El proveedor debe realizar el procedimiento de Instalación y desinstalación (PID), es decir, debe describirse el proceso de despliegue sobre la plataforma que previamente se habrá construido o modificado siguiendo el proceso de Gestión de Plataformas.
• No es posible solicitar una PL sin que la OCA realice una verificación del código entregado. Básicamente, la verificación de la entrega consta de las siguientes tareas:
  • Verificación estructura correcta del repositorio GIT
  • Verificación campos del fichero Readme.md
  • Verificación Cumplimiento de la Normativa Oracle
  • Verificación uso correcto de  Gitflow
  • Verificación estructura de los archivos pom.xml y build.xml
  • Compilaciones JENKINS
  • Verificación y validación de calidad estática del código

Mientras la OCA no ejecute su verificación es imposible avanzar con la PL. Ahora bien, el veredicto de la OCA puede ser conforme o no conforme. En cualquier caso, a excepción de que la no conformidad se deba a que la compilación en JENKINS falla, será posible seguir con el despliegue del código.

La verificación que hace la OCA del código y la PL están relacionadas y tienen un vínculo común, la entrega, de forma que para una entrega sólo es válida una SVE y una PL, a menos que la PL se cancelara y no llegara a ejecutarse.

Hay que tener en cuenta que además de la entidad en la que la OCA verifica el código (SVE=Servicio de Verificación de entrega), el proceso de gestión de lanzamientos se articula en JIRA con dos tipos de entidades:

• PL:  es la contenedora del alcance de la PL, sobre la que revisará la documentación (PID), se solicitarán y generarán implantaciones.
• PL hija: una subtarea de la PL por cada  instalación en una Plataforma, entorno, grupo lógico o conjunto de grupos lógicos. Cada una de estas entidades puede contener una o más ejecuciones, la primera siempre correspondiente a una instalación. El hecho de que no se acepte la solución por parte del peticionario, puede llevar a ejecutar una desinstalación, marcha atrás o reinstalación que serán controladas en la PL Hija como ejecuciones de la misma.

Por otra parte, cualquier PL incremento versión puede tener dos tipo:

• Normal: tienen un plazo de ejecución entre 24 y 48 horas.
• Urgente: En este caso la PL debe ejecutarse en el menor tiempo posible, no pudiendo asumirse el plazo de ejecución normal. Hay que tener en cuenta que la ejecución urgente de una PL incrementa los costes de gestión incurridos por este lanzamiento y supone un mayor riesgo de indisponibilidad del servicio. Los motivos por los que puede ser necesaria una PL urgente son:
• Hay que solucionar una incidencia lo antes posible
• Hay que instalar lo antes posible para cumplir cronograma de la STIC
• Hay que instalar lo antes posible para cumplir necesidades impuestas por el SAS 

...

Figura 2. Diagrama flujo PL Hija.

En el siguiente enlace al manual JIRA se detalla los estados, acciones y roles que pueden actuar en cada punto del flujo, puedes consultar el manual del JIRA , herramienta en la que se ha modelado este proceso.

Para que el solicitante pueda crear y seguir un flujo de PL de Incremento de versión en un proyecto de tipo aplicación, es necesario que:

...

• Cambiar la PL a PLU, lo que supondrá una variación en el límite de tiempo que tiene CTI para leer y aprobar la documentación. En el cambio a PLU  se generará automáticamente una PL hija sólo para un entorno y para todos los grupos lógicos.
• Solicitar PLs hijas, que serán generadas por el Grupo Planificador una vez que CTI haya revisado y aprobado el PID. Para la solicitud de hijas, debe indicarse de forma obligatoria la o las plataformas, el entorno o los entornos y la restricción horaria en la que se quiere hacer la implantación. Existe igualmente la posibilidad de solicitar la PL Hija como PLU.

Estado PLANIFICABLE

Estado asignado al Grupo Planificador para que genere las PLs hijas en el caso de que se le hayan solicitado. Al igual que en el estado anterior, el peticionario puede solicitar PLs hijas tantas veces como desee (tanto normales como PLU) e incluso tiene la posibilidad de cambiar la PL a PLU. En este último caso y, ya que la documentación ha sido aprobada, el cambio a PLU va a implicar que se genere automáticamente una PL hija urgente.

Cuando el Grupo Planificador genera las PLs hijas, debe indicar de forma obligatoria la o las plataformas, el o los entornos y el grupo lógico, pudiendo optar entre crear una PL hija por cada grupo lógico o bien una PL hija por cada uno de los grupos lógicos. Opcionalmente pueden seleccionar si se requiere o no Agrupación de plataforma. 

Como resultado de esta acción se generarán PLs Hijas por cada tripleta plataforma-entorno-grupo lógico de manera que no sea posible que dos PLs hijas tengan la misma tripleta.

El hecho de generar PLs hijas hace que la PL cambie a estado EN RESOLUCIÓN. 

El estado en el que se crean las PLs hijas es PLANIFICABLE si la hija no es urgente., con idea de que el Grupo Planificador proponga una fecha y que CTI la acepte o bien proponga otra que a su vez deberá ser aceptada por el Grupo Planificador.

...

Si el peticionario aún no ha solicitado PLs hijas, puede hacerlo en este estado tantas veces como desee.
En el momento en el que se hayan solicitado PLs hijas, el Grupo Planificador procederá a crearlas, para ello:

• Debe indicar obligatoriamente el o los entornos, la o las plataformas, los grupos lógicos (eligiendo si quiere una PL Hija para todos los grupos lógicos o bien una por cada uno de ellos) y opcionalmente las agrupaciones de plataformas.
• Por cada tripleta (entorno-plataforma-grupo lógico) se creará una PL Hija en estado Planificable.
  
  

El hecho de generar PLs hijas hace que la PL cambie a estado EN RESOLUCIÓN. 
El peticionario puede en cualquier momento cambiar la urgencia de la PL pasándola a PLU, lo que conllevará la creación automática de la PL Hija si no estuviera creada ya. En el caso de que ya existiera, podría cambiar la urgencia de la PL Hija.

Estado EN RESOLUCIÓN

Estado asignado al informador y que indica al solicitante que ya existen PL hijas. Al igual que en el estado anterior, el peticionario puede solicitar PLs hijas tantas veces como desee (tanto normales como PLU), y el Grupo Planificador podrá generar las PLs hijas.

Una vez que el Responsable de Producto considera que ya no debe haber más implantaciones, podrá finalizar la PL para lo cual es imprescindible que todas las PLs hijas estén cerradas. Ahora bien, dependiendo de cómo se hayan cerrado las hijas se cerrará la padre. Estos cierres se controlan con el campo Resolución que aparece debajo del estado.

Hay tres posibles resoluciones para una PL cerrada en una versión:

• Resuelta si todas las PLs hijas están resueltas.
• Parcialmente resuelta si alguna PL hija está resuelta y alguna cancelada.
• Cancelada si todas las PLs hijas están canceladas.

Ciclo de vida de la versión al finalizar la PL

Partíamos de versiones En resolución para poder generar PLs.

Una vez que la PL está cerrada, el Responsable de producto puede finalizar las implantaciones, pasando la versión de En resolución a Implantada, lo que hará que las mejoras e incidencias pasen de estado En versión a Cerradas.

Una vez que la versión esté en estado Implantada, el Responsable de producto puede cerrar la versión siempre que las OTs estén cerradas.

En la siguiente tabla se contemplan los posibles estados de la versión una vez que está En resolución

PL hija

Como hemos adelantado, las PLs hijas se crean de dos formas:

• Generadas por el Grupo Planificador en función de las solicitadas por el peticionario.

En este caso, las Pls hijas se crean en estado Planificable, con idea de que el Grupo Planificador proponga una fecha y que en base a la misma CTI la planifique. Esa fecha de planificación deberá ser validada por el Grupo Planificador.

• Generadas automáticamente si se ha solicitado por parte del peticionario una PLU. En este caso, se genera sólo una PL hija (correspondiente a una plataforma, entorno y para todos los grupos lógicos) en un estado en el que CTI planifica y pasa a ejecutar.

Si una PL hija se transforma en una PLU, transicionará automáticamente de estados anteriores al estado en el que CTI planifica, no necesitando aprobación por parte del Grupo Planificador de esa planificación.

Estas transiciones automáticas se harán también en el caso de una PLU que esté pendiente de planificación y que pase a ser normal. En este caso, pasará al estado en el que el Grupo Planificador proponga fechas.

Los estados por los que pasa la PL hija por tanto son:

Estado PLANIFICABLE

Al generarse la PL hija está en estado PLANIFICABLE si se ha solicitado una PL hija no urgente.

El Grupo Planificador solicita planificación a CTI indicándole una fecha en base a la restricción horaria del peticionario.

Estado PDTE. CALENDARIZAR

CTI recibe la solicitud de planificación del Grupo de Lanzamientos y propone una fecha de inicio estimada y una fecha fin estimada.

Estado CALENDARIZADA

El Grupo Planificador  debe aprobar o no aprobar las fechas que propone.  En caso de no estar conforme con las fechas, CTI deberá volver a planificar.

Estado PDTE. COMENZAR RESOLUCIÓN

Una vez la fecha está aprobada, la PL hija quedará pendiente de iniciar la resolución.

En este estado, el proveedor sistemas podrá cambiar tanto la fecha de inicio estimada como los grupos lógicos.

Hasta este estado, el peticionario podrá cambiar la urgencia de la PL.

Estado EN RESOLUCIÓN

El proveedor de sistemas comienza la resolución, realizando las actividades programadas en la documentación.

Al finalizar la resolución debe informar si se han producido errores y los comentarios que considere necesario.

Estado PDTE. REVISIÓN TÉCNICA

El peticionario debe revisar la ejecución y aceptar o no aceptar la solución técnica.

• Si acepta la solución técnica, la PL hija pasa a Estado CERRADA con resolución resuelta. Al cerrase la PL hija, se producirá el cambio de versión en CMS en la tripleta (plataforma-entorno-grupo lógico) correspondiente.
• Si no acepta solución técnica se pregunta al solicitante si quiere, reinstalación con o sin marcha atrás, si quiere desinstalar o si no quiere hacer nada.
  • Si se requiere reinstalación o desinstalación la PL hija pasará a estado PDTE. CALENDARIZAR y de ahí a PDTE. COMENZAR RESOLUCIÓN, es decir, no hay intervención del grupo de lanzamientos.
  • Si no se requiere ni reinstalación ni desinstalación, la PL hija se cerrará y cerrará automáticamente todas las PL hijas de la PL (PL hijas 'hermanas') y la resolución de todas ellas será "No se hará"

Al finalizar cada ejecución se graba en una tabla visible los siguientes datos:

• Tipo de actividad: Instalación, Reinstalación, Marcha atrás, Desinstalación.
• Entorno: Entorno en el que se ha ejecutado la PL hija.
• Fecha inicio: Fecha inicio real de la ejecución de la PL hija.
• Fecha fin: Fecha fin real de la ejecución de la PL Hija.
• Complejidad: Complejidad de la PL hija. Por defecto siempre es NO.
• Facturable: por defecto Facturable es Instalación y Desinstalación.
• PLU: Informa si la ejecución ha sido solicitada como Urgente.
• HBS: Valor de cada ejecución en función de los parámetros establecidos Prioridad (PLU), Complejidad, Horario.

El proveedor de sistemas dispondrá durante todos los estados de la PL Hija y hasta 10 días después de finalizar el mes, la acción Solicitar Revisión.  Con esta acción podrá solicitar al Grupo Planificador que se revisen los parámetros de Complejidad y/o facturación.  

El Grupo Planificador dispondrá de una acción para actualizar la tabla de ejecuciones si el proveedor sistemas así se lo ha solicitado. Los cambios quedarán registrados en el histórico de cambios.

Cambio en la urgencia de la PL

Como ya hemos comentado, el peticionario puede en cualquier momento cambiar la urgencia de la PL y de la PL hija (hasta el estado EN RESOLUCIÓN).

• Cambiar la urgencia de la PL tiene como repercusiones:
  • Si está en estado PDTE. REVISIÓN, el tiempo de lectura de la documentación variará. Si ya ha pasado de ese estado, en la PL no hay repercusión.
  • Se creará una PL hija automáticamente si es que se cambia a PLU. Si el cambio es al contrario, la PL hija pasará a un estado en el que intervenga el Grupo Planificador.

• Cambiar la urgencia de la PL hija tiene repercusiones:
  • Si el cambio es a PLU:
    • Si está en estado PLANIFICABLE à pasa a estado PDTE. CALENDARIZAR y se suprime el estado CALENDARIZADA.
    • Si está en estado CALENDARIZADA àpasa a estado PDTE.COMENZAR RESOLUCIÓN, pudiéndose variar la fecha de inicio estimada.
    • Si está en estado PDTE. COMENZAR RESOLUCIÓN àNo hay cambio de estado pero se puede variar la fecha de inicio estimada.

• • Si el cambio es de PLU a PL:
    • Si está en estado PDTE. CALENDARIZAR à pasa a estado PLANIFICABLE.
    • Si está en estado PDTE. COMENZAR RESOLUCIÓN à pasa a estado PLANIFICABLE

PL de modificación/configuración de software base (PL sistemas)

Roles 

El Responsable de sistemas podrá ejecutar las mismas acciones que cualquier usuario que tenga rol JP sistemas.

Requisitos para el ciclo de vida de la PL sistemas

• La gestión de cambios debe siempre hacerse en una plataforma.
• Es necesario relacionar la PL con la RFP  de la plataforma sobre la que se hace el lanzamiento.
• El peticionario debe indicar el o los entornos, la o las plataformas y los grupos lógicos, así como pedir si quiere ejecuciones para todos lod grupos lógicos o por cada uno de los grupos lógicos solicitadas.

En el siguiente enlace puedes consultar el manual de JIRA, donde se ha modelado este proceso.

Para que el solicitante pueda crear y seguir un flujo de PL de sistemas, es necesario que:

• Exista en JIRA una RFP en la que se haya construido o modificado significativamente la plataforma.
  
  

El solicitante, crea el tipo de entidad "PL sistemas " sobre el proyecto de tipo plataforma correspondiente.

Debe informar obligatoriamente:

• Tipo PL:
  • Normal. En este caso, podrá informar opcionalmente de la capacidad solicitada. 
  • Preaprobada
• ID RFP relacionada. Es la versión sobre la que se está solicitando una implantación. La versión debe estar en estado "EN RESOLUCIÓN".
• Agrupación de plataformas
• Plataforma o plataformas en la que se quiere hacer la implantación. 
• Entorno o entornos en los que se quiere hacer la implantación.
• Grupo o grupos lógicos en los que se quiere hacer la implantación. En el caso de que sean de tipo normal. será necesario saber si el peticionario quiere una implantación para todos los grupos lógicos seleccionados o una por cada uno de ellos.
• Restricción horaria.
• Si hay o no corte de servicio.
• Aportar el documento PID como adjunto.
  
  

Tras estos pasos, la PL se habrá creado y pasará a un estado en el que el proveedor de sistemas (CTI) deberá revisar la documentación aportada. 

Al igual que para la PL de incremeto versión, este proceso se modela con dos tipos de entidades:

• PL:  es la contenedora del alcance de la PL, sobre la que revisará la documentación (PID), y se generarán implantaciones que no se hayan solicitad en la creación.
• PL hija: una subtarea de la PL por cada  instalación en una Plataforma, entorno, grupo lógico o conjunto de grupos lógicos. Estas subtareas se crean de manera automática al crear la PL, aunque no pueden ser ejecutadas hasta que no se haya aprobado la documentación.
  
  

Estado PDTE. REVISIÓN 

El proveedor de sistemas revisa el PID. En cuanto lo revisa, se pasa al estado EN RESOLUCIÓN y pasan a poder ejecutarse las PLs hijas creadas de manera automática con la creación de la PL.

Estado EN RESOLUCIÓN

En este estado es posible generar PLs hijas que no correspondan a las creadas con los datos solicitados en la creación de la PL. Es posible generar hijas con la misma tripleta que ya se hubiera solicitado anteriormente.

Si todas las Pls hijas están cerradas y no es necesario generar ninguna más, el peticionario puede finalizar la PL.

Hay tres posibles resoluciones para cerrar la

Estado EN RESOLUCIÓN

Estado asignado al informador y que indica al solicitante que ya existen PL hijas. Al igual que en el estado anterior, el peticionario puede solicitar PLs hijas tantas veces como desee (tanto normales como PLU), y el Grupo Planificador podrá generar las PLs hijas.

Una vez que el Responsable de Producto considera que ya no debe haber más implantaciones, podrá finalizar la PL para lo cual es imprescindible que todas las PLs hijas estén cerradas. Ahora bien, dependiendo de cómo se hayan cerrado las hijas se cerrará la padre. Estos cierres se controlan con el campo Resolución que aparece debajo del estado.

Hay tres posibles resoluciones para una PL cerrada en una versión:

• Resuelta si todas las PLs hijas están resueltas.
• Parcialmente resuelta si alguna PL hija está resuelta y alguna cancelada.
• Cancelada si todas las PLs hijas están canceladas.

PL HIJA

Estado PLANIFICABLE

Al generarse la PL hija está en estado PLANIFICABLE si se ha solicitado una PL hija no urgente.

El Grupo Planificador solicita planificación a CTI indicándole una fecha en base a la restricción horaria del peticionario.

Estado PDTE. CALENDARIZAR

CTI recibe la solicitud de planificación del Grupo de Lanzamientos y propone una fecha de inicio estimada y una fecha fin estimada.

Estado CALENDARIZADA

El Grupo Planificador  debe aprobar o no aprobar las fechas que propone.  En caso de no estar conforme con las fechas.  

Estado PDTE. COMENZAR RESOLUCIÓN

Una vez la fecha está aprobada, la PL hija quedará pendiente de iniciar la resolución.

En este estado, el proveedor sistemas podrá cambiar tanto la fecha de inicio estimada como los grupos lógicos.

Hasta este estado, el peticionario podrá cambiar la urgencia de la PL.

Estado EN RESOLUCIÓN

El proveedor de sistemas comienza la resolución, realizando las actividades programadas en la documentación.

Al finalizar la resolución debe informar si se han producido errores y los comentarios que considere necesario.

Estado PDTE. REVISIÓN TÉCNICA

El peticionario debe revisar la ejecución y aceptar o no aceptar la solución técnica.

• Si acepta la solución técnica, la PL hija pasa a Estado CERRADA con resolución resuelta. Al cerrase la PL hija, se producirá el cambio de versión en CMS en la tripleta (plataforma-entorno-grupo lógico) correspondiente.
• Si no acepta solución técnica se pregunta al solicitante si quiere, reinstalación con o sin marcha atrás, si quiere desinstalar o si no quiere hacer nada.
  • Si se requiere reinstalación o desinstalación la PL hija pasará a estado PDTE. CALENDARIZAR y de ahí a PDTE. COMENZAR RESOLUCIÓN, es decir, no hay intervención del grupo de lanzamientos.
  • Si no se requiere ni reinstalación ni desinstalación, la PL hija se cerrará y cerrará automáticamente todas las PL hijas de la PL (PL hijas 'hermanas') y la resolución de todas ellas será "No se hará"

...

Al finalizar cada ejecución se graba en una tabla visible los siguientes datos:

• Tipo de actividad: Instalación, Reinstalación, Marcha atrás, Desinstalación.
• Entorno: Entorno en el que se ha ejecutado la PL hija.
• Fecha inicio: Fecha inicio real de la ejecución de la PL hija.
• Fecha fin: Fecha fin real de la ejecución de la PL Hija.
• Complejidad: Complejidad de la PL hija. Por defecto siempre es NO.
• Facturable: por defecto Facturable es Instalación y Desinstalación.
• PLU: Informa si la ejecución ha sido solicitada como Urgente.
• HBS: Valor de cada ejecución en función de los parámetros establecidos Prioridad (PLU), Complejidad, Horario.

El proveedor de sistemas dispondrá durante todos los estados de la PL Hija y hasta 10 días después de finalizar el mes, la acción Solicitar Revisión.  Con esta acción podrá solicitar al Grupo Planificador que se revisen los parámetros de Complejidad y/o facturación.  

El Grupo Planificador dispondrá de una acción para actualizar la tabla de ejecuciones si el proveedor sistemas así se lo ha solicitado. Los cambios quedarán registrados en el histórico de cambios.

Una vez que no sea necesario generar más PLs hijas, el peticionario puede manualmente finalizar la PL. La condición para poder finalizar una PL es que todas las PLs Hijas estén cerradas.

Existe la posibilidad de cancelar una PL por parte del peticionario siempre que las PLs hIjas se hayan cancelado (podrá hacerse siempre que no hayan llegado al estado En resolución).

Hay tres posibles resoluciones a la hora de cerrar la  PL:

• Resuelta si todas las PLs hijas están resueltas.
• Parcialmente resuelta si alguna PL hija está resuelta y alguna cancelada.
• Cancelada si todas las PLs hijas están canceladas.

El Responsable Producto dispone de una acción, finalizar implantaciones, para que la versión cambie de estado y pase a Implantada, lo que supondrá que las mejoras e incidencias contenidas en la versión pasen a estado Cerrada. Una vez en este estado, el Responsable Producto podrá finalizar la versión, pasando de Implantada a Cerrada.

En la siguiente tabla se describen los posibles estados de la versión y su flujo en función de las PLs;

...

...

...

...

...

...

...

...

Si sólo hay SVEs→deben estar cerradas

Si hay PLs →deben estar cerradas con resolución Cancelada

...

• PLs hijas están canceladas.

PL hija

Las PLs hijas se crean de dos formas:

• De forma automática cuando se solicita la PL
• Mediante la acción de generar PLs hijas cuando en la PL se haya revisado la documentación.

El ciclo de vida de las PLs hijas va a depender del tipo de la PL:

• Si la PL es de tipo preaprobada, las PLs hijas son planificadas por CTI y se ejecutan directamente, sin necesidad de aprobación por parte del Grupo Planificador.
• Si la PL es de tipo normal, las PLs hijas son planificadas por CTI, y esa planificación debe ser aprobada por el Grupo Planificador. Cuando las fechas hayan sido aprobadas, las PLs hijas podrán ejecutarse directamente.

En cualquier caso, cuando se ejecuta la PL hija NO hay revisión de la ejecución, pasando directamente al estado CERRADA.

Los esttados por los que pasa la PL hija por tanto son:

Estado PDTE. CALENDARIZAR

CTI  propone una fecha de inicio estimada y una fecha fin estimada.

Estado CALENDARIZADA

El Grupo Planificador  debe aprobar o no aprobar las fechas que propone.  En caso de no estar conforme con las fechas, CTI deberá volver a planificar.

Estado PDTE. COMENZAR RESOLUCIÓN

Una vez la fecha está aprobada, la PL hija quedará pendiente de iniciar la resolución.

En este estado, el proveedor sistemas podrá cambiar tanto la fecha de inicio estimada como los grupos lógicos.

Estado EN RESOLUCIÓN

El proveedor de sistemas comienza la resolución, realizando las actividades programadas en la documentación.

Al finalizar la resolución debe informar si se han producido errores y los comentarios que considere necesario.

...

...