Auditoria documental arquitetural e de código
Nesta aula
Comparar a promessa com o sistema existente
Auditoria é uma comparação orientada por critérios e sustentada por evidências. A camada documental registra intenção e instruções; a arquitetura define responsabilidades e relações; o código executa comportamentos. A Oficina Caracol pode ter testes locais aprovados e ainda possuir um README que leva outra pessoa a iniciar a aplicação pelo caminho errado. Essa contradição afeta a operação do projeto e precisa de tratamento rastreável.
O escopo define o que será examinado e o que permanece fora. Uma revisão do catálogo público não autoriza concluir que toda a organização é segura. O auditor registra fontes, versão, ambiente, achado e limite. O objetivo é permitir a outra pessoa repetir o raciocínio e verificar a correção. Revisão humana independente pode ser adequada ao risco, mas sua realização só será declarada quando ocorrer efetivamente.
Montar um pacote de evidência
- Escolha um requisito ou pergunta de auditoria. Para REQ-002, pergunte se registros inativos podem aparecer em qualquer resposta pública do catálogo.
- Identifique as fontes que prometem o comportamento e o caminho real da requisição, da entrada ao resultado. Declare quais arquivos e ambientes foram examinados.
- Compare instruções documentais, fronteiras arquiteturais e implementação. Procure também caminhos alternativos e tratamento de erro.
- Registre achados com localização, reprodução, esperado, observado, impacto e classificação. A severidade deve refletir consequência e alcance, não o incômodo de corrigir.
- Atribua responsável, decisão e prazo. Depois da correção, repita a verificação que revelou o problema e as proteções relacionadas; registre o reteste.
Achados preenchidos em um cenário fornecido
| Identificador | Evidência do cenário | Impacto e classificação | Reparo e reteste |
|---|---|---|---|
| AUD-01 | README orienta node app.js, mas o pacote documentado inicia com npm start | Instrução operacional inválida; prioridade média no exercício | Atualizar a instrução e reproduzir a inicialização a partir do README |
| AUD-02 | Regra isolada omite B inativo, mas uma rota pública alternativa devolve B | Violação de REQ-002; impeditiva no caso | Aplicar a política na fronteira correta e retestar ambas as rotas |
| AUD-03 | Relatório registra teste aprovado sem versão nem ambiente | Evidência não reproduzível; avaliação pendente | Reexecutar ou recuperar evidência suficiente, sem inventar identificação |
Interpretar a contradição arquitetural
AUD-02 demonstra por que auditar somente uma função seria insuficiente. A intenção é ocultar inativos; a regra isolada cumpre essa intenção; outra rota contorna a proteção. A arquitetura precisa tornar explícito onde a política é aplicada e como os consumidores devem acessá-la. O reparo pode centralizar a seleção ou reduzir caminhos de publicação, conforme a implementação existente. A decisão deve ser registrada com sua consequência.
No reteste, o conjunto artificial inclui A ativo e B inativo. A resposta esperada de cada rota pública contém apenas registros permitidos. O auditor também verifica se o estado vazio e os dados inválidos mantêm a resposta prevista, para evitar uma correção que esconda um defeito e crie outro. A tabela contém dados de um cenário para estudo; não afirma que essas rotas alternativas ou defeitos existem no pacote entregue.
Evitar uma auditoria decorativa
| Atalho que enfraquece o trabalho | Reparo |
|---|---|
| Marcar checklist sem guardar evidência | Associar cada conclusão a fonte e resultado identificáveis |
| Tratar todo desvio como crítico | Classificar pelo efeito, alcance e condições de ocorrência explicitadas |
| Corrigir e apagar o achado | Conservar o histórico de decisão e acrescentar a evidência do reteste |
| Auditar detalhes sem relação com o escopo | Reorientar a revisão para os requisitos e riscos declarados |
Condição observável de encerramento
Uma auditoria pode ser encerrada com problemas conhecidos, desde que seu relatório descreva a situação e as decisões sem ambiguidade. Encerrar a auditoria não significa autorizar a entrega. A liberação do produto depende de resultados aceitáveis, ausência de pendências impeditivas e aceitação competente das exceções. Um achado ter responsável e prazo melhora a gestão, mas não converte automaticamente uma falha crítica em risco aceitável.
Exercício e rubrica de correção
Dados: o README afirma que não há verificações manuais pendentes; a matriz de REQ-004 exige teclado e foco; o último relatório só apresenta npm test. Produza um achado de auditoria com critério, evidência, impacto, responsável esperado e reteste.
Ver solução comentada
Solução comentada: o critério é a demonstração manual de REQ-004. A evidência é a contradição entre README, matriz e relatório limitado ao automatizado. O impacto é declarar completude sem a verificação exigida. O responsável pela entrega deve corrigir a declaração e organizar a execução do roteiro por pessoa identificada. O reteste examina a nova documentação e a evidência manual produzida. A rubrica aceita severidades justificadas pelo contexto, mas exige preservar a pendência até obter resultado; imaginar que npm test executou uma avaliação humana não atende ao critério.
Fontes relacionadas
Consulte os limites e as seções de apoio de cada referência.
S01 S03Tente o exercício antes de consultar a solução. Marque a aula para organizar sua leitura.
A conclusão desta leitura não equivale a certificação ou aceite de um projeto real. Teste os exemplos no escopo indicado e registre as limitações.