Conteúdo – sábado - matutino

2. Metodologias e configuração de sistemas

2.1 Análise de Riscos – Metodologia GAMP
2.2 Hardware, software e sistema operacional
2.3 Interface com equipamentos e softwares e rotinas operacionais
2.4 Backup, Archive, Restore
2.5 Queda de energia e indisponibilidade de sistemas
2.6 Categorização de sistemas
2.1 Análise de Riscos segundo metodologia GAMP

• Avaliar através do conhecimento das especificações do sistema e nos processos

que os mesmos estão inseridos os potenciais impactos na saúde do consumidor,
qualidade do produto e integridade de dados.
• Dano - danos para a saúde, incluindo danos que podem ocorrer devido a uma
perda de qualidade do produto ou de sua disponibilidade.
• Perigo - fonte com potencial para provocar danos.
• Risco - a combinação da probabilidade de ocorrência e a severidade do dano.
• Severidade - medida das possíveis consequências do perigo.
• Detectabilidade - probabilidade desta falha ser detectada antes do risco
ocorrer.
2.1 Análise de Riscos
• Através da prioridade do risco são avaliados os processos e funcionalidades do
sistema que requerem validação e o esforço para cada um deles.
• Sugestão: Prever uma etapa de familiarização durante um projeto de validação
para avaliar de forma mais precisa as funções e processos realizados pelo
software.
Exemplo de Medidas através da Prioridade do
Risco
Função Risco Baixo Risco Médio Risco Alto

Verificar1 valor abaixo de Verificar os valores a

10, 1 entre 10 e 20, e 1 seguir: 9,9; 10,0; 10,1;
acima de 20 19,9; 20,0; 20,1.

Campo para inserção Desafiar valores nulos Desafiar valores nulos

Verificar a
de dados que são
inserção normal
aceitos entre 10,0 e
dos dados Verificar decimais
20,0
incorretos

Desafiar caracteres do
tipo texto
2.2 Hardware, Software e Sistema Operacional
• Avaliar os requisitos para que o sistema opere corretamente.
• Não atendimento pode provocar lentidão, falhas de comunicação
O quê avaliar no Hardware? Cuidado com requisitos mínimos e recomendados.
• Memória RAM –
• HD – Espaço disponível em disco ou espaço total
• Processador
• Placa de vídeo, Placa de rede, som, entrada VGA, cabo hdmi, leitor de
disquete/cd/dvd, Portas usb 3.0
• Monitor com resolução mínima de:
Software
• Leitor de PDF – impressão de dados
• Excel – cálculos internos
• Apache/Tomcat
• .net framework
• Dotnet
• Citrix
Sistema Operacional
• Windows (10, 8, 7, XP) – necessário virtualização?
• Windows Server
• Linux
• Android
• IOS
Exercício – Instalação sistema de documentação
• Será instalado um sistema de documentação na sua empresa. Os requisitos de hardware do sistema, a capacidade do
servidor físico da sua empresa e a capacidade da máquina virtual onde será instalado o software estão na tabela abaixo. É
possível instalar o software no servidor virtual?

Requisitos Sistema de documentação Servidor da sua empresa

Componente Mínimo Recomendado Componente Físico Virtual

Espaço 500gb 1000gb Espaço disponível em 8000gb 1000gb

disponível em disco
disco
Processador 10 núcles com 3,6 GHz Quad Core 2,2 GHz
Processador Dual Core 2,4 Quad Core 2,8 total Total
GHz total GHz Total
Memória RAM 32 GB 4 GB
Memória RAM 4 GB 8GB

Sistema operacional Windows Server 2019 Windows 10

Sistema Windows XP Windows XP
operacional
Net Framework 3.5 3.5
Net Framework 4.0 4.0

Leitor de PDF Sim (Acrobat Reader) Sim (Foxit Reader)

Leitor de PDF Sim Sim
2.3 Interface com equipamentos e softwares e
rotinas operacionais
Caso o sistema esteja conectado a um ERP, Sistema de documentação,
instrumentos de medição ou equipamentos é necessário testar a interface.
Para equipamentos e instrumentos:
• Teste de I/O (ex. instrumentos de medição)
• Teste de operação de cada um dos módulos (ex. equipamentos de laboratório)
Para sistemas:
• Verificar o tipo de comunicação (única ou bidirecional)
• Verificar que o dado foi registrado no sistema que recebeu a informação
Rotinas operacionais
Alguns sistemas para realizarem ações requerem que alguns serviços
ou rotinas estejam ativas. Exemplo:
• Expiração de lote SAP - jobs
• Comunicação com historiador – supervisórios
• Comunicação com banco de dados –
• Licença de usuários – softwares com gerenciadores de licença
2.4 Backup, Restore e Archive
Devem existir alternativas para manter o processo em operação.
Algumas alternativas:
• Redundância
• Nobreak / UPs
• Gerador
• Registros impressos ou manuais
• Formulários de contingência
Backup e Restore
• Backup
Cópia de uma base de dados ou do software efetuado em uma mídia externa capaz
de garantir a restauração posterior quando necessário. O objetivo é proteger
contra a perda física ou lógica dos dados do sistema.

• Restore
Capacidade de restaurar dados de um banco de dados / mídia externa
Deve existir procedimentos que assegurem o processo de backup, restauração e
manutenção dos registros. Documentar local de armazenamento, frequência de
backup, aprovação para atividade de restore, avaliar o impacto e riscos
relacionados a restauração.
O processo de backup e Restauração deve ser documentado e testado.
Manter os registros precisos e legíveis –
Backup/Arquivamento
• Exemplo de um relatório de backup do Empower

Estamos avaliando se
ocorrem falhas no backup
(Warnings)?
Plano de contingência
Informa como o negócio/processo continua a operação definindo passos
requeridos para restaurar o sistema e, se apropriado, definindo como registrar os
dados e continuar o processo durante a resolução da falha.
Defini as funções e responsabilidade durante a indisponibilidade do sistema e o
momento/evento que dá início a este plano.

Ex. Indisponibilidade do Analisador de TOC do Controle de Qualidade.

Efeito: Impossibilidade de analisar Carbono Orgânico Total no Sistema.
Continuidade do negócio: Realizar as análises conforme metodologia aprovada no
sistema durante a indisponibilidade do sistema registrando as análises no
formulário anexo ao POP do método.
Recuperação de Desastre

A recuperação de desastre tem por objetivo planejar as ações a serem

adotadas para que sistemas computadorizados validados voltem a
operar em ambiente de produção.
Normalmente são definidos SLAs (Service Level Agreement) com o
fornecedor do sistema ou do servidor descrevendo as
responsabilidades e ações necessárias.
Deve existir um procedimentos relacionados a recuperação após
desastres;
Exercício: Falha no Maldi-TOF

Queima do HD em um computador com o software Maldi-TOF

instalado. Como proceder?
2.5 Queda de energia e indisponibilidade de
sistemas
Devem existir alternativas para manter o processo em operação.
Algumas alternativas:
• Redundância
• Nobreak / UPs
• Gerador
• Registros impressos ou manuais
• Formulários de contingência
Exercício – Teste de queda de energia

Na empresa FARMAT foi instalado uma compressora controlada por um

computador com um software instalado. O computador está ligado em
uma rede de energia que possui nobreak para casos de falha.
A mesma está em processo de qualificação e/ou validação.
Foi contemplado um risco para o tema queda de energia. Como você
realizará este teste?
2.6 Categoria de Software
Categoria Descrição
• Software de Camada (isto
é, sobre os quais aplicações
Software de
são construídas)
Infraestrutura (1)
• Software utilizados para
gerenciar o ambiente
operacional
Parâmetros em tempo de
execução podem ser
inseridos e armazenados,
Software Não-
mas o software não pode
Configurado (3)
ser configurado para se
adequar aos processos de
negócio
SOFTWARE
Exemplos Abordagem típica
• Sistemas operacionais
• Mecanismos de bancos de dados
• Middleware
• Registro do número da versão e verificação da
• Linguagens de programação
correta instalação
• Pacotes estatísticos
• Vide GAMP Good Practice Guide: IT Infraestructure
• Planilhas
Control and Compliance
• Ferramentas de monitoramento de rede
• Ferramentas de agendamento
• Ferramentas de controle de versão
• Ciclo de vida abreviado
• Abordagem para avaliação do fornecedor com base
no risco
• Aplicações com base em firmware
• Registro do número da versão e verificação da
• Softwares do tipo COTS
correta instalação
• Instrumentos de Laboratório (Vide GAMP Good
• Testes com base no risco contra os requisitos, tendo
Practice Guide: Validation of Laboratory
por base a sua utilização (para sistemas simples a
Computerized Systems)
calibração pode ser a substituta dos testes)
• Existência de procedimentos para a manutenção do
atendimento e adequação ao uso
Categoria 3 Estratégia

Fonte: ISPE GAMP 5.

2.6 Categoria de Software
SOFTWARE
Categoria Descrição Exemplos Abordagem típica

• Abordagem de ciclo de vida

• Abordagem para avaliação do fornecedor com base
• LIMS no risco
• Sistemas de aquisição de dados • Demonstração de que o fornecedor possui um
• SCADA Sistema de Gerenciamento da Qualidade
• ERP • Alguma documentação do ciclo de vida mantida
Softwares, geralmente
• MRPII pelo fornecedor (ex.: Especificações de Projeto)
mais complexos, que
• DCS • Registro do número da versão e verificação da
Software podem ser configurados
• CDS correta instalação
Configurado (4) pelo usuário para atender
• EDMS • Realização de testes com base no risco para
as suas necessidades
• BMS demonstrar que a aplicação funciona conforme
especificas. O código do
• Planilhas projetada, em um ambiente de teste
software não é alterado.
• HMI (Human Machine Interfaces) simples • Realização de testes com base no risco para
NOTA: Exemplos específicos de tipos de sistemas demonstrar que a aplicação funciona conforme
acima podem conter elementos customizados projetada, em um ambiente de produção
substanciais. • Existência de procedimentos para a manutenção do
atendimento e adequação ao uso e gerenciamento
dos dados
Categoria 4 - Estratégia

Fonte: ISPE GAMP 5.

2.6 Categoria de Software

SOFTWARE

Categoria Descrição Exemplos Abordagem típica

Varia, mas inclui: Mesma abordagem utilizada para a Categoria

• Aplicações de TI desenvolvidas
internamente e externamente
Software customizado
Softwares • Aplicações para controle de processo
projetado e codificado
customizados desenvolvidas internamente e externamente
para atender a um
(5) • Lógica de escada personalizada
processo de negócio.
• Firmware personalizado
RPAs (Robotic Process Automation)
• Planilhas (macro)
4, mais:
• Uma avaliação de fornecedor mais rigorosa,
com possível auditoria deste
• Posse da documentação de todo o ciclo de
vida do sistema (Especificações Funcionais,
Especificações de Projeto, testes estruturais
etc.)
• Revisão do Projeto e do Código Fonte
Categoria 5 - Estratégia

Fonte: ISPE GAMP 5.

Fonte: ISPE GAMP 5.
 Exemplos de categorias de sistemas
Tipo Categoria Exemplos

Corporativos 4 SAP, Soft Expert, TrackWise, Ultrareg, Evolutio

5 Empower Enterprise (com o uso de Custom Field)

Analíticos 4 Empower Enterprise (sem o uso de Custom Field

3 Empower Personal (sem custom field, instalação local), Mastersize, Vision, Rheocalc, Chemstation,

Supervisório de Monitoramento (Base SCADA, Elipse)

4
Supervisórios de HVAC ou Sistema de Água
Supervisórios
3 Supervisórios de uma única câmara de estabilidade

Equipamentos onde o sistema é um padrão de mercado - Emblistadeiras, Sistemas de Visão, Balanças

3
Embarcados de Dinâmicas
Produção
4 Equipamentos onde o sistemas foi configurados para atender um determinado cliente

Não Embarcados de
4 ou 5 Sistemas que controlam processos produtivos e normalmente envolve receitas - Manipulação de Líquidos,
Produção

Planilhas, Banco de
3, 4 ou 5 Planilhas de cálculo de teor, peso médio, gestão de inventário, desvios
Dados ou estatística
Categoria de Hardware
Hardware

ANVISA GAMP TIPO ABORDAGEM

• Instalação correta e conectividade;

1 1 Padrão • Modelo, número da versão e número serial;
• Hardware’s data sheet ou especificação de materiais.
• Especificação de desenho;
• Testes de aceitação;
2 2 Customizado
• Qualificação do fornecedor;
• Compatibilidade da conexão entre os componentes de hardware.
ERPs – Qual categoria?

• Teoria – Categoria 4
• Desenvolvido internamente? Categoria 5
• Existem módulo desenvolvidos (exemplo, sistema de pesagem,
cockpits para cadastro de materiais, roteiros de produção) – Categoria
5