Capítulo 38 — Infraestrutura crítica e segurança setorial: validação
Mapa da aula
Aula 38 publicada. Mapa, exemplo, EX075.
flowchart TD
N0["38.1 Verificação não é validação"]
N1["38.2 A rastreabilidade como mapa de evidências"]
N2["38.3 Validação com as partes interessadas"]
N3["38.4 Relatar resultados parciais"]
N4["38.6 Atividade prática: Laboratório 14"]
N5["Síntese do capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX075"]
Desenho lógico
flowchart LR
N0["38.1 Verificação não é validação"]
N1["38.2 A rastreabilidade como mapa de evidências"]
N2["38.3 Validação com as partes interessadas"]
N3["38.4 Relatar resultados parciais"]
N4["38.6 Atividade prática: Laboratório 14"]
N5["Síntese do capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX075"]
[38.1 Verificação não é validação]
|
v
[38.2 A rastreabilidade como mapa de evidências]
|
v
[38.3 Validação com as partes interessadas]
|
v
[38.4 Relatar resultados parciais]
|
v
[38.6 Atividade prática: Laboratório 14]
|
v
[Síntese do capítulo]
|
v
[Exemplo resolvido] --> [Exercício EX075]
Objetivos de aprendizagem e conexão
Ao fim deste capítulo você será capaz de (1) distinguir a validação (o sistema certo para a necessidade) da verificação (o sistema construído segundo sua especificação); (2) validar com as partes interessadas por meio de demonstrações, ensaios operacionais e exercícios; (3) usar a rastreabilidade para mostrar quais necessidades estão apoiadas em evidências e quais não estão; e (4) relatar os resultados da validação com honestidade, incluindo os resultados parciais. Ele se apoia nos capítulos 16, 24 e 30 e prepara os capítulos 40 e 48.
38.1 Verificação não é validação
Um sistema pode passar em todos os testes contra sua especificação e ainda assim falhar com seus usuários, se a especificação estava errada ou incompleta. A validação pergunta se o sistema atende às necessidades das partes interessadas no ambiente pretendido: os operadores conseguem de fato operar o modo manual local à noite? O hospital de fato recebe água dentro de sua reserva quando a PS4 é perdida? As evidências de validação vêm do uso realista: ensaios operacionais, demonstrações com as partes interessadas, exercícios e os primeiros dados de operação. Para o TMRP, o exercício noturno do modo manual local é a atividade de validação que responde à primeira pergunta.
38.2 A rastreabilidade como mapa de evidências
Rastreie as necessidades até os requisitos, os testes e os resultados. Depois faça três perguntas: quais requisitos não têm teste (alegações não testadas)? Quais testes falharam ou não foram executados (alegações sem apoio)? Quais necessidades dependem apenas de requisitos ainda não verificados (necessidades não validadas)? O Laboratório 14 calcula isso para o dossiê do TMRP. Para o TMRP, as perguntas são concretas. R4 não tem teste porque sua demonstração nunca foi agendada. R9, o alarme de dosagem independente, não tem teste algum: a tabela de requisitos indica um teste como seu método de verificação, mas nenhum teste jamais foi escrito para ele. O único teste registrado de R3 é o reprovado na v1, e o teste de R8 não foi executado. N1 depende de R4, então não pode ser alegada como validada até que o exercício noturno aconteça. O Laboratório 14 imprime essas lacunas diretamente.
38.3 Validação com as partes interessadas
Envolva as pessoas a quem o sistema serve. Os operadores validam os procedimentos e as telas; a equipe de manutenção valida a reparabilidade e as peças de reposição; o hospital valida que os arranjos de abastecimento atendem às suas necessidades; os reguladores validam o raciocínio de conformidade. Registre as constatações deles como registraria as constatações de uma revisão, com respostas. Para o TMRP, os operadores validam o procedimento manual local e os novos alarmes de segurança, a equipe de manutenção confere que os gateways podem ser substituídos a partir das reservas, e o hospital confirma que os arranjos de abastecimento e sua reserva de quatro horas atendem às suas necessidades. As constatações deles vão para o mesmo registro de respostas das constatações da revisão de projeto.
38.4 Relatar resultados parciais
Relate a situação da validação por necessidade: validada, parcialmente validada (com o que falta), não validada. Não arredonde para cima. "N1 parcialmente validada: o ensaio de perda da PS4 atendeu à reserva de 4 h; a perda combinada da PS4 e do alimentador F1 da rede elétrica ainda não foi ensaiada." O mapa de evidências do TMRP torna isso concreto: N1 depende de R4, que ainda não foi demonstrado, então N1 é relatada como não validada até que o exercício noturno aconteça, mesmo que a maioria de seus outros requisitos tenha passado nos testes. A situação é atualizada depois do exercício.
38.5 Exemplo resolvido: mapa de evidências do TMRP (sintético)
O Laboratório 14 mostra: R4 (operação manual local) não tem teste — foi planejado como demonstração e nunca agendado; R3 tem um teste reprovado (na v1; o novo teste na v2 ainda não foi lançado na matriz); o teste T6 de R8 não foi executado. R9 (alarme de dosagem independente) também não tem teste: seu método de verificação é "Teste", mas nenhum identificador de teste foi jamais atribuído, então a evidência para ele é uma intenção de projeto, e não um resultado. Verificados: 5 de 9 requisitos (55,6%). Consequência para a validação: N1 (abastecimento do hospital) depende de R4, então N1 não pode ser alegada como validada; o exercício noturno do manual local é agendado como a atividade de validação. A matriz também expõe uma lacuna administrativa — o novo teste do T3 na v2 precisa ser registrado —, exatamente o tipo de inconsistência que examinadores e auditores encontram.
38.6 Atividade prática: Laboratório 14
# Lab 14 - requirements traceability: what is claimed but not shown? (synthetic TMRP dossier, offline)
REQS = ["R1 auth telemetry", "R2 replay reject", "R3 setpoint bounds", "R4 local manual", "R5 24h hold-up",
"R6 restore 8h", "R7 alarm 60s", "R8 log integrity", "R9 dosing alarm"]
TESTS = {"T1": ["R1"], "T2": ["R1", "R2"], "T3": ["R3"], "T4": ["R5"], "T5": ["R7"], "T6": ["R8"], "T7": ["R6"]}
RESULT = {"T1": "pass", "T2": "pass", "T3": "fail", "T4": "pass", "T5": "pass", "T6": "not run", "T7": "pass"}
ids = [r.split()[0] for r in REQS]
cov = {r: [t for t, rs in TESTS.items() if r in rs] for r in ids}
verified = [r for r in ids if cov[r] and all(RESULT[t] == "pass" for t in cov[r])]
print("untested:", [r for r in ids if not cov[r]])
print("tested but not passing:", [r for r in ids if cov[r] and r not in verified])
print(f"verified {len(verified)}/{len(ids)} = {100*len(verified)/len(ids):.1f}%")
Saída esperada:
untested: ['R4', 'R9']
tested but not passing: ['R3', 'R8']
verified 5/9 = 55.6%
A saída mostra que R4 e R9 não têm teste, que R3 e R8 estão testados mas não aprovados, e que cinco de nove requisitos estão verificados. A situação de R3 está desatualizada, e não realmente reprovada: o novo teste na v2 foi aprovado, mas ninguém o lançou na matriz, exatamente a lacuna administrativa de que o exemplo resolvido adverte. O EX075 atualiza o mapa. R9 é a lição mais difícil: o alarme de dosagem aparece no conjunto de requisitos, na tabela de riscos e nos controles de dosagem, então parece coberto, mas nenhum teste jamais lhe foi atribuído. Uma versão anterior desta matriz deixava R9 inteiramente fora da lista, o que elevava a fração verificada de cinco de nove para cinco de oito sem nenhuma evidência nova. Uma matriz precisa listar todo requisito definido, porque um requisito que ela omite não pode ser relatado como não testado.
38.7 Erros comuns e limites
- Chamar de "validação" um conjunto de testes aprovado.
- Partes interessadas consultadas apenas no início.
- Arredondar a validação parcial para "validada".
- Mapas de evidências não atualizados depois de novos testes.
O próprio mapa do TMRP mostra o último erro: o novo teste do T3 na v2 foi aprovado, mas a matriz nunca foi atualizada. Partes interessadas como os operadores e o hospital são envolvidas o tempo todo, e não apenas quando os requisitos foram escritos, e o mapa de evidências é atualizado toda vez que um novo teste ou uma demonstração produz um resultado, de modo que a situação de validação relatada nunca se adianta às evidências.
Exercícios — capítulo 38
EX075 — Atualize o mapa. Objetivo: manter a rastreabilidade. Entradas: Laboratório 14. Passos: (1) acrescente o T3b (novo teste na v2) cobrindo R3 com resultado "pass" e remova a ligação do T3 com R3 como superada; (2) acrescente a demonstração T8 cobrindo R4 com resultado "pass"; (3) execute o T6 com resultado "pass"; recalcule. Evidência esperada: código e saída. Rubrica: 3 = oito de nove verificados (88,9%), R9 ainda listado como não testado porque não existe teste do alarme de dosagem, com uma nota de que verificação ≠ validação; 2 = uma mudança não feita; 1 = não executado; 0 = nada.
EX076 — Plano de validação para N1. Objetivo: planejar a validação com as partes interessadas. Entradas: N1 "o hospital não pode ficar sem água por > 4 h". Passos: proponha duas atividades de validação com as partes interessadas, condições realistas, observações e critérios de sucesso. Evidência esperada: plano. Rubrica: 3 = atividades realistas (exercício noturno do manual local com o efetivo real; isolamento planejado da PS4 com monitoramento pelo hospital), critérios ligados à reserva de 4 h, partes interessadas nomeadas pelo papel; 2 = critérios vagos; 1 = testes rebatizados de validação; 0 = nada.
Síntese do capítulo
A verificação pergunta se o sistema foi construído direito; a validação pergunta se ele é o sistema certo. Use a rastreabilidade como mapa de evidências para encontrar alegações não testadas, sem apoio e não validadas, valide com as pessoas a quem o sistema serve em condições realistas e relate os resultados parciais como parciais.
Continue estudando — capítulo 38 de 50
← Capítulo 37 · Índice de capítulos do curso · Capítulo 39 →
Siga para a próxima lição escrita.