- Plan de gestión de riesgos
- Objetivos
- Introducción
- Campo de aplicación
- Recursos y roles
- Actividades de gestión de riesgos en las fases del ciclo del vida del software
- Criterios para aceptabilidad de los riesgos
- Revisión de las actividades de gestión de riesgos
- Informe de la gestión de los riesgos
- Información de Producción y posproducción
- Archivo de gestión de riesgos
- Apéndices
Plan de gestión de riesgos
Convenciones del documento
En el presente Documento se utilizan convenciones estándar de texto, con el objetivo de facilitar su comprensión y uso. En esta Sección se procede a detallar las instrucciones necesarias para que el usuario del documento sustituya la información genérica provista en esta plantilla con la información de su propio proyecto. El usuario del documento deberá evaluar la información genérica suministrada en este plan de Gestión de la Configuración y ajustarla a las necesidades de su proyecto.
[[texto]] Cambios globales: Los textos que aparecen en modo regular, y encerrados con dobles corchetes [[]], representan cambios que pueden realizarse de manera global (Por ej. en [[Modifique en “Asunto” el nombre del Proyecto]] el usuario podrá modificar la propiedad indicada (Archivo→Propiedades→Descripción) en el procesador de texto, lo que le permitirá hacer un cambio a todas las ocurrencias del proyecto.
\ Guías de uso: El texto que aparece encerrado entre los símbolos \ representa instrucciones o guías de ayuda al usuario del documento. Este texto sólo será visible e impreso en formato Markdown. De todas maneras, si lo considera necesario, puede borrar estas instrucciones.
Objetivos
Introducción
Este documento contiene la planificación de las actividades relacionadas a la gestión de los riesgos del Proyecto de Desarrollo/Mantenimiento de Software MoSimPa en base a los requerimientos establecidos en los estándares ISO 14971 e IEC 62304 y la guía de aplicación IEC/TR 80002-1.
Contiene:
- la documentación relacionada
- la asignación de recursos y sus roles.
- las actividades de gestión para la fase del ciclo de vida del software.
- los criterios para la aceptabilidad del riesgo, y
- los requisitos para la revisión de las actividades de gestión de los riesgos.
Documentos Relacionados
| Documento | Ubicación |
|---|---|
| Plan de Proyecto de MoSimPa | |
| Formulario de Gestión de Riesgos del Software MoSimPa | |
| Informe de gestión de riesgos | |
| Plan de Administración de la Configuración MoSimPa | PLN_Gestion_Configuracion |
Campo de aplicación
| Utilización prevista | Ubicación |
|---|---|
| Mala utilización razonablemente previsible | Ubicación |
|---|---|
Recursos y roles
La tabla siguiente lista los miembros de la organización responsables de las actividades de gestión de los riesgos durante el Proyecto de Desarrollo/Mantenimiento de Software MoSimPa.
| Recurso | Rol | Remplazo del Recurso |
|---|---|---|
| MANDOLESI, Pablo | Líder de Proyecto / Ingeniero de D&D de Hardware | |
| PÉREZ MEYER, Lisandro | Ingeniero de D&D de Software / Administrador de la Configuración | |
| AYMONINO, Andrés | Ingeniero de D&D de Hardware | |
| POUSO, Marcelo | Ingeniero de D&D de Software | |
| CASANOVA, Alejandro | Ingeniero de D&D de Software | |
| ROSSI, Esteban | Líder Consultor de Procesos – RRHH externo | |
| ALBORNOZ LAFERRARA, Josué | Ingeniero Consultor de Procesos Sr. – RRHH externo | |
| GRAMAJO, Rodrigo | Ingeniero Consultor de Procesos Jr. – RRHH externo | |
| CARDOSO, Paula | Ingeniera Consultora de Procesos Jr.– RRHH externo |
Actividades de gestión de riesgos en las fases del ciclo del vida del software
| Hitos del Proyecto | Fases de Ciclo de Vida | Actividades del Proceso de Gestión de Riesgos | Descripción de activos generados |
| LBC_ALC: Línea Base de Configuración de Alcance | Incremento 1 - Iteración 1: Planificación del desarrollo del software, incluye la inicialización de todos los planes |
Planificación de las actividades de gestión de riesgos para cada una de las fases del ciclo de vida del proyecto. Asignación de roles y recursos para la gestión de los riesgos. Definición de criterios de aceptabilidad de los riesgos. |
|
|
Incremento 1 - Iteración 2: Análisis de los requisitos software |
Análisis y definición del uso previsto y su mal uso razonablemente previsible. Identificación de los peligros conocidos y previsibles en relación con los médicos, los pacientes, el personal de servicio y cualquier otra persona que entre en contacto con el producto médico. Identificación de secuencias o combinaciones de eventos que podrían resultar en situaciones peligrosas. Estimación del riesgo para cada situación peligrosa identificada teniendo en cuenta la severidad de las posibles consecuencias. Decisión de si es necesaria la reducción del riesgo para el riesgo identificado. Identificación inicial de las medidas de control de riesgo software, para los riesgos identificados, que podrían impactar en el diseño, y determinación de si esas medidas de control resultarán adecuadas por sí solas o si se requerirá medidas de control de riesgos hardware. Revisión de las medidas de control identificadas por posibles nuevos peligros introducidos. |
||
| Incremento 2 - Iteración 2: Diseño arquitectónico del software |
Identificación de los elementos de software que podrían conducir a peligros con especial atención a las causas software. Identificación los peligros asociados. Identificación de las medidas de control de riesgos, a nivel de arquitectura, para aislar componentes críticos y prevenir o detectar las causas específicas de software que podrían incurrir en esos peligros. |
||
| Diseño detallado del software |
Identificación de las causas potenciales adicionales que contribuyen a situaciones peligrosas para las unidades software que constituirán los elementos o sistema software y que afecten a la seguridad. Re-evaluación de la eficacia de las medidas de control definidas para las unidades software identificadas. |
||
| Implementación y verificación de la unidad software | Identificación de causas potenciales de daños adicionales para los peligros analizados. | ||
| Integración software y ensayos de integración |
Verificación de las medidas de control de riesgos. Evaluación de aceptabilidad. |
||
| Ensayos del sistema software |
Verificación de las medidas de control de riesgos. Evaluación de aceptabilidad. |
||
| Liberación del software | Actualización del Informe de Gestión de Riesgos. |
Planificación de las actividades para el proyecto de mantenimiento de software MoSimPa
| Fase del ciclo de vida | Actividades de gestión de los riesgos | Descripción de activos generados |
| Establecimiento del plan de mantenimiento del software |
Planificación de las actividades de gestión de riesgos para cada una de las fases del ciclo de vida del proyecto de mantenimiento. Asignación de roles y recursos para la gestión de los riesgos. Definición de criterios de aceptabilidad de los riesgos. |
|
| Análisis de problemas y modificaciones |
Análisis del cambio para identificación nuevos peligros y situaciones peligrosas no reconocidas y causas asociadas a esos peligros. Re-evaluación de la clasificación de los riesgos y adecuación de las medidas de control de riesgos. Identificación de medidas de control de riesgo adicionales o necesidad de modificación de medidas existentes. |
|
| Implementación de las modificaciones |
Similar al proceso de desarrollo, pero con un enfoque en el impacto de los cambios en: • alteración de las medidas de control de riesgos existentes; • introducción de nuevas causas de peligros; • inclusión de nuevas funcionalidades en el uso previsto que introduce nuevos peligros; • verificación de las medidas de control nuevas o modificadas. |
Criterios para aceptabilidad de los riesgos
Criterios de aceptabilidad de riesgos y riesgos residuales
Los criterios de aceptación para los elementos/unidades que no son software se realizarán en base a la severidad del daño y a la probabilidad que el daño se dé ante la ocurrencia del fallo.
Los criterios de aceptación para los elementos/unidades software se realizarán solo en base a la severidad del daño, ya que en la sección B.4.3 de la IEC62304 y en la sección 4.4.3 de la IECTR-80002-1 se establece que la probabilidad en software es siempre 1 y se toma el riesgo como equivalente a la severidad del daño.
A continuación se especifican los criterios para aceptabilidad de los riesgos:
| Probabilidad | Descripción |
| Alta | Posible que ocurra, a menudo, frecuente |
| Media | Puede ocurrir, pero no frecuentemente |
| Baja | Improbable que ocurra, infrecuente, remoto |
| Severidad | Descripción |
| Alta: Muerte o Lesión Seria: Significativa | Muerte o perdida de la función o estructura |
| Media: Lesión No Seria: Moderada | Lesión reversible o pequeña |
| Baja: No es posible lesión | No causara lesión o lesionara ligeramente |
| Severidad | |||||
| Baja (A) | Media | Alta | |||
| Probabilidad | Alta (A) | MEDIO | ALTO | ALTO | |
| Media (M) | BAJO | MEDIO | ALTO | ||
| Baja (B) | BAJO | BAJO | MEDIO | ||
| Nivel de Riesgo | Acción |
| ALTO | Riesgo Inaceptable. Tomar medidas de control externo para la reducción |
| MEDIO | Riesgo Medianamente aceptable. Evaluar la factibilidad de tomar medidas de control para reducir tan bajo como sea posible |
| BAJO | Riesgo ampliamente aceptable. No es necesario tomar medidas de control |
Para cada Sistema/Elemento/Unidad Software considerado como Inaceptable se deberá definir el criterio de aceptabilidad para evaluar la eficacia de la medida de control del riesgo implementada:
| SISTEMA/ELEMENTO/UNIDAD SOFTWARE | RESULTADOS DE TESTING |
|---|---|
| Clase C | 100% caso de éxitos |
| Clase B | 60 % caso de éxitos |
| Clase A | 60 % caso de éxitos |
Aceptación del riesgo residual
Las pruebas (testing) tendientes a evaluar las Medidas de Control de Riesgos implementadas no deben identificar anomalías que implicarán nuevos riesgos. Esto permite evaluar la aceptación del riesgo residual de acuerdo al porcentaje de cobertura definido previamente.
Criterios de Aceptabilidad Residual Global
Los criterios de aceptabilidad global del software se subordinan a los criterios de aceptación del producto una vez definido el uso previsto.
Revisión de las actividades de gestión de riesgos
El Responsable de Aseguramiento de Calidad del Software (SQA) debe ejecutar la revisión del proceso de Gestión del Riesgo para cada hito definido en el proyecto de Desarrollo/Mantenimiento del Software MoSimPa.
| Hitos de revisión definidos en el proyecto de desarrollo | Actividades de Revisión |
| Diseño arquitectónico del software | Se revisará la documentación contenida en el Archivo de Gestión de Riesgos luego que el diseño arquitectónico haya sido validado. |
| Ensayos del sistema software | Se revisará la documentación contenida en el Archivo de Gestión de Riesgos luego de efectuados los testeos correspondientes y antes de cada entrega. |
| Hitos de revisión definidos en el proyecto de mantenimiento | Actividades de Revisión |
| Implementación de Modificaciones o Problemas | Se revisará la documentación contenida en el Archivo de Gestión de Riesgos luego de efectuados los cambios y luego de testeada su implementación |
Informe de la gestión de los riesgos
El informe de la gestión de los riesgos será una parte crucial del archivo de gestión de los riesgos.
Antes de entregar el producto médico para su distribución comercial, el fabricante debe efectuar una revisión del proceso de gestión de los riesgos. Esta revisión debe al menos asegurar que:
- el plan de gestión de los riesgos se ha implementado de forma apropiada;
- el riesgo residual global es aceptable;
- se han dispuesto los métodos apropiados para obtener la información de producción y posproducción pertinente.
Deberá ser un resumen de la revisión de los resultados finales del proceso de gestión de los riesgos. El informe representa el documento de nivel alto que proporciona la evidencia de que el fabricante se ha asegurado que el plan de gestión de los riesgos se ha cumplido de forma satisfactoria y que los resultados confirman que se ha alcanzado el objetivo requerido.
Información de Producción y posproducción
Las actividades relacionadas con la recolección y revisión de la información de producción y posproducción pertinente deben realizarse según lo definido en los documentos ………………….
Se supervisarán y evaluarán activamente las anomalías conocidas de los componentes SOUP identificados que constituyen el sistema software.
Hacer: linkear a la documentación pertinente.
Archivo de gestión de riesgos
Se debe establecer y mantener un archivo de gestión de los riesgos que proporcionará la trazabilidad para cada peligro identificado respecto a:
- el análisis del riesgo;
- la evaluación del riesgo;
- la implementación y verificación de las medidas de control del riesgo;
- la apreciación de la aceptabilidad de cualquier riesgo residual.
Para esto el archivo de gestión de riesgos deberá contener:
| Nombre del Activo | Link |
|---|---|
| Plan de Gestión de Riesgos | |
| Registro de Gestión de Riesgos | |
| Informe de Gestión de Riesgos |
Apéndices
Glosario
Clase de seguridad del software:
- Clase A: No es posible lesión o daño para la salud.
- Clase B: Es posible lesión no-seria.
- Clase C: Es posible muerte o lesión seria.
Definición según IEC 62304:2006
-
Lesión seria: Lesión o dolencia que directa o indirectamente:
-
amenaza la vida;
- resulta en un perjuicio permanente de una función del cuerpo humano o lesión permanente de una estructura del cuerpo humano; o
- necesita intervención médica o quirúrgica para prevenir un perjuicio permanente de una función del cuerpo humano o lesión permanente a una estructura del cuerpo humano.
Definición según IEC 62304:2006
- archivo de gestión de los riesgos: Conjunto de registros y otros documentos que produce la gestión de los riesgos.
Definición según ISO 14971:2007
Historial de Cambios
El historial de los cambios puede consultarse en la historia de las revisiones o mediante la identificación de las versiones tageadas según el Sistema de Control de Versionado (VCS, Version Control System) empleado. La descripción de los cambios estará especificada en los comentarios del commit correspondiente.
Revisión: Nro. De revisión.
Tipo de Cambio: A – alta, B – borrado, M-modificación.
Sección, figura, etc: Indique la sección, parráfo o diagrama del documento que fue modificado.
Fecha: Fecha en la que se produjo el cambio
Descripción: Descripción del cambio realizado