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 (El campo Entrada es G. Proyectos).

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

• • Si el producto NO tiene componentes

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.

• La PST (Petición Soporte a la Transición) se explicará por separado más adelante en el apartado Petición Soporte a la Transición.
  
  

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

Diagrama de estados

[]

Loading...

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

Diagrama de estados

[]

Loading...

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

Diagrama de estados

OT Ágil

[]

Loading...

Historias de usuario

[]

Loading...

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

[]

Loading...

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.

• Ver vídeo