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:

• A las áreas de la DGSIC (en el espacio de Coordinación SIC se refleja un organigrama con las diferentes áreas implicadas en el modelo.):
  • Soluciones Digitales
  • Gobernanza y Calidad
  • Sistemas y Comunicaciones
  • Servicio de Acompañamiento al Usuario
  • Servicios Transversales
  • Unidad de Seguridad TIC
• A los roles:
  • Subdirector
  • Responsable de área DGSIC
  • Centro de atención de usuarios de informática
  • Coordinador de actividad no planificada
  • Coordinador de actividad planificada
  • Oficina de Calidad
  • Responsable funcional
  • Responsable de Proyecto
  • Proveedor
  • Proveedor de Sistemas. 
• A las aplicaciones: CONFLUENCE, JIRA, Área personal de ayudaDIGITAL y CA SDM que además incluye WT, que provee el módulo de CMS.

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

• 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...

Diagrama de estados

[]

Loading...

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...

Diagrama de estados

[]

Loading...

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 

Ciclo de vida

Las mejoras se crean en estado WISHLIST tanto por integración como directamente en Jira.

Las creadas por integración pueden venir de:

• Creación por ayudaDIGITAL por parte de cualquier usuario (El campo Entrada es G. Proyectos). En este caso la solicitud que registra el usuario 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 a el número de solicitud, hay un visor que permite acceder a toda la información de la solicitud, incluso a los adjuntos de la misma.
• Como consecuencia de la resolución de un problema (El campo Entrada es G. Proyectos). En este caso, las mejoras entran en Jira aprobadas, es decir, en estado BACKLOG

Una vez en WISHLIST tanto el Responsable de producto como el Responsable funcional pueden

• Aprobar la mejora. Si es de integración se cierra en ayudaDIGITAL, informando al usuario que la regsitró que su propuesta tiene sentido y se acometerá. Tanto si es de integración como si no lo es, en Jira  pasa a BACKLOG. En área personal de ayudaDIGITAL, la solicitud 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. Al aprobar la mejora es necesario indicar la urgencia de la misma.

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 del primer estado al segundo si es que no ha sido informado mediante edición en el primero

• No aprobar la mejora:
  • 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.

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. 

Una vez que la mejora esté en Backlog, hay dos opciones:

• Trabajar la mejora en el marco de la versión, con lo cual hay que crear una versión. Podrá incluirse una mejora en una versión siempre que el estado de esta se ABIERTA o EN RESOLUCION. 

Incluir la mejora en la versIón puede hacerse desde la propia mejora (Asignar versión) o desde la versión (Gestionar alcance). El cambio de estado de la mejora es de BACKLOG a EN VERSION.

De la misma forma, pueden desasignar una mejora de una vesión si está en los estados indicados. El cambio de estado de la mejora será en ese caso de EN VERSION a BACKLOG.

Si incluir o excluir una mejora en la versión se hace cuando está  EN RESOLUCION, hará que se incremente un contador de cambios de alcance.

Si una mejora está incluida en una versión, podrá aparecer asociadas a la órdenes de trabajo que se soliciten para esa versión siempre que la OT 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.

• Trabajar directamente en la mejora y no crear la versión hasta que sea necesario desplegar la mejora. En este caso, puede hacerse un proceso de estimación y de incurridos en la propia mejora. Puedes revisarlo en Estimación e incurridos en las mejoras

Cuando la versión se implanta, las mejoras pasan de estado EN VERSION a CERRADA.

Versión  

 Es el núcleo de la evolución de las aplicaciones centralizadas, Dependiendo de cómo se gestione la apliccaión, puede usarse de diferentes formas:

• Si se sigue la metodología en cascada, puede considerarse la forma de gestión conjunta de mejoras aprobadas (mejoras del Backlog) y de incidencias resueltas (incidencias del Backlog) pendientes de implantación.
• Si se sigue la metodología en cascada, puede considerrase la unidad de despliegue, es decir, las mejoras se desarrollan en estado Backlog y una vez que es necesario desplegarlas, se incluyen en una versión junto a las incidencias corregidas que hay que desplegar. Los incurridos se hacen a nivel de versión 
• Si la gestión es ágil, una vez desarrolladas las historias de usuario en las que se descomponen las mejoras, se incluyen en la versión para poder desplegarlas.

Ciclo de vida

El ciclo de vida de la versión pasa por los siguinetes estados:

• ABIERTA: es el estado inicial en el que se crean las versiones
• EN PROGRESO: Para pasar a este estado es neceario que al menos contenga en su alcance una mejora o incidencia. También es posible que contengan NO CONFORMIDADES detectadas en versiones anteriores o en esa misma verión una vez que se hay desplegado en PREPRODUCCION
• IMPLANTADA: A este estado pasa la versión en el caso de tener PLs de versión cuando la última PL se haya cerrado. En ese momento se informa la Fecha de implantación en la versión y las mejoras e incidencias pasan de estado EN VERSION a CERRADA. Las No Conformidades deben estar VALIDADAS en ese momento, de lo contrario la versión no puede pasar a IMPLANTADA.
• CERRADA: A este estado se puede pasar directamente desde EN RESOLUCION si no hay PLs de versión o desde el estado IMPLANTADA. La única restriciión es que las órdenes de trabajo relacionadas con la versión deben estar cerradas.

¿Qué se puede hacer con una versión EN RESOLUCION?

Al ser el núcleo de la gestión, cuando la versión está EN RESOLUCION podemos:

• Crear órdenes de trabajo. (ver en siguiente apartado). Hay dos excepciones:
  • La orden de trabajo para hacer un estudio de viabilidad (OTEVS). Puede crearse independientemente de una versión o incluso relacionada con dos versiones independientemente de su estado (ABIERTA o EN RESOLUCION)
  • La orden de trabajo para una petición de soporte a la transición (PST). Se crea para pedir soporte al proveedor de sistemas centralizado. Aunque no es obligatorio que se haga en el marco de una versión, si se hace, la versión debe estar en estado EN RESOLUCION.

• Solicitar servicios a la Oficina de Calidad. En  Servicios  de la OCA  se detallan los servicios que se pueden solicitar en el marco de una versión (excepto la SVE. no  pueden  ser  solicitados  por  el  proveedor)
  • Servicios de testing temprano (STT)
  • Servicio de Validación Funcional (SVF): 
  • Servicio de Pruebas de Seguridad Dinámicas (SPSD)
    • Tal como se indica en la página a la que hemos hecho referencia, este servicio complementa la detección de vulnerabilidades de seguridad que ya hace la USTIC mediante la evaluación de seguridad
  • Servicio de validación de la accesibilidad (SVA):  
  • Servicio de validación de la usabilidad (SVU)
  • Servicio de verificación de entregas (SVE). Trataremos este caso aparte porque está relacionado con la gestión del producto con o sin componentes.

• Solicitar evaluaciones de seguridad. No es necesario qe la versión esté EN RESOLUCION, puede estar en el momento de la creación en estado ABIERTA. En Evaluaciones de seguridad puedes ver el ciclo de vida de este tipo de registro que como hemos comentado sirve como complemento a servicio de pruebas de seguridad dinámicas.

• Solicitar despliegues. Una vez que la versión tiene que desplegarse en los entornos de preproducción y producción, se solictan las correspondientes peticiones de lanzamiento. Puedes ver el proceso completo en Gestión de lanzamientos.

En este punto es cuando influye que el producto esté componetizado o no. (Ver Explicación del modelo de componentes)

• • Si el producto NO tiene componentes, habrá que crear una SVE para que la Oficina de Calidad haga una verificación de que el codigo entregado compila (eso no implica que la versión del producto cumpla con los requsitos funcionales o técnicos definidos). Una vez que la SVE esté cerrada, se podrá registrar la PL versión.

Si se trata de una PLU, será posible su registro sin que la SVE esté finalizado o que ni siquiera esté creada. En este último caso se creará automáticamente una vez se haya cerrado la primera PL Hija. Esta forma de trabajar conlleva a que posibles dudas de la OCA a la hora de verificar el código queden sin contestar puesto que el despliegue ya está hecho. con lo que en breve cambiaremos esta forma de trabajar e igualaremos el comportamiento al de las aplicaciónes con componentes.

• • Si el producto tiene componentes, cada vez que se haga en el repositorio una entrega, se creará automáticamente en Jira una SVE COMPONENTE. Para poder poner una PL es necesario crear una SVE APLICACION que contenga tantos componentes como se hayan indicado en la versión, teniendo en cuenta que solo puede haber una SVE COMPONENTE por cada uno de ellos. 

Como hemos comentado anteriormente, siempre va a tener que estar creada la SVE APLICACION para poder registrar la PL. En el caso de las PLUs no será necesario que esté finalizada.

Orden de trabajo

Representan el trabajo que debe resolver el proveedor normalmente en el marco de una versión- Pueden ser de dos tipos:

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

La orden de trabajo con crédito disponble 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 hacer un estudio de viabilidad. Puede o no hacerse en el marco de una versión, incluso puede estar relacionada con más de una.
• 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 se utiliza para registrar el trabajo mensual de equipos dedicados
• 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, por eso su uso se reduce a proyectos de Consultoría.

• La PST (Petición Soporte a la Transición) es un tipo de órdenes de trabajo que 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.
  Aunque sigue el flujo de una OT con crédito dsiponible, es validada por el Responsable de prodcuto o proveedor pero sus incurridos los valida el Responsable de sistemas de la aplicación correspondiente
  Hay casos en los que es necesario soporte del proveedor de sistemas centralizado para un equipo provincial. En ese caso, la Petición Soporte Transición se crea en otro tipo de proyectos como puedes ver aquí.

• En las que no son de esos dos tipos, el Responsable de producto puede asociar mejoras, de manera que hay una traza entre la OT y la o las mejoras que se trabajan en ella.

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". Si la OT se cancela estando EN RESOLUCION, pasará al estado PDTE. CANCELACION asignada al proveedor para que incurra el trabajo hecho hasta el momento de la cancelación. Una vez hecho, pasará al Responsable de producto para que revise el incurrido (estado PDTE. REVISION CANCELACION). Si todo está bien, la OT se cerrará con resolucion cancelada. Si el incurrido no es correcto, volverá al proveedor para que rectifique los incurridos.

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

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.

En Plantillas DGTIC están todas las plantillas definidas para los entregables de las órdenes de trabajo.

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, 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 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 mejoras pueden descomponerse en historias de usuario cuya gestión permiten:

• Reducción del tiempo de las entregas al hacer que el producto crezca de forma incremental

• Definición progresiva de los requisitos y reacción rápida al cambio.

• Detección y análisis de los riesgos, acometiendo aquella historias de usuario que puedan conllevar más riesgo en la viabilidad del desarrollo del producto.

Hay que tener en cuenta que 

• La unidad de gestión es la historia de usuario.

• Una mejora puede descomponerse en "n" historias de usuario.

• Una historia de usuario sólo puede tener como origen una mejora.

• Es requisito imprescindible para que una mejora pueda descomponerse en historias de usuario que la mejora esté aprobada.

• Las historias de usuario definen una pila de trabajo que el Responsable funcional/Responsable del producto deben priorizar.  

• Una historia de usuario se define por:

  • Narrativa: El formato debe responder al tipo "Como___quiero___para__"

  • Criterios de aceptación: Lista de criterios objetivos y comprobables

• De las historias de usuario pueden crearse subtarea, de tipo "Subtarea" y "Error técnico" que puede ser asignadas a diferentes miembros del proyecto. Esta asignación no es la nativa de JIRA, puesto que el usuario con el que acceden los proveedores es genérico.

Las historias de usuario se crean como entidades en JIRA pero se pueden documentar y completar en páginas de CONFLUENCE estableciendo un enlace con la entidad de JIRA.

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  mediante un SVS ya que en los poyectos ágiles, normalmente un integrante de la 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 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).

Eventos importantes en el Sprint:

Planning o reunión de planificación del Sprint:

En la primera reunión de planning, se deben acordar el DoR (Definición de listo) y DoD (Definición de hecho). Lo normal es que esos acuerdos varíen poco a lo largo de la vida del producto. No obstante, deben revisarse antes de cada reunión de planificación para detectar aquello que pudiera aplicar desde el Sprint en curso. Además, se determina la duración que van a tener los sprints, aunque pueda cambiar en cualquier momento.

En cada reunión de planificación del Sprint :

• Se determina la fecha de finalización del sprint.

• Se determinan las funcionalidades que se van a incorporar al producto.

• Se priorizan las historias de usuario y se les da un peso en puntos de historia (dependiendo de la complejidad, del esfuerzo y de la incertidumbre).

• Se define la disponibilidad de los miembros del proyecto.

• Se decide que miembro del equipo debe acometerlas.

La configuración del Sprint se hace en JIRA a partir de un filtro y de una pizarra Scrum.

En la pizarra se pueden visualizar las tareas del equipo y el estado en el que se encuentran.

En el espacio del producto en CONFLUENCE debe crearse una página de metodología ágil en la que se incluirá toda la documentación interesante a nivel de producto y a nivel de cada sprint.

Reunión de refinamiento:

Opcionalmente puede ser necesario hacer una reunión para aclarar ciertos aspectos que no han quedado claros en la propia historia de usuario.

Daily o reunión diaria:

Reunión diaria del equipo con el Responsable funcional y el Responsable de producto en la que cada miembro del equipo comenta lo que hizo el día anterior, lo que va a hacer ese día y si hay tiene alguna dificultad y necesita paralizar la tarea que esté haciendo.

Review o reunión de revisión de los hecho en el Sprint:

Reunión en la que el Responsable funcional o el Responsable del producto validan las funcionalidades implementadas y si se pueden dar por finalizadas o si por el contrario no pueden darse por validadas por no dar respuesta a la funcionalidad que se había pedido.

Tras la revisión se hace la retrospectiva, en la que se analiza lo que se ha hecho bien en el sprint y lo que se ha hecho mal. De este punto saldrán acciones y responsables de las mismas para no volver a cometer los mismos errores. Deberá crearse una página de retrospectiva dentro de cada sprint en CONFLUENCE

En el proceso de Gestión de cambios puedes encontrar más información del ciclo de vida ágil en las aplicaciones.

OT Ágil

Historias de usuario

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.