Común a todas las entidades

  • Existen una serie de acciones comunes a todas las entidades:
    • COMENTAR
    • ADJUNTAR ARCHIVOS
    • ENLAZAR
    • ETIQUETAR

  • Los usuarios necesarios en un proyecto son:
    • Responsable de Área
    • Responsable de producto
    • Responsable funcional
    • Responsable de sistemas
    • Proveedor

Estos usuarios aunque aparezcan como asignados de las entidades pertenecen a roles definidos:

  • COORDINADOR→Puede hacer todo lo que hace el rol JP-STIC además de ciertas acciones específicas que se detallan
  • JP-STIC→ A este rol pertenecen los usuarios Responsable de producto y Responsable de sistemas.
Todos los usuarios con este rol pueden hacer las mismas acciones independientemente de la entidad y de la aplicación


  • FUNCIONAL→ A este rol pertenecen los usuarios Responsable funcional
  • COLABORADOR–>Este rol se usa para ususarios que sólo pueden hacer las acciones comunes pero ninguna acción específica.



¿Cómo puedes usar esta guía rápida?


  • Para cada una de los tipos de entidades de JIRA se detallan las acciones que pueden ejecutarse en cada uno de sus estados indicando:
    • Usuarios que pueden ejecutarla.
    • Si procede, cambio de estado de la entidad.
    • Si procede, cambio de resolución de la entidad.



Incidencia

Las incidencias que llegan a JIRA suponen fallos en el software que hay actualmente en Producción y que se registran desde MiCS (Mi Centro Servicio) o desde NWT (Nueva Web Técnica).  Pueden por tanto tener su origen en incidencias de usuarios finales o en la resolución de un problema que debe ser acometida por el Proveedor del producto.

En cualquier caso son resueltas por el Proveedor en NWT y sólo llegan a JIRA si su corrección implica implantación y modificación de la línea base del producto. Por tanto, llegan a JIRA corregidas y a la espera de ser implantadas en Producción en la versión que el Responsable de Producto o el Proveedor consideren oportunas. Se crean informando la fecha de registro en NWT, el usuario afectado, el código de solicitud y la prioridad.

Una vez que la versión se implante (cierre de la RFC en FARO), significará que las incidencias están en Producción y se cerrarán en JIRA, lo que supondrá que acabarán su ciclo de vida también en NWT, comunicando al usuario afectado la resolución del fallo detectado.


Si la prioridad de la incidencia es P1 y en NWT el Proveedor indica que se requiere Versión de Emergencia, se generará una entidad de este tipo en la que quedará automáticamente incluida la incidencia.


Si la incidencia llega a JIRA por error o con datos incorrectos, existe la posibilidad de escalarla a NWT.


Creación

    • Por integración. Se crean en estado  asignadas a  tanto si su origen es la gestión de problemas como si es la gestión de incidencias.


Acciones en estado 

ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

ESCALAR

 a 


(Sin resolver) a (Cancelada)
ASIGNAR A VERSIÓN

 a 

N/A
CLONAR (en cualquier aplicación)

N/AN/A


Acciones en estado 

ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

DESASIGNAR DE VERSIÓN

 a 


N/A
ASIGNAR OT

N/A

N/A
CLONAR (en versiones de la misma aplicación)

N/AN/A
VALIDAR

N/AN/A
EDITAR

N/AN/A
CIERRE RFC

 a 

(Sin resolver) a (Cerrada)
  •  

Mejora

Una mejora es cualquier petición de evolución de una aplicación. Puede ser registrada por cualquier usuario en MiCS (Mi Centro Servicios). Su origen puede ser esa petición de un usuario final o bien la respuesta a la solución de un problema que hace el Responsable de Producto. Pueden ser registradas directamente en JIRA por los usuarios logados en la herramienta.

La mejoras son analizadas por los Responsables Funcionales para determinar su viabilidad, y, si la tienen, establecer la urgencia con la que deben ser incluidas en una versión.

Cuando se aprueba una mejora por ser considerada viable, se informa al usuario que la registró cerrando la solicitud en el caso de registro en MiCS.

Una vez incluidas en una versión podrán asignarse a las OTs incluidas en esa versión para ser desarrolladas por el Proveedor correspondiente.

Una vez implantada la versión (RFC cerrada en FARO o versión finalizada si no se genera RFC) las mejoras se cerrarán en JIRA lo que significará que están implantadas en Producción.


Creación

  • Por integración. 
    • Se crean en estado asignadas a para origen gestión de proyectos.
    • Se crean en estado asignadas a  para origen gestión de problemas.
  • Directamente en JIRA en estado  asignadas a por usuarios de la aplicación. 


Acciones en estado 


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

APROBAR MEJORA

 a 


N/A
NO APROBAR MEJORA

 a 

  • Rechazo: (Sin resolver) a (Rechazada)
  • Escalado: (Sin resolver) a (Escalada)
CLONAR (en cualquier aplicación)


N/AN/A
ESCALAR (Sólo para mejoras creadas por integración y que no han cambiado de estado)

N/A(Sin resolver) a (Escalada)




Acciones en estado 

ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

A WISHLIST 

 a  

N/A
ASIGNAR VERSIÓN

 a 

N/A

CLONAR (en cualquier aplicación)

N/AN/A
ESCALAR (Sólo para mejoras creadas por integración y que no han cambiado de estado)

N/A(Sin resolver) a (Escalada)




Acciones en estado  


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

DESASIGNAR DE VERSIÓN

a

N/A
ASIGNAR OT

N/A

N/A
CLONAR (en versiones de la misma aplicación)

N/AN/A
VALIDAR

N/AN/A
EDITAR

N/AN/A
CIERRE RFC

a

(Sin resolver) a (Cerrada)

No conformidad



Versión

Una versión es un contenedor de mejoras e incidencias, es decir, tiene un alcance y un presupuesto determinados a partir de la que se lanzan trabajos para el proveedor  (órdenes de trabajo). Existe la posibilidad de que sea necesario un estudio de viabilidad del de la versión antes de comenzar a trabajar para que el Jefe de Proyecto decida una alternativa en el caso de que haya más de una y la reserva correspondiente de HBS.

Por cada uno de los meses de duración de la versión se creará una subtarea de Previsión en la que se podrán estimar las HBS previstas y donde se irán incurriendo las HBS que el proveedor registre en ese mes en las órdenes de trabajo asociadas a la versión.

Existe la posibilidad de modificar el alcance incluyendo o excluyendo mejoras o incidencias. 

Si la implantación de la versión necesita la intervención del Proveedor de Sistemas, será necesario generar una RFC en FARO, donde el Proveedor generará PLs que transicionarán implantando el software en o en los entornos que se determinen y que terminarán cerrando la RFC. En ese momento, las mejoras e incidencias incluidas en la versión pasará a estado Cerrada, considerando que su implantación en el entorno de Producción está finalizada.

Durante este proceso será posible crear órdenes de trabajo y asociarlas a la versión. Como ya hemos comentado, las HBS incurridas en un mes determinado se irán sumando a las HBS incurridas de la subtarea de previsión correspondiente a ese mes (excepto para las órdenes de trabajo de tipo PST).

Creación 

Se crean en estado asignadas a  por 


Acciones en estado 


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

GESTIONAR ALCANCE (incluir/excluir mejoras, incidencias o No conformidades en estado de esa aplicación)

N/A

N/A

COMENZAR (imprescindible que al menos haya una mejora o incidencia en la versión)

  • Si la versión está aprobada por --> 
  • Si la versión no está aprobada por --> 

a

a

N/A
CANCELAR

a

(Sin resolver) a (Cancelada)



Acciones en estado 


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

COMENZAR

a

N/A

CANCELAR

a

(Sin resolver) a (Cancelada)


Acciones en estado 


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

GESTIONAR ALCANCE

N/A

N/A

GENERAR RFC




a

N/A
CANCELAR



  • GESTIONAR ALCANCE  R. PRODUCTO
  • GENERAR RFC R. PRODUCTO→Obligatorio tener el código de la versión
    EN RESOLUCIÓN-->EN RESOLUCIÓN CON RFC ABERTA
  • FINALIZAR R. PRODUCTO→Obligatorio tener el código de la versión y todas las OTs asociadas cerradas

EN RESOLUCIÓN--->CERRADA (Resolución Cerrada)

  • CANCELAR R. PRODUCTO-->Obligatorio tener  todas las OTs asociadas cerradas

EN RESOLUCIÓN--->CERRADA (Resolución Cancelada)


Acciones en estado EN RESOLUCIÓN CON RFC ABIERTA

  • GESTIONAR ALCANCE  R. PRODUCTO
  • CANCELAR R. PRODUCTO-->Obligatorio tener  todas las OTs asociadas cerradas

EN RESOLUCIÓN--->CERRADA (Resolución Cancelada)

  • CIERRE RFC PROCESO AUTOMATIZADO →(Mejoras, incidencias y No conformidades incluidas en la versión se cierran)EN RESOLUCIÓN--->EN RESOLUCIÓN CON RFC CERRADA



Acciones en estado EN RESOLUCIÓN CON RFC CERRADA

  • FINALIZAR R. PRODUCTO→Obligatorio tener todas las OTs asociadas cerradas

EN RESOLUCIÓN CON RFC CERRADA--->CERRADA (Resolución Cerrada)



OT con crédito disponible


Creación

Si no es de tipo PST ni de tipo EVS la crea  asignada a  en estado 

    • Si es de tipo EVS la crea :
      • Si el EVS está aprobado por el Responsable de Área →  asignada a  en estado 
      • Si el EVS no está aprobado por el Responsable de Área → asignada a  en estado 
    • Si es  de tipo PST la crea  asignada a  en estado 


Acciones en estado 


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

APROBAR

  a


N/A
NO APROBAR

 a 

(Sin resolver) a (No Aprobada RA)

Acciones en estado 



ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

CALENDARIZAR
  • Si no es de tipo PST
  • Si es PST

 a


N/A
CANCELAR

 a 

(Sin resolver) a (Cancelada)


Acciones en estado 


  •  


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

COMENZAR RESOLUCIÓN
  • Si no es de tipo PST
  • Si es PST

 a


N/A
CANCELAR

 a 

(Sin resolver) a (Cancelada)




Acciones en estado 


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

REGISTRAR HBS
  • Si no es de tipo PST
  • Si es PST

N/A

N/A
SEGUIMIENTO
  • Si no es de tipo PST
  • Si es PST

N/A

N/A
RESOLVER
  • Si no es de tipo PST
  • Si es PST
  • Si no es de tipo PST:
    • Si la OT es revisada por la OCA a
    • Si la OT no es revisada por la OCA a
  • Si es PST a
N/A
CANCELAR

a

N/A


Acciones en estado 


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

INFORMAR REVISIÓN OCA

a

N/A


Acciones en estado 


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

REGISTRAR HBS
  • Si no es de tipo PST
  • Si es PST

N/A

N/A
LIQUIDAR OT
  • Si no es de tipo PST
  • Si es PST

a

N/A


Acciones en estado 


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

ACEPTAR RESOLUCIÓN

a

(Sin resolver) a (Resuelta)
NO ACEPTAR RESOLUCIÓN

a

N/A

Si es de tipo EVS:

EDITAR (Informar campos Alternativa y Reserva HBS)

N/AN/A

Acciones en estado

ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

ACEPTAR RESOLUCIÓN

a

(Sin resolver) a (Resuelta)
NO ACEPTAR RESOLUCIÓN

a

N/A


Acciones en estado 


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

ACEPTAR CANCELACIÓN

a

(Sin resolver) a (Cancelada)
NO ACEPTAR CANCELACIÓN

a

N/A


Acciones en estado 


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

REGISTRAR HBS

N/AN/A

RESOLVER

a

N/A


Acciones en estado 


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

    • Rechazo sólo por motivos técnicos:
      RESOLVER

a

N/A
    • Rechazo por costes:
      REGISTRAR HBS

N/AN/A
    • Rechazo por costes:
      RESOLVER

a

N/A

OT con estimación

Creación

La crea R. PRODUCTOPROVEEDOR asignada a PROVEEDOR en estado PDTE. ESTIMAR

Acciones en estado PDTE. ESTIMAR


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

ESTIMAR

PROVEEDOR

 PDTE. estimAR a estimada


N/A
CANCELAR

y si es el informador

PDTE. estimAR a CERRADA

(Sin resolver) a (Cancelada)

Acciones en estado ESTIMADA 


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

APROBAR ESTIMACIÓN

R. PRODUCTO

 ESTIMADA a PDTE. COMENZAR RESOLUCIÓN


N/A
NO APROBAR ESTIMACIÓN

ESTIMADA a PDTE. ESTIMAR

N/A



A partir del estado PDTE. COMENZAR RESOLUCIÓN continúa igual que una OT con crédito disponible. 


Historias de usuario

Una historia de usuario es una entidad que se usa en los proyectos que se gestionan con metodología ágil para "descomponer las mejoras" y asociar tareas que se asignan a los integrantes del equipo. Esta gestión puede hacerse con la posibilidad que tiene la herramienta de uso de pizarras SCRUM que permiten la gestión de sprints en el que se incluyen estas historias que pueden a su vez descomponerse en subtareas y errores técnicos.

Creación

    •  Se crean en el mismo estado en el que esté la mejora origen, que puede ser  o  por los roles  y . Una Historia de Usuario sólo puede estar relacionada con una mejora.


Acciones en estado 

ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

EN VERSIÓN

La mejora origen debe haberse previamente asignado a una versión

 a 

N/A

CREAR SUBTAREA


N/A

N/A
EDITAR


N/A

N/A


Acciones en estado 

Es recomendable crear una pizarra SCRUM para organizar las historias de usuario en sprints y activar aquel en el que se vaya a trabajar. 

La configuración de las pizarras es independiente de los flujos de las historias de usuario y de subtareas y errores técnicos.

Puedes gestionar historias, subtareas y errores técnicos sin haber configurado la pizarra.


Ver "Configuración pizarras SCRUM"


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

CREAR SUBTAREA

N/AN/A
CREAR ERROR

N/AN/A
EDITAR

N/AN/A
RESOLVER (se pretende automatizar esta acción una vez que todas las subtareas y errores estén cerradas) (por ahora deberá hacerse por procedimiento, no acceder a ella hasta que las subtareas no estén cerradas)

a

N/A


Acciones en estado 

ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

EDITAR

N/AN/A
VALIDAR OCA

a


NO VALIDAR OCA

a

(Sin Resolver) a (Rechazada)
VALIDAR

a Si valida la OCA

a Si no valida la OCA

(Sin Resolver) a (Aceptada)
NO VALIDAR

a

(Sin Resolver) a (Rechazada)


Acciones en estado 


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

EDITAR

N/AN/A
CREAR ERRORES

N/AN/A
RESOLVER

a

N/A






Subtarea 


Creación

  • Se crean a como entidades de tipo subtarea a partir de una Historia de usuario que esté en estado   o en . Se crean en estado  por ,  


Acciones en estado 

ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

COMENZAR

(Obligatorio asignar la tarea a un integrante del equipo)

 a 

N/A
CANCELAR

a

(Sin Resolver) a (Cancelada)
EDITAR

N/AN/A


Acciones en estado 

ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

PARALIZAR

 a 

N/A
CANCELAR

a

(Sin Resolver) a (Cancelada)
RESOLVER

a

(Sin Resolver) a (Cerrada)
EDITAR

N/AN/A
REGISTRAR HBS

N/AN/A


Acciones en estado 

ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

REANUDAR

a

N/A
CANCELAR

a

(Sin Resolver) a (Cancelada)
EDITAR

N/AN/A



Acciones en estado 

ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

REABRIR

(Comentario Obligatorio)

a

N/A
EDITAR

N/AN/A


Error técnico


Creación

  • Se crean a como entidades de tipo subtarea a partir de una Historia de usuario que esté en estado  o posterior. Se crean en estado  por ,    


Acciones en estado 

ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

COMENZAR

(Obligatorio asignar la tarea a un integrante del equipo)

 a 

N/A
CANCELAR

a

(Sin Resolver) a (Cancelada)
EDITAR

N/AN/A


Acciones en estado 

ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

PARALIZAR

 a 

N/A
CANCELAR

a

(Sin Resolver) a (Cancelada)
RESOLVER

a

(Sin Resolver) a (Cerrada)
EDITAR

N/AN/A
REGISTRAR HBS

N/AN/A


Acciones en estado 

ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

REANUDAR

a

N/A
CANCELAR

a

(Sin Resolver) a (Cancelada)
EDITAR

N/AN/A


Acciones en estado 

ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

REABRIR

(Comentario Obligatorio)

a

N/A
EDITAR

N/AN/A



Configuración pizarras SCRUM


Crear pizarra

Accede a la creación de pizarras y crea una pizarra de tipo SCRUM de un proyecto existente. Vamos a tomar como ejemplo el proyecto de Admisión Única (AU)









Configurar el filtro de la pizarra

Accede a la configuración de la pizarra y a partir de ahí a la posibilidad de modificar el filtro (Editar consulta de filtro), ya que el filtro muestra todas las entidades del proyecto.


Selecciona la entidad "Historia de usuario" y las subtareas de tipo Subtarea y Error técnico en el filtro y guárdalo

Crear sprints

Accede de nuevo a la pizarra SCRUM que has creado y procede a crear los sprints que quieras para organizar en ellos las historias de usuario.

Configurar SPRINTS ACTIVOS

Configura las columnas. En este ejemplo hemos configurado las columnas ABIERTA, EN RESOLUCIÓN, PROCESO VALIDACIÓN. PARALIZADA Y CERRADA.

Entra en la configuración de la pizarra y en la columna de la izquierda accede a Columnas. Puedes añadir, eliminar o cambiar el nombre de las que aparecen por defecto




Crea las que te van a aportar más para mover de una columna a otra las historias y, sobre todo, las subtareas y los errores técnicos

Incluye dentro de cada columna los estados que consideras deben estar en cada una de ellas. Por ejemplo, en la columna En validación, incluimos los estados "PDTE. VALIDAR" y "VALIDADA OCA"


Crea filtros rápidos para las subtareas y los errores técnicos

Inicia sprint en Trabajo pendiente. En nuestro ejemplo, iniciamos el Sprint 1



Al comenzar el SPRINT, podremos mover historias, subtareas y errores técnicos por las columnas



Cerrar Sprint activo

Los sprints se cierran manualmente sin restricción en la fecha dando la posibilidad de incorporar el trabajo no realizado a otros sprints creados.



Más información en https://www.atlassian.com/agile/tutorials/sprints



PL Incremento versión

Creación

Debe seleccionarse un proyecto con tipo de recurso Aplicación.

Se crean por los roles

R.PRODUCTO o PROVEEDOR  

en estado PDTE.REVISIÓN asignada a PROVEEDOR SISTEMAS

En el momento de la creación puedo decidir si la implantación es normal o bien es urgente.

Los campos que deben informarse son

Título *

Descripción*

Tipificación*:

  • Incremento versión

Tipo PL*: En este caso, queda informado como Normal sin ser ese campo editable.

PLU:

Sí

No (informado por defecto)


ID Versión relacionada*: campo nfeed en el que se muestren todas las versiones del aplicativo que estén en estado "EN RESOLUCIÓN". Este campo es obligatorio para las PLs de tipo normal y tipificación "Incremento versión". El tipo de enlace entre la Versión y la entidad PL CONTENEDOR será "Está relacionada con". El campo NFEED debe mostrar la key, el título y el código de la versión.


Debe añadirse como validación que es imposible poder seleccionar una versión que ya tenga una PL en estado distinto de CERRADA





Para PLU=NO

SVEs de la versión: campo en el que se muestran todas las SVEs relacionadas con esa versión en estado Cerrada y con resolución distinta a Cancelada. Sólo podrá seleccionarse una SVE

Entrega*: se informará de manera automática con la entrega de la SVE seleccionada. Este campo no se podrá rellenar manualmente

  • No se permite crear una PL con un mismo código de Entrega de SVE que otra, aparecerá el mensaje:
    Ya existe una PL en este proyecto con ese código de Entrega.

Resolución SVE: se informará con la resolución de la SVE seleccionada (Conforme, No conforme o No aplica):

  • No se permite crear una PL en el caso de resolución SVE = 'No se hará' (corresponde a la no conformidad compilación fallida en Jenkins)
  • SI Resolución SVE = 'No conforme'
    • Mostrar el valor del campo Motivo no aceptación SVE
    • Debe aparecer un mensaje de advertencia 

Añadir el motivo de no aceptación de la SVE

Seleccionar otra plataforma:

Sí

No

IDs Plataformas*: 

Si se ha indicado Sí en el campo anterior, aparecerán en el campo IDs plataformas todas las plataformas disponibles con campo multiselección.

Si se ha indicado No en el campo anterior, aparecerán en el campo sólo las plataformas en las que está desplegada la aplicación. 

IDs Entornos*: 

Aparecerán los entornos disponibles con campo multiselección.

Corte servicio*: (S/N) informada por defecto a No

Adjunto*: debe adjuntarse el PID

Se incluye un mensaje de advertencia para indicar que es necesario adjuntar el PID de forma obligatoria: "Debes adjuntar el PID".

¿Necesita soporte?*: (S/N) informada por defecto a No.




Para PLU=SÍ

Aparecen dos mensajes informativos:

'Se está indicando que la PL debe ejecutarse en el menor tiempo posible, no pudiendo asumirse el plazo de ejecución normal que es de entre 24 y 48 horas.

Ten en cuenta que la ejecución urgente de una PL incrementa los costes de gestión incurridos por este lanzamiento y supone un mayor riesgo de indisponibilidad del servicio'



Motivo urgencia*: Seleccionar uno de los motivos del desplegable:


      • Hay que solucionar una incidencia lo antes posible
      • Hay que instalar  lo antes posible para cumplir cronograma de implantación de la STIC
      • Hay que instalar  lo antes posible para cumplir necesidades impuestas por el SAS



Aparece un mensaje explicativo de que en la información adicional deben incluir el nombre y el teléfono del técnico:




Información adicional*: Campo en el que se deben incluir el nombre y el teléfono del técnico



SVEs de la versión: Aparecerán todas las SVEs aunque aún no estén cerradas pero no es obligatorio elegir una

Entrega*: Permite poner a mano la entrega si es que no se ha seleccionado ninguna SVE

IDs Plataformas*: Mostrar los plataformas y dejar seleccionar sólo una.
IDs Entornos*: Mostrar los entornos y dejar seleccionar sólo uno.


IMPORTANTE

Al crear una PLU:

  • Se crea automáticamente una PL hija en estado PDTE. CALENDARIZAR asignada a PROVEEDOR SISTEMAS para el entorno, plataforma y para todos los grupos lógicos.


PL Padre


Acciones en estado PDTE. REVISIÓN

Asignada a PROVEEDOR SISTEMAS


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

SOLICITAR INFORMACIÓN

Comentario obligatorio

PROVEEDOR SISTEMAS

PDTE. REVISIÓN a PDTE. INFORMACIÓN

N/A

ACEPTAR

PROVEEDOR SISTEMAS

PDTE. REVISIÓN a 

para PLU=NO

PDTE. REVISIÓN a EN RESOLUCIÓN para PLU=SÍ

N/A

NO ACEPTAR

Comentario obligatorio

PROVEEDOR SISTEMAS

PDTE. REVISIÓN a NO ACEPTADA

N/A

CANCELAR

Incluir comentario obligatorio

Libera la entrega y la SVE para la creación de una nueva entidad PL

R. PRODUCTO


PDTE. REVISIÓN a CERRADA

(Sin resolver) a (Cancelada)

EDITAR

Deben poder editarse todos los campos incluso el cambio a PLU, excepto la posibilidad de cambiar la tipificación y el tipo de la PL

R. PRODUCTO

PROVEEDOR

N/AN/A

SOLICITAR IMPLANTACIONES




PL hija urgente:

Sí

No (informado por defecto)

Si PLU hija urgente =SÍ


Aparece un mensaje en el que se indica que debe elegirse un entorno y plataforma únicos y que se creará una PL hija para el entorno y plataforma elegidos y para todos los grupos lógicos.

Entorno

Plataforma

Grupo lógico

Al ejecutar la acción SOLICITAR IMPLANTACIONES:

  • El campo Implantaciones solicitadas se informa a Sí y se reseteará una vez que se ejecute GENERAR EJECUCIONES.
  • Se resetean los campos "IDS entornos", "IDS plataformas" y "IDS grupos lógicos"

Si SOLICITAR IMPLANTACIONES se ejecuta en este estado y solicito PL HIJA urgente, se cambia el valor a PLU de la padre



El campo Restricción horaria debe permanecer visible en la entidad hasta que se ejecute GENERAR EJECUCIONES. En ese momento deja de mostrarse porque no estará informado.


Si marcamos PLU, se generará una PL hija para la plataforma y entorno seleccionado y para todos los grupos lógicos. La PL Hija se crea en estado PDTE. CALENDARIZAR

Se resetea en la padre PLU a SÍ si y solo si la padre está en estado PDTE. REVISIÓN porque el valor del campo determinará el umbral para el ANS. En cualquier otro estado, el campo de PLU para la padre se mantiene.

R. PRODUCTO

PROVEEDOR


N/A

N/A

Acciones en estado NO ACEPTADA

Asignada a Informador

ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

COMPLETAR INFORMACIÓN

Comentario obligatorio

Adjunto obligatorio

Mensaje: Debes adjuntar un nuevo PID

R.PRODUCTO

PROVEEDOR

NO ACEPTADA a PDTE. REVISIÓN

N/A

CANCELAR

Incluir comentario obligatorio

R. PRODUCTO

PROVEEDOR

NO ACEPTADAa CERRADA

(Sin resolver) a (Cancelada)

Acciones en estado 

Asignada a PROVEEDOR SISTEMAS


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

SOLICITAR INFORMACIÓN

Se informa un campo "Dudas tras proceso de revisión" a SÍ

PROVEEDOR SISTEMAS

a PDTE. INFORMACIÓN

N/A

CANCELAR

Incluir comentario obligatorio

R. PRODUCTO

PROVEEDOR

a CERRADA

(Sin resolver) a (Cancelada)

SOLICITAR IMPLANTACIONES

Las restricciones son las mismas que al solicitar implantaciones en el estado PDTE. REVISIÓN con la salvedad de:

NO SE RESETEA EL CAMPO PLU DE LA PADRE


R. PRODUCTO

PROVEEDOR

N/A si PLU=NO

 a EN RESOLUCIÓN si PLU=SÍ

N/A

GENERAR EJECUCIONES

acción ASIGNAR A MÍ en los usuarios integrantes del grupo planificador.


Campos que tienen que informarse:

Agrupación Plataformas: campo nfeed informado por Servicios CGES.

Plataformas*: campo informado con el valor que se puso en la creación. Puede modificarse o bien eliminarse su valor.

Entornos*: Campo con los entornos.

Grupos Lógicos :  aquí hay que indicar si los grupos separados por comas corresponden cada uno a una ejecución. Existe la posibilidad de concatenar grupos y que sea una ejecución por grupo concatenado. 

Se generará una subtarea de ejecución por cada agrupación de plataformas (o plataforma), entorno y grupo lógico (simple o concatenado). 

Subtareas creadas por usuarios pertenecientes al GRUPO PLANIFICADOR en estado  asignada a PROVEEDOR SISTEMAS


Aparecerá mensaje indicándose si se quiere crear una PL Hija por entorno, plataforma y para todos los grupos lógicos o si se quiere crear una PL Hija por cada grupo lógico.

GRUPO PLANIFICADOR

a EN RESOLUCIÓN

N/A


Acciones en estado EN RESOLUCIÓN

Asignada a  PROVEEDOR SISTEMAS  


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

SOLICITAR INFORMACIÓN

Se informa un campo "Dudas con documentación aprobada" a SÍ si no estuviera informado. Si ya estuviera informado a SÍ, se mantiene el valor.

PROVEEDOR SISTEMAS

EN RESOLUCIÓN a PDTE. INFORMACIÓN

N/A

CANCELAR

Incluir comentario obligatorio

Si tiene PLs hijas, deben estar todas cerradas y con resolución cancelada

R. PRODUCTO

PROVEEDOR

EN RESOLUCIÓNa CERRADA

(Sin resolver) a (Cancelada)

SOLICITAR IMPLANTACIONES

IDEM a en estado


R. PRODUCTO

PROVEEDOR

N/A

N/A

GENERAR EJECUCIONES


GRUPO PLANIFICADOR

N/A

N/A

FINALIZAR

Todas las Pls hijas deben estar cerradas

R. PRODUCTO

PROVEEDOR

EN RESOLUCIÓN a CERRADA

(Sin resolver) a (Cerrada)

Acciones en estado PDTE. INFORMACIÓN

Asignada al informador  R. PRODUCTO  PROVEEDOR

ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

COMPLETAR INFORMACIÓN

R. PRODUCTO

PROVEEDOR

PDTE. INFORMACIÓN a ESTADO ORIGEN

N/A

CANCELAR

Incluir comentario obligatorio

Si tiene PLs hijas, deben estar todas cerradas y con resolución cancelada

R. PRODUCTO

PROVEEDOR

EN RESOLUCIÓN a CERRADA

(Sin resolver) a (Cancelada)

PL Hija

Las PLS hijas se crearán con título : {Plataforma} - {Entorno} - {Grupos lógicos}. 

Debe estar visible el campo que identifique si es o no PLU


No podrán existir dos entidades "PL hija" con el mismo valor para los campos "IDS entornos", "IDS plataformas" y "IDS grupos lógicos", para un mismo padre (PL). Sólo será posible si la primera se ha cancelado.

Si PL hija urgente=SÍ, la PL hija queda en estado PDTE. CALENDARIZAR y cuando el PROVEEDOR SISTEMAS pone fechas, pasa directamente al estado PDTE. COMENZRA RESOLUCIÓN

En las PLs hijas debe siempre estar visible si son o no PL hija urgente

Desde la PL padre deben verse las PL hijas identificando de manera visual si son o no PL hija urgente o no


El ciclo completo de la PL hija se da únicamente en el caso de la primera vuelta, correspondiente a la actividad de instalación.

Para cualquier otra vuelta, que siempre supone una NO aceptación de la solución técnica por parte del solicitante, el flujo comienza en el estado PDTE. CALENDARIZAR y de ahí pasa a PDTE. COMENZAR RESOLUCIÓN. El solicitante debe escribir en un comentario las fechas que desea tenga esa nueva actividad.


Acciones en estado 

ACTIVIDAD=INSTALACIÓN

Asignada  GRUPO PLANIFICADOR cuyos integrantes podrán asignarse la entidad

ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

EDITAR

Podrá convertirse en PL hija urgente(1). indicar motivo y campo de información adicional

Podrán cambiarse los grupos lógicos(2)

RESPONSABLE PRODUCTO(1)

PROVEEDOR(1)

PROVEEDOR SISTEMAS(2)

GRUPO PLANIFICADOR(2)

a PDTE. CALENDARIZAR si PL hija urgente=Sí

N/A en el resto de los casos


SOLICITAR PLANIFICACIÓN

Debe indicarse fecha de inicio deseada

GRUPO PLANIFICADOR

a PDTE. CALENDARIZAR


N/A

CANCELAR

Incluir comentario obligatorio

R.PRODUCTO

PROVEEDOR

GRUPO PLANIFICADOR

a CERRADA

(Sin resolver) a (Cancelada)

SOLICITAR REVISIÓN

Indicar en comentario lo que se quiere cambiar. Comentario obligatorio.

Informar el campo Pdte. revisión STIC a SÍ


GRUPO PLANIFICADOR

PROVEEDOR SISTEMAS

N/A

EDITAR EJECUCIONES

Modificar en el tablegrid lo que sea necesario y cambiar el campo Pdte. revisión STIC a NO.

Recalcular las HBS incurridas

GRUPO PLANIFICADOR

N/A

Acciones en estado PDTE. CALENDARIZAR

ACTIVIDAD=TODAS

Asignada a PROVEEDOR SISTEMAS


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

EDITAR

Podrá convertirse en PL hija urgente(1). indicar motivo y campo de información adicional

Podrán cambiarse los grupos lógicos(2)


RESPONSABLE PRODUCTO(1)

PROVEEDOR(1)

PROVEEDOR SISTEMAS(2)

GRUPO LANZAMIENTO(2)

N/A

N/A

CALENDARIZAR (**)


PROVEEDOR SISTEMAS

GRUPO PLANIFICADOR

PDTE. CALENDARIZARa CALENDARIZADASI ACTIVIDAD=INSTALACIÓN Ó

PLU=NO

PDTE. CALENDARIZAR a PDTE. COMENZAR RESOLUCIÓN SI ACTIVIDAD no es INSTALACIÓN Ó PLU=SÍ

N/A

CANCELAR

Incluir comentario obligatorio

R. PRODUCTO

GRUPO PLANIFICADOR

PDTE. CALENDARIZAR a CERRADA

(Sin resolver) a (Cancelada)

SOLICITAR REVISIÓN

Indicar en comentario lo que se quiere cambiar. Comentario obligatorio.

Informar el campo Pdte. revisión STIC a SÍ

PROVEEDOR SISTEMAS

GRUPO PLANIFICADOR

N/A

EDITAR EJECUCIONES

Modificar en el tablegrid lo que sea necesario y cambiar el campo Pdte. revisión STIC a NO.

Recalcular las HBS incurridas

GRUPO PLANIFICADOR

N/A

(**)

Campos que deben informarse o estarán informados al CALENDARIZAR:

Actividad*(se informa automáticamente):  posibles valores Instalación, Desinstalación y Marcha Atrás (conlleva una reinstalación, que se informará automáticamente en el campo Actividad al aceptar la marcha atrás). Para la primera vez que se haga la ejecución, estará informado "Instalación". Posteriormente dependerá de lo que informe el solicitante cuando no acepte la solución técnica o si la acepta siendo la actividad una marcha atrás.

Facturable*:

ACTIVIDAD= INSTALACIÓN, el campo estará informado a Sí 

ACTIVIDAD= MARCHA ATRÁS, el campo estará informado a No 

ACTIVIDAD= REINSTALACIÓN, el campo estará informado a No

 ACTIVIDAD= DESINSTALACIÓN, el campo estará informado a Sí 


Complejidad*: (Sí/No) por defecto informado a NO hasta que no solicite CTI 


En cada ejecución, se reseteará el valor del campo PLU a NO


Acciones en estado 

ACTIVIDAD= INSTALACIÓN

Asignada a GRUPO PLANIFICADOR 


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

EDITAR

Podrá convertirse en PL hija urgente(1). indicar motivo y campo de información adicional


Podrán cambiarse los grupos lógicos(2)


RESPONSABLE PRODUCTO(1)

PROVEEDOR(1)

PROVEEDOR SISTEMAS(2)

GRUPO LANZAMIENTO(2)

CALENDARIZADA a PDTE. COMENZAR RESOLUCIÓN si (1)

N/A si (2)

N/A

APROBAR FECHAS

Si la PL está enlazada con otra porque tenga dependencia, debería aparecer un mensaje de advertencia

GRUPO PLANIFICADOR

CALENDARIZADA a PDTE. COMENZAR RESOLUCIÓN

N/A

NO APROBAR FECHAS

(Incluir motivo obligatorio)

GRUPO PLANIFICADOR

CALENDARIZADA a PDTE. CALENDARIZAR

N/A

CANCELAR

Incluir comentario obligatorio

R. PRODUCTO

PROVEEDOR

GRUPO PLANIFICADOR

CALENDARIZADA  a CERRADA

(Sin resolver) a (Cancelada)

SOLICITAR REVISIÓN

Indicar en comentario lo que se quiere cambiar. Comentario obligatorio.

Informar el campo Pdte. revisión STIC a SÍ

PROVEEDOR SISTEMAS

GRUPO PLANIFICADOR

N/A

EDITAR EJECUCIONES

Modificar en el tablegrid lo que sea necesario y cambiar el campo Pdte. revisión STIC a NO

Recalcular las HBS incurridas

GRUPO PLANIFICADOR

N/A

Acciones en estado  PDTE. COMENZAR RESOLUCIÓN

Asignada a  PROVEEDOR SISTEMAS


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

EDITAR

Podrá convertirse en PL hija urgente(1). indicar motivo y campo de información adicional


Podrán cambiarse los grupos lógicos(2)

Podrán cambiarse las fechas, si y sólo si no se haya llegado a la fecha de inicio estimada (3)


R. PRODUCTO (1)

PROVEEDOR (1)

PROVEEDOR SISteMAS (2) (3)


GRUPO PLANIFICADOR(2)(3)

N/A

N/A

COMENZAR RESOLUCIÓN

Para cada actividad informar "Fecha inicio real" para cargar en la tabla de ejecuciones

PROVEEDOR SISteMAS

GRUPO PLANIFICADOR

PDTE. COMENZAR RESOLUCIÓN a EN RESOLUCIÓN

N/A

CANCELAR

Incluir comentario obligatorio

R. PRODUCTO

GRUPO PLANIFICADOR

PDTE. COMENZAR RESOLUCIÓN a CERRADA

(Sin resolver) a (Cancelada)

SOLICITAR REVISIÓN

Indicar en comentario lo que se quiere cambiar. Comentario obligatorio.

Informar el campo Pdte. revisión STIC a SÍ

PROVEEDOR SISteMAS

GRUPO PLANIFICADOR

N/A

EDITAR EJECUCIONES

Modificar en el tablegrid lo que sea necesario y cambiar el campo Pdte. revisión STIC a NO

Recalcular las HBS incurridas

GRUPO PLANIFICADOR

N/A


Acciones en estado  EN RESOLUCIÓN

Asignada a  PROVEEDOR SISTEMAS


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

RESOLVER

Informar campo "Errores detectados" Sí/No. El campo no está informado hasta ese momento.

Describir los errores detectados en un campo Comentario obligatorio.


PROVEEDOR SISteMAS

EN RESOLUCIÓN  a  PDTE.REVISIÓN TÉCNICA

N/A

SOLICITAR REVISIÓN

Indicar en comentario lo que se quiere cambiar. Comentario obligatorio.

Informar el campo Pdte. revisión STIC a SÍ

PROVEEDOR SISteMAS

GRUPO PLANIFICADOR

N/A

EDITAR EJECUCIONES

Modificar en el tablegrid lo que sea necesario y cambiar el campo Pdte. revisión STIC a NO

Recalcular las HBS incurridas

GRUPO PLANIFICADOR

N/A


Acciones en estado  PDTE. REVISIÓN TÉCNICA

Asignada a solicitante (R.PRODUCTO , PROVEEDOR) de la PL padre


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

ACEPTAR SOLUCIÓN TÉCNICA

Si está informado el campo "Errores detectados", el solicitante deberá justificar el motivo por el que acepta la solución a pesar de los errores detectados en el despliegue. Se hace en campo comentario


R.PRODUCTO

PROVEEDOR

a  

(Sin resolver) a (Cerrada)

NO ACEPTAR SOLUCIÓN TÉCNICA*

(Informar obligatoriamente el campo "MOTIVO NO ACEPTACIÓN"

y el campo ACTIVIDAD)

R.PRODUCTO

PROVEEDOR

PDTE.REVISIÓN TÉCNICA a PDTE. CALENDARIZAR


N/A

SOLICITAR REVISIÓN

Indicar en comentario lo que se quiere cambiar. Comentario obligatorio.

Informar el campo Pdte. revisión STIC a SÍ

PROVEEDOR SISteMAS

GRUPO PLANIFICADOR

N/A

EDITAR EJECUCIONES

Modificar en el tablegrid lo que sea necesario y cambiar el campo Pdte. revisión STIC a NO

Recalcular las HBS incurridas

GRUPO PLANIFICADOR

N/A


*Cuando se accede a No aceptar solución técnica, deben mostrarse una serie de preguntas al solicitante


  • ¿Quieres reinstalación?

    • No. 
      • ¿Quieres desinstalar?
        • Sí
          • Indicar en comentario la fecha en la que el peticionario desea que se haga la desinstalación
          • Pasa a PDTE. CALENDARIZAR y se informa como Actividad "Desinstalación"
        • No. 
          • Pasa a CERRADA con Resolución "Anulada por defecto de Software"
    • Sí
      • ¿Quieres marcha atrás?
        • Sí
          • Indicar en comentario la fecha en la que el peticionario desea que se haga la MARCHA ATRÁS
          • Pasa a PDTE. CALENDARIZAR y se informa como Actividad "Marcha Atrás". Al aceptar la solución técnica debe ir de nuevo al principio con Actividad "Reinstalación"
        • No
          • Pasa a PDTE. CALENDARIZAR y se informa como Actividad "Reinstalación"






Control facturación

Cada ejecución se registra en una fila de un table grid


Los datos que se muestran en la tabla son:

  • Tipo actividad
  • PLU (sí o no)
  • Compleja (informado siempre a NO)
  • Facturable: vendrá informado por el tipo de actividad
  • Fecha de inicio real
  • Fecha de inicio estimada : marca la hora para saber si la facturación corresponde a horario normal o extendido.
  • Fecha resolución: corresponde al campo "Fecha resolución proveedor" de cada ejecución (paso del estado EN RESOLUCIÓN a PDTE. REVISIÓN TÉCNICA)

La factura se conforma con los datos del table grid el día 11 de cada mes. Cualquier modificación de una ejecución hecha después del día 10, no se tendrá en cuenta en la facturación



RFP (Request For Platform)

Común a todas las entidades

  • Existen una serie de acciones comunes a todas las entidades:
    • COMENTAR
    • ADJUNTAR ARCHIVOS
    • ENLAZAR
    • ETIQUETAR

  • Los usuarios necesarios en un proyecto son:
    • Responsable de Área
    • Responsable de producto
    • Responsable funcional
    • Responsable de sistemas
    • Proveedor

Estos usuarios aunque aparezcan como asignados de las entidades pertenecen a roles definidos:

  • COORDINADOR→Puede hacer todo lo que hace el rol JP-STIC además de ciertas acciones específicas que se detallan
  • JP-STIC→ A este rol pertenecen los usuarios Responsable de producto y Responsable de sistemas.
Todos los usuarios con este rol pueden hacer las mismas acciones independientemente de la entidad y de la aplicación


  • FUNCIONAL→ A este rol pertenecen los usuarios Responsable funcional
  • COLABORADOR–>Este rol se usa para ususarios que sólo pueden hacer las acciones comunes pero ninguna acción específica.



¿Cómo puedes usar esta guía rápida?


  • Para cada una de los tipos de entidades de JIRA se detallan las acciones que pueden ejecutarse en cada uno de sus estados indicando:
    • Usuarios que pueden ejecutarla.
    • Si procede, cambio de estado de la entidad.
    • Si procede, cambio de resolución de la entidad.



Incidencia

Las incidencias que llegan a JIRA suponen fallos en el software que hay actualmente en Producción y que se registran desde MiCS (Mi Centro Servicio) o desde NWT (Nueva Web Técnica).  Pueden por tanto tener su origen en incidencias de usuarios finales o en la resolución de un problema que debe ser acometida por el Proveedor del producto.

En cualquier caso son resueltas por el Proveedor en NWT y sólo llegan a JIRA si su corrección implica implantación y modificación de la línea base del producto. Por tanto, llegan a JIRA corregidas y a la espera de ser implantadas en Producción en la versión que el Responsable de Producto o el Proveedor consideren oportunas. Se crean informando la fecha de registro en NWT, el usuario afectado, el código de solicitud y la prioridad.

Una vez que la versión se implante (cierre de la RFC en FARO), significará que las incidencias están en Producción y se cerrarán en JIRA, lo que supondrá que acabarán su ciclo de vida también en NWT, comunicando al usuario afectado la resolución del fallo detectado.


Si la prioridad de la incidencia es P1 y en NWT el Proveedor indica que se requiere Versión de Emergencia, se generará una entidad de este tipo en la que quedará automáticamente incluida la incidencia.


Si la incidencia llega a JIRA por error o con datos incorrectos, existe la posibilidad de escalarla a NWT.


Creación

    • Por integración. Se crean en estado  asignadas a  tanto si su origen es la gestión de problemas como si es la gestión de incidencias.


Acciones en estado 

ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

ESCALAR

 a 


(Sin resolver) a (Cancelada)
ASIGNAR A VERSIÓN

 a 

N/A
CLONAR (en cualquier aplicación)

N/AN/A


Acciones en estado 

ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

DESASIGNAR DE VERSIÓN

 a 


N/A
ASIGNAR OT

N/A

N/A
CLONAR (en versiones de la misma aplicación)

N/AN/A
VALIDAR

N/AN/A
EDITAR

N/AN/A
CIERRE RFC

 a 

(Sin resolver) a (Cerrada)
  •  

Mejora

Una mejora es cualquier petición de evolución de una aplicación. Puede ser registrada por cualquier usuario en MiCS (Mi Centro Servicios). Su origen puede ser esa petición de un usuario final o bien la respuesta a la solución de un problema que hace el Responsable de Producto. Pueden ser registradas directamente en JIRA por los usuarios logados en la herramienta.

La mejoras son analizadas por los Responsables Funcionales para determinar su viabilidad, y, si la tienen, establecer la urgencia con la que deben ser incluidas en una versión.

Cuando se aprueba una mejora por ser considerada viable, se informa al usuario que la registró cerrando la solicitud en el caso de registro en MiCS.

Una vez incluidas en una versión podrán asignarse a las OTs incluidas en esa versión para ser desarrolladas por el Proveedor correspondiente.

Una vez implantada la versión (RFC cerrada en FARO o versión finalizada si no se genera RFC) las mejoras se cerrarán en JIRA lo que significará que están implantadas en Producción.


Creación

  • Por integración. 
    • Se crean en estado asignadas a para origen gestión de proyectos.
    • Se crean en estado asignadas a  para origen gestión de problemas.
  • Directamente en JIRA en estado  asignadas a por usuarios de la aplicación. 


Acciones en estado 


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

APROBAR MEJORA

 a 


N/A
NO APROBAR MEJORA

 a 

  • Rechazo: (Sin resolver) a (Rechazada)
  • Escalado: (Sin resolver) a (Escalada)
CLONAR (en cualquier aplicación)


N/AN/A
ESCALAR (Sólo para mejoras creadas por integración y que no han cambiado de estado)

N/A(Sin resolver) a (Escalada)




Acciones en estado 

ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

A WISHLIST 

 a  

N/A
ASIGNAR VERSIÓN

 a 

N/A

CLONAR (en cualquier aplicación)

N/AN/A
ESCALAR (Sólo para mejoras creadas por integración y que no han cambiado de estado)

N/A(Sin resolver) a (Escalada)




Acciones en estado  


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

DESASIGNAR DE VERSIÓN

a

N/A
ASIGNAR OT

N/A

N/A
CLONAR (en versiones de la misma aplicación)

N/AN/A
VALIDAR

N/AN/A
EDITAR

N/AN/A
CIERRE RFC

a

(Sin resolver) a (Cerrada)

No conformidad



Versión

Una versión es un contenedor de mejoras e incidencias, es decir, tiene un alcance y un presupuesto determinados a partir de la que se lanzan trabajos para el proveedor  (órdenes de trabajo). Existe la posibilidad de que sea necesario un estudio de viabilidad del de la versión antes de comenzar a trabajar para que el Jefe de Proyecto decida una alternativa en el caso de que haya más de una y la reserva correspondiente de HBS.

Por cada uno de los meses de duración de la versión se creará una subtarea de Previsión en la que se podrán estimar las HBS previstas y donde se irán incurriendo las HBS que el proveedor registre en ese mes en las órdenes de trabajo asociadas a la versión.

Existe la posibilidad de modificar el alcance incluyendo o excluyendo mejoras o incidencias. 

Si la implantación de la versión necesita la intervención del Proveedor de Sistemas, será necesario generar una RFC en FARO, donde el Proveedor generará PLs que transicionarán implantando el software en o en los entornos que se determinen y que terminarán cerrando la RFC. En ese momento, las mejoras e incidencias incluidas en la versión pasará a estado Cerrada, considerando que su implantación en el entorno de Producción está finalizada.

Durante este proceso será posible crear órdenes de trabajo y asociarlas a la versión. Como ya hemos comentado, las HBS incurridas en un mes determinado se irán sumando a las HBS incurridas de la subtarea de previsión correspondiente a ese mes (excepto para las órdenes de trabajo de tipo PST).

Creación 

Se crean en estado asignadas a  por 


Acciones en estado 


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

GESTIONAR ALCANCE (incluir/excluir mejoras, incidencias o No conformidades en estado de esa aplicación)

N/A

N/A

COMENZAR (imprescindible que al menos haya una mejora o incidencia en la versión)

  • Si la versión está aprobada por --> 
  • Si la versión no está aprobada por --> 

a

a

N/A
CANCELAR

a

(Sin resolver) a (Cancelada)



Acciones en estado 


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

COMENZAR

a

N/A

CANCELAR

a

(Sin resolver) a (Cancelada)


Acciones en estado 


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

GESTIONAR ALCANCE

N/A

N/A

GENERAR RFC




a

N/A
CANCELAR



  • GESTIONAR ALCANCE  R. PRODUCTO
  • GENERAR RFC R. PRODUCTO→Obligatorio tener el código de la versión
    EN RESOLUCIÓN-->EN RESOLUCIÓN CON RFC ABERTA
  • FINALIZAR R. PRODUCTO→Obligatorio tener el código de la versión y todas las OTs asociadas cerradas

EN RESOLUCIÓN--->CERRADA (Resolución Cerrada)

  • CANCELAR R. PRODUCTO-->Obligatorio tener  todas las OTs asociadas cerradas

EN RESOLUCIÓN--->CERRADA (Resolución Cancelada)


Acciones en estado EN RESOLUCIÓN CON RFC ABIERTA

  • GESTIONAR ALCANCE  R. PRODUCTO
  • CANCELAR R. PRODUCTO-->Obligatorio tener  todas las OTs asociadas cerradas

EN RESOLUCIÓN--->CERRADA (Resolución Cancelada)

  • CIERRE RFC PROCESO AUTOMATIZADO →(Mejoras, incidencias y No conformidades incluidas en la versión se cierran)EN RESOLUCIÓN--->EN RESOLUCIÓN CON RFC CERRADA



Acciones en estado EN RESOLUCIÓN CON RFC CERRADA

  • FINALIZAR R. PRODUCTO→Obligatorio tener todas las OTs asociadas cerradas

EN RESOLUCIÓN CON RFC CERRADA--->CERRADA (Resolución Cerrada)



OT con crédito disponible


Creación

Si no es de tipo PST ni de tipo EVS la crea  asignada a  en estado 

    • Si es de tipo EVS la crea :
      • Si el EVS está aprobado por el Responsable de Área →  asignada a  en estado 
      • Si el EVS no está aprobado por el Responsable de Área → asignada a  en estado 
    • Si es  de tipo PST la crea  asignada a  en estado 


Acciones en estado 


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

APROBAR

  a


N/A
NO APROBAR

 a 

(Sin resolver) a (No Aprobada RA)

Acciones en estado 



ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

CALENDARIZAR
  • Si no es de tipo PST
  • Si es PST

 a


N/A
CANCELAR

 a 

(Sin resolver) a (Cancelada)


Acciones en estado 


  •  


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

COMENZAR RESOLUCIÓN
  • Si no es de tipo PST
  • Si es PST

 a


N/A
CANCELAR

 a 

(Sin resolver) a (Cancelada)




Acciones en estado 


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

REGISTRAR HBS
  • Si no es de tipo PST
  • Si es PST

N/A

N/A
SEGUIMIENTO
  • Si no es de tipo PST
  • Si es PST

N/A

N/A
RESOLVER
  • Si no es de tipo PST
  • Si es PST
  • Si no es de tipo PST:
    • Si la OT es revisada por la OCA a
    • Si la OT no es revisada por la OCA a
  • Si es PST a
N/A
CANCELAR

a

N/A


Acciones en estado 


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

INFORMAR REVISIÓN OCA

a

N/A


Acciones en estado 


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

REGISTRAR HBS
  • Si no es de tipo PST
  • Si es PST

N/A

N/A
LIQUIDAR OT
  • Si no es de tipo PST
  • Si es PST

a

N/A


Acciones en estado 


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

ACEPTAR RESOLUCIÓN

a

(Sin resolver) a (Resuelta)
NO ACEPTAR RESOLUCIÓN

a

N/A

Si es de tipo EVS:

EDITAR (Informar campos Alternativa y Reserva HBS)

N/AN/A

Acciones en estado

ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

ACEPTAR RESOLUCIÓN

a

(Sin resolver) a (Resuelta)
NO ACEPTAR RESOLUCIÓN

a

N/A


Acciones en estado 


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

ACEPTAR CANCELACIÓN

a

(Sin resolver) a (Cancelada)
NO ACEPTAR CANCELACIÓN

a

N/A


Acciones en estado 


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

REGISTRAR HBS

N/AN/A

RESOLVER

a

N/A


Acciones en estado 


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

    • Rechazo sólo por motivos técnicos:
      RESOLVER

a

N/A
    • Rechazo por costes:
      REGISTRAR HBS

N/AN/A
    • Rechazo por costes:
      RESOLVER

a

N/A

OT con estimación

Creación

La crea R. PRODUCTOPROVEEDOR asignada a PROVEEDOR en estado PDTE. ESTIMAR

Acciones en estado PDTE. ESTIMAR


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

ESTIMAR

PROVEEDOR

 PDTE. estimAR a estimada


N/A
CANCELAR

y si es el informador

PDTE. estimAR a CERRADA

(Sin resolver) a (Cancelada)

Acciones en estado ESTIMADA 


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

APROBAR ESTIMACIÓN

R. PRODUCTO

 ESTIMADA a PDTE. COMENZAR RESOLUCIÓN


N/A
NO APROBAR ESTIMACIÓN

ESTIMADA a PDTE. ESTIMAR

N/A



A partir del estado PDTE. COMENZAR RESOLUCIÓN continúa igual que una OT con crédito disponible. 


Historias de usuario

Una historia de usuario es una entidad que se usa en los proyectos que se gestionan con metodología ágil para "descomponer las mejoras" y asociar tareas que se asignan a los integrantes del equipo. Esta gestión puede hacerse con la posibilidad que tiene la herramienta de uso de pizarras SCRUM que permiten la gestión de sprints en el que se incluyen estas historias que pueden a su vez descomponerse en subtareas y errores técnicos.

Creación

    •  Se crean en el mismo estado en el que esté la mejora origen, que puede ser  o  por los roles  y . Una Historia de Usuario sólo puede estar relacionada con una mejora.


Acciones en estado 

ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

EN VERSIÓN

La mejora origen debe haberse previamente asignado a una versión

 a 

N/A

CREAR SUBTAREA


N/A

N/A
EDITAR


N/A

N/A


Acciones en estado 

Es recomendable crear una pizarra SCRUM para organizar las historias de usuario en sprints y activar aquel en el que se vaya a trabajar. 

La configuración de las pizarras es independiente de los flujos de las historias de usuario y de subtareas y errores técnicos.

Puedes gestionar historias, subtareas y errores técnicos sin haber configurado la pizarra.


Ver "Configuración pizarras SCRUM"


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

CREAR SUBTAREA

N/AN/A
CREAR ERROR

N/AN/A
EDITAR

N/AN/A
RESOLVER (se pretende automatizar esta acción una vez que todas las subtareas y errores estén cerradas) (por ahora deberá hacerse por procedimiento, no acceder a ella hasta que las subtareas no estén cerradas)

a

N/A


Acciones en estado 

ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

EDITAR

N/AN/A
VALIDAR OCA

a


NO VALIDAR OCA

a

(Sin Resolver) a (Rechazada)
VALIDAR

a Si valida la OCA

a Si no valida la OCA

(Sin Resolver) a (Aceptada)
NO VALIDAR

a

(Sin Resolver) a (Rechazada)


Acciones en estado 


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

EDITAR

N/AN/A
CREAR ERRORES

N/AN/A
RESOLVER

a

N/A






Subtarea 


Creación

  • Se crean a como entidades de tipo subtarea a partir de una Historia de usuario que esté en estado   o en . Se crean en estado  por ,  


Acciones en estado 

ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

COMENZAR

(Obligatorio asignar la tarea a un integrante del equipo)

 a 

N/A
CANCELAR

a

(Sin Resolver) a (Cancelada)
EDITAR

N/AN/A


Acciones en estado 

ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

PARALIZAR

 a 

N/A
CANCELAR

a

(Sin Resolver) a (Cancelada)
RESOLVER

a

(Sin Resolver) a (Cerrada)
EDITAR

N/AN/A
REGISTRAR HBS

N/AN/A


Acciones en estado 

ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

REANUDAR

a

N/A
CANCELAR

a

(Sin Resolver) a (Cancelada)
EDITAR

N/AN/A



Acciones en estado 

ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

REABRIR

(Comentario Obligatorio)

a

N/A
EDITAR

N/AN/A


Error técnico


Creación

  • Se crean a como entidades de tipo subtarea a partir de una Historia de usuario que esté en estado  o posterior. Se crean en estado  por ,    


Acciones en estado 

ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

COMENZAR

(Obligatorio asignar la tarea a un integrante del equipo)

 a 

N/A
CANCELAR

a

(Sin Resolver) a (Cancelada)
EDITAR

N/AN/A


Acciones en estado 

ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

PARALIZAR

 a 

N/A
CANCELAR

a

(Sin Resolver) a (Cancelada)
RESOLVER

a

(Sin Resolver) a (Cerrada)
EDITAR

N/AN/A
REGISTRAR HBS

N/AN/A


Acciones en estado 

ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

REANUDAR

a

N/A
CANCELAR

a

(Sin Resolver) a (Cancelada)
EDITAR

N/AN/A


Acciones en estado 

ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

REABRIR

(Comentario Obligatorio)

a

N/A
EDITAR

N/AN/A



Configuración pizarras SCRUM


Crear pizarra

Accede a la creación de pizarras y crea una pizarra de tipo SCRUM de un proyecto existente. Vamos a tomar como ejemplo el proyecto de Admisión Única (AU)









Configurar el filtro de la pizarra

Accede a la configuración de la pizarra y a partir de ahí a la posibilidad de modificar el filtro (Editar consulta de filtro), ya que el filtro muestra todas las entidades del proyecto.


Selecciona la entidad "Historia de usuario" y las subtareas de tipo Subtarea y Error técnico en el filtro y guárdalo

Crear sprints

Accede de nuevo a la pizarra SCRUM que has creado y procede a crear los sprints que quieras para organizar en ellos las historias de usuario.

Configurar SPRINTS ACTIVOS

Configura las columnas. En este ejemplo hemos configurado las columnas ABIERTA, EN RESOLUCIÓN, PROCESO VALIDACIÓN. PARALIZADA Y CERRADA.

Entra en la configuración de la pizarra y en la columna de la izquierda accede a Columnas. Puedes añadir, eliminar o cambiar el nombre de las que aparecen por defecto




Crea las que te van a aportar más para mover de una columna a otra las historias y, sobre todo, las subtareas y los errores técnicos

Incluye dentro de cada columna los estados que consideras deben estar en cada una de ellas. Por ejemplo, en la columna En validación, incluimos los estados "PDTE. VALIDAR" y "VALIDADA OCA"


Crea filtros rápidos para las subtareas y los errores técnicos

Inicia sprint en Trabajo pendiente. En nuestro ejemplo, iniciamos el Sprint 1



Al comenzar el SPRINT, podremos mover historias, subtareas y errores técnicos por las columnas



Cerrar Sprint activo

Los sprints se cierran manualmente sin restricción en la fecha dando la posibilidad de incorporar el trabajo no realizado a otros sprints creados.



Más información en https://www.atlassian.com/agile/tutorials/sprints



PL Incremento versión

Creación

Debe seleccionarse un proyecto con tipo de recurso Aplicación.

Se crean por los roles

R.PRODUCTO o PROVEEDOR  

en estado PDTE.REVISIÓN asignada a PROVEEDOR SISTEMAS

En el momento de la creación puedo decidir si la implantación es normal o bien es urgente.

Los campos que deben informarse son

Título *

Descripción*

Tipificación*:

  • Incremento versión

Tipo PL*: En este caso, queda informado como Normal sin ser ese campo editable.

PLU:

Sí

No (informado por defecto)


ID Versión relacionada*: campo nfeed en el que se muestren todas las versiones del aplicativo que estén en estado "EN RESOLUCIÓN". Este campo es obligatorio para las PLs de tipo normal y tipificación "Incremento versión". El tipo de enlace entre la Versión y la entidad PL CONTENEDOR será "Está relacionada con". El campo NFEED debe mostrar la key, el título y el código de la versión.


Debe añadirse como validación que es imposible poder seleccionar una versión que ya tenga una PL en estado distinto de CERRADA





Para PLU=NO

SVEs de la versión: campo en el que se muestran todas las SVEs relacionadas con esa versión en estado Cerrada y con resolución distinta a Cancelada. Sólo podrá seleccionarse una SVE

Entrega*: se informará de manera automática con la entrega de la SVE seleccionada. Este campo no se podrá rellenar manualmente

  • No se permite crear una PL con un mismo código de Entrega de SVE que otra, aparecerá el mensaje:
    Ya existe una PL en este proyecto con ese código de Entrega.

Resolución SVE: se informará con la resolución de la SVE seleccionada (Conforme, No conforme o No aplica):

  • No se permite crear una PL en el caso de resolución SVE = 'No se hará' (corresponde a la no conformidad compilación fallida en Jenkins)
  • SI Resolución SVE = 'No conforme'
    • Mostrar el valor del campo Motivo no aceptación SVE
    • Debe aparecer un mensaje de advertencia 

Añadir el motivo de no aceptación de la SVE

Seleccionar otra plataforma:

Sí

No

IDs Plataformas*: 

Si se ha indicado Sí en el campo anterior, aparecerán en el campo IDs plataformas todas las plataformas disponibles con campo multiselección.

Si se ha indicado No en el campo anterior, aparecerán en el campo sólo las plataformas en las que está desplegada la aplicación. 

IDs Entornos*: 

Aparecerán los entornos disponibles con campo multiselección.

Corte servicio*: (S/N) informada por defecto a No

Adjunto*: debe adjuntarse el PID

Se incluye un mensaje de advertencia para indicar que es necesario adjuntar el PID de forma obligatoria: "Debes adjuntar el PID".

¿Necesita soporte?*: (S/N) informada por defecto a No.




Para PLU=SÍ

Aparecen dos mensajes informativos:

'Se está indicando que la PL debe ejecutarse en el menor tiempo posible, no pudiendo asumirse el plazo de ejecución normal que es de entre 24 y 48 horas.

Ten en cuenta que la ejecución urgente de una PL incrementa los costes de gestión incurridos por este lanzamiento y supone un mayor riesgo de indisponibilidad del servicio'



Motivo urgencia*: Seleccionar uno de los motivos del desplegable:


      • Hay que solucionar una incidencia lo antes posible
      • Hay que instalar  lo antes posible para cumplir cronograma de implantación de la STIC
      • Hay que instalar  lo antes posible para cumplir necesidades impuestas por el SAS



Aparece un mensaje explicativo de que en la información adicional deben incluir el nombre y el teléfono del técnico:




Información adicional*: Campo en el que se deben incluir el nombre y el teléfono del técnico



SVEs de la versión: Aparecerán todas las SVEs aunque aún no estén cerradas pero no es obligatorio elegir una

Entrega*: Permite poner a mano la entrega si es que no se ha seleccionado ninguna SVE

IDs Plataformas*: Mostrar los plataformas y dejar seleccionar sólo una.
IDs Entornos*: Mostrar los entornos y dejar seleccionar sólo uno.


IMPORTANTE

Al crear una PLU:

  • Se crea automáticamente una PL hija en estado PDTE. CALENDARIZAR asignada a PROVEEDOR SISTEMAS para el entorno, plataforma y para todos los grupos lógicos.


PL Padre


Acciones en estado PDTE. REVISIÓN

Asignada a PROVEEDOR SISTEMAS


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

SOLICITAR INFORMACIÓN

Comentario obligatorio

PROVEEDOR SISTEMAS

PDTE. REVISIÓN a PDTE. INFORMACIÓN

N/A

ACEPTAR

PROVEEDOR SISTEMAS

PDTE. REVISIÓN a 

para PLU=NO

PDTE. REVISIÓN a EN RESOLUCIÓN para PLU=SÍ

N/A

NO ACEPTAR

Comentario obligatorio

PROVEEDOR SISTEMAS

PDTE. REVISIÓN a NO ACEPTADA

N/A

CANCELAR

Incluir comentario obligatorio

Libera la entrega y la SVE para la creación de una nueva entidad PL

R. PRODUCTO


PDTE. REVISIÓN a CERRADA

(Sin resolver) a (Cancelada)

EDITAR

Deben poder editarse todos los campos incluso el cambio a PLU, excepto la posibilidad de cambiar la tipificación y el tipo de la PL

R. PRODUCTO

PROVEEDOR

N/AN/A

SOLICITAR IMPLANTACIONES




PL hija urgente:

Sí

No (informado por defecto)

Si PLU hija urgente =SÍ


Aparece un mensaje en el que se indica que debe elegirse un entorno y plataforma únicos y que se creará una PL hija para el entorno y plataforma elegidos y para todos los grupos lógicos.

Entorno

Plataforma

Grupo lógico

Al ejecutar la acción SOLICITAR IMPLANTACIONES:

  • El campo Implantaciones solicitadas se informa a Sí y se reseteará una vez que se ejecute GENERAR EJECUCIONES.
  • Se resetean los campos "IDS entornos", "IDS plataformas" y "IDS grupos lógicos"

Si SOLICITAR IMPLANTACIONES se ejecuta en este estado y solicito PL HIJA urgente, se cambia el valor a PLU de la padre



El campo Restricción horaria debe permanecer visible en la entidad hasta que se ejecute GENERAR EJECUCIONES. En ese momento deja de mostrarse porque no estará informado.


Si marcamos PLU, se generará una PL hija para la plataforma y entorno seleccionado y para todos los grupos lógicos. La PL Hija se crea en estado PDTE. CALENDARIZAR

Se resetea en la padre PLU a SÍ si y solo si la padre está en estado PDTE. REVISIÓN porque el valor del campo determinará el umbral para el ANS. En cualquier otro estado, el campo de PLU para la padre se mantiene.

R. PRODUCTO

PROVEEDOR


N/A

N/A

Acciones en estado NO ACEPTADA

Asignada a Informador

ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

COMPLETAR INFORMACIÓN

Comentario obligatorio

Adjunto obligatorio

Mensaje: Debes adjuntar un nuevo PID

R.PRODUCTO

PROVEEDOR

NO ACEPTADA a PDTE. REVISIÓN

N/A

CANCELAR

Incluir comentario obligatorio

R. PRODUCTO

PROVEEDOR

NO ACEPTADAa CERRADA

(Sin resolver) a (Cancelada)

Acciones en estado 

Asignada a PROVEEDOR SISTEMAS


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

SOLICITAR INFORMACIÓN

Se informa un campo "Dudas tras proceso de revisión" a SÍ

PROVEEDOR SISTEMAS

a PDTE. INFORMACIÓN

N/A

CANCELAR

Incluir comentario obligatorio

R. PRODUCTO

PROVEEDOR

PLANIFICABLE a CERRADA

(Sin resolver) a (Cancelada)

SOLICITAR IMPLANTACIONES

Las restricciones son las mismas que al solicitar implantaciones en el estado PDTE. REVISIÓN con la salvedad de:

NO SE RESETEA EL CAMPO PLU DE LA PADRE


R. PRODUCTO

PROVEEDOR

N/A si PLU=NO

PLANIFICABLE a EN RESOLUCIÓN si PLU=SÍ

N/A

GENERAR EJECUCIONES

acción ASIGNAR A MÍ en los usuarios integrantes del grupo planificador.


Campos que tienen que informarse:

Agrupación Plataformas: campo nfeed informado por Servicios CGES.

Plataformas*: campo informado con el valor que se puso en la creación. Puede modificarse o bien eliminarse su valor.

Entornos*: Campo con los entornos.

Grupos Lógicos :  aquí hay que indicar si los grupos separados por comas corresponden cada uno a una ejecución. Existe la posibilidad de concatenar grupos y que sea una ejecución por grupo concatenado. 

Se generará una subtarea de ejecución por cada agrupación de plataformas (o plataforma), entorno y grupo lógico (simple o concatenado). 

Subtareas creadas por usuarios pertenecientes al GRUPO PLANIFICADOR en estado  PLANIFICABLE  asignada a PROVEEDOR SISTEMAS


Aparecerá mensaje indicándose si se quiere crear una PL Hija por entorno, plataforma y para todos los grupos lógicos o si se quiere crear una PL Hija por cada grupo lógico.

GRUPO PLANIFICADOR

PLANIFICABLE a EN RESOLUCIÓN

N/A


Acciones en estado EN RESOLUCIÓN

Asignada a  PROVEEDOR SISTEMAS  


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

SOLICITAR INFORMACIÓN

Se informa un campo "Dudas con documentación aprobada" a SÍ si no estuviera informado. Si ya estuviera informado a SÍ, se mantiene el valor.

PROVEEDOR SISTEMAS

EN RESOLUCIÓN a PDTE. INFORMACIÓN

N/A

CANCELAR

Incluir comentario obligatorio

Si tiene PLs hijas, deben estar todas cerradas y con resolución cancelada

R. PRODUCTO

PROVEEDOR

EN RESOLUCIÓNa CERRADA

(Sin resolver) a (Cancelada)

SOLICITAR IMPLANTACIONES

IDEM a en estado PLANIFICABLE


R. PRODUCTO

PROVEEDOR

N/A

N/A

GENERAR EJECUCIONES


GRUPO PLANIFICADOR

N/A

N/A

FINALIZAR

Todas las Pls hijas deben estar cerradas

R. PRODUCTO

PROVEEDOR

EN RESOLUCIÓN a CERRADA

(Sin resolver) a (Cerrada)

Acciones en estado PDTE. INFORMACIÓN

Asignada al informador  R. PRODUCTO  PROVEEDOR

ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

COMPLETAR INFORMACIÓN

R. PRODUCTO

PROVEEDOR

PDTE. INFORMACIÓN a ESTADO ORIGEN

N/A

CANCELAR

Incluir comentario obligatorio

Si tiene PLs hijas, deben estar todas cerradas y con resolución cancelada

R. PRODUCTO

PROVEEDOR

EN RESOLUCIÓN a CERRADA

(Sin resolver) a (Cancelada)

PL Hija

Las PLS hijas se crearán con título : {Plataforma} - {Entorno} - {Grupos lógicos}. 

Debe estar visible el campo que identifique si es o no PLU


No podrán existir dos entidades "PL hija" con el mismo valor para los campos "IDS entornos", "IDS plataformas" y "IDS grupos lógicos", para un mismo padre (PL). Sólo será posible si la primera se ha cancelado.

Si PL hija urgente=SÍ, la PL hija queda en estado PDTE. CALENDARIZAR y cuando el PROVEEDOR SISTEMAS pone fechas, pasa directamente al estado PDTE. COMENZRA RESOLUCIÓN

En las PLs hijas debe siempre estar visible si son o no PL hija urgente

Desde la PL padre deben verse las PL hijas identificando de manera visual si son o no PL hija urgente o no


El ciclo completo de la PL hija se da únicamente en el caso de la primera vuelta, correspondiente a la actividad de instalación.

Para cualquier otra vuelta, que siempre supone una NO aceptación de la solución técnica por parte del solicitante, el flujo comienza en el estado PDTE. CALENDARIZAR y de ahí pasa a PDTE. COMENZAR RESOLUCIÓN. El solicitante debe escribir en un comentario las fechas que desea tenga esa nueva actividad.


Acciones en estado PLANIFICABLE

ACTIVIDAD=INSTALACIÓN

Asignada  GRUPO PLANIFICADOR cuyos integrantes podrán asignarse la entidad

ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

EDITAR

Podrá convertirse en PL hija urgente(1). indicar motivo y campo de información adicional

Podrán cambiarse los grupos lógicos(2)

RESPONSABLE PRODUCTO(1)

PROVEEDOR(1)

PROVEEDOR SISTEMAS(2)

GRUPO PLANIFICADOR(2)

PLANIFICABLE a PDTE. CALENDARIZAR si PL hija urgente=Sí

N/A en el resto de los casos


SOLICITAR PLANIFICACIÓN

Debe indicarse fecha de inicio deseada

GRUPO PLANIFICADOR

PLANIFICABLE a PDTE. CALENDARIZAR


N/A

CANCELAR

Incluir comentario obligatorio

R.PRODUCTO

PROVEEDOR

GRUPO PLANIFICADOR

PLANIFICABLE a CERRADA

(Sin resolver) a (Cancelada)

SOLICITAR REVISIÓN

Indicar en comentario lo que se quiere cambiar. Comentario obligatorio.

Informar el campo Pdte. revisión STIC a SÍ


GRUPO PLANIFICADOR

PROVEEDOR SISTEMAS

N/A

EDITAR EJECUCIONES

Modificar en el tablegrid lo que sea necesario y cambiar el campo Pdte. revisión STIC a NO.

Recalcular las HBS incurridas

GRUPO PLANIFICADOR

N/A

Acciones en estado PDTE. CALENDARIZAR

ACTIVIDAD=TODAS

Asignada a PROVEEDOR SISTEMAS


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

EDITAR

Podrá convertirse en PL hija urgente(1). indicar motivo y campo de información adicional

Podrán cambiarse los grupos lógicos(2)


RESPONSABLE PRODUCTO(1)

PROVEEDOR(1)

PROVEEDOR SISTEMAS(2)

GRUPO LANZAMIENTO(2)

N/A

N/A

CALENDARIZAR (**)


PROVEEDOR SISTEMAS

GRUPO PLANIFICADOR

PDTE. CALENDARIZARa CALENDARIZADASI ACTIVIDAD=INSTALACIÓN Ó

PLU=NO

PDTE. CALENDARIZAR a PDTE. COMENZAR RESOLUCIÓN SI ACTIVIDAD no es INSTALACIÓN Ó PLU=SÍ

N/A

CANCELAR

Incluir comentario obligatorio

R. PRODUCTO

GRUPO PLANIFICADOR

PDTE. CALENDARIZAR a CERRADA

(Sin resolver) a (Cancelada)

SOLICITAR REVISIÓN

Indicar en comentario lo que se quiere cambiar. Comentario obligatorio.

Informar el campo Pdte. revisión STIC a SÍ

PROVEEDOR SISTEMAS

GRUPO PLANIFICADOR

N/A

EDITAR EJECUCIONES

Modificar en el tablegrid lo que sea necesario y cambiar el campo Pdte. revisión STIC a NO.

Recalcular las HBS incurridas

GRUPO PLANIFICADOR

N/A

(**)

Campos que deben informarse o estarán informados al CALENDARIZAR:

Actividad*(se informa automáticamente):  posibles valores Instalación, Desinstalación y Marcha Atrás (conlleva una reinstalación, que se informará automáticamente en el campo Actividad al aceptar la marcha atrás). Para la primera vez que se haga la ejecución, estará informado "Instalación". Posteriormente dependerá de lo que informe el solicitante cuando no acepte la solución técnica o si la acepta siendo la actividad una marcha atrás.

Facturable*:

ACTIVIDAD= INSTALACIÓN, el campo estará informado a Sí 

ACTIVIDAD= MARCHA ATRÁS, el campo estará informado a No 

ACTIVIDAD= REINSTALACIÓN, el campo estará informado a No

 ACTIVIDAD= DESINSTALACIÓN, el campo estará informado a Sí 


Complejidad*: (Sí/No) por defecto informado a NO hasta que no solicite CTI 


En cada ejecución, se reseteará el valor del campo PLU a NO


Acciones en estado 

ACTIVIDAD= INSTALACIÓN

Asignada a GRUPO PLANIFICADOR 


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

EDITAR

Podrá convertirse en PL hija urgente(1). indicar motivo y campo de información adicional


Podrán cambiarse los grupos lógicos(2)


RESPONSABLE PRODUCTO(1)

PROVEEDOR(1)

PROVEEDOR SISTEMAS(2)

GRUPO LANZAMIENTO(2)

CALENDARIZADA a PDTE. COMENZAR RESOLUCIÓN si (1)

N/A si (2)

N/A

APROBAR FECHAS

Si la PL está enlazada con otra porque tenga dependencia, debería aparecer un mensaje de advertencia

GRUPO PLANIFICADOR

CALENDARIZADA a PDTE. COMENZAR RESOLUCIÓN

N/A

NO APROBAR FECHAS

(Incluir motivo obligatorio)

GRUPO PLANIFICADOR

CALENDARIZADA a PDTE. CALENDARIZAR

N/A

CANCELAR

Incluir comentario obligatorio

R. PRODUCTO

PROVEEDOR

GRUPO PLANIFICADOR

CALENDARIZADA  a CERRADA

(Sin resolver) a (Cancelada)

SOLICITAR REVISIÓN

Indicar en comentario lo que se quiere cambiar. Comentario obligatorio.

Informar el campo Pdte. revisión STIC a SÍ

PROVEEDOR SISTEMAS

GRUPO PLANIFICADOR

N/A

EDITAR EJECUCIONES

Modificar en el tablegrid lo que sea necesario y cambiar el campo Pdte. revisión STIC a NO

Recalcular las HBS incurridas

GRUPO PLANIFICADOR

N/A

Acciones en estado  PDTE. COMENZAR RESOLUCIÓN

Asignada a  PROVEEDOR SISTEMAS


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

EDITAR

Podrá convertirse en PL hija urgente(1). indicar motivo y campo de información adicional


Podrán cambiarse los grupos lógicos(2)

Podrán cambiarse las fechas, si y sólo si no se haya llegado a la fecha de inicio estimada (3)


R. PRODUCTO (1)

PROVEEDOR (1)

PROVEEDOR SISteMAS (2) (3)


GRUPO PLANIFICADOR(2)(3)

N/A

N/A

COMENZAR RESOLUCIÓN

Para cada actividad informar "Fecha inicio real" para cargar en la tabla de ejecuciones

PROVEEDOR SISteMAS

GRUPO PLANIFICADOR

PDTE. COMENZAR RESOLUCIÓN a EN RESOLUCIÓN

N/A

CANCELAR

Incluir comentario obligatorio

R. PRODUCTO

GRUPO PLANIFICADOR

PDTE. COMENZAR RESOLUCIÓN a CERRADA

(Sin resolver) a (Cancelada)

SOLICITAR REVISIÓN

Indicar en comentario lo que se quiere cambiar. Comentario obligatorio.

Informar el campo Pdte. revisión STIC a SÍ

PROVEEDOR SISteMAS

GRUPO PLANIFICADOR

N/A

EDITAR EJECUCIONES

Modificar en el tablegrid lo que sea necesario y cambiar el campo Pdte. revisión STIC a NO

Recalcular las HBS incurridas

GRUPO PLANIFICADOR

N/A


Acciones en estado  EN RESOLUCIÓN

Asignada a  PROVEEDOR SISTEMAS


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

RESOLVER

Informar campo "Errores detectados" Sí/No. El campo no está informado hasta ese momento.

Describir los errores detectados en un campo Comentario obligatorio.


PROVEEDOR SISteMAS

EN RESOLUCIÓN  a  PDTE.REVISIÓN TÉCNICA

N/A

SOLICITAR REVISIÓN

Indicar en comentario lo que se quiere cambiar. Comentario obligatorio.

Informar el campo Pdte. revisión STIC a SÍ

PROVEEDOR SISteMAS

GRUPO PLANIFICADOR

N/A

EDITAR EJECUCIONES

Modificar en el tablegrid lo que sea necesario y cambiar el campo Pdte. revisión STIC a NO

Recalcular las HBS incurridas

GRUPO PLANIFICADOR

N/A


Acciones en estado  PDTE. REVISIÓN TÉCNICA

Asignada a solicitante (R.PRODUCTO , PROVEEDOR) de la PL padre


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

ACEPTAR SOLUCIÓN TÉCNICA

Si está informado el campo "Errores detectados", el solicitante deberá justificar el motivo por el que acepta la solución a pesar de los errores detectados en el despliegue. Se hace en campo comentario


R.PRODUCTO

PROVEEDOR

a  

(Sin resolver) a (Cerrada)

NO ACEPTAR SOLUCIÓN TÉCNICA*

(Informar obligatoriamente el campo "MOTIVO NO ACEPTACIÓN"

y el campo ACTIVIDAD)

R.PRODUCTO

PROVEEDOR

PDTE.REVISIÓN TÉCNICA a PDTE. CALENDARIZAR


N/A

SOLICITAR REVISIÓN

Indicar en comentario lo que se quiere cambiar. Comentario obligatorio.

Informar el campo Pdte. revisión STIC a SÍ

PROVEEDOR SISteMAS

GRUPO PLANIFICADOR

N/A

EDITAR EJECUCIONES

Modificar en el tablegrid lo que sea necesario y cambiar el campo Pdte. revisión STIC a NO

Recalcular las HBS incurridas

GRUPO PLANIFICADOR

N/A


*Cuando se accede a No aceptar solución técnica, deben mostrarse una serie de preguntas al solicitante


  • ¿Quieres reinstalación?

    • No. 
      • ¿Quieres desinstalar?
        • Sí
          • Indicar en comentario la fecha en la que el peticionario desea que se haga la desinstalación
          • Pasa a PDTE. CALENDARIZAR y se informa como Actividad "Desinstalación"
        • No. 
          • Pasa a CERRADA con Resolución "Anulada por defecto de Software"
    • Sí
      • ¿Quieres marcha atrás?
        • Sí
          • Indicar en comentario la fecha en la que el peticionario desea que se haga la MARCHA ATRÁS
          • Pasa a PDTE. CALENDARIZAR y se informa como Actividad "Marcha Atrás". Al aceptar la solución técnica debe ir de nuevo al principio con Actividad "Reinstalación"
        • No
          • Pasa a PDTE. CALENDARIZAR y se informa como Actividad "Reinstalación"






Control facturación

Cada ejecución se registra en una fila de un table grid


Los datos que se muestran en la tabla son:

  • Tipo actividad
  • PLU (sí o no)
  • Compleja (informado siempre a NO)
  • Facturable: vendrá informado por el tipo de actividad
  • Fecha de inicio real
  • Fecha de inicio estimada : marca la hora para saber si la facturación corresponde a horario normal o extendido.
  • Fecha resolución: corresponde al campo "Fecha resolución proveedor" de cada ejecución (paso del estado EN RESOLUCIÓN a PDTE. REVISIÓN TÉCNICA)

La factura se conforma con los datos del table grid el día 11 de cada mes. Cualquier modificación de una ejecución hecha después del día 10, no se tendrá en cuenta en la facturación



RFP (Request For Platform)

Común a todas las entidades

  • Existen una serie de acciones comunes a todas las entidades:
    • COMENTAR
    • ADJUNTAR ARCHIVOS
    • ENLAZAR
    • ETIQUETAR

  • Los usuarios necesarios en un proyecto son:
    • Responsable de Área
    • Responsable de producto
    • Responsable funcional
    • Responsable de sistemas
    • Proveedor

Estos usuarios aunque aparezcan como asignados de las entidades pertenecen a roles definidos:

  • COORDINADOR→Puede hacer todo lo que hace el rol JP-STIC además de ciertas acciones específicas que se detallan
  • JP-STIC→ A este rol pertenecen los usuarios Responsable de producto y Responsable de sistemas.
Todos los usuarios con este rol pueden hacer las mismas acciones independientemente de la entidad y de la aplicación


  • FUNCIONAL→ A este rol pertenecen los usuarios Responsable funcional
  • COLABORADOR–>Este rol se usa para ususarios que sólo pueden hacer las acciones comunes pero ninguna acción específica.



¿Cómo puedes usar esta guía rápida?


  • Para cada una de los tipos de entidades de JIRA se detallan las acciones que pueden ejecutarse en cada uno de sus estados indicando:
    • Usuarios que pueden ejecutarla.
    • Si procede, cambio de estado de la entidad.
    • Si procede, cambio de resolución de la entidad.



Incidencia

Las incidencias que llegan a JIRA suponen fallos en el software que hay actualmente en Producción y que se registran desde MiCS (Mi Centro Servicio) o desde NWT (Nueva Web Técnica).  Pueden por tanto tener su origen en incidencias de usuarios finales o en la resolución de un problema que debe ser acometida por el Proveedor del producto.

En cualquier caso son resueltas por el Proveedor en NWT y sólo llegan a JIRA si su corrección implica implantación y modificación de la línea base del producto. Por tanto, llegan a JIRA corregidas y a la espera de ser implantadas en Producción en la versión que el Responsable de Producto o el Proveedor consideren oportunas. Se crean informando la fecha de registro en NWT, el usuario afectado, el código de solicitud y la prioridad.

Una vez que la versión se implante (cierre de la RFC en FARO), significará que las incidencias están en Producción y se cerrarán en JIRA, lo que supondrá que acabarán su ciclo de vida también en NWT, comunicando al usuario afectado la resolución del fallo detectado.


Si la prioridad de la incidencia es P1 y en NWT el Proveedor indica que se requiere Versión de Emergencia, se generará una entidad de este tipo en la que quedará automáticamente incluida la incidencia.


Si la incidencia llega a JIRA por error o con datos incorrectos, existe la posibilidad de escalarla a NWT.


Creación

    • Por integración. Se crean en estado  asignadas a  tanto si su origen es la gestión de problemas como si es la gestión de incidencias.


Acciones en estado 

ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

ESCALAR

 a 


(Sin resolver) a (Cancelada)
ASIGNAR A VERSIÓN

 a 

N/A
CLONAR (en cualquier aplicación)

N/AN/A


Acciones en estado 

ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

DESASIGNAR DE VERSIÓN

 a 


N/A
ASIGNAR OT

N/A

N/A
CLONAR (en versiones de la misma aplicación)

N/AN/A
VALIDAR

N/AN/A
EDITAR

N/AN/A
CIERRE RFC

 a 

(Sin resolver) a (Cerrada)
  •  

Mejora

Una mejora es cualquier petición de evolución de una aplicación. Puede ser registrada por cualquier usuario en MiCS (Mi Centro Servicios). Su origen puede ser esa petición de un usuario final o bien la respuesta a la solución de un problema que hace el Responsable de Producto. Pueden ser registradas directamente en JIRA por los usuarios logados en la herramienta.

La mejoras son analizadas por los Responsables Funcionales para determinar su viabilidad, y, si la tienen, establecer la urgencia con la que deben ser incluidas en una versión.

Cuando se aprueba una mejora por ser considerada viable, se informa al usuario que la registró cerrando la solicitud en el caso de registro en MiCS.

Una vez incluidas en una versión podrán asignarse a las OTs incluidas en esa versión para ser desarrolladas por el Proveedor correspondiente.

Una vez implantada la versión (RFC cerrada en FARO o versión finalizada si no se genera RFC) las mejoras se cerrarán en JIRA lo que significará que están implantadas en Producción.


Creación

  • Por integración. 
    • Se crean en estado asignadas a para origen gestión de proyectos.
    • Se crean en estado asignadas a  para origen gestión de problemas.
  • Directamente en JIRA en estado  asignadas a por usuarios de la aplicación. 


Acciones en estado 


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

APROBAR MEJORA

 a 


N/A
NO APROBAR MEJORA

 a 

  • Rechazo: (Sin resolver) a (Rechazada)
  • Escalado: (Sin resolver) a (Escalada)
CLONAR (en cualquier aplicación)


N/AN/A
ESCALAR (Sólo para mejoras creadas por integración y que no han cambiado de estado)

N/A(Sin resolver) a (Escalada)




Acciones en estado 

ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

A WISHLIST 

 a  

N/A
ASIGNAR VERSIÓN

 a 

N/A

CLONAR (en cualquier aplicación)

N/AN/A
ESCALAR (Sólo para mejoras creadas por integración y que no han cambiado de estado)

N/A(Sin resolver) a (Escalada)




Acciones en estado  


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

DESASIGNAR DE VERSIÓN

a

N/A
ASIGNAR OT

N/A

N/A
CLONAR (en versiones de la misma aplicación)

N/AN/A
VALIDAR

N/AN/A
EDITAR

N/AN/A
CIERRE RFC

a

(Sin resolver) a (Cerrada)

No conformidad



Versión

Una versión es un contenedor de mejoras e incidencias, es decir, tiene un alcance y un presupuesto determinados a partir de la que se lanzan trabajos para el proveedor  (órdenes de trabajo). Existe la posibilidad de que sea necesario un estudio de viabilidad del de la versión antes de comenzar a trabajar para que el Jefe de Proyecto decida una alternativa en el caso de que haya más de una y la reserva correspondiente de HBS.

Por cada uno de los meses de duración de la versión se creará una subtarea de Previsión en la que se podrán estimar las HBS previstas y donde se irán incurriendo las HBS que el proveedor registre en ese mes en las órdenes de trabajo asociadas a la versión.

Existe la posibilidad de modificar el alcance incluyendo o excluyendo mejoras o incidencias. 

Si la implantación de la versión necesita la intervención del Proveedor de Sistemas, será necesario generar una RFC en FARO, donde el Proveedor generará PLs que transicionarán implantando el software en o en los entornos que se determinen y que terminarán cerrando la RFC. En ese momento, las mejoras e incidencias incluidas en la versión pasará a estado Cerrada, considerando que su implantación en el entorno de Producción está finalizada.

Durante este proceso será posible crear órdenes de trabajo y asociarlas a la versión. Como ya hemos comentado, las HBS incurridas en un mes determinado se irán sumando a las HBS incurridas de la subtarea de previsión correspondiente a ese mes (excepto para las órdenes de trabajo de tipo PST).

Creación 

Se crean en estado asignadas a  por 


Acciones en estado 


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

GESTIONAR ALCANCE (incluir/excluir mejoras, incidencias o No conformidades en estado de esa aplicación)

N/A

N/A

COMENZAR (imprescindible que al menos haya una mejora o incidencia en la versión)

  • Si la versión está aprobada por --> 
  • Si la versión no está aprobada por --> 

a

a

N/A
CANCELAR

a

(Sin resolver) a (Cancelada)



Acciones en estado 


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

COMENZAR

a

N/A

CANCELAR

a

(Sin resolver) a (Cancelada)


Acciones en estado 


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

GESTIONAR ALCANCE

N/A

N/A

GENERAR RFC




a

N/A
CANCELAR



  • GESTIONAR ALCANCE  R. PRODUCTO
  • GENERAR RFC R. PRODUCTO→Obligatorio tener el código de la versión
    EN RESOLUCIÓN-->EN RESOLUCIÓN CON RFC ABERTA
  • FINALIZAR R. PRODUCTO→Obligatorio tener el código de la versión y todas las OTs asociadas cerradas

EN RESOLUCIÓN--->CERRADA (Resolución Cerrada)

  • CANCELAR R. PRODUCTO-->Obligatorio tener  todas las OTs asociadas cerradas

EN RESOLUCIÓN--->CERRADA (Resolución Cancelada)


Acciones en estado EN RESOLUCIÓN CON RFC ABIERTA

  • GESTIONAR ALCANCE  R. PRODUCTO
  • CANCELAR R. PRODUCTO-->Obligatorio tener  todas las OTs asociadas cerradas

EN RESOLUCIÓN--->CERRADA (Resolución Cancelada)

  • CIERRE RFC PROCESO AUTOMATIZADO →(Mejoras, incidencias y No conformidades incluidas en la versión se cierran)EN RESOLUCIÓN--->EN RESOLUCIÓN CON RFC CERRADA



Acciones en estado EN RESOLUCIÓN CON RFC CERRADA

  • FINALIZAR R. PRODUCTO→Obligatorio tener todas las OTs asociadas cerradas

EN RESOLUCIÓN CON RFC CERRADA--->CERRADA (Resolución Cerrada)



OT con crédito disponible


Creación

Si no es de tipo PST ni de tipo EVS la crea  asignada a  en estado 

    • Si es de tipo EVS la crea :
      • Si el EVS está aprobado por el Responsable de Área →  asignada a  en estado 
      • Si el EVS no está aprobado por el Responsable de Área → asignada a  en estado 
    • Si es  de tipo PST la crea  asignada a  en estado 


Acciones en estado 


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

APROBAR

  a


N/A
NO APROBAR

 a 

(Sin resolver) a (No Aprobada RA)

Acciones en estado 



ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

CALENDARIZAR
  • Si no es de tipo PST
  • Si es PST

 a


N/A
CANCELAR

 a 

(Sin resolver) a (Cancelada)


Acciones en estado 


  •  


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

COMENZAR RESOLUCIÓN
  • Si no es de tipo PST
  • Si es PST

 a


N/A
CANCELAR

 a 

(Sin resolver) a (Cancelada)




Acciones en estado 


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

REGISTRAR HBS
  • Si no es de tipo PST
  • Si es PST

N/A

N/A
SEGUIMIENTO
  • Si no es de tipo PST
  • Si es PST

N/A

N/A
RESOLVER
  • Si no es de tipo PST
  • Si es PST
  • Si no es de tipo PST:
    • Si la OT es revisada por la OCA a
    • Si la OT no es revisada por la OCA a
  • Si es PST a
N/A
CANCELAR

a

N/A


Acciones en estado 


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

INFORMAR REVISIÓN OCA

a

N/A


Acciones en estado 


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

REGISTRAR HBS
  • Si no es de tipo PST
  • Si es PST

N/A

N/A
LIQUIDAR OT
  • Si no es de tipo PST
  • Si es PST

a

N/A


Acciones en estado 


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

ACEPTAR RESOLUCIÓN

a

(Sin resolver) a (Resuelta)
NO ACEPTAR RESOLUCIÓN

a

N/A

Si es de tipo EVS:

EDITAR (Informar campos Alternativa y Reserva HBS)

N/AN/A

Acciones en estado

ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

ACEPTAR RESOLUCIÓN

a

(Sin resolver) a (Resuelta)
NO ACEPTAR RESOLUCIÓN

a

N/A


Acciones en estado 


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

ACEPTAR CANCELACIÓN

a

(Sin resolver) a (Cancelada)
NO ACEPTAR CANCELACIÓN

a

N/A


Acciones en estado 


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

REGISTRAR HBS

N/AN/A

RESOLVER

a

N/A


Acciones en estado 


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

    • Rechazo sólo por motivos técnicos:
      RESOLVER

a

N/A
    • Rechazo por costes:
      REGISTRAR HBS

N/AN/A
    • Rechazo por costes:
      RESOLVER

a

N/A

OT con estimación

Creación

La crea R. PRODUCTOPROVEEDOR asignada a PROVEEDOR en estado PDTE. ESTIMAR

Acciones en estado PDTE. ESTIMAR


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

ESTIMAR

PROVEEDOR

 PDTE. estimAR a estimada


N/A
CANCELAR

y si es el informador

PDTE. estimAR a CERRADA

(Sin resolver) a (Cancelada)

Acciones en estado ESTIMADA 


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

APROBAR ESTIMACIÓN

R. PRODUCTO

 ESTIMADA a PDTE. COMENZAR RESOLUCIÓN


N/A
NO APROBAR ESTIMACIÓN

ESTIMADA a PDTE. ESTIMAR

N/A



A partir del estado PDTE. COMENZAR RESOLUCIÓN continúa igual que una OT con crédito disponible. 


Historias de usuario

Una historia de usuario es una entidad que se usa en los proyectos que se gestionan con metodología ágil para "descomponer las mejoras" y asociar tareas que se asignan a los integrantes del equipo. Esta gestión puede hacerse con la posibilidad que tiene la herramienta de uso de pizarras SCRUM que permiten la gestión de sprints en el que se incluyen estas historias que pueden a su vez descomponerse en subtareas y errores técnicos.

Creación

    •  Se crean en el mismo estado en el que esté la mejora origen, que puede ser  o  por los roles  y . Una Historia de Usuario sólo puede estar relacionada con una mejora.


Acciones en estado 

ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

EN VERSIÓN

La mejora origen debe haberse previamente asignado a una versión

 a 

N/A

CREAR SUBTAREA


N/A

N/A
EDITAR


N/A

N/A


Acciones en estado 

Es recomendable crear una pizarra SCRUM para organizar las historias de usuario en sprints y activar aquel en el que se vaya a trabajar. 

La configuración de las pizarras es independiente de los flujos de las historias de usuario y de subtareas y errores técnicos.

Puedes gestionar historias, subtareas y errores técnicos sin haber configurado la pizarra.


Ver "Configuración pizarras SCRUM"


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

CREAR SUBTAREA

N/AN/A
CREAR ERROR

N/AN/A
EDITAR

N/AN/A
RESOLVER (se pretende automatizar esta acción una vez que todas las subtareas y errores estén cerradas) (por ahora deberá hacerse por procedimiento, no acceder a ella hasta que las subtareas no estén cerradas)

a

N/A


Acciones en estado 

ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

EDITAR

N/AN/A
VALIDAR OCA

a


NO VALIDAR OCA

a

(Sin Resolver) a (Rechazada)
VALIDAR

a Si valida la OCA

a Si no valida la OCA

(Sin Resolver) a (Aceptada)
NO VALIDAR

a

(Sin Resolver) a (Rechazada)


Acciones en estado 


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

EDITAR

N/AN/A
CREAR ERRORES

N/AN/A
RESOLVER

a

N/A






Subtarea 


Creación

  • Se crean a como entidades de tipo subtarea a partir de una Historia de usuario que esté en estado   o en . Se crean en estado  por ,  


Acciones en estado 

ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

COMENZAR

(Obligatorio asignar la tarea a un integrante del equipo)

 a 

N/A
CANCELAR

a

(Sin Resolver) a (Cancelada)
EDITAR

N/AN/A


Acciones en estado 

ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

PARALIZAR

 a 

N/A
CANCELAR

a

(Sin Resolver) a (Cancelada)
RESOLVER

a

(Sin Resolver) a (Cerrada)
EDITAR

N/AN/A
REGISTRAR HBS

N/AN/A


Acciones en estado 

ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

REANUDAR

a

N/A
CANCELAR

a

(Sin Resolver) a (Cancelada)
EDITAR

N/AN/A



Acciones en estado 

ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

REABRIR

(Comentario Obligatorio)

a

N/A
EDITAR

N/AN/A


Error técnico


Creación

  • Se crean a como entidades de tipo subtarea a partir de una Historia de usuario que esté en estado  o posterior. Se crean en estado  por ,    


Acciones en estado 

ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

COMENZAR

(Obligatorio asignar la tarea a un integrante del equipo)

 a 

N/A
CANCELAR

a

(Sin Resolver) a (Cancelada)
EDITAR

N/AN/A


Acciones en estado 

ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

PARALIZAR

 a 

N/A
CANCELAR

a

(Sin Resolver) a (Cancelada)
RESOLVER

a

(Sin Resolver) a (Cerrada)
EDITAR

N/AN/A
REGISTRAR HBS

N/AN/A


Acciones en estado 

ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

REANUDAR

a

N/A
CANCELAR

a

(Sin Resolver) a (Cancelada)
EDITAR

N/AN/A


Acciones en estado 

ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

REABRIR

(Comentario Obligatorio)

a

N/A
EDITAR

N/AN/A



Configuración pizarras SCRUM


Crear pizarra

Accede a la creación de pizarras y crea una pizarra de tipo SCRUM de un proyecto existente. Vamos a tomar como ejemplo el proyecto de Admisión Única (AU)









Configurar el filtro de la pizarra

Accede a la configuración de la pizarra y a partir de ahí a la posibilidad de modificar el filtro (Editar consulta de filtro), ya que el filtro muestra todas las entidades del proyecto.


Selecciona la entidad "Historia de usuario" y las subtareas de tipo Subtarea y Error técnico en el filtro y guárdalo

Crear sprints

Accede de nuevo a la pizarra SCRUM que has creado y procede a crear los sprints que quieras para organizar en ellos las historias de usuario.

Configurar SPRINTS ACTIVOS

Configura las columnas. En este ejemplo hemos configurado las columnas ABIERTA, EN RESOLUCIÓN, PROCESO VALIDACIÓN. PARALIZADA Y CERRADA.

Entra en la configuración de la pizarra y en la columna de la izquierda accede a Columnas. Puedes añadir, eliminar o cambiar el nombre de las que aparecen por defecto




Crea las que te van a aportar más para mover de una columna a otra las historias y, sobre todo, las subtareas y los errores técnicos

Incluye dentro de cada columna los estados que consideras deben estar en cada una de ellas. Por ejemplo, en la columna En validación, incluimos los estados "PDTE. VALIDAR" y "VALIDADA OCA"


Crea filtros rápidos para las subtareas y los errores técnicos

Inicia sprint en Trabajo pendiente. En nuestro ejemplo, iniciamos el Sprint 1



Al comenzar el SPRINT, podremos mover historias, subtareas y errores técnicos por las columnas



Cerrar Sprint activo

Los sprints se cierran manualmente sin restricción en la fecha dando la posibilidad de incorporar el trabajo no realizado a otros sprints creados.



Más información en https://www.atlassian.com/agile/tutorials/sprints



PL Incremento versión

Creación

Debe seleccionarse un proyecto con tipo de recurso Aplicación.

Se crean por los roles

R.PRODUCTO o PROVEEDOR  

en estado PDTE.REVISIÓN asignada a PROVEEDOR SISTEMAS

En el momento de la creación puedo decidir si la implantación es normal o bien es urgente.

Los campos que deben informarse son

Título *

Descripción*

Tipificación*:

  • Incremento versión

Tipo PL*: En este caso, queda informado como Normal sin ser ese campo editable.

PLU:

Sí

No (informado por defecto)


ID Versión relacionada*: campo nfeed en el que se muestren todas las versiones del aplicativo que estén en estado "EN RESOLUCIÓN". Este campo es obligatorio para las PLs de tipo normal y tipificación "Incremento versión". El tipo de enlace entre la Versión y la entidad PL CONTENEDOR será "Está relacionada con". El campo NFEED debe mostrar la key, el título y el código de la versión.


Debe añadirse como validación que es imposible poder seleccionar una versión que ya tenga una PL en estado distinto de CERRADA





Para PLU=NO

SVEs de la versión: campo en el que se muestran todas las SVEs relacionadas con esa versión en estado Cerrada y con resolución distinta a Cancelada. Sólo podrá seleccionarse una SVE

Entrega*: se informará de manera automática con la entrega de la SVE seleccionada. Este campo no se podrá rellenar manualmente

  • No se permite crear una PL con un mismo código de Entrega de SVE que otra, aparecerá el mensaje:
    Ya existe una PL en este proyecto con ese código de Entrega.

Resolución SVE: se informará con la resolución de la SVE seleccionada (Conforme, No conforme o No aplica):

  • No se permite crear una PL en el caso de resolución SVE = 'No se hará' (corresponde a la no conformidad compilación fallida en Jenkins)
  • SI Resolución SVE = 'No conforme'
    • Mostrar el valor del campo Motivo no aceptación SVE
    • Debe aparecer un mensaje de advertencia 

Añadir el motivo de no aceptación de la SVE

Seleccionar otra plataforma:

Sí

No

IDs Plataformas*: 

Si se ha indicado Sí en el campo anterior, aparecerán en el campo IDs plataformas todas las plataformas disponibles con campo multiselección.

Si se ha indicado No en el campo anterior, aparecerán en el campo sólo las plataformas en las que está desplegada la aplicación. 

IDs Entornos*: 

Aparecerán los entornos disponibles con campo multiselección.

Corte servicio*: (S/N) informada por defecto a No

Adjunto*: debe adjuntarse el PID

Se incluye un mensaje de advertencia para indicar que es necesario adjuntar el PID de forma obligatoria: "Debes adjuntar el PID".

¿Necesita soporte?*: (S/N) informada por defecto a No.




Para PLU=SÍ

Aparecen dos mensajes informativos:

'Se está indicando que la PL debe ejecutarse en el menor tiempo posible, no pudiendo asumirse el plazo de ejecución normal que es de entre 24 y 48 horas.

Ten en cuenta que la ejecución urgente de una PL incrementa los costes de gestión incurridos por este lanzamiento y supone un mayor riesgo de indisponibilidad del servicio'



Motivo urgencia*: Seleccionar uno de los motivos del desplegable:


      • Hay que solucionar una incidencia lo antes posible
      • Hay que instalar  lo antes posible para cumplir cronograma de implantación de la STIC
      • Hay que instalar  lo antes posible para cumplir necesidades impuestas por el SAS



Aparece un mensaje explicativo de que en la información adicional deben incluir el nombre y el teléfono del técnico:




Información adicional*: Campo en el que se deben incluir el nombre y el teléfono del técnico



SVEs de la versión: Aparecerán todas las SVEs aunque aún no estén cerradas pero no es obligatorio elegir una

Entrega*: Permite poner a mano la entrega si es que no se ha seleccionado ninguna SVE

IDs Plataformas*: Mostrar los plataformas y dejar seleccionar sólo una.
IDs Entornos*: Mostrar los entornos y dejar seleccionar sólo uno.


IMPORTANTE

Al crear una PLU:

  • Se crea automáticamente una PL hija en estado PDTE. CALENDARIZAR asignada a PROVEEDOR SISTEMAS para el entorno, plataforma y para todos los grupos lógicos.


PL Padre


Acciones en estado PDTE. REVISIÓN

Asignada a PROVEEDOR SISTEMAS


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

SOLICITAR INFORMACIÓN

Comentario obligatorio

PROVEEDOR SISTEMAS

PDTE. REVISIÓN a PDTE. INFORMACIÓN

N/A

ACEPTAR

PROVEEDOR SISTEMAS

PDTE. REVISIÓN a 

para PLU=NO

PDTE. REVISIÓN a EN RESOLUCIÓN para PLU=SÍ

N/A

NO ACEPTAR

Comentario obligatorio

PROVEEDOR SISTEMAS

PDTE. REVISIÓN a NO ACEPTADA

N/A

CANCELAR

Incluir comentario obligatorio

Libera la entrega y la SVE para la creación de una nueva entidad PL

R. PRODUCTO


PDTE. REVISIÓN a CERRADA

(Sin resolver) a (Cancelada)

EDITAR

Deben poder editarse todos los campos incluso el cambio a PLU, excepto la posibilidad de cambiar la tipificación y el tipo de la PL

R. PRODUCTO

PROVEEDOR

N/AN/A

SOLICITAR IMPLANTACIONES




PL hija urgente:

Sí

No (informado por defecto)

Si PLU hija urgente =SÍ


Aparece un mensaje en el que se indica que debe elegirse un entorno y plataforma únicos y que se creará una PL hija para el entorno y plataforma elegidos y para todos los grupos lógicos.

Entorno

Plataforma

Grupo lógico

Al ejecutar la acción SOLICITAR IMPLANTACIONES:

  • El campo Implantaciones solicitadas se informa a Sí y se reseteará una vez que se ejecute GENERAR EJECUCIONES.
  • Se resetean los campos "IDS entornos", "IDS plataformas" y "IDS grupos lógicos"

Si SOLICITAR IMPLANTACIONES se ejecuta en este estado y solicito PL HIJA urgente, se cambia el valor a PLU de la padre



El campo Restricción horaria debe permanecer visible en la entidad hasta que se ejecute GENERAR EJECUCIONES. En ese momento deja de mostrarse porque no estará informado.


Si marcamos PLU, se generará una PL hija para la plataforma y entorno seleccionado y para todos los grupos lógicos. La PL Hija se crea en estado PDTE. CALENDARIZAR

Se resetea en la padre PLU a SÍ si y solo si la padre está en estado PDTE. REVISIÓN porque el valor del campo determinará el umbral para el ANS. En cualquier otro estado, el campo de PLU para la padre se mantiene.

R. PRODUCTO

PROVEEDOR


N/A

N/A

Acciones en estado NO ACEPTADA

Asignada a Informador

ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

COMPLETAR INFORMACIÓN

Comentario obligatorio

Adjunto obligatorio

Mensaje: Debes adjuntar un nuevo PID

R.PRODUCTO

PROVEEDOR

NO ACEPTADA a PDTE. REVISIÓN

N/A

CANCELAR

Incluir comentario obligatorio

R. PRODUCTO

PROVEEDOR

NO ACEPTADAa CERRADA

(Sin resolver) a (Cancelada)

Acciones en estado 

Asignada a PROVEEDOR SISTEMAS


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

SOLICITAR INFORMACIÓN

Se informa un campo "Dudas tras proceso de revisión" a SÍ

PROVEEDOR SISTEMAS

PLANIFICABLE a PDTE. INFORMACIÓN

N/A

CANCELAR

Incluir comentario obligatorio

R. PRODUCTO

PROVEEDOR

PLANIFICABLE a CERRADA

(Sin resolver) a (Cancelada)

SOLICITAR IMPLANTACIONES

Las restricciones son las mismas que al solicitar implantaciones en el estado PDTE. REVISIÓN con la salvedad de:

NO SE RESETEA EL CAMPO PLU DE LA PADRE


R. PRODUCTO

PROVEEDOR

N/A si PLU=NO

PLANIFICABLE a EN RESOLUCIÓN si PLU=SÍ

N/A

GENERAR EJECUCIONES

acción ASIGNAR A MÍ en los usuarios integrantes del grupo planificador.


Campos que tienen que informarse:

Agrupación Plataformas: campo nfeed informado por Servicios CGES.

Plataformas*: campo informado con el valor que se puso en la creación. Puede modificarse o bien eliminarse su valor.

Entornos*: Campo con los entornos.

Grupos Lógicos :  aquí hay que indicar si los grupos separados por comas corresponden cada uno a una ejecución. Existe la posibilidad de concatenar grupos y que sea una ejecución por grupo concatenado. 

Se generará una subtarea de ejecución por cada agrupación de plataformas (o plataforma), entorno y grupo lógico (simple o concatenado). 

Subtareas creadas por usuarios pertenecientes al GRUPO PLANIFICADOR en estado  PLANIFICABLE  asignada a PROVEEDOR SISTEMAS


Aparecerá mensaje indicándose si se quiere crear una PL Hija por entorno, plataforma y para todos los grupos lógicos o si se quiere crear una PL Hija por cada grupo lógico.

GRUPO PLANIFICADOR

PLANIFICABLE a EN RESOLUCIÓN

N/A


Acciones en estado EN RESOLUCIÓN

Asignada a  PROVEEDOR SISTEMAS  


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

SOLICITAR INFORMACIÓN

Se informa un campo "Dudas con documentación aprobada" a SÍ si no estuviera informado. Si ya estuviera informado a SÍ, se mantiene el valor.

PROVEEDOR SISTEMAS

EN RESOLUCIÓN a PDTE. INFORMACIÓN

N/A

CANCELAR

Incluir comentario obligatorio

Si tiene PLs hijas, deben estar todas cerradas y con resolución cancelada

R. PRODUCTO

PROVEEDOR

EN RESOLUCIÓNa CERRADA

(Sin resolver) a (Cancelada)

SOLICITAR IMPLANTACIONES

IDEM a en estado PLANIFICABLE


R. PRODUCTO

PROVEEDOR

N/A

N/A

GENERAR EJECUCIONES


GRUPO PLANIFICADOR

N/A

N/A

FINALIZAR

Todas las Pls hijas deben estar cerradas

R. PRODUCTO

PROVEEDOR

EN RESOLUCIÓN a CERRADA

(Sin resolver) a (Cerrada)

Acciones en estado PDTE. INFORMACIÓN

Asignada al informador  R. PRODUCTO  PROVEEDOR

ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

COMPLETAR INFORMACIÓN

R. PRODUCTO

PROVEEDOR

PDTE. INFORMACIÓN a ESTADO ORIGEN

N/A

CANCELAR

Incluir comentario obligatorio

Si tiene PLs hijas, deben estar todas cerradas y con resolución cancelada

R. PRODUCTO

PROVEEDOR

EN RESOLUCIÓN a CERRADA

(Sin resolver) a (Cancelada)

PL Hija

Las PLS hijas se crearán con título : {Plataforma} - {Entorno} - {Grupos lógicos}. 

Debe estar visible el campo que identifique si es o no PLU


No podrán existir dos entidades "PL hija" con el mismo valor para los campos "IDS entornos", "IDS plataformas" y "IDS grupos lógicos", para un mismo padre (PL). Sólo será posible si la primera se ha cancelado.

Si PL hija urgente=SÍ, la PL hija queda en estado PDTE. CALENDARIZAR y cuando el PROVEEDOR SISTEMAS pone fechas, pasa directamente al estado PDTE. COMENZRA RESOLUCIÓN

En las PLs hijas debe siempre estar visible si son o no PL hija urgente

Desde la PL padre deben verse las PL hijas identificando de manera visual si son o no PL hija urgente o no


El ciclo completo de la PL hija se da únicamente en el caso de la primera vuelta, correspondiente a la actividad de instalación.

Para cualquier otra vuelta, que siempre supone una NO aceptación de la solución técnica por parte del solicitante, el flujo comienza en el estado PDTE. CALENDARIZAR y de ahí pasa a PDTE. COMENZAR RESOLUCIÓN. El solicitante debe escribir en un comentario las fechas que desea tenga esa nueva actividad.


Acciones en estado PLANIFICABLE

ACTIVIDAD=INSTALACIÓN

Asignada  GRUPO PLANIFICADOR cuyos integrantes podrán asignarse la entidad

ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

EDITAR

Podrá convertirse en PL hija urgente(1). indicar motivo y campo de información adicional

Podrán cambiarse los grupos lógicos(2)

RESPONSABLE PRODUCTO(1)

PROVEEDOR(1)

PROVEEDOR SISTEMAS(2)

GRUPO PLANIFICADOR(2)

PLANIFICABLE a PDTE. CALENDARIZAR si PL hija urgente=Sí

N/A en el resto de los casos


SOLICITAR PLANIFICACIÓN

Debe indicarse fecha de inicio deseada

GRUPO PLANIFICADOR

PLANIFICABLE a PDTE. CALENDARIZAR


N/A

CANCELAR

Incluir comentario obligatorio

R.PRODUCTO

PROVEEDOR

GRUPO PLANIFICADOR

PLANIFICABLE a CERRADA

(Sin resolver) a (Cancelada)

SOLICITAR REVISIÓN

Indicar en comentario lo que se quiere cambiar. Comentario obligatorio.

Informar el campo Pdte. revisión STIC a SÍ


GRUPO PLANIFICADOR

PROVEEDOR SISTEMAS

N/A

EDITAR EJECUCIONES

Modificar en el tablegrid lo que sea necesario y cambiar el campo Pdte. revisión STIC a NO.

Recalcular las HBS incurridas

GRUPO PLANIFICADOR

N/A

Acciones en estado PDTE. CALENDARIZAR

ACTIVIDAD=TODAS

Asignada a PROVEEDOR SISTEMAS


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

EDITAR

Podrá convertirse en PL hija urgente(1). indicar motivo y campo de información adicional

Podrán cambiarse los grupos lógicos(2)


RESPONSABLE PRODUCTO(1)

PROVEEDOR(1)

PROVEEDOR SISTEMAS(2)

GRUPO LANZAMIENTO(2)

N/A

N/A

CALENDARIZAR (**)


PROVEEDOR SISTEMAS

GRUPO PLANIFICADOR

PDTE. CALENDARIZARa CALENDARIZADASI ACTIVIDAD=INSTALACIÓN Ó

PLU=NO

PDTE. CALENDARIZAR a PDTE. COMENZAR RESOLUCIÓN SI ACTIVIDAD no es INSTALACIÓN Ó PLU=SÍ

N/A

CANCELAR

Incluir comentario obligatorio

R. PRODUCTO

GRUPO PLANIFICADOR

PDTE. CALENDARIZAR a CERRADA

(Sin resolver) a (Cancelada)

SOLICITAR REVISIÓN

Indicar en comentario lo que se quiere cambiar. Comentario obligatorio.

Informar el campo Pdte. revisión STIC a SÍ

PROVEEDOR SISTEMAS

GRUPO PLANIFICADOR

N/A

EDITAR EJECUCIONES

Modificar en el tablegrid lo que sea necesario y cambiar el campo Pdte. revisión STIC a NO.

Recalcular las HBS incurridas

GRUPO PLANIFICADOR

N/A

(**)

Campos que deben informarse o estarán informados al CALENDARIZAR:

Actividad*(se informa automáticamente):  posibles valores Instalación, Desinstalación y Marcha Atrás (conlleva una reinstalación, que se informará automáticamente en el campo Actividad al aceptar la marcha atrás). Para la primera vez que se haga la ejecución, estará informado "Instalación". Posteriormente dependerá de lo que informe el solicitante cuando no acepte la solución técnica o si la acepta siendo la actividad una marcha atrás.

Facturable*:

ACTIVIDAD= INSTALACIÓN, el campo estará informado a Sí 

ACTIVIDAD= MARCHA ATRÁS, el campo estará informado a No 

ACTIVIDAD= REINSTALACIÓN, el campo estará informado a No

 ACTIVIDAD= DESINSTALACIÓN, el campo estará informado a Sí 


Complejidad*: (Sí/No) por defecto informado a NO hasta que no solicite CTI 


En cada ejecución, se reseteará el valor del campo PLU a NO


Acciones en estado 

ACTIVIDAD= INSTALACIÓN

Asignada a GRUPO PLANIFICADOR 


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

EDITAR

Podrá convertirse en PL hija urgente(1). indicar motivo y campo de información adicional


Podrán cambiarse los grupos lógicos(2)


RESPONSABLE PRODUCTO(1)

PROVEEDOR(1)

PROVEEDOR SISTEMAS(2)

GRUPO LANZAMIENTO(2)

CALENDARIZADA a PDTE. COMENZAR RESOLUCIÓN si (1)

N/A si (2)

N/A

APROBAR FECHAS

Si la PL está enlazada con otra porque tenga dependencia, debería aparecer un mensaje de advertencia

GRUPO PLANIFICADOR

CALENDARIZADA a PDTE. COMENZAR RESOLUCIÓN

N/A

NO APROBAR FECHAS

(Incluir motivo obligatorio)

GRUPO PLANIFICADOR

CALENDARIZADA a PDTE. CALENDARIZAR

N/A

CANCELAR

Incluir comentario obligatorio

R. PRODUCTO

PROVEEDOR

GRUPO PLANIFICADOR

CALENDARIZADA  a CERRADA

(Sin resolver) a (Cancelada)

SOLICITAR REVISIÓN

Indicar en comentario lo que se quiere cambiar. Comentario obligatorio.

Informar el campo Pdte. revisión STIC a SÍ

PROVEEDOR SISTEMAS

GRUPO PLANIFICADOR

N/A

EDITAR EJECUCIONES

Modificar en el tablegrid lo que sea necesario y cambiar el campo Pdte. revisión STIC a NO

Recalcular las HBS incurridas

GRUPO PLANIFICADOR

N/A

Acciones en estado  PDTE. COMENZAR RESOLUCIÓN

Asignada a  PROVEEDOR SISTEMAS


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

EDITAR

Podrá convertirse en PL hija urgente(1). indicar motivo y campo de información adicional


Podrán cambiarse los grupos lógicos(2)

Podrán cambiarse las fechas, si y sólo si no se haya llegado a la fecha de inicio estimada (3)


R. PRODUCTO (1)

PROVEEDOR (1)

PROVEEDOR SISteMAS (2) (3)


GRUPO PLANIFICADOR(2)(3)

N/A

N/A

COMENZAR RESOLUCIÓN

Para cada actividad informar "Fecha inicio real" para cargar en la tabla de ejecuciones

PROVEEDOR SISteMAS

GRUPO PLANIFICADOR

PDTE. COMENZAR RESOLUCIÓN a EN RESOLUCIÓN

N/A

CANCELAR

Incluir comentario obligatorio

R. PRODUCTO

GRUPO PLANIFICADOR

PDTE. COMENZAR RESOLUCIÓN a CERRADA

(Sin resolver) a (Cancelada)

SOLICITAR REVISIÓN

Indicar en comentario lo que se quiere cambiar. Comentario obligatorio.

Informar el campo Pdte. revisión STIC a SÍ

PROVEEDOR SISteMAS

GRUPO PLANIFICADOR

N/A

EDITAR EJECUCIONES

Modificar en el tablegrid lo que sea necesario y cambiar el campo Pdte. revisión STIC a NO

Recalcular las HBS incurridas

GRUPO PLANIFICADOR

N/A


Acciones en estado  EN RESOLUCIÓN

Asignada a  PROVEEDOR SISTEMAS


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

RESOLVER

Informar campo "Errores detectados" Sí/No. El campo no está informado hasta ese momento.

Describir los errores detectados en un campo Comentario obligatorio.


PROVEEDOR SISteMAS

EN RESOLUCIÓN  a  PDTE.REVISIÓN TÉCNICA

N/A

SOLICITAR REVISIÓN

Indicar en comentario lo que se quiere cambiar. Comentario obligatorio.

Informar el campo Pdte. revisión STIC a SÍ

PROVEEDOR SISteMAS

GRUPO PLANIFICADOR

N/A

EDITAR EJECUCIONES

Modificar en el tablegrid lo que sea necesario y cambiar el campo Pdte. revisión STIC a NO

Recalcular las HBS incurridas

GRUPO PLANIFICADOR

N/A


Acciones en estado  PDTE. REVISIÓN TÉCNICA

Asignada a solicitante (R.PRODUCTO , PROVEEDOR) de la PL padre


ACCIÓN

QUIÉN PUEDE

CAMBIO DE ESTADO

CAMBIO RESOLUCIÓN

ACEPTAR SOLUCIÓN TÉCNICA

Si está informado el campo "Errores detectados", el solicitante deberá justificar el motivo por el que acepta la solución a pesar de los errores detectados en el despliegue. Se hace en campo comentario


R.PRODUCTO

PROVEEDOR

a  

(Sin resolver) a (Cerrada)

NO ACEPTAR SOLUCIÓN TÉCNICA*

(Informar obligatoriamente el campo "MOTIVO NO ACEPTACIÓN"

y el campo ACTIVIDAD)

R.PRODUCTO

PROVEEDOR

PDTE.REVISIÓN TÉCNICA a PDTE. CALENDARIZAR


N/A

SOLICITAR REVISIÓN

Indicar en comentario lo que se quiere cambiar. Comentario obligatorio.

Informar el campo Pdte. revisión STIC a SÍ

PROVEEDOR SISteMAS

GRUPO PLANIFICADOR

N/A

EDITAR EJECUCIONES

Modificar en el tablegrid lo que sea necesario y cambiar el campo Pdte. revisión STIC a NO

Recalcular las HBS incurridas

GRUPO PLANIFICADOR

N/A


*Cuando se accede a No aceptar solución técnica, deben mostrarse una serie de preguntas al solicitante


  • ¿Quieres reinstalación?

    • No. 
      • ¿Quieres desinstalar?
        • Sí
          • Indicar en comentario la fecha en la que el peticionario desea que se haga la desinstalación
          • Pasa a PDTE. CALENDARIZAR y se informa como Actividad "Desinstalación"
        • No. 
          • Pasa a CERRADA con Resolución "Anulada por defecto de Software"
    • Sí
      • ¿Quieres marcha atrás?
        • Sí
          • Indicar en comentario la fecha en la que el peticionario desea que se haga la MARCHA ATRÁS
          • Pasa a PDTE. CALENDARIZAR y se informa como Actividad "Marcha Atrás". Al aceptar la solución técnica debe ir de nuevo al principio con Actividad "Reinstalación"
        • No
          • Pasa a PDTE. CALENDARIZAR y se informa como Actividad "Reinstalación"






Control facturación

Cada ejecución se registra en una fila de un table grid


Los datos que se muestran en la tabla son:

  • Tipo actividad
  • PLU (sí o no)
  • Compleja (informado siempre a NO)
  • Facturable: vendrá informado por el tipo de actividad
  • Fecha de inicio real
  • Fecha de inicio estimada : marca la hora para saber si la facturación corresponde a horario normal o extendido.
  • Fecha resolución: corresponde al campo "Fecha resolución proveedor" de cada ejecución (paso del estado EN RESOLUCIÓN a PDTE. REVISIÓN TÉCNICA)

La factura se conforma con los datos del table grid el día 11 de cada mes. Cualquier modificación de una ejecución hecha después del día 10, no se tendrá en cuenta en la facturación



RFP (Request For Platform)