Capítulo 46 — Projeto final de engenharia II
Mapa da aula
Aula 46 publicada. Mapa, exemplo, EX136.
flowchart TD
N0["46.1 Construindo segundo a linha de base"]
N1["46.2 Implementando os controles"]
N2["46.3 Estrutura de avaliação"]
N3["46.4 Defeitos e mudanças"]
N4["46.4b Demonstrações e evidências"]
N5["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX136"]
Desenho lógico
flowchart LR
N0["46.1 Construindo segundo a linha de base"]
N1["46.2 Implementando os controles"]
N2["46.3 Estrutura de avaliação"]
N3["46.4 Defeitos e mudanças"]
N4["46.4b Demonstrações e evidências"]
N5["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX136"]
[46.1 Construindo segundo a linha de base]
|
v
[46.2 Implementando os controles]
|
v
[46.3 Estrutura de avaliação]
|
v
[46.4 Defeitos e mudanças]
|
v
[46.4b Demonstrações e evidências]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX136]
Objetivos de aprendizagem
Você vai (1) construir e integrar o sistema do projeto final segundo a linha de base aprovada; (2) implementar controles de segurança e estruturas de avaliação; (3) gerenciar mudanças e defeitos; e (4) preparar-se para a verificação e para o ensaio de recuperação.
46.1 Construindo segundo a linha de base
Implemente em incrementos, cada um terminando com testes e uma demonstração curta. Mantenha a rastreabilidade dos requisitos em dia: cada requisito aponta para código, configuração e testes. Use o portão de segurança de CI do Capítulo 14 desde o primeiro incremento. Os incrementos mantêm pequena a distância entre o projeto e o código, de modo que os problemas aparecem enquanto ainda são baratos de corrigir. Uma demonstração no fim de cada incremento mostra ao cliente um progresso real e convida a um feedback precoce. Rodar o portão de segurança desde o início significa que a primeira versão já tem uma linha de base para comparação, em vez de se descobrirem muitas falhas de uma vez no fim.
46.2 Implementando os controles
Implemente o ponto de aplicação, o tratamento da proveniência, a validação das saídas, o monitoramento e as verificações da cadeia de suprimentos como módulos separados e testáveis. Evite desvios "temporários"; se um for necessário para o desenvolvimento, coloque-o atrás de uma configuração que não possa ser habilitada no build de liberação. Módulos separados permitem que cada controle seja testado e revisado por si só, e substituído sem perturbar os outros. Desvios temporários são uma fonte clássica de incidentes: uma flag que desativa o ponto de aplicação para testes locais é inofensiva até chegar à produção. Tornar o build de liberação incapaz de habilitá-la transforma uma promessa em uma verificação que o pipeline aplica.
46.3 Estrutura de avaliação
Construa a estrutura que executa os conjuntos reservados benignos e adversariais, calcula as métricas com intervalos e guarda as saídas brutas. Inclua o conjunto independente de ataques adaptativos fornecido por outra equipe. Execute-a todas as noites e a cada candidata a versão. O conjunto adaptativo da outra equipe é a parte mais valiosa, porque seus autores não sabiam quais ataques o projeto previa. As execuções noturnas pegam regressões até um dia depois da mudança que as causou. As saídas brutas guardadas permitem que a equipe investigue uma falha sem executar o modelo de novo e dão suporte a perguntas posteriores da banca.
46.4 Defeitos e mudanças
Acompanhe os defeitos com gravidade; defeitos de segurança bloqueiam a liberação até serem corrigidos ou formalmente aceitos com um responsável pelo risco. Mudanças de escopo ou de requisitos passam pelo controle de mudanças combinado no projeto final I. Um defeito de segurança formalmente aceito nomeia quem o aceitou, por que e até quando, para que não se torne permanente por omissão. Bloquear a liberação por defeitos de segurança não corrigidos pode parecer lento, mas impede o padrão comum de fraquezas conhecidas serem liberadas porque um prazo chegou. As mudanças de escopo durante a construção usam o mesmo processo de antes, mantendo a linha de base significativa.
46.4b Demonstrações e evidências
Termine cada incremento com uma demonstração curta ao cliente que inclua pelo menos um caso adversarial, e não apenas o caminho feliz. Guarde o roteiro, as entradas e as saídas da demonstração como evidência; eles passam a fazer parte do dossiê no Capítulo 48. Demonstrar uma falha com honestidade, com a correção planejada, gera mais confiança do que uma demonstração polida que a esconde. A demonstração do Bulletin Gate após a mudança de esquema incluiu um dos boletins adaptativos da outra equipe: uma instrução escondida em uma nota de manutenção, agora mapeada para uma categoria enumerada, sem texto livre na saída. Mostrar a queda de acurácia para 95,3% na mesma demonstração fez parte da honestidade que a banca procurava.
46.5 Exemplo resolvido (caso sintético da NRS)
Durante a construção, o modelo em quarentena do Bulletin Gate às vezes copiava frases com cara de instrução para um campo de texto livre "notes" de seu esquema de saída. O esquema foi apertado: o campo de notas virou uma enumeração de categorias de manutenção predefinidas mais campos numéricos. O conjunto adaptativo da outra equipe produziu então zero strings de instrução nas saídas em 300 casos (limite superior de 95% ≈ 1%), enquanto a acurácia de extração caiu de 96,4% para 95,3% — ainda atendendo ao requisito. A correção foi estrutural, e não um filtro melhor: remover o texto livre eliminou o lugar onde as instruções podiam se esconder.
46.6 Erros e limites
Três erros são comuns: campos de texto livre que reabrem caminhos de injeção; desvios de desenvolvimento liberados para produção; e estruturas de avaliação executadas apenas no fim. Um campo de texto livre em uma saída supostamente estruturada dá às instruções injetadas um caminho através da quarentena, como mostrou o campo de notas. Desvios de desenvolvimento que chegam à produção transformam uma conveniência em uma porta aberta. Uma estrutura de avaliação executada só no fim encontra todos os problemas de uma vez, tarde demais para corrigi-los bem. A equipe de Sam manteve a estrutura de avaliação, a verificação do build de liberação e a revisão do esquema na definição de pronto de cada incremento.
Exercícios
- EX136 — Rastreabilidade. Mostre como um requisito é rastreado até código, configuração e testes. Rubrica: 3 = ID do requisito com ligações concretas aos três; 2 = dois; 1 = vago; 0 = nenhum.
- EX137 — Texto livre. Por que o campo de notas importou, e que regra geral decorre disso? Rubrica: 3 = texto livre carrega instruções injetadas; restringir as saídas a enumerações/estruturas; 2 = parcial; 1 = vago; 0 = errado.
- EX138 — Limite. Com 0 falhas em 300 casos, qual é o limite superior aproximado de 95%? Rubrica: 3 = ≈ 3/300 = 1%; 2 = só o método; 1 = errado, mas fundamentado; 0 = nenhum.
Síntese
O projeto final II constrói o sistema como foi projetado: de forma incremental, rastreável, com portões de avaliação e com os defeitos de segurança tratados como bloqueadores de liberação.
Continue estudando — capítulo 46 de 50
← Capítulo 45 (rascunho) · Índice de capítulos do curso · Capítulo 47 (rascunho) →