Sección 8: Control de la configuración general

El Control de la Configuración es un subproceso del proceso de Gestión de la Configuración, en el que se establecen los mecanismos para el control de los cambios en los procesos de Diseño y Desarrollo de productos médicos. Será entendido como cambio a toda propuesta de mejora (modificación o requerimiento) y resolución de anomalías (problemas, defectos o no conformidades). Se define entonces una Solicitud de Cambio (SC) como un mecanismo para llevar adelante un cambio.

Una SC es una especificación documentada, cuyo origen presunto se recomienda esté documentado. Un Ítem de Configuración (IC) sólo podrá ser modificado ante una SC, ya sea que la misma surja en la etapa de desarrollo o en la de mantenimiento. Como la implementación de la SC puede derivar en una re-clasificación de la seguridad de la unidad/elemento/componente de software, la evaluación de la implementación del cambio debe estar por lo tanto relacionada con el proceso de Gestión de Riesgos del Software (RSKM).

En el marco del Proyecto MoSimPa, en este Plan se propone un subproceso dentro de la gestión de configuración general cuyas actividades estén relacionadas a la gestión de los cambios. Una vez implementada, la SC debe ser verificada, y esta verificación tiene que ser coherente con los procesos en los cuales impacte, tanto de desarrollo como de mantenimiento, testing y gestión de modificaciones y problemas. La norma exige trazabilidad entre los procesos de verificación, implementación, solicitud de cambios e Informe de Problemas (IP), y esta evidencia se consigue a partir de la realización de auditorías, las cuales pueden dispararse en función de un cronograma establecido, o luego de ser implementado el cambio. Cabe aclarar que no todo IP precede a una SC, sino que un IP puede quedar en un estado final.

Para gestionar las SC y lograr trazabilidad se utilizarán en Gitlab issues, sus etiquetas (labels) y su feature etiquetas con scope.

De esta manera una etiqueta se puede determinar de la forma:

<scope>::<etiqueta>

Los etiquetas dentro de un mismo scope son mutualmente exclusivas, por lo que solo se puede aplicar una de ellas a un issue en particular.

Cada issue tendrá su propio workflow configurado y sus estados. La documentación y el registro de las SC se realizarán a través de los mismos issues. Asimismo, los IP, con el análisis y registro del comportamiento real o potencial que sea considerado no seguro, inapropiado para el uso previsto o contrario a especificación, serán documentados en los mismos issues de defectos o no conformidades. Todos los issues deberán estar relacionados, de manera de lograr la trazabilidad solicitada por la norma.

Se propone identificar los siguientes elementos:

  • Tipos de issues: se identificarán a partir del uso de etiquetas con scope "Issue". Ver la tabla de etiquetas definidas para este scope.
  • Tableros (Board): se identificarán tres boards: Project Backlog; Product Backlog; Problem and Change Backlog. Ver tabla de boards definidos y la tabla de etiquetas a utilizar en los boards.
  • Workflows: se evidencian con la configuración de boards, para lo cual deben identificarse etiquetas.
  • Líneas de base: se identificarán con milestones. Una línea de base puede tener varias versiones de un repositorio.
  • Versiones: se identificarán con tags en repositorios.

8.1 Definiciones de boards y etiquetas

8.1.1 Etiquetas dentro del scope Issue

Tabla de etiquetas dentro del scope Issue
Etiquetas de tipo de peticiones Descripción Relaciones Board Relacionado Nomenclatura Propuesta Repo
Requirement Etiqueta para Requerimientos. Expresan requisitos de alto nivel, tanto funcionales como no funcionales No requieren relación. Pero pueden vincularse a algún issue que les de origen, e.g.: “Elicitar Requerimientos” Product backlog

REQ_FUNC_YYY:Nombre_Descriptivo;

REQ_NFUNC_YYY: Nombre_Descriptivo; donde YYY es un número consecutivo.

Asimismo puede ser un issue relacionado a ingeniería de requerimientos y no un requerimiento en sí mismo.

 Documentation o código
Use case Etiqueta para los Casos de Uso Issues relacionados a los Requirement Product backlog UC_YYY: Nombre_Descriptivo; donde YYY es un número consecutivo
Test Case Etiqueta para los Casos de Prueba, por escenario Issues relacionados a Use Case como también al issue que da origen a la actividad, e.g.: “Redactar Casos de Prueba”; “Correr Caso de Prueba”, etc. Product backlog TC_UC_YYY_ZZZ; donde CU_YYY identifica al caso o porción de caso de uso que el escenario prueba y ZZZ el escenario.
Issue Etiqueta genérica para toda actividad diferente de las anteriores Cualquiera que sea necesario trazar Product backlog No aplica Cualquiera
Change Etiqueta para los issues tipo cambios/modificaciones Se podría relacionar a los Requirement or Use Case que modifica Change Backlog No aplica Documentation y luego repo código
Bug Etiquetas para los issues tipo errores, anomalías, no conformidades, es decir todo desvío respecto a la especificación. Con los Test Case cuando estos fallaron o bloquearon, como así también a un issue de auditoría Problem Backlog No aplica
Planning Estado para issues relacionados a planificación Product backlog No aplica
Testing Estado para issues relacionados a actividades de verificación y validación Product backlog No aplica
Design Estado para actividades relacionadas con el diseño (Arquitectura, diseño detallado) Product backlog No aplica
Integration and delivery Estado para actividades relacionadas paquetizado, integración y liberación de software Product backlog No aplica Documentation o código
Risk Management Estado de actividades relacionadas con el proceso de gestión de los riesgos Product backlog No aplica Documentation

8.1.2 Boards y sus etiquetas

Boards definidos
Board Scope Descripción Etiquetas (tipo de issues)
Problem and Change Backlog PCB Tablero para issues tipo Bug Open; Bug; CCB Review; CCB Approved; To Do; Doing; CCB Rejected; Closed
Product Backlog PB Tablero para issues empleados en la planificación del proyecto, diseño, desarrollo, testing (excepto Test Cases) integración y despliegue, gestión de riesgos Open; To Do; Doing; Closed
Testing Backlog TB Tablero para issues tipo Test Case Open; To Do; Doing; Pass; Failed; Locked; Closed

Etiquetas a utilizarse en los boards
Etiquetas Descripción Estados Relacionados Boards Relacionados
Open Estado por defecto, inicio

Anterior: -

Siguiente: To Do o CCB Review

 Todos (estado predefinido de Gitlab)
To Do Estado para peticiones que estén aceptadas/asignadas para desarrollar

Anterior: -

Siguiente:

 Product Backlog; Problem and Change Backlog; Testing Backlog
Doing Estado para peticiones que se estén desarrollando

Anterior: -

Siguiente:

 Product Backlog; Problem and Change Backlog; Testing Backlog
Closed Estado por defecto, fin

Anterior: cualquiera

Siguiente: -

 Todos (estado predefinido de Gitlab)
CCB Review Denota estado de análisis

Anterior: Open

Siguiente: CCB Approved or CCB Rejected

 Problem and Change Board
CCB Approved Aprobación por CCB

Anterior: CCB Review

Siguiente: To Do

 Problem and Change Board
CCB Rejected Rechazo por CCB

Anterior: -

Siguiente: Closed or Open

 Problem and Change Board
Failed Caso de Prueba fallido

Anterior: Doing

Siguiente: -

 Testing Backlog
Pass Caso de Prueba pasado

Anterior: Doing

Siguiente: -

 Testing Backlog
Locked Caso de Prueba bloqueado

Anterior: Doing

Siguiente: -

 Testing Backlog

8.2 Workflows empleados

A continuación se detallan los tipos de issues que serán gestionados en el proyecto, como así también los flujos de trabajo para los mismos, y se describen los procesos que se utilizarán para implementar el circuito de control de cambios en cada caso.

Los flujos describen los diferentes estados para los diferentes tipos de cambio. Cada issue deberá contar con su propio workflow, pero como se expresó anteriormente estos deberán relacionarse entre sí, con el objetivo de garantizar la trazabilidad.

8.2.1 Issues de tipo Change o Bug

Los issues de tipo Change ("modificación") sólo podrán pasar al repositorio de código para su implementación si previamente se encuentran en estado CCB Approved (es decir, aprobados por el Comité de Control de Cambios).

A continuación, se expone el flujo de trabajo que describe el circuito de control de cambios para este issue aplicable a GitLab.

Workflow para issue Issue::Change

Los issues de tipo Bug ("error") podrán pasar al repositorio de código para su corrección si previamente se encuentran en estado CCB Approved (es decir, aprobados por el Comité de Control de Cambios).

En los siguientes workflows se exponen los flujos de trabajo que describen los circuitos de control de cambios para cada uno de estos issues, aplicables a GitLab.

Workflow para issue Issue::Bug

Un issue de tipo Change o Bug estará asignado al board de Problem and Change Backlog, y por lo tanto los posibles estados serán:

  • Open: Estado por defecto en la creación.

  • CCB Review: Cuando un issue de tipo Bug o *Change es tomado para revisión, donde se evaluará y registrará:

    • Tipo:

      • Correctivo;
      • Preventivo;
      • Adaptación a un nuevo entorno;
      • Etc.

    • Riesgos:

      • ¿Implica riesgos reales y/o potenciales para la seguridad (safety)? (En este punto debe aplicarse el proceso de Gestión de Riesgos).
      • ¿La petición realizada implica algún riesgo en la salud del usuario del producto (safety)?
      • ¿La petición realizada implica algún riesgo para la integridad del producto?
      • ¿La petición realizada supone algún riesgo para continuar con el desarrollo del proyecto?

    • Urgencia:

      • ¿La petición realizada requiere un tratamiento urgente?

    • Complejidad:

      • ¿La petición requiere un tratamiento especial por su complejidad?
      • ¿El pedido requiere del análisis de un experto? ¿Se cuenta con un experto en el tema?
      • ¿En función del análisis se modifica o crea algún Ítem de Configuración?
      • ¿Es necesario introducir modificaciones en la línea de base (LB) de desarrollo actual; o la petición puede ser incluida en una LB posterior?
      • ¿Exige un tratamiento inmediato?
      • ¿Puede ser resuelta con los recursos disponibles?
      • En caso de no contar con los recursos en forma inmediata, ¿puede ser diferida esta petición?
      • ¿Requiere de personal externo para su tratamiento?
      • ¿Necesita llegar a nuevos acuerdos con el/los cliente/s? (En este caso se requiere de la intervención del área de ventas.)

Del análisis anterior, el CCB asignará un peso al issue tal como se detalle en la sección Clasificación de la Severidad de las Solicitudes de Cambio.

Como resultado de esta actividad puede ser necesaria la creación de branch de desarrollo o fix. El análisis anterior denota el INFORME DEL PROBLEMA (IP) o SOLICITUD DE CAMBIO (SC), según corresponda, y por lo tanto debe documentarse/evidenciarse en el mismo issue.

  • CCB Approved: Estado que denota la aprobación por parte del Comité de Control de Cambios para su atención/implementación.
  • CCB Rejected: Estado que denota el rechazo del Comité de Control de Cambios para su resolución/implementación. Un estado CCB Rejected puede ser luego reabierto.

Cuando un issue de tipo Change, Bug es tratado y aprobado puede ser pasado al repositorio de código correspondiente para su resolución. Todo el análisis debe quedar asentado en la misma petición, constituyendo la Solicitud de Cambio o Informe de Problema, según corresponda.

Un Informe de Problema puede derivar en un Cambio (Change); si esto sucede se cargarán los issues como relacionados.

8.2.2 Issues de tipo Test Case

Los issues de tipo Test Case (“caso de prueba”) estarán asignados al board de Testing Backlog, por lo tanto los estados serán:

  • Open: Estado por defecto en la creación.
  • To Do: Asignados a un sprint listos para correr.
  • Doing: Corriendo el escenario.
  • Failed: Escenario fallido.
  • Locked: Caso de prueba bloqueado, es decir cuando alguna precondición no se encontraba satisfecha.
  • Pass: Caso de éxito en la corrida.
  • Closed: Cuando el escenario fue exitoso, posterior a Pass.

En el siguiente workflow se expone el flujo de trabajo que describe el circuito de control de cambios para este issue, aplicable a GitLab.

Workflow para Issue::Test Case

8.2.3 Issues de tipo Issue, Requirement, Use Case, Planning, Testing, Design, Integration and Delivery, Risk Management

Los issues de tipo Issues, Requirement, Use Case, Planning, Testing, Design, Integration y Delivery estarán asignados al board de Product Backlog, por lo tanto los estados serán:

  • Open: Estado por defecto en la creación.
  • To Do: Asignados a un sprint/incremento listos para ser desarrollados.
  • Doing: Ejecutando la actividad.
  • Closed: Cuando se finalizó la petición.

Para los issues de tipo Requirement y Use Case los estados denotan:

  • Open: Estado por defecto en la creación.
  • To Do: Asignados a un sprint/incremento listos para ser modelados / elicitados / especificados / desarrollados.
  • Doing: En el caso de Requirement elicitando y modelando interacción o comportamiento, ejemplo Modelo de Casos de Uso con CUs que implementen el Requerimiento y redacción de alto nivel, como así también escenarios de atributos de calidad. En el caso de Use Case este estado involucra las actividades de especificación e implementación.
  • Closed: Estado de finalización del issue, para Use Case daría lugar a las peticiones de tipo Test Case.

El siguiente workflow muestra el flujo de trabajo que describe los circuitos de control de cambios para cada uno de estos issues y que son aplicables a GitLab.

El mismo debe considerarse como un template, es decir, el mismo workflow es aplicable a cada uno de los tipos de Issues considerados en este inciso, conformando un workflow único en cada caso. Si a futuro fuese necesario modificar alguno de los Issues contemplados en este inciso se deberá agregar como un caso mas a la lista.

Reemplazar <tipo> por Issue, Requirement, Use Case, Planning, Testing, Design, Integration and Delivery o Risk Management.

Workflow para scope Issue de tipo Issue, Requirement, Use Case, Planning, Testing, Design, Integration and Delivery, Risk Management

8.3. Comité de Control de Cambios

El Comité de Control de Cambios (CCB) del Proyecto MoSimPa será el órgano encargado de tomar las decisiones relacionadas a la gestión de los cambios que se susciten. El propósito del CCB es asegurar que cada cambio es evaluado y coordinado adecuadamente.

La siguiente tabla muestra la estructura del CCB. La misma podrá ser ajustada acorde a las definiciones realizadas.

Miembros/Rol Apellido y nombre
Redacción 1 PÉREZ MEYER, Lisandro
Redacción 2 AYMONINO, Andrés
Revisión 1 ROSSI, Esteban
Aprobación MANDOLESI, Pablo

Se deberá identificar la frecuencia con la que deberá reunirse el CCB para el proyecto, la cual podrá variar de acuerdo a las necesidades.

Cabe aclarar que el poder de aprobación final recae sobre el rol "Aprobación" del CCB.

8.3.1 Listado de cambios del CCB

  • 20210104: siguiendo la decisión del CCB se dá de baja del CCB a Josué Albornoz Laferrara, quedando en disponibilidad para futuras consultas.

8.4. Clasificación de la Severidad de las Solicitudes de Cambio

La siguiente tabla describe las posibles severidades asignadas a las solicitudes de cambio que pudieran generarse durante el ciclo de vida del Proyecto MoSimPa. Al tipo de severidad se le aplica el número entre paréntesis que deberá ser usado en el campo “Peso” de GitLab.

Tipos de severidad Descripción
<Identificación del tipo de cambio>

<Descripción del tipo de cambio>

<Descripción del circuito definido para soportar el pedido de cambio>
BAJA (2) Corresponde al tipo de cambio cuyo tratamiento podría efectuarse en el largo plazo, no peligrando ni la seguridad, ni la continuidad del proyecto. En general, asociado a sugerencias.
NORMAL (4) Corresponde al tipo de cambio, cuyo tratamiento debería efectuarse en el mediano plazo.
ALTA (6) Corresponde al tipo de cambio, cuyo tratamiento debería efectuarse en el corto plazo.
URGENTE (8) Corresponde al tipo de cambio, en general asociado a errores, que podría significar un retraso o compromiso económico de alto impacto.
INMEDIATA (10) Corresponde al tipo de cambio, cuyo no tratamiento podría implicar un riesgo de no continuación del proyecto.

8.5. Criterios de Evaluación de las Solicitudes de Cambio

La evaluación de los cambios que pudieran suscitarse a lo largo del ciclo de vida del Proyecto MoSimPa debería estar orientada a los siguientes interrogantes:

Criterios de evaluación de las solicitudes de cambio - Checklist

Pregunta Hecho
¿Es posible atenderla en función de la disponibilidad de recursos, tiempo y costos asignados al Proyecto?
¿Implica una modificación del alcance en la especificación de requerimientos del producto?
¿Es necesario un ajuste en el presupuesto acordado?
¿Cumplirá todavía el producto los requisitos especificados del mismo?
¿Resultará afectada la utilización prevista?
¿Resultará afectada la evaluación de los riesgos existentes?
¿Supone algún riesgo para la continuidad del Proyecto?
¿Necesita adecuarse el cronograma previamente definido?
¿Es necesario efectuar consultas a expertos externos para su tratamiento?
¿Implica la modificación/actualización de activos? ¿Cuáles?