Image RemovedImage Added

Diagrama

1. Evaluación del cambio (desde la perspectiva del ENS)

En este caso, el Responsable técnico principal debe solicitar su creación, tal como se describe:

1. Solicitud de creación de proyecto nuevo

Cuando el PORTICO asociado a este proyecto es un desarrollo evolutivo de una aplicación que YA existe, es posible que no sean necesaria la creación de este proyecto.

2. Solicitud de cambio (si procede)

En este paso, el Responsable técnico principal debe actualizar los siguientes datos en la aplicación PORTICO:

• Actualizar o añadir los proyectos JIRA asociados
• Añadir responsable técnicos adicionales (en su caso)
• Añadir el espacio de Confluence asociado al proyecto (Pendiente implementación en PORTICO)

1. Gestión del cambio durante el desarrollo de proyectos nuevos

Diagrama

Image Added

1.1. Evaluar si aplicar el Procedimiento de Gestión del Cambio del ENS

Aplicar los Criterios de valoración para iniciar el procedimiento de cambio en ENS

.

1.2. Aplicar el procedimiento de Gestión del Cambio del ENS

Si el resultado de la evaluación anterior es que se inicie el Procedimiento de Gestión del Cambio, se realizará como se describe en Procedimiento de Gestión del Cambio (ENS).

2. Gestión del cambio en pequeños evolutivos / mejoras (BOLSA)

Diagrama

Image Added

2.1. Solicitudes de desarrollo de pequeños evolutivos o mejoras

Las aplicaciones y servicios TI en producción, son susceptibles de incorporar mejoras y nuevas funcionalidades (al margen de la cartera de proyectos PÓRTICOS nuevos) con cargo a la BOLSA de los pórticos de OPERACIÓN, siempre y cuando existan horas suficientes y el desarrollo haya sido aprobado por el responsable funcional de la misma. Esta solicitud debe realizarse siempre a través de DJ Dumbo - Atención a Usuarios. 

2.2. Gestión de la solicitud e identificación de trabajo asociado a bolsa

Una vez recibida la solicitud, el Responsable Técnico deberá de realizar los siguientes pasos en la Tarea recibida:

1. Asociar la tarea al PORTICO de OPERACION correspondiente.
2. Determinar si la tarea es un Mejorativo/Evolutivo (No Mantenimiento).
   1. En caso negativo (se trata de una tarea de Mantenimiento), dará curso al trámite de resolución.

   2. En case afirmativo, comprobar que la tarea está tipificada como Petición de Servicio, y continuar al siguiente paso (2.2-3.).

      Info
      title Tipos de tareas en JIRA
      Es sobre todo el TIPO de tarea lo que determina si es MANTENIMIENTO o BOLSA: Image Added Esto es INDEPENDIENTE del número de horas que requiera (es el Responsable de la Bolsa quién decide cuánta Bolsa autoriza gastar en cada caso), con una excepción: un mantenimiento necesario porque se trate de un error que impida el uso de la aplicación habrá que abordarlo, aunque superemos la disponibilidad en Operación, mientras que la BOLSA no debe superarse nunca salvo autorización expresa del CD-GTI.

      
      

3. Se comprueba si hay saldo disponible en la BOLSA de horas del PORTICO de operación.
   1. En caso negativo:
      1. Se imputa el tiempo de dedicación mínimo (10-15m).
      2. Se cierra la tarea como NO RESUELTA indicando "Se trata de un evolutivo y no existe BOLSA de horas disponible".
   2. En caso afirmativo, se continuará en el siguiente paso (2.3).

2.3. Estimación dedicación requerida

El Responsable Técnico realizará la siguiente tarea:

• El tiempo de dedicación correspondiente a las labores de estimación será imputados en esta tarea, o si fuera necesario, en las subtareas o subtareas externas para los Miembros del Equipo de desarrollo que se considere necesarias.
• Una vez conocida la estimación de la dedicación de horas que requiere la tarea, se debe comprobar si la BOLSA de horas restantes en el PÓRTICO de operación permite llevar a cabo la solicitud.
  • En caso negativo:
    • Se cierra la tarea como NO RESUELTA, indicando "Se trata de un evolutivo, el tiempo estimado es XX y la BOLSA disponible es de YY horas".
  • En caso afirmativo, se continuará en el siguiente paso (2.4).

2.4. Puesta EN ESPERA de la tarea

El Responsable Técnico pasará la tarea inicial al estado EN ESPERA.

2.5. Evaluar si aplicar el Procedimiento de Gestión del Cambio del ENS

En este punto, el Responsable Técnico debe aplicar los criterios de valoración para iniciar el Procedimiento de Gestión del Cambio para decidir si debe iniciar el Procedimiento de Gestión del Cambio del ENS o no. 

• En caso afirmativo, el Responsable Técnico debe:
  • Comunicar por correo electrónico al Responsable de la Bolsa que se ha iniciado el Procedimiento de Gestión del Cambio del ENS, y se está a la espera de una decisión por parte de la Comisión del Cambio.
  • Continuar por el paso 2.6.
• En caso negativo, el Responsable Técnico debe:
  • Continuar por el paso 2.7.

2.6. Aplicar el procedimiento de Gestión del Cambio del ENS

Si el resultado de la evaluación anterior es que se inicie el Procedimiento de Gestión del Cambio, se realizará como se describe en Procedimiento de Gestión del Cambio (ENS).

Si se inicia el Procedimiento anterior, el resultado podrá ser:

• NO autorizado. En este caso, el Responsable Técnico debe:
  • Pasarla a en Progreso o Reactivada
  • Cerrarla como NO RESUELTA, indicando "Cambio no autorizado por la Comisión del Cambio (ENS)".
• Re-evaluarlo por no estar clara alguna condición impuesta. En este caso, el Responsable Técnico deberá:
  • Aclarar con el Responsable de la Bolsa aquellos aspectos que se le transmitan.
  • Transmitir a la Comisión del Cambio aquellos aspectos solicitados.
  • Quedar a la espera de la decisión de la Comisión del Cambio.
• Aceptados. 
  • Se continúa en el siguiente paso 2.7.

2.7. Solicitud aprobación al responsable de la bolsa

El Responsable Técnico deberá realizar ahora las siguientes tareas:

• Enviar una comunicación por correo electrónico al Responsable de la Bolsa correspondiente (PÓRTICO OPERACIÓN), informando sobre la solicitud y estimación de horas e indicando que la tarea se queda en espera hasta recibir la confirmación.
• En el caso de que se hubiera iniciado el Procedimiento de Gestión del Cambio, informar en el comunicado anterior de que el cambio ha sido Aceptado por la Comisión del Cambio. 

El Responsable de la Bolsa deberá responder, en uno de los dos sentidos:

• Negativamente. En este caso, el Responsable Técnico debe:
  • Imputar cualquier tiempo de dedicación de dedicación adicional a las gestiones de esta tarea.
  • Cerrar la tarea como NO RESUELTA, indicando "BOLSA no aprobada por el Responsable de la Bolsa".
• Afirmativamente. En este caso, el Responsable Técnico deberá:
  • Crear una tarea en la que se imputará el trabajo de desarrollo necesario. Esta última tarea estará asociada al PÓRTICO correspondiente y será marcada como de BOLSA, y debe rellenarse el campo ESTIMACION de horas que necesita para la tarea de bolsa (Esta estimación se mostrará en DJ al Responsable de la Bolsa). 
  • Enlazar la tarea anterior con la Tarea inicial.
  • Es posible crear subtareas y subtareas externas si es necesario, pero todas ellas deben estar asociadas al PÓRTICO correspondiente. Se continuará en el siguiente paso.

3. Criterios de valoración para iniciar el procedimiento de cambio en ENS

El Responsable Técnico realizará una evaluación previa de la "importancia" del cambio (subjetiva), de modo que determine si procede o no aplicar el procedimiento de "Gestión del Cambio" del ENS, y su correspondiente instrucción operativa.

Entre los criterios a tener en cuenta, se valorará:

• Impacto estimado en la disponibilidad de los servicios, especialmente en aquellos que afectan a los indicadores de la carta de servicios.
• Número de servicios afectados.
• Número de usuarios potenciales afectados.
• Tiempo de no disponibilidad.

4. Procedimiento de Gestión del Cambio (ENS)

El siguiente diagrama muestra un resumen del procedimiento de "Gestión del Cambio" del ENS, y su correspondiente instrucción operativa, desde la perspectiva de MEDEA y los pasos a realizar por el Responsable Técnico.

Diagrama

Image Added

4.1. Solicitud de valoración de cambio

• El Responsable técnico principal debe crear una tarea en JIRA en el proyecto GDC de "Gestión del Cambio" dirigida a la jefatura del servicio en cuestión, que en el resumen incluya "PPP_AAAA" (donde PPP es el código del pórtico de la aplicación o servicio afectado por el cambio, y AAAA el año, por ejemplo 530_2024, teniendo en cuenta que si es necesario pueden indicarse varios pórticos en el resumen de la misma tarea GDC). Además, en la descripción de la tarea se registrarán los siguientes datos:
  • Situación actual
  • Situación propuesta
  • Mejoras o necesidades que cubre el cambio (parches, versiones, etc)
  • Perjuicios en caso de no realizar el cambio (errores de funcionamiento, vulnerabilidades, etc.)
  • Impacto estimado sobre el resto de sistemas.

• • El código PPP_AAAA se usará para que la tarea se muestre en el apartado "Gestión del Cambio" de las actas de seguimiento de la PMO donde se revise dicho pórtico, por lo que en el campo Resumen de una misma tarea podría haber varios PPP_AAAA separados por espacios.
• Enlazar la tarea Jira que ha disparado la gestión del cambio, para tener trazabilidad.

4.2. Valoración de la solicitud

La Comisión de Gestión del Cambio cuando inicie el análisis de la petición pasará manualmente la tarea registrada al estado EN VALORACION.

Cualquier información que sea necesario aportar por el Responsable Técnico, se realizará:

• Anexando informes al JIRA creado en el punto anterior.
• Enlazando JIRAs ya existentes relativos a este cambio.

4.3. Resultado de la valoración

Tras la valoración, el Responsable Técnico recibirá el resultado en la misma tarea, a través del campo "Aprobado" de JIRA en esa tarea.

• NO autorizado. La tarea será CERRADA, indicándose en la misma las causas. 
• Re-evaluarlo / a valorar. La tarea seguirán en estado EN EVALUACIÓN. Se necesita mas información que deberá proporcionar el Responsable Técnico.
• Aceptados. La tarea es puesta en estado EN REALIZACION. 

5. Comunicar actualización de aplicación

En el caso de que los cambios propuestos hayan sido aceptados, una vez estén terminados y listos para desplegar en producción, deberemos seguir el procedimiento de 07. Gestión de actualizaciones para asegurar que la implantación del cambio se realiza de manera correcta y controlada sin perjuicio de otras aplicaciones y/o servicios.

El Responsable Técnico Principal o la persona en la que delegue deberá realizar las gestiones pertinentes descritas en 07. Gestión de actualizaciones para coordinar el cambio de manera que los servicios que se vean afectados estén preparados para dicho cambio y que los usuarios finales estén informados mediante el panel del monitorización del estado del servicio

5. Alta de la aplicación en APIUM

El  Responsable técnico principal , o el miembro del equipo de desarrollo en el que delegue, y si no existe previamente, debe dar de alta en APIUM la aplicación que se está construyendo, y caracterizar al menos los datos básicos de la misma;

Image Removed

En la pestaña DESARROLLO, se deberá establecer que la aplicación está en Estado "Desarrollo".

6. Alta en repositorio del control de versiones

Actualmente, el sistema de control de versiones de código recomendado por MNCS es Gitlab, aunque todavía se soporta SVN para aquellos proyectos que lo necesitan.

Para dar de alta el proyecto en Gitlab, un  Responsable técnico debe seguir las siguientes:

.