Partimos de una solicitud que necesita ser resuelta por el proveedor. Al acceder a "Resolver" aparecen las siguientes opciones:

Si elegimos la opción NO INCREMENTA VERSIÓN (SÓLO RQUIERE PERTICIÓN DE LANZAMIENTO DE DATOS) aparecerá la opción de incluir esa solicitud en una de las PLs de datos para ese aplicativo ya creadas en JIRA. Puede ocurrir que no hubiera creada ninguna con lo que esa operación se haría posteriormente en JIRA.

Con esta acción, la solicitud en NWT queda en estado PDTE. IMPLANTAR y se creará en JIRA un registro de tipo SOLICITUD DE DATOS en estado:

• PDTE. IMPLANTAR → Si se ha incluido en una PL ya creada al resolver en NWT
• BACKLOG → Si no se ha incluido en una PL al resolver en NWT

Creación de la PL de datos

La PL de datos es un tipo de registro que puede ser creado en JIRA tanto por el Proveedor como por el Responsable de producto. Necesita para su creación información obligartoria como la plataforma y entorno/s, además de información sobre si es necesario corte de servicio, si necesita soporte y el teléfono del proveedor.

Hay además una información importante:

• Tipo PL: El creador de la PL puede elegir dos 
  • Normal:
    • Sin ventana horaria
    • Con ventana horaria
  • Preaprobada
    • Sin ventana horaria
    • Con ventana horaria
• PLU:
  • Sí
  • No

Veamos las diferencias del proceso según el tipo de PL y si es o no PLU

PLs normales sin ventana horaria

La PL se crea pero debe ser aprobada por el Responsable de producto, con lo que para su creación debe asociársele al menos una solicitud de datos. El Responsable de producto puede:

• Aprobar la PL:  Pasaría a estado ABIERTA y no podrían asociárseles más solicitudes de datos.
• No aprobar la PL, con lo que se cancelaría la PL, se cancelaría la solicitud y en NWT pasaría a estado ABIERTA.

PLs normales con ventana horaria

El proceso de creación es el mismo y variaría sólo la forma de gestionar las PLs hijas, ya que no requieren planificación por parte del Grupo de Lanzamientos puesto que CTI sabe la ventana horaria en las que las tiene que ejecutar.

PLs preaprobadas sin ventana horaria

La PL se crea en estado ABIERTA.

PLs preaprobadas con ventana horaria

Se quedan igualmente en estado ABIERTA y variaría sólo la forma de gestionar las PLs hijas, ya que no requieren planificación por parte del Grupo de Lanzamientos puesto que CTI sabe la ventana horaria en las que las tiene que ejecutar.

PLUs

Se crean también en estado ABIERTA y avanzan al estado EN RESOLUCIÓN una vez que se tenga listo el PID. Las PLs Hijas pueden ser o no urgentes, hay que indicarlo cuando se soliciten. La urgencia de la padre implica que el PID tiene que ser revisado en menos tiempo.

PL en estado ABIERTA

En este estado el Proveedor o Responsable de producto pueden:

• Incluir en ella otras solicitudes de datos, tanto directamente en JIRA como desde la resolución de la solicitud en NWT.
• Se habrá creado la página de CONFLUENCE donde debe completarse el PID.
• Se creará la SVD para que la OCA haga su revisión y será ahí donde se adjuntarán los ficheros de datos. Una vez que se adjunten se asignará directamente a la OCA para que verifique que realmente son ficheros de datos y no modifican la línea base del producto.

Una vez que el PID esté listo y la SVD cerrada y aceptada por la OCA podrá continuarse el proceso. En este caso, la página del PID quedará bloqueada y la PL pasará al estado EN RESOLUCIÓN.

Si la SVD no es aceptada por la OCA deberá indicar el o los motivos por los que no acepta:

• Si uno de los motivos es Modificación de LB, la PL se cancelará directamente, se cerrarán las solicitudes de datos y en NWT las solicitudes pasarán a estado ABIERTA.
• Si el motivo es Incumplimiento CNO, se creará otra SVD para que se adjunten los nuevos ficheros y la OCA deberá volver a revisar.

Como ya henos dicho, en el caso de PLU no es necesario que la SVD esté cerrada para que la PL avance de estado.

PL en estado EN RESOLUCIÓN

En este estado podrán solicitarse las PLs hijas, indicando si son o no urgentes.

Las hijas se planificarán y ejecutarán y tras su resolución, el Proveedor o Responsable de Producto determinarán si esa resolución es correcta o si es necesario pedir una reinstalación, marcha atrás o desinstalación.

Una vez que se cierren las hijas es necesario finalizar la padre. Hay dos opciones:

• Que con la resolución de la PL se resuelvan totalmente las solicitudes:
  • Si se resuelven totalmente TODAS las solicitudes incluidas en la PL, ésta se finaliza, las solitudes de datos se cierran y en NWT las solicitudes pasan a estado PDTE.CONFIRMACIÓN CIERRE.
  • Si hay algunas que no se resuelven normalmente van a requerir que se ejecute otra PL, con lo que se sacan de la PL que se va a finalizar y se quedan disponibles para incluirlas en PLs posteriores.
• Que con la resolución de la PL no se resuelvan totalmente las solicitudes:
  • Se pueden sacar todas de la PL quedando disponibles para PLs posteriores
  • Se indica que no se han resuelto con lo que se cierra la PL, las solicitudes de datos y en NWT las solicitudes pasan a estado ABIERTA.

RESOLUCIÓN DE SOLICITUDES MEDIANTE EL ORQUESTADOR

En estos casos hay dos opciones:

• Ejecutar el cambio y poner la solicitud como resuelta.
• Planificarla para no computar en ANS y una vez ejecutado el cambio resolverla