Proceso: Gestión de Plataformas
Objetivo
El objetivo de este proceso es gestionar las solicitudes de plataformas, 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
Son solicitudes de servicios de transición para proyectos de ingeniería, trabajos de evolución, mejora y/o implantación de infraestructuras hardware y/o software, que llegarán al adjudicatario en forma de peticiones de plataforma (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. El procedimiento a seguir en estas reuniones es el siguiente.
- RFP de sistemas: reunión del comité de cambios (Change Advisory Board (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
| Rol | Descripción |
|---|---|
| Informador | Rol solicitante de la RFP |
| Coordinador | Rol que aprueba la RFP y controla y supervisa todo el proceso de la RFP |
| Responsable sistemas | Rol responsable de la plataforma sobre la que se solicita una RFP. Responsable de la ejecución concreta de las RFPs de sus plataformas. |
| Resolutor | Rol que ejecuta y resuelve la RFP. Es el proveedor de sistemas (CTI) |
Diagrama de Flujo
Loading...
draw.io
Diagrama de Estados
Loading...
draw.io
Tabla de estados y acciones
En el siguiente enlace al manual JIRA se detallan los estados, acciones y roles que pueden actuar en cada punto del flujo.
Descripción del flujo
Crear RFP
El solicitante realiza login 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 que puede encontrar en la sección de plantillas del espacio del área de servicios al usuario y gestión TIC.
Aprobar RFP
El coordinador aprueba la RFP y determina en primera instancia si es de tipo Simple, Normal o Compleja, y la 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 RFPs 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 del tiempo indicado por el proveedor de sistemas para que se apruebe la estimación que ha hecho, la RFP Hija hace una transición automática a Pdte. Solicitar nueva estimación, un estado asignado al Responsable de sistemas, que debe solicitar una nueva estimación para pasar de nuevamente la asignación al proveedor en 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.
A partir de este momento el flujo es exactamente igual para las RFPs Hijas tanto si son simples, normales o complejas.
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. El Responsable de Sistemas decidirá si la causa del rechazo es imputable o no al proveedor de sistemas.
A los siete días de estar en estado, se producirá una validación automática y la RFP Hija pasará al siguiente estado.
Pdte. Revisión
Tras la aceptación del solicitante, el Responsable de sistemas debe aceptar o no la RFP Hija. Por este estado pasan todas las RFPs hijas.
En caso de que no sea aceptada, 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.
Puedes acceder a la presentación de la formación impartida para la incorporación del proceso a JIRA:
.
Ayuda relacionada:
- Enlace
- Enlace
Vista general
Herramientas de contenido
- Impreso por Atlassian Confluence 8.7.2