Versiones comparadas

Versión anterior 36

changes.mady.by.user JOSE MIGUEL LOZANO

Guardado el

comparado con

Nueva versión Actual

changes.mady.by.user LUCIA ACOSTA CABANILLAS

Guardado el

Clave

  • Se ha añadido esta línea.
  • Se ha eliminado esta línea.
  • El formato se ha cambiado.
Extracto
Divbox
classestiloindice
Expandir
titleÍndice

Tabla de contenidos

outlinetrue
absoluteUrltrue
excludeAyuda relacionada:.*

Divbox
classdivcontenedor
Divbox
stylewidth: 92%; text-align: left;
classdivcontenido

Image Added Proceso: 
Titulo pagina


Objetivo

Objetivo

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

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
  • el siguiente.
  • RFP de sistemas: reunión del comité de cambios (Change Advisory Board (CAB) de sistemas).

Las RFPs se gestionan

en

en JIRA

y

 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

en CMS

la

 la nueva plataforma. Esta acción la pueden realizar los responsables de Sistemas que tienen perfil STIC SISTEMAS.

Procedimiento

Roles

RolDescripción
InformadorRol solicitante de la RFP
CoordinadorRol que aprueba la RFP y controla y supervisa todo el proceso de la RFP
Responsable sistemasRol responsable de la plataforma sobre la que se solicita una RFP. Responsable de la ejecución concreta de las RFPs de sus plataformas.
ResolutorRol que ejecuta y resuelve la RFP. Es el proveedor de sistemas (CTI)

Diagrama de Flujo

Lucidchart
lcId9174f587-e9f0-4d84-80bf-442c8ef521f1
rich-viewertrue
autoUpdatetrue
autofitfalse
nameDiagrama RFP - Skj91uFJclNW
width1793
convertedFromonprem
origParamseyJib3JkZXIiOiJ0cnVlIiwiIjoiIiwiYXV0b1VwZGF0ZSI6InRydWUiLCJzaXplIjoiNjAwIiwi c2ltcGxlVmlld2VyIjoidHJ1ZSIsImF0dGFjaG1lbnRJZCI6IjUwMDg0ODYzIiwidmVyc2lvbiI6 IjM3In0=
documentTokenv2_541e017b6002bb6d5bd5c22f6d77afc40fdf6e9480c143b496cbf8790470742d-a=171816341&c=d1873183-daff-4cd4-a0ef-3f5bcb960f8c&d=11dfc423-e697-4712-9606-212bc8ef7e52&p=
id11dfc423-e697-4712-9606-212bc8ef7e52
alignLeft
height882

draw.io Diagram
diagramNameDiagrama RFP (from Lucidchart).drawio
revision1


 Diagrama de Estados

Lucidchart
lcIdf5fb34db-089b-4559-87fa-162ecc70cfd2
rich-viewertrue
autoUpdatetrue
autofitfalse
nameEstados RFP - dqB6AuDWIYGH
width1094
convertedFromonprem
origParamseyIiOiIiLCJhdXRvVXBkYXRlIjoidHJ1ZSIsInNpemUiOiI2MDAiLCJzaW1wbGVWaWV3ZXIiOiJ0 cnVlIiwiYXR0YWNobWVudElkIjoiNTAwODQ5NDMiLCJ2ZXJzaW9uIjoiMjYifQ==
documentTokenv2_ad2c34637eb26ed0f12c4836b6fb18e3826ee14f24ada70d4febaf7551262591-a=171816341&c=d1873183-daff-4cd4-a0ef-3f5bcb960f8c&d=818a838a-9884-4835-a490-e9dc8408ff0c&p=
id818a838a-9884-4835-a490-e9dc8408ff0c
alignLeft
height712

draw.io Diagram
diagramNameEstados RFP (from Lucidchart).drawio
revision1


Tabla de estados y acciones

En el siguiente enlace al

manual

manual JIRA

se

 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
  • 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

 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á

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:

 

View file
nameFormación RFPs.pptx
height250
.





Ayuda relacionada:

  • Enlace
  • Enlace


Propiedades de página
hiddentrue
DescripciónControlar el diseño y la construcción de nuevas plataformas, así como posibles modificaciones en las existentes. (RFP en JIRA).
Categoría

Sistemas e infraestructuras

SubcategoríaPlataformas
Modificado

Modifieddate

Divbox
classir-arriba


HTML
<script>
/*------*/
/* JS para botón para Subir al inicio de la página (fixed esquina derecha abajo)*/
/*------*/
$(document).ready(function(){
	$('.ir-arriba').click(function(){
		$('body, html').animate({
			scrollTop: '0px'
		}, 300);
	});

	$(window).scroll(function(){
		if( $(this).scrollTop() > 0 ){
			$('.ir-arriba').slideDown(300);
		} else {
			$('.ir-arriba').slideUp(300);
		}
	});
});
</script>