El flujo se modela en JIRA (https://ws001.sspa.juntadeandalucia.es/jira/).

La RFP se creará como una nueva entidad de JIRA dentro de un proyecto de tipo plataforma para creación de una plataforma o para modificación de una existente.

La plataforma debe estar dada de alta en CMS y se habrá creado el proyecto correspondiente en JIRA.

Los atributos que vienen en ese tipo de proyectos como propiedades del mismo son:

Creación

Nueva entidad que se crea por parte de   o en estado  asignada a  (podrá hacer todas sus acciones cualquier usuario con rol )

Título*

Descripción*

Entornos*: permite selección múltiple

• PRE
• PRO
• FOR
• VAL

Adjunto*: debe adjuntarse el DGT

Aparece un mensaje de advertencia para indicar que es necesario adjuntar el DGT de forma obligatoria: "Debes adjuntar el DGT".

Acciones en estado 

Asignada a 

ACCIÓN	QUIÉN PUEDE	CAMBIO DE ESTADO	CAMBIO RESOLUCIÓN
APROBAR		a	N/A
NO APROBAR (Incluir motivo en comentario obligatorio)		a	(Sin Resolver) a (No se hará)
CANCELAR Incluir comentario obligatorio		a	(Sin Resolver) a (Cancelada)

En esa misma pantalla, aparecerán el campo  "Fecha fin estimada" para ser informado opcionalmente. Este campo debe ser editable en cualquier estado para el rol 

Aparece también el campo Entornos con el valor que hubiera elegido el solicitante.

Igualmente de manera opcional puede informarse el tipo de RFP y el miembro asignado. Tanto el proveedor como el JP pueden gestionar los integrantes del equipo del proveedor que van a ser responsables de la plataforma. Ese campo va a ser en cualquier momento editable por esos mismos roles.

TIPO RFP:

Simple

Normal

Compleja

Acciones en estado 

Asignada a 

Informar obligatoriamente el tipo de RFP y la fecha fin estimada  si no estuvieran informados. Aparecerá cargados por defecto los que se hubieran podido informar al aprobar.

TIPO RFP:

Simple

Normal

Compleja

Acciones en estado 

Asignada a  o , es decir, solicitante de la RFP

Acciones en estado 

Asignada a  o , es decir, solicitante de la RFP.

 Aparece un mensaje de advertencia para indicar que es necesario adjuntar el DGT de forma obligatoria: "Debes adjuntar un nuevo DGT".

Acciones en estado 

Asignada a 

(*)La condición para que se pueda acceder a la acción es que no exista ninguna fase en estado distinto a 

Si ocurriera ese caso, aparece un mensaje en el que se indica que será necesario previamente cancelar las fases que no estén cerradas.

Creación automática de las fases en función del tipo de RFP en estado 

Tipo RFP normal o simple

Se crearán automáticamente las fases Diseño y Construcción por cada entorno y una fase de Transferencia, todas en estado  que serán subtareas de la entidad padre.

• Diseño y Construcción PRE
• Diseño y Construcción PRO
• Diseño y Construcción FOR
• Diseño y Construcción VAL
• Transferencia

Las fases pueden calendarizarse por el  en cualquier momento. Se establece restricción para acceder a la acción COMENZAR RESOLUCIÓN en la de Transferencia. No debe salir disponible esa opción hasta que las fases anteriores estén en estado 

Acciones en estado 

Asignada a 

Es obligatorio adjuntar el fichero de estimación .

Aparece un mensaje de advertencia para indicar que es necesario adjuntar el fichero de estimación de forma obligatoria: "Debes adjuntar fichero de estimación".

Acciones en estado 

Asignada a 

Acciones en estado 

Asignada a 

 En el momento en el que hay HBS incurridas, se calcula el campo %Desviación HBS

En el momento en el que se cambia la Fecha fin actualizada, se calcula el campo %Desviación fecha

 Aparece el resumen con la misma pantalla que las OTs

Los dos grados de avance se ponen automáticamente a 100%.

Es obligatorio adjuntar el fichero de incurridos como en las OTs

Quitar la obligatoriedad del campo Ubicación de entregables de salida.

Incluir un mensaje de advertencia para indicar que es necesario adjuntar el fichero de incurridos de forma obligatoria

"Debes adjuntar fichero de incurridos de forma obligatoria"

Acciones en estado 

Asignada a  o , es decir, el solicitante

Acciones en estado 

Asignada a 

 La pantalla que debe salir es igual a la que aparece al aceptar una OT por el 

Deben mostrarse las desviaciones en HBS y fechas y que exista la posibilidad de justificar o no el desvío. En caso de que se justifique, es necesario que se indique de manera obligatoria el motivo.

En el caso de que la desviación de fechas sea negativa, no pedir la justificación del desvío.

 Debe indicarse el motivo en el Mensaje de rechazo RFP HIJA con los mismos motivos que en las OTs en el caso en que la RFP HIJA sea de Transferencia

Acciones en estado 

Asignada a 

Acciones en estado 

Asignada a 

Acciones en estado 

Asignada a 

ACCIÓN	QUIÉN PUEDE	CAMBIO DE ESTADO	CAMBIO RESOLUCIÓN
IMPUTAR CAUSANTES RECHAZOS SOLICITANTE		N/A	N/A
REGISTRAR HBS		N/A	N/A
SEGUIMIENTO Al acceder a esta acción será posible informar de la nueva "Fecha fin actualizada"		N/A
RESOLVER		a si el flujo viene de revisión técnica ("No aceptar solución técnica"). En este caso debe informarse un campo de fecha (Fecha nueva resolución) que no se muestre y que sirva para poner en marcha el contador de tiempo a si el flujo viene de una revisión no técnica ("No aceptar costes"). En este caso, no se informa el campo fecha anterior, con lo que no se activará el contador de tiempo	N/A N/A

Tipo RFP compleja

Se crearán automáticamente las fases Diseño y las fases Construcción por cada entorno y una fase Transferencia, todas en estado  que serán subtareas de la entidad padre.

• Diseño PRE
• Construcción PRE
• Diseño PRO
• Construcción PRO
• Transferencia

Podrán estimarse todas de manera independiente y esa estimación deberá ser aprobada, aunque al aprobar la estimación, sólo se podrá comenzar la resolución en las que sean de diseño tanto de los entornos en PRE y PRO. Seguirán el flujo con la revisión sólo del Responsable de Sistemas (no del JP STIC Solicitante) y hay que establecer la lógica para que las tareas de Construcción de los entornos no comiencen (no pueda accederse a  la acción “COMENZAR RESOLUCIÓN”) hasta que no esté cerrada la correspondiente de su entorno.

Las de Construcción seguirán el mismo flujo que las de Diseño y Construcción de las RFP simples, es decir, pasan al estar resueltas a ser revisadas por el JP STIC Solicitante, quien debe aceptar o no la solución técnica y debe informarse el motivo que ocasiona la no aceptación. Una vez aceptada la solución técnica, debe pasar la revisión del Responsable de Sistemas para aceptar o no costes.

Hasta que las tareas de diseño y construcción de los entornos solicitados no estén Cerradas, no puede activarse la acción "COMENZAR RESOLUCIÓN" en la subtarea de Transición, cuyo flujo será el mismo del de las RFP simples, es decir, no necesita revisión del JP STIC Solicitante.

Acciones en estado 

Asignada a 

 Se aplican restricciones a las fechas: 

Fechas iguales o posteriores a fecha actual

Fecha de caducidad anterior a la fecha de inicio estimada

Acciones en estado 

Asignada a 

Acciones en estado 

Asignada a 

Acciones en estado 

Asignada a 

Acciones en estado 

Acciones en estado 

Asignada a 

 La pantalla que debe salir es igual a la que aparece al aceptar una OT por el 

Deben mostrarse las desviaciones en HBS y fechas y que exista la posibilidad de justificar o no el desvío. En caso de que se justifique, es necesario que se indique de manera obligatoria el motivo.

En el caso de que la desviación de fechas sea negativa, no pedir la justificación del desvío.

 Debe indicarse el motivo en el Mensaje de rechazo RFP HIJA con los mismos motivos que en las OTs en el caso en que la RFP HIJA sea de Transferencia

Acciones en estado 

Asignada a 

Acciones en estado 

Asignada a 

Acciones en estado 

Asignada a 

Enlaces relacionados

Puede consultar el proceso para la Gestión de Plataformas pulsando aquí.

Documentación Time to SLA: https://confluence.snapbytes.com/display/TTS/Time+to+SL