Validação de Softwares, o guia definitivo – Parte I: como começar um processo de validação

Afinal, o que é validação de softwares? Como o Tiago Stifft já apontou em outro artigo, “A validação de sistemas computadorizados é um processo que consiste em desafiar e documentar um sistema e todo o seu meio ambiente, a fim de garantir e evidenciar que ele atenda a um conjunto de requisitos definidos”. Ou seja: se o seu software executa alguma função crítica no SGQ, você deve provar que ele faz isso direitinho, e sempre, e documentar essa prova. Isso serve para garantir que o seu sistema não está fazendo alguma coisa errada, e que você não vai notar isso só quando for tarde demais.

O Tiago também já apontou quais os tipos de sistema que você pode ter na sua organização, o que eles fazem, as formas possíveis de validação de softwares e uma estrutura de planejamento sugerida por ele, para você usar. É interessante ler o artigo dele para introduzir o assunto. Vai lá: Clique Aqui

Ok, entendido. Mas, e agora? Como é que a gente faz a validação de softwares?

Nesse artigo, vou tentar explicar isso de uma forma bem simples. Essa estrutura pode servir para você compreender o processo de Validação de Software e executar a sua primeira Validação de Softwares, prevendo que você a aprimore no futuro.

Uma observação importante, antes de começar: o processo de validação de softwares é ÚNICO para cada empresa, mesmo que várias empresas usem o mesmíssimo software. Porque isso? Porque os Requerimentos de Usuário e as Especificações Funcionais de cada software (como nós vamos ver abaixo) são específicos para cada empresa, cada processo, cada produto. Cada empresa precisa usar o software de um jeito diferente, e você precisa provar, documentalmente, que o sistema funciona dentro da SUA realidade. Então, não adianta copiar documentação de validação de ninguém!

Vamos lá!

Passo 1: faça um levantamento de todos os softwares na sua organização.

A primeira coisa que você deve definir é o escopo da Validação de Softwares na sua empresa. Afinal, o que você precisa validar, mesmo?

Bem, então, quais os sistemas que você deve incluir no escopo da sua validação, afinal? Todos aqueles que auxiliem ou executem de forma automática alguma ação, monitoramento, atividade ou controle que possa impactar no seu Sistema de Gestão da Qualidade ou na qualidade do seu produto.

Se você tem um software do tipo ERP para executar aberturas de OPs, abertura e fechamento de atividades, etc., você tem que validá-lo, pois ele provavelmente interfere em várias atividades dentro do seu processo. Se você tem uma planilhinha Excel com uma macro que calcula a quantidade de amostras que você deve coletar em uma análise, baseada em algum Plano de Amostragem, você deve validá-la, afinal, ela impacta na Qualidade do produto. Se você tem um sistema tipo “software de prateleira” que faz somente faturamento e emissão de Notas Fiscais, você tem que validá-lo também, pois afinal, ele impacta na rastreabilidade.

Uma nota minha sobre softwares embarcados em máquinas: sim, eles impactam, e muito, na qualidade do produto, visto que eles podem, por exemplo, estabelecer sozinhos parâmetros de processo, como temperatura, pressão, corrente, posição de ferramenta, e esses parâmetros afetam a qualidade do produto. Mas eu não faço uma validação específica para eles. Eu incorporo essa validação na Qualificação de Equipamentos. Mas isso é uma filosofia minha de trabalho!

Fez o levantamento de todos os sistemas que precisam ser validados na sua empresa? Ótimo. Inclua esses sistemas no Plano Mestre de Validação, e comece a definir os requerimentos de cada um deles (Passo 2) em documentos separados (eu sugiro validar um software de cada vez, separadamente).

Passo 2: Definir os User Requirements (URs) do seu software

Os URs são os requisitos do processo – no caso, as funcionalidades que o seu software deve ter. Nessa etapa, você deve fazer um mapeamento das funções críticas (as que podem impactar na qualidade do seu produto) que você espera que o seu software execute.

Vou dar alguns exemplos:

-Criação de uma Ordem de Produção: É uma função extremamente crítica, que impacta em toda a cadeia de rastreabilidade do produto. Nessa função do software, seus requisitos podem ser de que ele gere, automaticamente, um número de lote; também, pode ser que você espere que o software registre o lote e quantidade de matéria-prima utilizados nessa Ordem de Produção, pelo método FIFO, de forma automática.

– Qualificação de Fornecedores: Outra função suuuper crítica que você pode querer que o sistema execute. Seu requisito para o sistema pode ser que ele bloqueie, sozinho, a criação de Ordens de Compra contra fornecedores desqualificados.

– Inspeção: Você pode alimentar o sistema com os Limites de Tolerância para uma cota crítica, e esperar que, quando o operador digitar a medição que ele fez no sistema, o sistema informe se essa medição está dentro dos limites de tolerância, e verifique se esse produto está conforme, ou não.

E essa lista vai longe. Amostragem: seu sistema de Controle da Qualidade deveria fazer a comutação de Severo para Normal e te informar a quantidade de amostras de uma inspeção? Ou seu sistema deve registrar a quantidade exata de etiquetas que você imprimiu para rotular determinado produto?

Pense bem e defina TODOS os requisitos do seu sistema em uma lista. Concluído esse levantamento, siga para o passo 3.

Passo 3: Especificações Funcionais

Para cada um dos requisitos de sistema levantados anteriormente, agora, faça um levantamento das especificações funcionais, ou seja, a função que o software deve executar para atender ao seu requisito. Vou dar um exemplo:

Criação da Ordem de Produção

Requisito 1:

Geração do Número de Lote: O software deve gerar um Número de Lote de forma automática, no formato XXXX/AA, onde XXXX é um número sequencial, e YY é o ano de criação da OP. O Número de Lote deve ser único e não deve se repetir.

Requisito 2:

Seleção e Registro de Matéria-Prima. Se eu informar a quantidade de matéria-prima Y que cada unidade de produto exige para ser fabricada, o sistema deve calcular automaticamente a quantidade total de matéria-prima que um lote de 100 unidades vai consumir. Além disso, o sistema deve selecionar o lote de matéria-prima que eu vou consumir pelo sistema FIFO. O sistema deve registrar a quantidade e o número de lote na OP, para o meu auxiliar de almoxarifado usar essas informações para buscar matéria-prima no estoque.

Definiu as Especificações Funcionais para cada um dos User Requirement que você levantou? Então pronto! Os fundamentos do seu Plano de Validação estão quase definidos!

No próximo artigo, nós vamos ver como fazer a Qualificação de Instalação, a Qualificação de Operação e a Qualificação de Desempenho do seu software.