Proceso: Modelo de gestión de servicios (aplicaciones centralizadas)


Objetivo

Establecer la relación de la DGSIC con sus proveedores en el ámbito centralizado.

De esta forma se establece cómo gestionar todo el trabajo que se le puede solicitar al proveedor de desarrollo de software y al de sistemas e infraestructura, dando cobertura a los modos de prestación de los distintos servicios gestionados que los pliegos de contratación establecen.

A fin de lograr este propósito, el documento incluye los siguientes apartados:

  • Objetivos y alcance del modelo: Bases para el entendimiento del documento.
  • Acrónimos y definiciones: Terminología fundamental para la comprensión del modelo en su contexto.
  • Descripción general del modelo: Explicación breve del modelo a través de los roles, entidades y su relaciones globales.
  • Descripción detallada del modelo: Explicación del modelo a través de sus procesos y la descripción de las actividades que lo componen. Visualización del flujo de trabajo del proceso.

Alcance

El modelo, afecta:

Acrónimos

  • ANS: Acuerdo de Nivel de Servicio
  • CANP: Coordinador de Actividad No Planificada
  • CAP: Coordinador de Actividad Planificada
  • CA SDM: Computer Associates-Service Desk Manager
  • CI: Configuration Item, elemento de la configuración
  • CMDB: Configuration Management Data Base
  • CSU: Centro de Servicios al Usuario
  • EA: Entreprise Architect
  • EVS: Estudio de Viabilidad del Sistema
  • HBS: Hora Básica de Servicio
  • LB: Línea Base del producto
  • NC: No Conformidad
  • WT: Web Técnica
  • OCA: Oficina de Calidad
  • OT: Orden de Trabajo
  • OTEVS: Orden de Trabajo de EVS
  • OTR: Orden de Trabajo de Requisitos
  • OTA: Orden de Trabajo de Análisis
  • OTD: Orden de Trabajo de Diseño
  • OTC: Orden de Trabajo de Construcción
  • OTImpl: Orden de Trabajo de Implantación
  • OTInm: Orden de Trabajo Inmediata
  • OTAD: Orden de Trabajo de Análisis y Diseño
  • OTADC: Orden de Trabajo de Análisis, Diseño y Construcción
  • OTEquipo: Orden de trabajo para el control de costes de un equipo dedicado.
  • OTÁgil: Orden de trabajo para el control de costes de un sprint
  • PL: Petición de Lanzamiento
  • RA: Responsable Área
  • RF: Responsable Funcional
  • RFP: Request For Platform
  • RP: Responsable de Producto
  • RS: Responsable de Sistemas
  • SAS: Servicio Andaluz de Salud
  • SPI: Solicitud Proyecto de Ingeniería
  • SSHH: Servicios Horizontales
  • DGSIC: Dirección General de Sistemas de Información y Comunicaciones
  • SVT: Servicio de Valor a la Transición
  • SW: Software 
  • TI: Tecnologías de la Información
  • TIC: Tecnologías de la Información y Comunicaciones

Definiciones

  • Producto: Programa informático diseñado para una utilización específica y vinculada a un ámbito TIC, a través del contrato correspondiente.
  • Backlog: Conjunto de mejoras aprobadas para su inclusión en una versión, junto a incidencias resueltas que requieren implantación.
  • Confluence: Herramienta destinada a la gestión del conocimiento. 
  • Contrato: Documento administrativo que tiene por objeto la definición de los servicios a prestar por el proveedor, incluyendo las condiciones del mismo y obligaciones.
  • JIRA:  Herramienta que permite la gestión de la actividad planificada, en concreto las líneas de diseño y transición de los contratos de desarrollo de software y de sistemas e infraestructura.
  • ayudaDIGITAL: servicio de Soporte Integral TIC del SAS para los profesionales del SAS (lajunta.es/ayudadigital)
  • Área personal de ayudaDIGITAL: Herramienta donde el usuario final registra incidencias, peticiones y consultas.
  • Orden de Trabajo: unidad mínima de trabajo planificada que resuelve el proveedor y que solicita el Responsable de Producto DGSIC.
  • Prioridad: Medida de la importancia de una incidencia y determina la rapidez con la que una incidencia debe quedar resuelta. Se distinguen de mayor a menor prioridad: P1, P2 y P3.
  • Servicio (de TI): Un servicio es un medio para entregar valor a los clientes facilitándoles un resultado deseado sin la necesidad de que estos asuman los costes y riesgos específicos asociados.
  • Wishlist: Conjunto de mejoras que han sido solicitadas para una aplicación.

Descripción general del modelo

Consideraciones iniciales

En el presente modelo se plasma el proceso que gestiona la demanda de los usuarios desde su registro hasta que esa mejora se refleja en las aplicaciones teniendo en cuenta que se trate de aplicativos del ámbito centralizado. Esto implica que esos aplicativos deben estar registrados como CIs (Configuration Item) en el sistema que gestiona la configuración, CMS. Por tanto, si el aplicativo es nuevo, hay que primero seguir los siguientes pasos:

  • Solicitar el alta del aplicativo en CMS: Para ello, será necesario seguir el Procedimiento de alta/modificación/baja de aplicación en CMS  que se detalla en el Proceso de Gestión de la Configuración. El alta en CMS desencadena el alta en JIRA/CONFLUENCE.
  • El Responsable de Producto deberá comunicar al CSU la existencia de una nueva aplicación para que la incluyen dentro de sus procedimientos y están preparados para el día que comience a entrar tanto demanda como incidencias por parte de los usuarios para esa aplicación, En Centro de Servicios al Usuario puedes encontrar los canales de acceso.
  • Paralelamente al alta del aplicativo, es necesario ir gestionando la infraestructura necesaria para el futuro despliegue. Por tanto, será necesaria la petición de una plataforma, para lo cual pueden verse los pasos a seguir en el proceso de Gestión de Plataformas al que también se hace referencia más adelante.

Visión general del modelo


draw.io

Source page access restriction: Click the link below to check if the page is accessible.
/confluence/pages/viewpage.action?pageId=247570247




  • Una vez que la aplicación está dada de alta en CMS y por tanto en JIRA/CONFLUENCE. pueden comenzar a registrarse la demanda de los usuarios en forma de mejoras, así como peticiones e incidencias.
  • Las mejoras y aquellas incidencias que requieran modificar la línea base del producto, y por lo tanto requieran incremento de versión del mismo, se registran en JIRA.
  • El Responsable Funcional de la aplicación decide qué demanda de la registrada tiene sentido en la evolución de la aplicación y cual no.
  • El Responsable del producto creará versiones, entendiendo como tales "pequeños proyectos" dotados de un coste, un horizonte temporal y un alcance. Este alcance estará conformado tanto por aquellas mejoras aprobadas que tengan mayor urgencia en su aprobación como por aquellas incidencias que requieran subida de versión del producto.
  • Una vez conformada la versión, el Responsable de producto gestiona el trabajo que debe hacer el proveedor. Puede hacerlo siguiendo la metodología clásica que consiste en pedir al proveedor órdenes de trabajo que vayan cubriendo el ciclo de vida o bien con metodología ágil descomponiendo la demanda en historias de usuario y creando sprints. La validación funcional que hace la OCA se hará en la versión desplegada en PRE en el caso de que la gestión se haga en cascada (SVF). En el caso de metodología ágil, la validación se hará en los diferentes sprints (SVS) y una vez que se vaya a desplegar la versión sobre ésta.
  • Paralelamente al desarrollo, será necesaria la petición de una plataforma si se trata de una aplicativo nuevo. Puede ser que otras veces sea necesaria la modificación de una existente para el despliegue de una determinada versión.
  • Una vez que el alcance de la versión está desarrollado y la plataforma está lista, se procede al despliegue, normalmente en el entorno de preproducción.
  • Cuando la versión está desplegada, la Oficina de Calidad comienza el testing de forma paralela a las pruebas funcionales que normalmente hacen los Responsables Funcionales. Los errores detectados se registran como No Conformidades que deben ser corregidas normalmente antes del despliegue en producción.
  • Cuando la versión está lista y testeada, se hace el despliegue en producción de la misma, lo que implica que tanto la demanda de los usuarios como la resolución de las incidencias son visibles por los mismos


El modelo se ha dividido en los siguientes ámbitos:


  • Actividad no Planificada

    • Comprende los servicios de la línea de operación: 
      • Peticiones: Petición que hace el usuario solicitando información, asesoramiento, un cambio estándar o acceso a un servicio TI.
        • Se corresponden con aquellas peticiones de usuario final con tipificación: Petición /  Consulta.
        • El usuario las registra en el área personal de ayudaDIGITAL y se gestionan íntegramente en WT.

      • Incidencias: Interrupción no planificada de un servicio de TI o reducción en la calidad de un servicio TI.

        • Se corresponden con aquellas incidencias de usuario final en área personal de ayudaDIGITAL con tipificación: Incidencia.
        • Las incidencias que para su resolución no requieren implantación, se gestionan íntegramente en WT.
        • Las incidencias que para su resolución requieren de implantación, se resuelven en WT pero quedan pendientes de gestionar su implantación en JIRA a través de las versiones.

  • Actividad Planificada

    • Comprende los servicios de la línea de diseño y transición: 
      • Mejora: Todas aquellas entradas que buscan la evolución (cambio) de una aplicación y requieren ser planificadas para su resolución.
        • Incluye: 
          • Las integradas/escaladas desde área personal de ayudaDIGITAL con tipificación Mejora.
          • Las registradas en JIRA por los roles autorizados.
      • Versión: Agrupación de mejoras y/o incidencias de una determinada aplicación que persiguen implantarse de manera conjunta.
        • Es la unidad de gestión del Responsable de Producto.
        • Se gestionan íntegramente en JIRA.
      • Orden de trabajo (OT): Unidad mínima de trabajo planificada que resuelve el proveedor y que solicita el Responsable de Producto.

        • Existen las siguientes tipologías: 
          • Orden de Trabajo de EVS (OTEVS).
          • Orden de Trabajo de Requisitos (OTR).
          • Orden de Trabajo de Análisis (OTA).
          • Orden de Trabajo de Diseño (OTD).
          • Orden de Trabajo de Construcción (OTC).
          • Orden de Trabajo de Implantación (OTImpl).
          • Orden de Trabajo de Análisis/Diseño (OTAD).
          • Orden de Trabajo de Análisis/Diseño/Construcción (OTADC).
          • Orden de Trabajo de Equipo (OTEquipo).
          • Orden de Trabajo Inmediata (Puede incluir Requisitos/Análisis/Diseño/Construcción aunque su objetivo principal es ser lanzada para P1) (OTInm).
          • SVT: Comprende aquellos servicios de valor dentro del ámbito del contrato como son los proyectos que definen los planes de transformación, formación, consultoría, etc., no asociados a aplicativos concretos.

          • Petición Soporte a la Transición (PST).

          • Orden de trabajo ágil (OTágil).
        • Se gestionan íntegramente en JIRA.
        • Entregables: son los productos de salida de cada tipo de Orden de Trabajo.
      • Petición de plataforma (RFP - Request For Platform): solicitudes destinadas a la creación de las Plataformas tecnológicas necesarias para el despliegue de los diferentes aplicativos incluidos dentro del catálogo de aplicaciones.
        • Se desencadena para realizar una modificación sustancial de plataforma:
          • Desplegar nuevas máquinas físicas o virtuales.
          • Crear nuevas bases de datos.
          • Reinstalar completamente sistemas operativos.
        • Se gestionan íntegramente en JIRA.
      • Petición de lanzamiento (PL): solicitudes de servicios de transición de instalaciones software como consecuencia del desarrollo y evolución de sistemas de información.
        • Se clasifican por tipificaciones:
          • Peticiones de lanzamiento de incremento de versión (PL versión).  
          • Peticiones de lanzamiento para modificación/configuración de software base (PL sistemas). 
          • Peticiones de lanzamiento para modificaciones de datos (PL datos).  
          • Peticiones de lanzamiento para cambios de configuración (PL configuración).  
        • Es necesaria la verificación del código a implantar por la Oficina de Calidad, esta verificación se modela en el Servicio de Verificación de Entrega (SVE) en el caso de las PLs de incremento de versión y mediante el Servicio de verificación de datos (SVD) para las PLs de datos.
        • Se gestionan íntegramente en JIRA.

      • No conformidad (NC):  Es todo aquel fallo detectado en un entorno no productivo en un proceso de validación. 
        • Las no conformidades debidas a la incorrecta solución de mejoras/incidencias se gestionan nuevamente por el proveedor.

        • Se gestionan íntegramente en JIRA. 

      • Petición Soporte a la Transición (PST): son peticiones que el área de proyectos y desarrollo hace al proveedor de sistemas y que se modelan como órdenes de trabajo que ejecuta el proveedor de sistemas (CTI).


En el caso de que la gestión de los productos se haga siguiendo metodología ágil, las entidades son las mismas y se incluyen las historias de usuario, que se definen como entidades en las que se descomponen las mejoras aprobadas y que van siendo desarrolladas en un sprint.

Descripción detallada del modelo


Actividad no planificada


Petición 

  

Descripción del proceso


El objetivo de este proceso es atender las peticiones del usuario, ya sea final, técnico (de otros proveedores) o de la DGSIC.
Inicialmente, el proveedor deberá realizar un estudio para determinar si le corresponde la resolución de la misma o no.
A partir de ese momento existen diferentes escenarios:

  • Si el proveedor ACEPTA la petición, indicará las HBS de resolución y la escalará para que el usuario confirme su correcta solución y por tanto, confirme su cierre.
  • Si el proveedor NO ACEPTA la petición, incurre las HBS de estudio y la escala de nuevo a CSU. 

En caso de que se reabra la petición, el proveedor no podrá volver a incurrir HBS de resolución ni de estudio.


Diagrama del proceso

Loading...

draw.io

Diagram attachment access error: cannot display diagram


     

Diagrama de estados

Loading...

draw.io

Diagram attachment access error: cannot display diagram


     

Etapas del proceso 


Gestión CSU

Una vez se registra una petición, en el CSU se realizan las acciones correspondientes al proceso de Gestión de peticiones: registro y clasificación, análisis, resolución de primer nivel, etc. La petición pasa a estar en estado "Abierta". Continúa en Escalar a proveedor.


Escalar a proveedor

Con la petición ya gestionada, ya sea tras hacer Gestión en CSU o tras una petición rechazada por el proveedor y aceptada dicha transferencia, en CSU se pasa a determinar qué hay que transferirle al proveedor y se realiza dicha transferencia. La petición se mantiene en estado "Abierta". Continúa en Realizar estudio. 


Realizar estudio 

Recibida la petición gestionada por CSU, el proveedor realiza un estudio acerca de la pertinencia de la petición recibida (CI, prioridad, proveedor). La petición continúa en estado "Abierta".

  • Si el proveedor considera que dicha petición NO le pertenece, la escala a CSU continuando así el proceso por Escalar a CSU. 
  • Si el proveedor considera que dicha petición SI le pertenece, pasa a resolverla, continuando así el proceso por Resolver.


Escalar a CSU

Como tras el estudio de la petición el proveedor ha determinado que debe devolverla a CSU, debe indicar el motivo de la devolución, incurrir las HBS del estudio y escalar dicha petición a CSU, donde se revisa esta no aceptación en el paso Revisar la NO aceptación. La petición sigue en estado "Abierta".


Revisar la NO aceptación

Teniendo la petición escalada, el informe con los costes incurridos y el motivo de devolución completado, en CSU se revisa dicha devolución. La petición sigue en estado "Abierta". 

  • Si se considera justificado el rechazo de la petición por parte del proveedor, se gestiona de nuevo desde CSU. Continúa el proceso en Gestión CSU.
  • Si NO se considera justificado el rechazo de la petición por parte del proveedor, se vuelve a mandar la petición al proveedor. Continúa el proceso en Escalar a proveedor.

Resolver 

Ya con la petición revisada por el proveedor y aceptado que es de su pertinencia, dicho proveedor pasa a resolverla (Sólo se podrá imputar la primera vez que se resuelve. Tras una reapertura no se podrá incurrir HBS de resolución ni de estudio). La petición pasa a estado "Fijada". El proceso sigue en Revisar resolución. 


Revisar resolución

Una vez el proveedor resuelve la petición, se le envía al solicitante para que compruebe si dicha petición está correctamente resuelta. 

  • Si el solicitante está conforme con la resolución, el estado de la petición pasa a estar "Cerrada" y finaliza el proceso.
  • Si el solicitante NO está conforme con la resolución, el estado de la petición pasa a estar "Abierta" de nuevo y se vuelve a gestionar. El proceso continúa en Gestión CSU.         



Incidencia

  

Descripción del proceso


El objetivo de este proceso es resolver las incidencias del usuario, ya sea final, técnico (proveedores de otros ámbitos TIC) o de la DGSIC, según los niveles de servicio acordados.
El proveedor deberá registrar cada una de las actuaciones que hace sobre la incidencia, anotando las HBS imputadas en cada una de ellas. Al acabar una actuación podrá:

  • Continuar con la incidencia para hacer una nueva actuación.
  • Escalar la incidencia a CSU para que la resuelva otro proveedor.
  • Cerrar la incidencia. Al acceder a esta opción, el proveedor informará de si la resolución de la incidencia necesita o no implantación:
    • Si necesita implantación y NO modifica la LB del producto, generará una solicitud de datos o de configuración que se integrará con JIRA. Se incluirá en una Pl de datos o de configuración y quedará resuelta cuando se implante la misma.
    • Si necesita implantación y modifica la LB del producto, la incidencia se replicará como objeto de JIRA para que pueda ser implantada en una versión.
    • Si NO necesita implantación, se pasa a resolver directamente. 

Diagrama del proceso


Loading...

draw.io

Diagram attachment access error: cannot display diagram



Diagrama de estados


Loading...

draw.io

Diagram attachment access error: cannot display diagram


  

Etapas del proceso


Gestión CSU

Una vez se registra una incidencia en WEB AUTOSERVICIO, el CSU realiza las acciones del proceso de gestión de incidencias que tiene encomendadas: registro y clasificación, análisis de primer nivel, resolución de primer nivel, etc. La incidencia pasa a estar en estado "Abierta". Continúa en Escalar a proveedor.


Escalar a proveedor

Con la incidencia ya gestionada, ya sea tras hacer Gestión en CSU o tras una incidencia rechazada por el proveedor y aceptada dicha transferencia, en CSU se pasa a determinar qué hay que transferirle al proveedor y se realiza dicha transferencia. La incidencia se mantiene en estado "Abierta". Continúa en Realizar estudio. 


Realizar estudio 

Recibida la incidencia gestionada y escalada desde CSU a la WT, el proveedor realiza un estudio acerca de la pertinencia de la incidencia recibida (CI, prioridad, proveedor). La incidencia continúa en estado "Abierta" tanto en CSU como en la WT.

  • Si el proveedor considera que dicha incidencia NO le pertenece, la escala a CSU continuando así el proceso por Escalar a CSU. 
  • Si el proveedor considera que dicha incidencia SI le pertenece, pasa a resolverla, continuando así el proceso por Resolver.


Escalar a CSU

Como tras el estudio de la incidencia el proveedor ha determinado que debe devolverla a CSU, debe indicar el motivo de la devolución, incurrir las HBS del estudio y escalar dicha incidencia a CSU, donde se revisa esta NO aceptación en el paso Revisar la NO aceptación. La incidencia sigue en estado "Abierta".


Revisar la NO aceptación

Teniendo la incidencia escalada, el informe con los costes incurridos y el motivo de devolución completado, en CSU se revisa dicha devolución. La incidencia sigue en estado "Abierta". 

  • Si se considera justificado el rechazo de la incidencia por parte del proveedor, se gestiona de nuevo desde CSU. Continúa el proceso en Gestión CSU.
  • Si NO se considera justificado el rechazo de la incidencia por parte del proveedor, se vuelve a mandar la petición al proveedor. Continúa el proceso en Escalar a proveedor.


Resolver

Ya con la incidencia revisada por el proveedor y aceptado que es de su pertinencia, este pasa a resolverla. Al finalizar dicha resolución, el proveedor realiza las siguientes acciones: 

  • Registra las diferentes actuaciones e imputa las HBS incurridas en cada una de ellas indicando si la causa de la incidencia es propia o ajena.
  • Si ha acabado de resolver la incidencia, en caso de que sea de forma parcial, puede escalarla a CSU indicando si escala para que se le asigne la incidencia a un resolutor de la misma organización o de otra para que este continúe con la resolución. 
  • Una vez que se ha acabado de actuar, se accede a cerrar la incidencia indicando obligatoriamente si la resolución implica modificar o no la línea base del producto.

En el caso de que la resolución NO implique una modificación de la LB del producto pero pueda requerir implantación una vez resuelta, se realiza una PL, la incidencia pasa a estado "Pte. implantación" y no pasa a estado "Fijada" hasta que la PL en la que se incluya se cierre satisfactoriamente. El proceso continúa en Revisar resolución. 

Por el contrario, en el caso de que la resolución SI implique una modificación de la LB del producto: 

    • Primero se replica en JIRA asignada al Responsable de Producto y queda a la espera de que se incluya en la versión que él considere oportuna, modificando el estado de la incidencia pasando de "Backlog" a "En versión". Cabe la posibilidad de que una vez se incluya en una versión, se desasigne nuevamente. En este caso, continuaría en Asociar/Desasignar.
    • Luego, en área personal de ayudaDIGITAL/WT cambia de estado de "Abierta" a "Pte implantar".
    • Cuando se finaliza la PL a la versión en la que está incluida en JIRA pasa de estado "En versión" a "Cerrada", en área personal de ayudaDIGITAL pasa de "Pte implantar" a "Fijada" y en WT pasa de "Pte implantar" a "Pte confirmación cierre". El proceso continúa en Revisar resolución. 

Revisar resolución

Una vez el proveedor resuelve la incidencia, se le envía al solicitante para que compruebe si dicha incidencia está correctamente resuelta. 

  • Si el solicitante está conforme con la resolución, el estado de la incidencia pasa de "Fijada" a estar "Cerrada" y finaliza el proceso.
  • Si el solicitante NO está conforme con la resolución, el estado de la incidencia pasa de "Fijada" a estar "Abierta" de nuevo y se vuelve a gestionar. El proceso continúa en Gestión CSU.


Asociar/Desasignar

En el caso de que se tenga una incidencia, ya sea en estado "Backlog" o "En versión", el Responsable de Producto puede desasignar dicha incidencia de una determinada versión, cambiando por tanto el estado de "En versión" a "Backlog" o incluir la incidencia en una de las versiones abiertas. En esta última situación, las versiones pueden estar en estado "Abierta" o "En resolución" . Una vez que la incidencia se ha incluido en una versión será posible para el RP y para el proveedor asociar la incidencia con las OTs permitidas, pasando de "Backlog" a "En versión". 


      


Actividad planificada


Mejora 

  

Descripción del proceso


El objetivo final es implantar las mejoras (entradas que buscan una evolución de una aplicación) a través de una versión. Para ello, las mejoras entran en la Wishlist, donde el Responsable de Producto y/o el responsable funcional realizan una criba previa rechazando las que no aplican, exponiendo el motivo, o aprobando las que sí, pasándolas a Backlog indicando la urgencia.

Hay tres tipos de urgencia: 1- Muy alta 2- Alta 3- Normal. Este campo debe ser editable tanto en Wishlist como en Backlog, pero siempre se debe informar de este campo en la transición de Wishlist a Backlog si es que no ha sido informado mediante edición en Wishlist.

El RP deberá incluir las mejoras en Backlog en una versión para gestionar el cambio del aplicativo. Una mejora estará en versión hasta que el Responsable de Producto:

  • La desasigne de la versión por el motivo que considere y la devuelve a Backlog.
  • Cancela la versión.
  • Finaliza la PL asociada a la versión en la que estaba incluida.

Por otra parte, podría darse el caso de que una mejora registrada, no sea considerada como tal por el RP o incluso que lo sea pero que la aplicación no sea la correcta, con lo que cabe la posibilidad de que sea escalada a CSU. En este caso se comunicará al usuario que su mejora registrada ha sido devuelta a CSU en el registro de actividad de la solicitud. Esta opción sólo puede darse si la mejora ha sido creada desde área personal de ayudaDIGITAL y si no ha pasado nunca por el estado Backlog.

Cabe mencionar que existe en JIRA la posibilidad de clonar mejoras en diferentes estados para cualquier aplicación del mismo ámbito que la original, incluso en el momento de la aprobación de la misma. 


Diagrama del proceso


Loading...

draw.io

Diagram attachment access error: cannot display diagram


  

Diagrama de estados


Loading...

draw.io

Diagram attachment access error: cannot display diagram



Etapas del proceso


Registrar mejora

El primer paso es detectar la necesidad de mejora dentro de una aplicación de un ámbito TIC. Posteriormente hay que registrarla en JIRA, lo cuál lo hará el RP, el RF o el proveedor. La mejora pasa a ser creada en "Wishlist". El proceso continúa en Revisar mejora.

Por otro lado, existe la posibilidad de que la mejora no se registre en JIRA, sino que cualquier usuario pueda registrarla en área personal de ayudaDIGITAL. En este caso la mejora queda en estado "Abierta" y se replicará de forma automática en JIRA en estado "Wishlist" asignada al Responsable de Producto para evaluarla. Cuando se replica en JIRA, se incluirá de forma automática la fecha de registro, el usuario peticionario y el código de solicitud que aparece en la aplicación en la que se ha registrado la mejora, junto con los documentos que hayan sido adjuntados por el peticionario. Una vez que esta mejora se ha replicado en JIRA el proceso continúa en Revisar mejora.


Revisar mejora

Una vez la mejora está en "Wishlist", el RP o el RF son los encargados de analizar y determinar si se aprueba o no la mejora. Si la mejora no se aprueba será necesario establecer la causa de la no aprobación, que podrá ser por rechazo de la mejora propiamente dicho o porque sea necesario escalar a CSU para su correcta tipificación. Opcionalmente se puede indicar la urgencia de la mejora mediante la edición de la misma.

En el caso de que se apruebe, el estado de la mejora  pasa a "Backlog". En área personal de ayudaDIGITAL pasa de "Abierta" a "Cerrada" y se envía al peticionario un mensaje en el que se le informa de que su mejora va a ser tenida en cuenta y se implantará en futuras versiones. 

  • Mensaje al usuario: Desde el equipo responsable de la aplicación le agradecemos su colaboración. Tras analizar su propuesta de mejora, consideramos que ésta aporta valor y va en consonancia con las líneas estratégicas marcadas. Por tanto, será incluida en próximas versiones. Un cordial saludo.

Si se decide NO continuar con la mejora en Backlog, el proceso sigue en A Wishlist. Si se decide continuar con la mejora en Backlog, el proceso continúa en Asociar/desasignar. 

Destacar que existe la posibilidad de clonar la mejora y asignarla a aplicaciones del mismo ámbito. 

Por el contrario, si la mejora no se aprueba, el estado pasa a ser "Cerrada", indicando la causa de la no aprobación. 

  • Si la causa de no aprobación es que necesita escalarse a CSU, se indica el motivo del escalado: que no sea mejora, que lo sea pero la aplicación no sea la correcta u otros. En este caso, el estado final en JIRA será "Cerrada" con resolución "Escalada". En área personal de ayudaDIGITAL permanecerá en estado "Abierta" y en el registro de actividad se informará al usuario final que su mejora ha sido escalada para su correcta gestión.
  • Si la causa de no aprobación es el propio rechazo de la mejora, deberá indicarse el motivo del rechazo (se traducirá en un mensaje de correo electrónico que será enviado al peticionario). En este caso, el estado final será "Cerrada" con resolución "Rechazada". Distintos casos de rechazo con su correspondiente mensaje al usuario:
    • No compatible con la estrategia de evolución. 
      • Mensaje al usuario: Desde el equipo responsable de la aplicación le agradecemos su colaboración. Analizada su solicitud, sentimos comunicarle que no podemos atenderla ya que no se ajusta a la estrategia diseñada para la evolución de la aplicación. Seguimos trabajando para dar respuesta a todas las necesidades de la organización y esperamos que las mejoras que se introduzcan faciliten su labor. Un cordial saludo.
    • Funcionalidad ya detectada.

      • Mensaje al usuario: Desde el equipo responsable de la aplicación le agradecemos su colaboración. Tras analizar su solicitud, le comunicamos que en siguientes versiones su necesidad quedará cubierta o no será necesaria por otras mejoras que se implementarán. Un cordial saludo.


Asociar/Desasignar

En el caso de que se tenga una mejora, ya sea en estado "Backlog" o "En versión", el Responsable de Producto puede incluir dicha mejora una de las versiones abiertas o desasignarla de una determinada versión.

Para este primer caso, las versiones pueden estar en estado "Abierta" o "En resolución" . En esta última situación, se incrementará el contador de cambios de alcance funcional de la versión. Una vez que la mejora ya está asignada a una versión, será posible asociarla a las OTs que se hayan solicitado para esa versión, teniendo en cuenta que para las OTs con crédito disponible será posible mientras el estado sea "Pte. calendarizar". En el caso de que las OTs sea con estimación, será posible asociar la mejora hasta que las OTs lleguen al estado "Estimada", estado en el que ya no será posible la asociación. Aquí el estado de la mejora pasa de "Backlog" a "En versión". Una vez que se cierre la PL asociada de la versión en la que se ha incluido la mejora correspondiente, el estado de la misma pasa de "En versión" a "Cerrada".

Para el segundo caso, se desasignar la mejora de la versión a la que esté asociada. El contador de cambios de alcance funcional funciona igual y el estado de la mejora pasa de  "En versión" a "Backlog".



Versión  

  

Descripción del proceso


Es el proceso a través del cual se trata de gestionar de manera conjunta de las mejoras aprobadas (mejoras del Backlog) y las incidencias resueltas (incidencias del Backlog) pendientes de implantación. Es la unidad de gestión del Responsable de Producto y debe estar creada con anterioridad a la inclusión de mejoras e incidencias.

El RP debe indicar una fecha deseada de puesta en producción de esa versión y generar la previsión de la ejecución, opcionalmente podrá realizarlo con el soporte de una OTEVS. Cuando se solicita un EVS el RP puede actuar por delegación del Responsable de Área o no, con la diferencia de que si el RP actúa por delegación decide si se realiza la realización del mismo o no, mientras que, si no actúa por delegación, es el RA quien decide la realización del EVS. En ambos casos, el encargado de aprobar o rechazar el trabajo que realiza el proveedor es el RP.

Si se ha solicitado un EVS, el resultado del mismo se comunicará a la versión desde la que ha sido solicitada, de manera que dará como resultado un EVS aprobado del que el RP podrá sacar los datos para completar la previsión de la ejecución. No hay restricción en el número de EVS solicitados, la única condición es que no puede haber más de un EVS abierto al mismo tiempo.

Una vez realizada la previsión, con mejoras e incidencias, el RP puede comenzar la versión. Al igual que al solicitar el EVS, puede comenzar por delegación del Responsable de Área o no. Si actúa por delegación del RA, podrá empezar a solicitar OTs al proveedor sobre esta versión. En el caso de que no actúe por delegación, será el RA quien determine si comenzar o cancelar la versión. Una vez decida comenzar, pasará el testigo al RP, que podrá actuar como si hubiera comenzado por delegación.

Una vez comenzada la versión, el RP puede asignar y desasignar mejoras e incidencias hasta que la PL se haya cerrado. Estas asignaciones/desasignaciones conllevan el incremento de un contador de cambio de alcance para las mejoras.

El RP deberá determinar siempre el código de versión (3 dígitos), independientemente de si la versión requiere generar una PL o no. En caso positivo, la PL heredará dichos dígitos.

Una vez recibido el fin de la PL o que se finalice la versión si es que no necesita PL, las mejoras e incidencias se cerrarán automáticamente en JIRA. Las incidencias deberán ser revisadas por el solicitante en área personal de ayudaDIGITAL. Si el usuario no está conforme, el objeto se puede volver a reabrir  pero no podrá volver a entrar como objeto en JIRA. Es decir, la relación, será 1 a 1 entre objeto CA SDM y objeto JIRA.

En estado "Implantada" no hay posibilidad de cancelar la versión.


Diagrama del proceso


Loading...

draw.io

Diagram attachment access error: cannot display diagram


     

Diagrama de estados


Loading...

draw.io

Diagram attachment access error: cannot display diagram


    

Etapas del proceso


Registrar

Se tiene la necesidad de registrar una versión nueva para implantar de manera conjuntada distintas mejoras y/o incidencias. El Responsable de Producto registra la versión sobre una de sus aplicaciones indicando el código de 3 dígitos. Este código será nuevo, no pudiendo registrar ni numeraciones existentes ni ninguna numeración que sea mayor que la menor existente. Esta acción puede realizarse mientras la versión esté en estado "Abierta" o "En resolución", de manera que el registro es obligatorio sólo cuando se vaya a acceder a la actividad Generar PL. 

El RP también debe identificar la fecha fin deseada de puesta en producción de la versión pudiendo registrar en ese momento la previsión de la ejecución si no necesita solicitar un EVS. Al registrar la versión se genera una tabla mensualizada con tres anualidades completas a partir del año en curso. Al igual que para el caso del código de la versión, no es obligatorio hacerlo en este momento siempre y cuando que quede hecho antes de ejecutar la acción

 

Comenzar.

La versión pasa a "Abierta".  Ya en estado "Abierta", la versión tiene varios atributos:

  • Código de versión: Completada en registro (si ha sido completada).
  • Fecha fin deseado: Completada en registro.
  • Se genera una previsión por cada mes del plazo de ejecución previsto. Para cada previsión pueden estimarse las HBS que debe incurrir el proveedor para luego poder comparar con las realmente incurridas si es que NO es necesario solicitar un EVS. En el caso de que sea necesario, antes debe haber al menos una mejora o incidencia incluida en la versión.

El proceso continúa en Gestionar alcance.


Gestionar alcance

Teniendo una versión "Abierta" o"En resolución", tanto el Proveedor como el RP pueden incluir incidencias, pero solo este último puede añadir mejoras que estén en estado Backlog. En el caso de que el estado de la versión sea "En resolución", cada vez que se asigne o desasigne una mejora, se incrementará el contador de cambio de alcance.

Las incidencias y mejoras que sean asignadas a la versión pasarán de estado "Backlog" a "En versión". El cambio de estado será el contrario para aquellas incidencias y mejoras que se desasignen de la versión. Por otro lado, en WT las incidencias continúan en estado "Pendiente de implantar".

Si es necesario un EVS, el proceso continúa en Solicitar EVS. Si por el contrario, NO hace falta solicitar un EVS, se pasa a Calendarizar.


Solicitar EVS

Ya con la versión "Abierta" con mejoras e incidencias incluidas (al menos una), hay que indicar: el crédito disponible (HBS), la fecha de inicio y fin deseadas, marcar check si el EVS está aprobado por delegación del RA (por defecto sale marcado NO) e indicar la prioridad del EVS, que podrá tener tres valores: P1, P2 y P3, siendo P1 la más urgente.

Respecto a las transiciones de estado, la versión pasa a "Pte. aprobar" si permanece el NO marcado por defecto. En este caso, el EVS quedará asignado al RA. Continúa por  Revisar EVS. O la versión pasa a "Pte. calendarizar" si se ha marcado el check como SÍ, con lo que el EVS está aprobado por delegación del RA. En este caso, el EVS quedará asignado al proveedor. Continúa por Calendarizar .

(estrella) NOTA: Un EVS puede solicitarse en cualquier momento y puede pedirse para varias versiones.(estrella)


Revisar EVS

Una vez se tiene el EVS informado con prioridad, crédito disponible, fechas de inicio y fin deseadas y prioridad, hay que proceder a revisar y modificar mediante edición, la prioridad del EVS y decidir si se autoriza o no. 

Si se aprueba y autoriza, la versión pasa de "Pte. aprobar" a "Pte. calendarizar". Continuando por  Calendarizar. Si por el contrario no se aprueba, la versión pasa a "Cerrada" con resolución "No aprobada-RA". En este caso, para la versión para la que se solicitó ese EVS puede volver a solicitar tantos EVS como quiera.


Calendarizar

Con el EVS ya aprobado o sin EVS puesto que no ha sido necesaria su realización, hay que indicar fechas de inicio y fin estimadas según la gestión de capacidad del proveedor. Una vez el proveedor realiza dicha calendarización, la versión pasa a estado "Pte. comenzar resolución". El proceso sigue en Comenzar resolución.


Comenzar resolución

Cuando el EVS está ya calendarizado, con crédito disponible y asignado al proveedor, automáticamente se genera la tabla de mensualizaciones para el desglose de las HBS por mes y se registra la fecha real de inicio de los trabajos. Es posible que en ese momento el proveedor registre las HBS mensualizadas y pueda acceder directamente a resolver la OT. Deberá registrar igualmente las HBS restantes que calcularán directamente el grado de avance.

Aquí la versión pasa a "En resolución". Continúa en  Seguimiento OT.

 

Seguimiento OT

Como ya se tienen las OTs con tabla de mensualizaciones y en la que se ha comenzado a trabajar, el proveedor tiene que desglosar las HBS incurridas por mes. Este proceso puede hacerse tantas veces como el proveedor quiera, de manera que cuando acceda a resolver la OT, la suma de las HBS mensualizadas coincidan con las HBS incurridas en la OT. También tiene que r egistrar las HBS restantes, de manera que se calculará el grado de avance económico y, registrar grado de avance técnico.

No hay cambios de estado. El proceso pasa a Resolver OT.


Resolver OT

El proveedor tiene las OTs registradas y asignadas u OTs no aceptadas por el RP. Por tanto, tiene que pasar a proporcionar obligatoriamente la ubicación de los entregables de salida, a i ndicar las HBS reales de resolución, que en caso de no haber sido aceptada por gestión podrán volver a incurrirse HBS, y a adjuntar el fichero de incurridos. Acción obligatoria la primera vez que se resuelve la OT y si la OT es no aceptada por el RP por rechazo en las HBS.

El estado pasa a ser "Pte. revisión-JP". Las OTs pasan a ser revisadas en el siguiente paso,  Revisar resolución OT por RP.


Revisar resolución OT por RP

El RP es el que va a proceder a revisar el EVS con las OTs. Para ello, revisa el EVS y registra de forma obligatoria la alternativa y la reserva de HBS, con posibilidad de poder elegir la opción de ninguna de las propuestas y de reservar 0 HBS. 

  • Si no acepta el EVS, debe especificar el o los motivos de rechazo, ya sea por entregables,  por gestión (HBS y grado de avance) o por entregables y gestión. Cada vez que el Responsable de Producto rechace la resolución del EVS se incrementará un contador dependiendo del motivo del rechazo. En el caso de que el rechazo obedezca al tercer motivo, se incrementarán los dos contadores (de rechazo por entregables y de rechazo por gestión).
  • Si acepta la resolución del EVS, quedan registradas las HBS incurridas. Si son mayores que el crédito disponible se puede o no justificar el desvío con objeto de que se aplique o NO la penalización al proveedor. En el caso de que el desvío esté justificado por el RP correspondiente, podrá indicar el motivo que justifique el desvío (cambios de alcance, otros, etc). De la misma forma, puede aceptar o no y justificar en el primer caso la desviación entre la fecha fin estimada y la fecha fin real.

Aquí el proveedor puede incurrir nuevas HBS tras la resolución de la OT, indicando el motivo de la nueva imputación y volviendo a adjuntar el fichero de incurridos.

Si NO se acepta la resolución del EVS, la versión pasa a "No aceptado JP". Si una vez se rechaza el EVS, se quiere cancelar la versión, el proceso continúa en  Cancelar versión, si NO se quiere cancelar, el proceso se retoma de nuevo por Resolver OT.

Si se acepta la resolución del EVS, la versión pasa a "Aceptado JP", finalizando el proceso del EVS y continuando por Completar previsión ejecución y versión.


Cancelar versión

La versión, revisada por RA/RP, en estado "Abierta" o "En resolución" , se va a cancelar. El RA o el RP decide que no se va a implantar y completa un mensaje con el motivo de la cancelación. Es condición indispensable para cancelar la versión que si existen OTs asociadas, todas y cada una de ellas estén cerradas .

Respecto a la transición de estado, pasa a "Cerrada" (resolución Cancelada) y las incidencias y mejoras asociadas pasan a estado "Backlog".  Continúa por  Desasignar mejoras e incidencias.


Desasignar mejoras e incidencias

Una vez se tiene la versión finalmente cancelada, se pasa a desasignar las mejoras o incidencias asignadas a la versión que se ha cancelado.

No hay cambio de estado para la versión, l as mejoras e incidencias pasan a estado "Backlog" y en WT las incidencias permanecen en estado "Pte de implantar".

 

Completar previsión ejecución y versión

Ya con la versión abierta, que puede o no tener mejoras e incidencias incluidas, y al menos un EVS aprobado, el Responsable de Producto debe completar la previsión de ejecución.

Los datos de previsión de ejecución consisten en la reserva de recursos necesarios en HBS de la versión mensualizados durante el periodo que se estima que duraría la versión previa a su cierre y que son necesarios para la gestión de la capacidad. Los meses que no tengan previsión quedarán a 0. El RP también puede decidir cancelar la versión.

No hay cambio de estado. 

El proceso prosigue en Comenzar versión. Si el RP decide cancelar la versión, el proceso pasa a Cancelar versión.


Comenzar versión

Tras tener la versión con la previsión realizada y las mejoras e incidencias incluidas (al menos una), se procede a comenzarla. Una vez que se accede a esta acción, la versión quedará asignada al RP para que prosiga con su gestión. El estado pasa a ser "En resolución" y el siguiente paso es Solicitar OT.


Solicitar OT

Como la versión ya está en proceso de resolución, tanto el Responsable de Producto como el Proveedor podrán solicitar tantas OTs como estimen necesario, seleccionando el tipo de OT que quieren solicitar, siendo únicamente permitidas para el proveedor las OTs que conlleven una estimación por su parte y que posteriormente requieran aprobación. 

No hay cambio de estado. El proceso continúa con las diferentes OTs y una vez se realicen, dependiendo de si hace falta generar una PL o NO, el procedimiento sigue en el paso Generar PL o en Finalizar versión. 

(advertencia) Todo el desarrollo en cuanto al procedimiento de las OTs y de las PLs se explicará en sus propios apartados, incluidos en  Orden de Trabajo y Gestión de Lanzamientos   (advertencia)


Generar PL

Con la versión en resolución y el código de tres dígitos de la versión informado de forma obligatoria, el RP lanza la integración de la PL. Al generarse, el RP puede seguir gestionando alcance y solicitando OTs (podrán ser igualmente solicitadas por el proveedor en el caso de que lleven estimación).

El estado continúa siendo "En resolución". Cada vez que se asocie o desasigne una mejora o una incidencia, el contador de cambio de alcance se incrementará y el proceso podrá dirigirse a Gestionar alcance. El proceso continúa en Esperar FIN PL. 

 

Esperar FIN PL

El sistema recibe la notificación de que la PL está abierta y la gestiona hasta su cierre de manera automática.

Si la versión tiene incidencias se ejecuta el proceso Gestión cierre para gestionar el cambio de estado de las incidencias contenidas en la versión en otros sistemas (CSU, área personal de ayudaDIGITAL y WT). Respecto a las transiciones de estado de la versión, esta pasa de "En resolución" a "Implantada" y las mejoras e incidencias contenidas en la versión pasan de estar en estado "En versión" a estado "Cerrada". El proceso sigue por Esperar FIN OT.

 

Gestión Cierre

Con la notificación de que la PL está cerrada, se gestiona el cierre de las incidencias en todas las demás plataformas. Por ello las transiciones de estado que tienen que realizarse son:

    • En área personal de ayudaDIGITAL: De "Pte. implantar" a "Pte. confirmación cierre".
    • En WT: De "Pte. implantar" a "Pte. confirmación cierre".
    • En CSU: De "Pte. implantar" a "Fijada" para las incidencias.


Esperar FIN OT

Como la versión ya está en estado "Implantada", la aplicación queda a la espera de que finalicen todas las OTs asociadas a la versión. Una vez esto ocurra, la versión finalmente pasa a estado "Cerrada". El proceso finaliza ya en el último paso, Finalizar versión.


Finalizar versión

Con todos los procedimientos anteriores hechos, el RP cierra manualmente la versión.  Además, el sistema informará de que la versión se va a finalizar sin generar RFC. En este caso, será en este momento cuando mejoras e incidencias pasen a estar cerradas. El sistema almacenará la fecha fin real.

Si NO todas las OTs están finalizadas, se mantiene en estado "En resolución". Si todo está cerrado, finalmente se finaliza el proceso.



Orden de trabajo


Orden de trabajo con crédito disponible (OTR/OTEquipo/OTEVS/OTInm/SVT/PST)


Descripción del proceso


La orden de trabajo es la unidad mínima de trabajo planificada que resuelve el proveedor y que solicita el Responsable de Producto. Incluye los tipos: OTEVS, OTR, OTEquipo, OTInm, SVT, PST.

  • La orden de trabajo de EVS (OTEVS) es una orden de trabajo que se realiza para obtener la Previsión de la ejecución de la versión y sólo podrá registrarse si la versión se encuentra en estado "Abierta". Tiene un flujo especial puesto que puede ser aprobada y aceptada bien por el Responsable de Área o por el Responsable de Producto si actúa por delegación. Su flujo se ha definido al definir el de la versión.
  • La orden de trabajo de requisitos (OTR) se solicita con el objetivo de definir los requisitos de la versión.
  • La orden de trabajo Equipo (OTEquipo), es una orden de trabajo que incluye: Requisitos, Análisis, Diseño, Construcción y se usa para aquéllas versiones que quieren que sigan un ciclo de vida ágil.
  • La orden de trabajo inmediata (OTInm) tiene la misma filosofía que la OTEquipo y se usa fundamentalmente para las versiones de casos inminentes. Su uso no es muy recomendable. 

Las OTR, OTEquipo y OTInm podrán registrarse si la versión se encuentra en estado "En resolución" o "Implantada".

  • La SVT es un tipo de OT que no está ligada a una aplicación. Sólo puede ser creada por personal de la DGSIC, no por el proveedor.

No existirá límite sobre orden ni límite de OTs. Como excepción para las OTEVS, decir que no tienen que ir forzosamente ligadas a una versión y pueden además afectar a versiones de diferentes aplicativos.

Al solicitar cualquier tipo de estas OTs, el Responsable de Producto debe indicar un techo de gasto en HBS disponible para resolverla (Crédito disponible), fechas de inicio y fin deseadas, qué entregables opcionales deberá aportar (si aplica) en cada tipo de OT y el lugar donde están ubicados los entregables de entrada, que es Gestión del Conocimiento.

El proveedor debe revisar el calendario de fechas que propone el Responsable de Producto, registrando las fechas de inicio y fin estimadas según su capacidad. Y procederá a comenzar la resolución cuando le sea posible, desglosando las HBS por meses.

Al finalizar cualquier tipo de estas OTs, el proveedor deberá incurrir las HBS reales, adjuntar fichero de incurridos por perfiles e indicar en qué ubicación ha dejado los entregables obligatorios y opcionales solicitados.

Finalmente se debe aceptar y cerrar la OT. El Responsable de Producto acepta o no la OT, lo que implica aceptar los entregables y las HBS incurridas por el proveedor. Si existiera desvío respecto al crédito disponible, el Responsable de Producto podrá justificar o no este desvío. Si lo justifica, deberá indicar el motivo de ese desvío (cambio de alcance, etc.). En el caso de que el RP no justifique el desvío, el proveedor tendrá penalización. En el caso de que exista desvío entre la fecha fin real y la fecha estimada por el proveedor, el Responsable de Producto deberá indicar igualmente si acepta o no ese desvío.

Desde cualquiera de los estados es posible por parte del RP cancelar la OT. En El caso en que no se haya llegado a estado "En resolución" , la cancelación sólo supondrá que la entidad pase a estado "Cerrada" con resolución "Cancelada". 


Diagrama del proceso


Loading...

draw.io

Diagram attachment access error: cannot display diagram



Diagrama de estados


Loading...

draw.io

Diagram attachment access error: cannot display diagram




Etapas del proceso

 

Crear OT

Hay una necesidad de OT para ser incluida directamente en una versión, por lo que hay que crearla y asignarla a la versión. Si se crea directamente debe seleccionarse una OT con crédito disponible. Para el caso de la SVT sólo podrá crearse de esta forma al no estar asociada ni a una aplicación ni a una versión.

A la hora de crearla, hay que indicar la estimación (Crédito disponible, Fecha de inicio deseada y Fecha de fin deseada), los entregables requeridos y la ubicación de entregables de entrada (si se considera oportuno). También hay que asociar mejoras e incidencias incluidas en la versión (Esta acción no es válida para la SVT) y tener presente que las incidencias sólo pueden asociarse con OTs de tipo Implantación.

Respecto a la transición de estado, la OT pasa a "Pte. calendarizar". El proceso continúa en Calendarizar.


Calendarizar

Una vez que la OT está registrada y asignada al proveedor, este debe indicar las fechas de inicios y fin estimadas según la gestión de su capacidad.

Realizado este paso, la OT pasa a estado "Pte. comenzar resolución". Saber que Con el cambio de estado se elimina la posibilidad de asociar o desasociar mejoras/incidencias. 

El procedimiento sigue en Comenzar resolución.


Comenzar resolución

Tras tener una OT con crédito disponible, calendarizada y asignada al proveedor, se registra la fecha real de inicio de los trabajos. Es posible que en ese momento el proveedor registre las HBS, sumándose estas a la previsión de la versión de ese mismo mes, y pueda acceder directamente a resolver la OT. El proveedor además, debe informar desde este momento las HBS restantes, lo que calculará el grado de avance en coste.

La OT comienza a estar en estado "En resolución".  En el caso de iniciarse el proceso de la OT, el proceso continúa en Seguimiento OT. Si por el contrario ya estamos en iteraciones del proceso, si se aceptan las HBS y el grado de avance, se procede al paso Resolver OT y, si NO se aceptan, se pasa a Seguimiento OT.


Seguimiento OT

En esta acción, el proveedor realiza una simulación de como resultaría la OT en el caso de que se acabase en ese mismo instante con los avances realizados hasta ese perciso momento. También debe informar de las HBS restantes, lo que calculará el grado de avance económico.

No hay cambio de estado y el procedimiento sigue en Resolver OT.



Resolver OT

Después de que la OT esté registrada y asignada al proveedor o de que la OT no se acepte por el RP, el proveedor proporciona la ubicación de los entregables de salida, indica las HBS reales de resolución, en el caso de no haber sido aceptada por gestión podrán volver a incurrirse HBS, y adjunta el fichero de incurridos. Esta última acción es obligatoria la primera vez que se resuelve la OT y si la OT es no aceptada por el RP debido a un rechazo en las HBS.

El estado pasa a ser "Pte. revisión- JP" y el proceso sigue en Revisar resolución OT por RP.

 

Revisar resolución OT por RP

Teniendo como entrada  una OT pendiente de revisión por RP o una OT rechazada por el RP por gestión y corregida por el proveedor, las acciones a realizar son la propia revisión de la OT por parte del RP y, en el caso de la NO aceptación, especificar el/los motivos de rechazo: rechazo por entregables, por gestión (HBS y grado de avance) o por entregables y gestión.

Cada vez que el Responsable de Producto rechace la resolución de la OT se incrementará un contador dependiendo del motivo del rechazo. En el caso de que el rechazo obedezca al tercer motivo, se incrementarán los dos contadores (de rechazo por entregables y de rechazo por gestión).

Si acepta la resolución de la OT, y las HBS aprobadas son mayores que las estimadas, se puede o no justificar el desvío con objeto de que aplique o no la penalización al proveedor. En el caso de que el desvío esté justificado por el Responsable de Producto correspondiente, podrá indicar el motivo que justifique el desvío (cambios de alcance, otros, etc). De la misma forma, puede aceptar o no y justificar en el primer caso la desviación entre la fecha fin estimada y la fecha fin real, con lo que se aplicará o no penalización al proveedor.

Respecto a las transiciones de estado, la OT pasa de "Pte. revisión-JP" a "No aceptada JP" si no se acepta la OT tras la revisión del Responsable de Producto. Si volver a resolver la OT por parte del proveedor no implica actualizar el seguimiento de la misma, continúa en Resolver OT. Si al volver a resolver la OT el proveedor necesita actualizar HBS o grado de avance de la misma, continuar por Seguimiento OT. Si se acepta la OT tras la revisión del Responsable de Producto, la OT pasa a "Cerrada", finaliza el proceso y de manera automática se comunica el fin de la OT a la versión en la que está incluida.


Cancelar OT

Desde cualquiera de los estados de la OT va a ser posible por parte del RP la cancelación de una OT. Si la OT no ha llegado al estado "En resolución" el RP puede cancelar indicando el motivo de la cancelación y si la OT está en estado "En resolución" el RP tiene que acceder a la acción de cancelar, pasando el estado a ser "Pte. cancelación". 

A continuación, con la OT pendiente de cancelación, el proveedor debe incurrir las HBS, el grado de avance técnico y las HBS restantes, indicando también la ubicación de los entregables realizados hasta el momento. Pasando ahora la OT a estado "Pte. revisión cancelación". 

Por último, el RP tiene que revisar si las imputaciones y los entregables suministrados por el proveedor se aceptan o no. De forma que, las transiciones de estado son: de "Pte. revisión cancelación" a "Cerrada" con resolución Cancelada si se acepta la cancelación de la OT o de "Pte. revisión cancelación" a "Pte cancelación" si no se acepta la cancelación. 




Orden de trabajo con estimación del proveedor (A/D/C/IMPL/AD/ADC/SVT)


Descripción del proceso


La orden de trabajo con estimación del proveedor se solicita con el objetivo de realizar el análisis, diseño, construcción, implantación o análisis y diseño, o análisis, diseño y construcción de la versión.
Respecto a la creación de estas OTs, sólo podrán solicitarse si la versión se encuentra en estado "En resolución" o "Implantada" y al crearlas de manera independiente sólo podrán asociarse a versiones en los estados anteriormente mencionados, a excepción de la SVT, que sólo puede crearse de manera independiente y que no está asociada a ninguna aplicación ni por tanto a una versión. Todas los que no sean de tipo SVT pueden ser solicitadas por el proveedor y no existe límite sobre orden ni límite de OTs. 

Al solicitar cualquier tipo de estas OTs, el Responsable de Producto (o el proveedor) aportará las entradas necesarias para que el proveedor realice una estimación inicial (HBS estimadas y fechas de inicio y de fin estimada) y resuelva la OT e indicará tanto los entregables requeridos, ya sean por defecto como adicionales, como opcionalmente, el lugar donde están ubicados los entregables de entrada.

En todas las que no son de tipo SVT es posible, siempre y cuando el proveedor no haya estimado, asociar la OT con las mejoras o incidencias incluidas en la versión con dos restricciones:

  • El proveedor sólo puede asociar mejoras en las OTs que hayan sido creadas por él.
  • Las incidencias sólo pueden ser asociadas a OTs del tipo Implantación.

Luego comenzará la fase de estimación donde el Proveedor realizará una estimación inicial e indicará la fecha hasta la que esa estimación es válida. El Responsable de Producto deberá aprobarla antes de comenzar la resolución y, una vez aprobada, el Proveedor mensualizará las HBS para la gestión de la capacidad.

Al finalizar cualquier tipo de estas OTs, el proveedor, realizará entre otras acciones que serán: incurrir las HBS reales, que coincidirán con la suma de HBS mensualizadas, adjuntar fichero de incurridos por perfiles e indicar en qué ubicación ha dejado los entregables requeridos.

Finalmente tiene acciones de aceptación y cierre donde el RP acepta o no la OT y acepta, si lo considera necesario, el desvío HBS incurridas frente a las estimadas y duración (de existir desvío). En el caso de desvío en HBS, puede o no justificar el mismo. Si lo acepta, indicando el motivo, no aplicará penalización alguna para el proveedor.

Al igual que para las OTs con crédito disponible, es posible cancelar la OT en cualquier estado por parte del Responsable de Producto siempre que no se haya concluido su resolución, es decir, si la OT no ha llegado a ser estimada, el Responsable de Producto podrá cancelarla indicando el motivo de cancelación, y si la OT ha llegado a estar estimada, aprobada o no, el Responsable de Producto podrá imputar HBS tras llegar a un acuerdo con el proveedor.

NOTA: Indicar que el proveedor sólo podrá cancelar aquellas OTs creadas por él mismo y siempre antes de llegar a estimarlas. No podrá imputar HBS en estas OTs.


Diagrama del proceso


Loading...

draw.io

Diagram attachment access error: cannot display diagram



Diagrama de estados


Loading...

draw.io

Diagram attachment access error: cannot display diagram



Etapas del proceso


Crear OT

Con la versión lista para solicitar OTs, estas se podrán empezar a lanzar pero sólo si la versión está en estado "En resolución" o "Implantada". En este paso por tanto, se crean OTs relacionadas con la versión. Primero tener en cuenta que las OTs se crean de forma independiente, por ello es necesario identificar si es de tipo con o sin estimación por parte del Responsable de Producto. Luego hay que indicar el tipo de OT, ya sea de Análisis, Diseño, Análisis-Diseño, Construcción, Análisis-Diseño-Construcción, Implantación o SVT. También indicar los entregables requeridos, la ubicación de entregables de entrada, si se considera oportuno, y asociar mejoras e incidencias incluidas en la versión. Esta acción no es válida para la SVT. Recordar que las incidencias sólo pueden asociarse con OTs de tipo Implantación.

Respecto a la transición de estado, la OT pasa a "Pte. estimar". El procedimiento continúa en Revisar OT.

 

Revisar OT

Ahora, ya con la OT registrada, el Proveedor la revisa para verificar que dispone de la información necesaria para estimarla y resolverla.

En el caso de que el proveedor considere que necesita más información para realizar la estimación, la OT pasa a "Pte. información JP" y el paso siguiente es Completar información. Sin embargo, si va a continuar con la estimación, el estado se mantiene en "Pte. estimar" y el proceso continúa en Estimar OT.

 

Completar información

Tras estar la OT revisada, el RP debe aportar la información necesaria para realizar la estimación. Pasando así la OT a estado "Pte. estimar" y continuando en Revisar OT.


Estimar OT

Aquí se tiene la OT revisada (tanto de nueva creación como con estimación caducada o de estimación no aprobada por RP) y hay que pasar a estimarla en base a la entradas proporcionadas e indicar las HBS estimadas, las fechas de inicio y fin estimadas, la fecha de caducidad de la estimación (que, como mínimo, tiene que ser un día después de la fecha en la que se realiza la estimación y como máximo un día antes de la fecha de inicio estimada) y adjuntar de forma obligatoria un archivo de estimación por perfiles.
Una vez realizado todo, pasa a estado "Estimada" y se asigna al Responsable de Producto para su revisión. A partir de este estado no es posible asociar /desasociar mejoras e incidencias con la OT. El proceso sigue en Revisar estimación.


Revisar estimación

Con la estimación de la OT por parte del Proveedor, el RP tiene que revisar la estimación para aceptarla o rechazarla. Tener en cuenta que, transcurrido el periodo de validez, sólo podrá volver a solicitar una nueva estimación y que el periodo de validez acaba a las 00:00 horas del día indicado como fecha de caducidad de la estimación.

Si se rechaza la estimación, la OT pasa a estado "Pte. Estimar" y el proceso continúa en Estimar OT.

Si el periodo de validez ha finalizado, es decir, la estimación ha caducado, la OT pasa a "Pte. solicitar nueva estimación" de manera automática y se pasa al apartado Solicitar nueva estimación.

Si la estimación se aprueba, la OT cambia al estado "Pte. comenzar resolución" y el proceso sigue en Comenzar resolución.


Solicitar nueva estimación

Tras producirse la caducidad de una estimación hecha por el proveedor, el RP solicitar una nueva estimación. Esto conlleva que la OT pase a estado "Pte. Estimar-Caducada" y a la acción Estimar OT.


Comenzar resolución

Una vez que la OT con estimación ha sido aprobada por el Responsable de Producto, queda lista para que el proveedor comience su resolución. 

La OT entra en estado "En resolución", donde el proveedor puede registrar las HBS y resolver. Opcionalmente, el proceso puede continuar en Seguimiento OT en el caso de que el proveedor quiera simular como va la OT.  Si estamos en iteraciones del proceso y se aceptan tanto las HBS como el grado de avance, se procede al paso Resolver OT.


Seguimiento OT

En esta acción, el proveedor realiza una simulación de como resultaría la OT en el caso de que se acabase en ese mismo instante con los avances realizados hasta ese preciso momento. También debe informar de las HBS restantes, lo que calculará el grado de avance económico.

No hay cambio de estado y el procedimiento sigue en Resolver OT.


Resolver OT

Después de que la OT esté registrada con las HBS incurridas, el grado de avance actualizado y asignada al proveedor, este debe realizar las tareas necesarias para resolverla, así como proporciona la ubicación de los entregables de salida, indica las HBS reales de resolución, en el caso de no haber sido aceptada por gestión podrán volver a incurrirse HBS, y adjunta el fichero de incurridos. Esta última acción es obligatoria la primera vez que se resuelve la OT y si la OT es no aceptada por el RP debido a un rechazo en las HBS.

El estado pasa a ser "Pte. revisión- JP" y el proceso sigue en Revisar resolución OT por RP.


Revisar resolución OT por RP

Teniendo como entrada  una OT pendiente de revisión por RP o una OT rechazada por el RP por gestión y corregida por el proveedor, las acciones a realizar son la propia revisión de la OT por parte del RP y, en el caso de la NO aceptación, especificar el/los motivos de rechazo: rechazo por entregables, por gestión (HBS y grado de avance) o por entregables y gestión.

Cada vez que el Responsable de Producto rechace la resolución de la OT se incrementará un contador dependiendo del motivo del rechazo. En el caso de que el rechazo obedezca al tercer motivo, se incrementarán los dos contadores (de rechazo por entregables y de rechazo por gestión).

Si acepta la resolución de la OT, y las HBS aprobadas son mayores que las estimadas, se puede o no justificar el desvío con objeto de que aplique o no la penalización al proveedor. En el caso de que el desvío esté justificado por el Responsable de Producto correspondiente, podrá indicar el motivo que justifique el desvío (cambios de alcance, otros, etc). De la misma forma, puede aceptar o no y justificar en el primer caso la desviación entre la fecha fin estimada y la fecha fin real, con lo que se aplicará o no penalización al proveedor.

Respecto a las transiciones de estado, la OT pasa de "Pte. revisión-JP" a "No aceptada JP" si no se acepta la OT tras la revisión del Responsable de Producto. Si volver a resolver la OT por parte del proveedor no implica actualizar el seguimiento de la misma, continúa en Resolver OT. Si al volver a resolver la OT el proveedor necesita actualizar HBS o grado de avance de la misma, continuar por Seguimiento OT. Si se acepta la OT tras la revisión del Responsable de Producto, la OT pasa a "Cerrada", finaliza el proceso y de manera automática se comunica el fin de la OT a la versión en la que está incluida.


Cancelar OT

Ver procedimiento para las OTs con crédito disponible.



Entregables


Objetivos


Detallar una guía acerca de los entregables, a los actores de los distintos Ámbitos TIC, relativa a la Actividad Planificada.


Alcance


Afecta a todos los proveedores de desarrollo de software.  De acuerdo al Modelo de Gestión de Servicios en la DGSIC, existen una serie de órdenes de trabajo a través de la cual se demanda trabajo planificado a los proveedores. Concretamente son las siguientes órdenes de trabajo:  

    • OT EVS (OTEVS)
    • OT Requisitos (OTR)
    • OT Análisis (OTA)
    • OT Diseño (OTD)
    • OT Construcción (OTC)
    • OT Implantación (OTImpl)
    • OT Análisis y Diseño (OTAD)
    • OT Análisis, Diseño y Construcción (OTADC)
    • OT Equipo (OTEquipo)
    • OT Inmediata (OTInm)
    • SVT


Política


La política que rige a los Entregables de las OT identificadas en el alcance son: 

  1. Para cada una de las OTs existen una serie de Entregables de entrada y Entregables de salida.
  2. Si para una determinada entidad, un Entregable de entrada aparece también como salida, en la salida, el grado de completud será mayor, de acuerdo al trabajo que represente la OT a la que están vinculados en ese momento.
  3. Existirán una serie de Entregables obligatorios y otros opcionales.
  4. Los Entregables tienen distintos tipos de soporte (formato), entre ellos documentales.
  5. Los Entregables documentales, podrán tener plantillas las cuales están disponibles en el  Área de Servicios al Usuario y Gestión TIC.
  6. Los proveedores, para evitar desactualizaciones, deberán descargarse la plantilla del repositorio cada vez que hagan uso de ella.


Plantillas


Todas las Órdenes de Trabajo llevan asociadas una serie de plantillas referente a los entregables que conllevan. Estas plantillas las podemos encontrar en la página principal del espacio de Servicios de Gestión TIC que es una de las 4 divisiones del Área de Servicios al Usuario y Gestión TIC, dentro del apartado de Plantillas, en el punto  Entregables de las Órdenes de Trabajo. 

A continuación, se van a enumerar los entregables que están relacionados a cada tipo de OT de forma que se pueda establecer una relación clara OT-Entregable.

Para las OTs con crédito disponible:

  • OTEVS:
     [EVS] Estudio de viabilidad del sistema

  • OTR: 
    [REQ] Especificación de requisitos del Sistema (Proyecto Enterprise Architect)

  • OTEquipo y OTInm: tienen asociados todos los tipos de entregables que hay. 

  • PST: No tiene entregable asociado.


Para las OTs con estimación del proveedor:

  • OTA: 

    [ASI] Análisis del Sistema de Información (Proyecto Enterprise Architect)

    [PPF] Plan de Pruebas Funcionales (Proyecto Enterprise Architect)

    [DGT] Documento General de Entorno Tecnológico

  • OTD: 
    [DSI] Diseño del Sistema de Información

  • OTC: 
    [CSI] Código del Sistema de Información

    [RPF] Registro del Plan de Pruebas Funcionales

    [MDU] Manual de usuario

    [PIM] Plan de implantación

    [PID] Procedimiento de instalación y desinstalación
  • OTImpl: No tiene entregable asociado. 

  • OTAD, OTADC: Toda combinación de las órdenes de trabajo anteriores, tanto de la de análisis como la de diseño como la de construcción, llevan asociados tantos entregables como tenga cada uno. Por ejemplo, la OTAD al ser una Orden de Trabajo de Análisis y Diseño, lleva asociados los entregables referidos a la OTA y a la OTD, de forma que estos serían  [ASI] , [PPF] , [DGT]y [DSI].  



Metodología ágil


La metodología ágil es otra forma de gestionar las mejoras, su desarrollo y su inclusión en las versiones. En esta metodología, las mejoras aprobadas, junto con incidencias y no conformidades, se descomponen en historias de usuario, que constituyen el backlog del producto. Esas historias de usuario se priorizan e incluso se les da un peso, bien por puntos de historia o por horas estimadas, y se incluyen en un sprint, que es un miniproyecto de no más de un mes (ciclos de ejecución entre una y cuatro semanas), cuyo objetivo es conseguir un incremento de valor en el producto que estamos construyendo.  Una vez que se tienen las historias de usuario, el equipo puede descomponerlas en subtareas que van acometiendo y que pueden visualizarse en JIRA en una pizarra. Cuando ya se tengan  todas las subtareas de una historia de usuario cerradas, la historia podrá resolverse y pasar a ser validada. A los 15 días se hace una review de ese sprint y si funciona, se procede a realizar el siguiente. 

La gestión de los costes de un sprint se hace mediante una especie de proyecto (subproyecto en JIRA) al que se da un horizonte temporal y en el que se van sumando los costes de los diferentes sprints creados en el tiempo de ejecución del proyecto. La gestión de costes en un sprint se controla mediante la creación en la reunión de planning de una OTAgil, orden de trabajo de crédito disponible en la que se controlan los costes del equipo durante el tiempo que dure el sprint y que debe estar relacionada con el subproyecto en el que se quieran controlar los costes.

En cada uno de los sprints interviene la OCA y esto es debido a que el miembro de OCA que está trabajando con el equipo ágil realiza una serie de tareas que van destinadas a verificar todo lo que conlleva la entrega que se hace en el sprint. Estas tareas son: 

        1. Verificación uso Gitflow
        2. Verificación estructura del repositorio GIT
        3. Verificación y validación de calidad estática del código
        4. Verificación feature
        5. Detallar criterios de aceptación usando Gherkin
        6. Verificación cumplimiento DoR
        7. Verificación cumplimiento DoD

Estas tareas no siempre se realizan en su totalidad, depende cada caso. Posteriormente, de cara al despliegue de la mejora, es necesario crear una versión tal y como se realiza en la metodología en cascada.  
En cuanto a la Gestión del Conocimiento, se hace de manera ligeramente diferente. En el espacio de cada producto debe haber una página denominada "Metodología ágil" en la que se debe crear una pagina con el "Definition of Done" y "Definition of Ready" siguiendo las plantillas definidas. Además por cada sprint que se cree, será necesario crear una página con la planificación del sprint (plantilla Sprint Planning) y otra de retrospectiva (con la plantilla del mismo nombre) el día que se haga la review. Es aconsejable usar una macro de calendario de CONFLUENCE para controlar la disponibilidad del equipo durante el sprint (vacaciones, formación, dedicaciones parciales, etc).

Diagrama del proceso

 

Loading...

draw.io

Diagram attachment access error: cannot display diagram


 

Diagrama de estados

OT Ágil


Loading...

draw.io

Diagram attachment access error: cannot display diagram



Historias de usuario


Loading...

draw.io

Diagram attachment access error: cannot display diagram





Servicio de Validación Funcional (SVF)


Es un testing funcional de cara a la validación de las versiones que se realiza por parte de la OCA o de cualquier usuario que tenga rol OCA. De este testing se obtienen todos los errores OCA que se devuelven al proveedor para que los corrija antes de implantar en producción la versión. 

Su completo desarrollo, los procedimientos necesarios para llevarlos a cabo y los requisitos previos se encuentran explicados en la página de Servicio de Validación Funcional.


Loading...

draw.io

Diagram attachment access error: cannot display diagram



Loading...

draw.io

Diagram attachment access error: cannot display diagram







Petición de Plataforma (RFP)


Las Peticiones de Plataforma son solicitudes destinadas a la creación de las Plataformas tecnológicas necesarias para el despliegue de los diferentes aplicativos incluidos dentro del catálogo de aplicaciones. Son conocidas como RFP, es decir, Request For Platform y se llevan a cabo en JIRA. 

Su completo desarrollo, los procedimientos necesarios para llevarlos a cabo y los requisitos previos se encuentran explicados en la página de Gestión de Plataformas.




Petición de Lanzamiento (PL)


Las Peticiones de Lanzamiento son solicitudes de servicios de transición de instalaciones software como consecuencia del desarrollo y evolución de sistemas de información. Más conocidas como PL, se llevan a cabo en su totalidad en la plataforma de JIRA y están totalmente desarrolladas en la página de Gestión de Lanzamientos. Ahí se explican la PL de incremento de versión, la PL de sistemas, la PL de datos y la PL de configuración en su totalidad junto con el Servicio de Verificación de Entrega, el SVE, que es de vital importancia en este ámbito. Respecto a la PL de datos y a la PL de configuración, están en proceso de inclusión en esa página.

 

 

 

No conformidad (NC)


Las No Conformidades son todos aquellos fallos detectados en un entorno no productivo acerca del desarrollo de una versión. Es un equivalente a las incidencias pero en el entorno de pre-producción. Pasa por una serie de estados, el Responsable Funcional aprueba que se vaya a arreglar y es el Proveedor quien lo soluciona.

Al respecto de las No Conformidades, en el caso de que estas sean una incidencia en entorno no productivo, pasan a Backlog y se pasa a corregir de cara a una versión futura. Si por el contrario, esa No Conformidad surge debida a una determinada mejora no solicitada con anterioridad ni correctamente, pasa a Mejora.

Todo lo referente a su procedimiento, a sus características y a su función se encuentra desarrollado en Gestión de No Conformidades. 




Petición Soporte a la Transición (PST)


Las Peticiones de Soporte a la Transición son un tipo de órdenes de trabajo normalmente relacionadas con peticiones de lanzamiento y/o peticiones de plataforma de cara a facilitar su ejecución, difícilmente automatizables y que requieren conocimiento experto de las tareas a llevar a cabo. Las crea el Responsable de Producto o el Proveedor y están asignadas al proveedor de sistemas (CTI) como forma de pedir ayuda en base a un catálogo definido según los siguientes motivos:

      • Revisión conjunta de entorno aplicativo.
      • Apoyo a pruebas no funcionales de aplicación (rendimiento).
      • Soporte a desarrollo para actuaciones planificadas.

De cara a la aprobación de las PST, esta debe hacerla tanto el solicitante/informador, aprobando lo que CTI realiza como respuesta a esa PST, como el Responsable de Sistemas que es el encargado de dar el visto bueno respecto al coste que incurre la realización de dicha PST. 

El funcionamiento de las PST en JIRA y cómo se realiza su gestión de una forma más precisa y detallada, se encuentran detallados en el Manual de JIRA, en la sección Petición Soporte Transición.

Vídeo presentación del modelo


En el espacio de Ayuda Jira/confluence podrás ver un vídeo explicativo del modelo de gestión de servicios.




Ayuda relacionada:

  • Enlace
  • Enlace