Versiones comparadas

Clave

  • Se ha añadido esta línea.
  • Se ha eliminado esta línea.
  • El formato se ha cambiado.

...

    • Si el cambio es de PLU a PL:
      • Si está en estado PDTE. CALENDARIZAR à pasa a estado PLANIFICABLE.
      • Si está en estado PDTE. COMENZAR RESOLUCIÓN pasa a estado PLANIFICABLE


PL

...

Roles

...

Rol

...

Descripción

...

Rol solicitante de la PL.

Es siempre el usuario de integración WT-JIRA

...

Rol responsable de la aplicación sobre la que se solicita una PL.

...

Responsable funcional (***)

...

Son implantaciones necesarias para resolver una solicitud pero que no modifican la línea base del producto. Cuando un proveedor está resolviendo una incidencia o petición puede necesitar hacer una implantación normalmente de scripts de datos. Al resolver la solicitud se crean por integración en JIRA dos objetos:

  • La PL de datos. Se crea con el título "PL para solicitud 999999".
  • El Servicio de verificación de datos (SVD) para que la Oficina de Calidad haga la revisión de los scripts que deben implantarse para asegurar que en ningún momento suponen un incremento de versión del producto.

La solicitud quedará en estado PDTE. IMPLANTAR.

El primer paso es aportar en la PL la información necesaria para poder avanzar. Hay que tener en cuenta que las solicitudes origen de las PL de datos se crean en un CI de tipo aplicación, con lo que la PL se crea en JIRA en el proyecto correspondiente a esa aplicación. Pero hay datos que son imprescindibles para la implantación y que deben ser aportados por el Responsable de producto/Proveedor, como son la plataforma y el entorno. Además habrá qe indicar si la PL es normal o si es urgente y si es preaprobada o no, es decir, si tiene ya concertada con Sistemas una ventana horaria para su implantación.

Una vez informados todos esos datos, será necesario:

  • Asignar la SVD a la OCA adjuntando los archivos a implantar para que efectúe la revisión necesaria, ya que hasta que la SVD no esté cerrada no podrá avanzar la PL, a menos que se trate de una PLU en cuyo caso no podrá cerrarse la PL sin que se haya cerrado la SVD.
  • Hacer el PID en la página de CONFLUENCE enlazada con la PL. Se enlazan dos páginas con el registro de la PL:
    • Una página para la PL que se encuentra en la sección PLs de negocio de la plataforma correspondiente.
    • La página del PID que se encuentra dentro de la página de la PL.

Una vez completado el PID y siempre que la SVD esté cerrada, se podrá comenzar con la PL, lo que supondrá que se asigne al Proveedor de sistemas de la plataforma para que revise el PID.

A partir de este momento, el flujo de la PL de datos es similar al de la PL versión con la diferencia de que las hijas no tienen que ser generadas por el Grupo Planificador, sino que se crean solas porque no es necesario informar los grupos lógicos. Lo único a destacar es que si se ha elegido la opción de PREAPROBADA, las hijas no se crearán en estado PLANIFICABLE sino en estado PDTE. CALENDARIZAR por el Proveedor de sistemas de la plataforma.

Otra diferencia respecto a las PLs de versión es que al aceptar la solución técnica por parte del Responsable de producto/Proveedor, es que no hay ninguna actualización de CMS.

El cambio a PLU se gestiona como en las PLs de versión. Si una PL se convierte en PLU podrá ejecutarse sin que tenga que estar cerrada la SVD, que deberá cerrarse a posteriori.

...

de datos

PL de modificación/configuración de software base (PL sistemas)

Roles 

Rol

Descripción

Peticionario

Rol solicitante de la PL, en este caso el proveedor de sistemas (CTI)

Responsable sistemasRol responsable de la plataforma en la que se hace la modificación o el cambio de configuración
Grupo planificadorRol responsable de la correcta gestión y planificación por parte del resolutor
ResolutorRol que ejecuta y resuelve la PL. Es el proveedor de sistemas (CTI)

...