Objetivo

Controlar el diseño y la construcción de nuevas plataformas, así como posibles modificaciones en las existentes.

El objetivo de este proceso es gestionar las solicitudes de lanzamiento, RFPs. Este tipo de solicitudes está destinado a la creación de las Plataformas tecnológicas necesarias para el despliegue de los diferentes aplicativos incluidos dentro del Catálogo de aplicaciones.

Alcance RFP

Un petición de plataforma (RFP - Request For Platform) se desencadena para realizar una modificación sustancial de plataforma:

• Desplegar nuevas máquinas físicas o virtuales.
• Crear nuevas bases de datos.
• Reinstalar completamente sistemas operativos.

Cualquier otro cambio ejecutado sobre una plataforma se considerará cambio menor y se gestionará mediante peticiones de lanzamiento (PL).

Prerrequisito

Los mecanismos por los que se determina que es necesario crear una nueva RFP son:

• RFP de negocio: reunión de Kick-off.
• RFP de sistemas: CAB de sistemas.

Las RFPs se gestionan en JIRA y es necesario que el proyecto plataforma esté dado de alta en la herramienta.

Si la plataforma no existe, es necesario como paso previo a crear la RFP en JIRA que se dé de alta en CMS la nueva plataforma. Esta acción la pueden realizar los responsables de Sistemas que tienen perfil STIC SISTEMAS.

Procedimiento

Roles

Diagramas de Flujo

Figura 1. Diagrama flujo RFP

Figura 2. Diagrama flujo RFP Hija

Tabla de estados y acciones

En el siguiente enlace al manual JIRA se detalla los estados, acciones y roles que pueden actuar en cada punto del flujo

Descripción del flujo

Crear RFP

El solicitante realiza logon en JIRA y crea una nueva entidad RFP sobre el proyecto Plataforma necesario.

Debe informar obligatoriamente:

• Entornos sobre los que se necesita la RFP
• Aportar el documento DGT 

Aprobar RFP

El coordinador aprueba la RFP y determina en primera instancia si es de tipo Simple, Normal o Compleja, y fecha fin estimada.

Revisar documentación

El resolutor revisa el DGT. Pudiendo:

• Solicitar información al solicitante si tiene dudas.
• No aceptar la documentación, teniendo que aportar el solicitante un nuevo DGT.
• Comenzar si la documentación está revisada y correcta. En esta transición debe informar:
  • El tipo: Simple, normal o Compleja
  • Los entornos necesarios
  • Y fecha fin estimada.

Tras esta transición se crean automáticamente las RFP hijas siendo:

Si es de tipo Simple o Normal:

• N RFP Hija de Diseño y Construcción [Entorno]
• 1 RFP Hija de Transferencia

Si es de tipo Compleja:

• N RFP Hija de Diseño [Entorno]
• N RFP Hija de Construcción [Entorno]
• 1 RFP Hija de Transferencia

A partir de esta transición se sigue operando sobre las RFPs Hijas

Si es compleja

Pdte. Estimar

El proveedor debe estimar, tanto esfuerzo, adjuntando el EDT, como las fechas de cada una de las RFPs Hijas.

Estimada

El Responsable de sistemas podrá Aprobar la estimación. En caso de que no la Apruebe, el proveedor sistemas deberá de nuevo estimar la RFP Hija.

Pdte. Solicitar nueva estimación

Si la estimación caduca, es decir, transcurre más de 7 días desde que el proveedor sistemas ha estimado, la RFP Hija hace una transición automática a Pdte. Solicitar nueva estimación, un estado de nuevo asignado al Proveedor sistemas que es equivalente a Pdte. Estimar.

Si es simple o normal

Calendarizar

El proveedor debe informar de las HBS estimadas de cada una de las RFP Hija de acuerdo con los valores de catálogo, adjuntar el EDT, así como indicar sus fechas fin estimadas.

Pdte. Comenzar resolución

La RFP Hija estará en dicho estado asignado al proveedor hasta que éste decida comenzar su resolución.

En resolución

El proveedor está trabajando en la RFP Hija, pudiendo incurrir, informar del avance, comentar, etiquetar, etc. en cualquier momento. Al terminar cada RFP Hija el proveedor deberá Resolver.

Hay que tener en cuenta que no se puede comenzar la RFP Hija de Transferencia hasta que las RFP de Diseño y Construcción, en el caso de las simples y normales o de la RFP de Construcción, en caso de las complejas, de todos los entornos finalicen.

Pdte. Revisión técnica

Una vez se resuelve, el solicitante debe aceptar o no la construcción del entorno.

El solicitante sólo debe revisar aquéllas RFP Hija que tengan construcción.

En caso de que no sea aceptada, el proveedor de sistemas debe de nuevo revisar la construcción del entorno.

Pdte. Revisión

Tras la aceptación del solicitante, el Responsable de sistemas debe aceptar o no la RFP Hija. Por este estado pasa todas las RFPs hijas.

En caso de que no sea aceptada, el responsable de sistemas debe el proveedor de sistemas debe de nuevo revisar la construcción del entorno.

No aceptada

Es un estado equivalente al En resolución, donde el proveedor debe trabajar en la resolución de la RFP Hija. Lo que indica es que ha sido no aceptada la resolución previa.

Finalización RFP

Una vez se han completado todas las RFP Hijas, con una acción automática, la RFP finaliza (estado Cerrada, resolución Resuelta)

Subflujo de cancelación

La RFP puede ser Cancelada por el Responsable de Sistemas o Coordinador en cualquier momento.

Si la RFP está en estados previos a En resolución, es decir, aún no se han creado las RFP Hijas, se podrá cancelar sin ninguna acción adicional.

Si la RFP está En resolución, habrá que ir cancelando cada una de las RFP Hijas, pasando estas por los estados

Pdte. Cancelación

El proveedor sistemas debe registrar las HBS y Liquidar.

Pdte. Revisión cancelación

El Responsable de Sistemas deberá aceptar la liquidación y si no está conforme vuelve a Pdte. Cancelación para que el proveedor sistemas corrija.

Al cancelarse todas, la RFP también se cancelará.

Subflujo de paralización

El coordinador podrá paralizar y reanudar cualquier RFP Hija en cualquier momento. Una vez estime que se puede volver a trabajar en ella, la podrá reanudar.