[:pb]O processo de validar software industrial não é uma tarefa trivial, mas com uma boa orientação e metodologia consistente, tornar-se um procedimento que irá fluir naturalmente conforme o desenrolar das etapas.

O post Preciso validar meu software. Por onde começo? apresentou as considerações e passos iniciais neste processo, desde a identificação se de fato o sistema precisa ou não ser validado até o fluxograma macro das atividades envolvidas. Também vimos no post Como realizar o gerenciamento de riscos na validação de software? como é relevante entender e classificar cada funcionalidade do sistema.

Chegou a hora de apresentar as documentações e protocolos que precisam ser criados e avaliados como parte do escopo do processo de validar software industrial, independente do plano de validação adotado pela sua empresa.

Boa leitura!

Especificação de Requisitos do Usuário (URS – User Requirement Specification)

Este documento precisa definir de forma clara e objetiva todos os requisitos necessários que um sistema computadorizado deve atender. Deve ser revisado e aprovado pelos usuários envolvidos, incluindo a Garantia da Qualidade, e pode ser elaborado em conjunto com o fornecedor do software.

Os requisitos do usuário devem contemplar todas as necessidades da empresa em relação à instalação, operação e desempenho do sistema. Também devem ser consideradas todas as necessidades do usuário em termos de capacidade tecnológica, segurança dos dados e informações, requisitos de engenharia, interfaces, manutenção e atendimento às BPx.

BPx: termo geral para aplicação de boas práticas relacionadas a qualquer área (fabricação, distribuição, pesquisa clínica, laboratório, etc.).

Pela abrangência das áreas envolvidas, é recomendável que a elaboração deste documento seja realizada por uma equipe multidisciplinar para que todas as necessidades sejam devidamente identificadas e descritas como requisitos.

Classificação dos Requisitos

Após definir os requisitos,  o Guia da ANVISA recomenda realizar a classificação dos mesmos para contribuir com a identificação dos possíveis riscos às BPx que um sistema computadorizado pode apresentar.

Algumas das principais classificações a serem utilizadas:

• Informativo: não é exatamente um requisito e sim uma informação que será dada aos fornecedores para auxiliá-los na elaboração de suas propostas comerciais;
• Importante: requisito que obrigatoriamente será verificado durante o desenvolvimento do sistema/equipamento, mas que não será necessariamente avaliado durante o processo de validação do sistema, por não ter impacto em BPx;
• Regulatório e/ou Mandatório: requisito que obrigatoriamente deverá ser considerado durante o desenvolvimento do sistema/equipamento e obrigatoriamente será avaliado durante o processo de validação do sistema por ter impacto em BPx;
• Desejável: requisito que se deseja no desenvolvimento do sistema, porém o mesmo não obrigatoriamente poderá ser considerado pelo fornecedor, ou mesmo desconsiderado se acarretar custos demasiados ou dificuldade técnicas para atendê-lo.

A partir dessa classificação você terá o mapeamento dos itens que requerem um maior detalhamento e que necessariamente devem ser contidos nos protocolos de testes de validação.

Especificação de Requisitos do Sistema (SRS – System Requirement Specification)

Este item descreve todos os requisitos técnicos considerando hardware e software, sendo desejável também a descrição de servidores, arquitetura de rede, estações de trabalho e hardware de automação quando aplicável. Exemplos de itens a considerar:

• Descrição do hardware (considerando computadores, componentes, CPU, memórias, capacidade, etc.);
• Entradas/saídas de dados, considerando sinais analógicos e/ou digitais;
• Temperatura e umidade do ambiente no qual os equipamentos estão instalados;
• Interferências externas;
• Etc.

Uma vez descritas todas as especificações do usuário e sistema, que são a base para desenvolver os protocolos para validar software industrial, segue-se para a etapa da descrição das especificações funcionais.

Especificação de Requisitos Funcionais (FRS – Functional Requirement Specification)

A especificação funcional serve para definir completamente o que o sistema faz e quais funções e instalações são fornecidas para atender as necessidades descritas nos Requisitos do Usuário. 

A especificação funcional deverá ser clara e organizada de uma maneira que permita rastreabilidade entre os requisitos do usuário e as funcionalidades. Por isso, é recomendável que cada requisito e funcionalidade contenham um único número de referência para facilitar a rastreabilidade e a referência cruzada com outros documentos.

De fato o que deve-se fazer é o desdobramento dos requisitos do usuário para um nível de funções individuais, onde podem ser descritos as seguintes informações com os seguintes aspectos:

• Detalhes dos aspectos funcionais e de dados do sistema que atenderão aos requisitos do usuário;
• Todas as limitações do sistema, observando quaisquer divergências entre a funcionalidade fornecida pelo sistema com relação aos requisitos do usuário;
• Objetivo de cada função ou instalação;
• Descrição das interfaces internas e externas;
• Entradas, saídas, cálculos críticos, lógicas de funcionamento, e impactos em outras funções ou outros sistemas;
• Ação em caso de falhas do software selecionado ou falhas no hardware, checagens automáticas, checagem de valores de entrada, redundância, restrições de acesso e recuperação de dados;
• Funções que são parametrizáveis/configuráveis e seus limites;
• Funções relativas à segurança do sistema;
• Etc.

São muitos detalhes não é mesmo?

Para tornar mais simples o entendimento das funcionalidades, recomenda-se também a elaboração do desenho do software (Software Design). Este item fornece detalhe técnico do sistema sendo uma expansão da especificação funcional utilizado fluxogramas e esquemas. Auxilia na descrição de como o sistema atenderá cada uma das funções definidas na especificação funcional.

Testes de Qualificação

Com os requisitos do sistema e usuário definidos e as respectivas funcionalidades detalhadas, o processo de validar software industrial parte para a etapa de elaboração dos protocolos de testes, que possuem como objetivo justamente comprovar as funcionalidades descritas.

As verificações devem ser assinadas e datadas, e os desvios, não-conformidades e/ou condições questionáveis detectados durante a execução da qualificação, devem ser registrados, investigados e controlados.

Qualificação de Instalação (IQ – Installation Qualification)

Visa verificar e documentar as condições de instalação do sistema e se este cumpre satisfatoriamente com os requisitos previamente aprovados na especificação técnica.

Qualificação de Operação (OQ – Operational Qualification)

Tem com objetivo referenciar, verificar e documentar as condições de operação do sistema e se este cumpre satisfatoriamente com os requisitos pré-definidos para sua operação. Quando possível, o protocolo deve ser executado em ambiente de testes, sendo este cópia fiel do ambiente que será usado em produção.

Qualificação do Desempenho (PQ – Performance Qualification)

Tem como objetivo referenciar, verificar e documentar que o sistema computadorizado, após ser instalado no ambiente de produção e estar adequadamente parametrizado, cumpre satisfatoriamente com os requisitos pré-definidos pela Especificação de Requerimentos do Usuário e/ou Especificação Funcional.

Matriz de Rastreabilidade (TM – Traceability Matrix)

A Matriz de Rastreabilidade estabelece a relação entre os documentos desenvolvidos durante o processo de validar software industrial. Ela pode ser demonstrada de várias maneiras, desde a elaboração de uma tabela de informação cruzada ou referências diretamente inseridas nos documentos.

A ideia é conseguir conectar tudo de forma rápida. A matriz deve responder o seguinte: “Quais itens do protocolo de validação comprovam a funcionalidade solicitada pelo usuário descrita no requisito?”

Documentos para validar software industrial finalizados. E agora?

Agora entra a manutenção do estado validado, que é gerida por uma série de procedimentos operacionais de forma a assegurar que seja mantido este estado do sistema.

Um dos procedimentos extremamente relevantes é o de Controle de Mudanças, que deve apresentar a descrição das ações a serem tomadas para execução de uma alteração ou correção do sistema validado durante ou após o término da Qualificação (relembre no fluxograma 1 apresentado neste post os demais procedimentos relevantes).

Para finalizar o assunto

Este é o terceiro post que tratamos de validação de software, o que mostra que este tema é bastante extenso não é mesmo?

Mas ainda tem mais. Devido a complexidade dos sistemas computadorizados, existe uma padronização global que visa classificá-los conforme sua atuação, facilitando o entendimento de sua aplicação. E para cada classificação, o Guia da ANVISA descreve respectivas particularidades a serem consideradas neste processo de validar software industrial.

Mas destacamos novamente que, com a orientação correta, o processo de validar software industrial pode ser desenvolvido de forma robusta e eficiente, comprovando a segurança das suas informações e tornando-se uma ferramenta de melhoria e prevenção de falhas.

Se você precisa de ajuda com a validação de software ou cumprimento com a FDA CFR 21 Part 11, entre em contato conosco para mais detalhes de como a nossa equipe pode auxiliá-lo neste processo.[:es]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.[:]