El proceso de validar software industrial no es una tarea trivial, pero con una buena orientación y metodología consistente, puede convertirse en un procedimiento que fluirá naturalmente según el desarrollo de las etapas.

El post Necesito validar mi software. ¿Por dónde empiezo? presentó las consideraciones y pasos iniciales en este proceso, desde la identificación si de hecho el sistema necesita o no ser validado hasta el diagrama de flujo macro de las actividades involucradas. También hemos visto en el post ¿Cómo realizar la gestión de riesgos en la validación de software? como es relevante entender y clasificar cada funcionalidad del sistema.

Ha llegado el momento de presentar las documentaciones y protocolos que necesitan ser creados y evaluados como parte del alcance del proceso de validar software industrial, independientemente del plan de validación adoptado por su empresa.

¡Buena lectura!

Especificación de Requisitos de Usuario (URS – User Requirement Specification)

Este documento debe definir de forma clara y objetiva todos los requisitos necesarios que un sistema computarizado debe atender. Debe ser revisado y aprobado por los usuarios involucrados, incluyendo la Garantía de Calidad, y puede ser elaborado en conjunto con el proveedor del software.

Los requisitos del usuario deben contemplar todas las necesidades de la empresa en relación a la instalación, operación y desempeño del sistema. También deben ser consideradas todas las necesidades del usuario en términos de capacidad tecnológica, seguridad de los datos e informaciones, requisitos de ingeniería, interfaces, mantenimiento y atención a las BPx.

BPx: término general para aplicación de las buenas prácticas relacionadas con cualquier área (fabricación, distribución, investigación clínica, laboratorio, etc.).

Por el alcance de las áreas involucradas, es recomendable que la elaboración de este documento sea realizada por un equipo multidisciplinario para que todas las necesidades sean debidamente identificadas y descritas como requisitos.

Clasificación de los Requisitos

Después de definir los requisitos, la Guía de la ANVISA (Agencia Nacional Brasileña de Vigilancia Sanitaria) recomienda realizar la clasificación de los mismos para contribuir con la identificación de los posibles riesgos a las BPx que un sistema computarizado puede presentar.

Algunas de las principales clasificaciones utilizadas:

• Informativo: no es exactamente un requisito sino una información que será dada a los proveedores para auxiliarlos en la elaboración de sus propuestas comerciales;
• Importante: requisito que se verificará de modo obligatorio durante el desarrollo del sistema/equipo, pero que no será necesariamente evaluado durante el proceso de validación del sistema, por no tener impacto en BPx;
• Regulatorio y/o Obligatorio: requisito que obligatoriamente deberá ser considerado durante el desarrollo del sistema/equipo y obligatoriamente será evaluado durante el proceso de validación del sistema por tener impacto en BPx;
• Deseable: requisito que se desea en el desarrollo del sistema, pero el mismo no obligatoriamente podrá ser considerado por el proveedor, o incluso desconsiderado si acarrear demasiados costos o dificultades técnicas para atenderlo.

A partir de esta clasificación usted tendrá el mapeo de los ítems que requieren un mayor detalle y que necesariamente deben ser contenidos en los protocolos de pruebas de validación.

Especificación de Requisitos de Sistema (SRS – System Requirement Specification)

Este ítem describe todos los requisitos técnicos considerando hardware y software, siendo deseable también la descripción de servidores, arquitectura de red, estaciones de trabajo y hardware de automatización cuando sea aplicable. Ejemplos de elementos a considerar:

• Descripción del hardware (considerando computadoras, componentes, CPU, memorias, capacidad, etc.);
• Entradas/salidas de datos, considerando señales analógicas y/o digitales;
• Temperatura y humedad del ambiente en el cual los equipos están instalados;
• Interferencias externas;
• Etc.

Una vez descritas todas las especificaciones del usuario y sistema, que son la base para desarrollar los protocolos para validar software industrial, se sigue al paso de la descripción de las especificaciones funcionales.

Especificación de Requisitos Funcionales (FRS – Functional Requirement Specification)

La especificación funcional sirve para definir completamente lo que el sistema hace y qué funciones e instalaciones se proporcionan para satisfacer las necesidades descritas en los Requisitos del Usuario.

La especificación funcional debe ser clara y organizada de una manera que permita la trazabilidad entre los requisitos del usuario y las funcionalidades. Por lo tanto, se recomienda que cada requisito y funcionalidad contenga un único número de referencia para facilitar la trazabilidad y la referencia cruzada con otros documentos.

De hecho lo que se debe hacer es el desdoblamiento de los requisitos del usuario para un nivel de funciones individuales, donde puede describirse la siguiente información con los siguientes aspectos:

• Detalles de los aspectos funcionales y de datos del sistema que cumplen los requisitos del usuario;
• Todas las limitaciones del sistema, observando cualquier divergencia entre la funcionalidad proporcionada por el sistema con respecto a los requisitos del usuario;
• Objetivo de cada función o instalación;
• Descripción de las interfaces internas y externas;
• Entradas, salidas, cálculos críticos, lógicas de funcionamiento, e impactos en otras funciones u otros sistemas;
• Acción en caso de fallas del software seleccionado o fallas en el hardware, chequeos automáticos, chequeo de valores de entrada, redundancia, restricciones de acceso y recuperación de datos;
• Funciones que son parametrizables/configurables y sus límites;
• Funciones relativas a la seguridad del sistema;
• Etcétera

¿Son muchos detalles no es así?

Para hacer más simple el entendimiento de las funcionalidades, se recomienda también la elaboración del diseño del software (Software Design). Este elemento proporciona detalle técnico del sistema, siendo una expansión de la especificación funcional con diagramas de flujo y esquemas. Ayuda en la descripción de cómo el sistema atenderá cada una de las funciones definidas en la especificación funcional.

Pruebas de Calificación

Con los requisitos del sistema y usuario definidos y las respectivas funcionalidades detalladas, el proceso de validar software industrial parte para la etapa de elaboración de los protocolos de pruebas, que tienen como objetivo justamente comprobar las funcionalidades descritas.

Las comprobaciones deben ser firmadas y fechadas, y las desviaciones, no conformidades y/o condiciones cuestionables detectadas durante la ejecución de la calificación, deben ser registradas, investigadas y controladas.

Calificación de Instalación (IQ – Installation Qualification)

Tiene por objetivo verificar y documentar las condiciones de instalación del sistema y si cumple satisfactoriamente con los requisitos previamente aprobados en la especificación técnica.

Calificación de Operação (OQ – Operational Qualification)

Tiene como objetivo referenciar, verificar y documentar las condiciones de operación del sistema y si éste cumple satisfactoriamente con los requisitos predefinidos para su operación. Cuando sea posible, el protocolo debe ser ejecutado en un ambiente de pruebas, siendo esta copia fiel del ambiente que será usado en producción.

Calificación de Desempeño (PQ – Performance Qualification)

Se trata de referir, verificar y documentar que el sistema computarizado, después de ser instalado en el ambiente de producción y estar adecuadamente parametrizado, cumple satisfactoriamente con los requisitos predefinidos por la especificación de requerimientos del usuario y o especificación funcional.

Matriz de Trazabilidad (TM – Traceability Matrix)

La Matriz de Trazabilidad establece la relación entre los documentos desarrollados durante el proceso de validar software industrial. Se puede demostrar de varias maneras, desde la elaboración de una tabla de información cruzada o referencias directamente insertadas en los documentos.

La idea es conseguir conectar todo de forma rápida. La matriz debe responder lo siguiente: «¿Qué elementos del protocolo de validación comprueban la funcionalidad solicitada por el usuario descrita en el requisito?»

Documentos para validar software industrial finalizados. Y ahora?

Ahora entra el mantenimiento del estado validado, que es gestionado por una serie de procedimientos operativos para asegurar que se mantenga este estado del sistema.

Uno de los procedimientos extremadamente relevantes es el de Control de Cambios, que debe presentar la descripción de las acciones a ser tomadas para la ejecución de una alteración o corrección del sistema validado durante o después del término de la Calificación (recuerda en el diagrama de flujo 1 presentado en este post los demás procedimientos relevante).

Para finalizar el asunto

Este es el tercer post que tratamos de validación de software, lo que muestra que este tema es bastante extenso no es así?

Pero todavía tiene más. Debido a la complejidad de los sistemas computarizados, existe una estandarización global que pretende clasificarlos según su actuación, facilitando el entendimiento de su aplicación. Y para cada clasificación, la Guía de ANVISA describe sus particularidades a ser consideradas en este proceso de validar software industrial.

Pero destacamos nuevamente que, con la orientación correcta, el proceso de validar software industrial puede ser desarrollado de forma robusta y eficiente, comprobando la seguridad de sus informaciones y convirtiéndose en una herramienta de mejora y prevención de fallas.

 Si usted necesita ayuda con la validación de software o cumplimiento con la FDA CFR 21 Part 11, póngase en contacto con nosotros  para más detalles sobre cómo nuestro equipo puede ayudarle en este proceso.