Capítulo 46 — Projeto final de engenharia II
Mapa da aula
Aula 46 publicada. Mapa, exemplo, EX136.
flowchart TD
N0["46.1 Congelamento"]
N1["46.2 Verificar"]
N2["46.3 Documentação"]
N3["Nota prática"]
N4["46.1b Roteiro da demonstração e passagem"]
N5["Nota de campo — travamento na execução silenciosa"]
N6["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX136"]
Desenho lógico
flowchart LR
N0["46.1 Congelamento"]
N1["46.2 Verificar"]
N2["46.3 Documentação"]
N3["Nota prática"]
N4["46.1b Roteiro da demonstração e passagem"]
N5["Nota de campo — travamento na execução silenciosa"]
N6["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX136"]
[46.1 Congelamento]
|
v
[46.2 Verificar]
|
v
[46.3 Documentação]
|
v
[Nota prática]
|
v
[46.1b Roteiro da demonstração e passagem]
|
v
[Nota de campo — travamento na execução silenciosa]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX136]
Objetivos de aprendizagem
Você vai (1) terminar a implementação conforme a proposta congelada; (2) executar o Laboratório de Verificação II; (3) entregar a documentação de operação e a titularidade operacional.
46.1 Congelamento
A data de congelamento de funcionalidades é real: depois dela, apenas correções de segurança física. Ideias novas vão para uma proposta de continuação.
O projeto final de Lena congelou na v1.0 do seu compilador. Depois do congelamento, ela corrigiu apenas o travamento silencioso no carregador de vetores, porque ele podia esconder uma falha, e registrou toda ideia nova, como o suporte a uma segunda planta, numa proposta de continuação. A data de congelamento foi acordada com o orientador na fase da proposta, então ninguém podia tratá-la como uma meta flexível quando as últimas semanas ficaram corridas.
46.2 Verificar
O projeto final só conta como verificado depois de passar no Laboratório II (Capítulo 40) sobre dados de teste sintéticos da planta.
Lena rodou de novo o Laboratório II para o compilador numa máquina limpa construída a partir da tag v1.0, usando apenas dados de teste sintéticos. A máquina limpa não tinha artefatos de build em cache, então todo resultado veio do código-fonte marcado. O checklist foi assinado por Lena e pelo seu revisor, e o relatório listou todo teste pulado, com o motivo. Lena guardou o log de build da máquina limpa ao lado da tag v1.0, e ele registra a execução travada do carregador de vetores além da aprovada.
46.3 Documentação
Seção do runbook, ADR, tutorial do operador com capturas de tela da interface sintética — nenhum dado da planta. A assinatura da operação é exigida antes da tag.
"""Lab: alarm load per operator hour before and after rationalisation (synthetic counts)."""
before = {"T-1 high": 140, "T-2 high": 95, "R-101 temp": 30, "pump trip": 6, "comm loss PLC-A": 210, "door open": 75}
remove = {"comm loss PLC-A": 200, "door open": 70, "T-1 high": 110} # chattering/duplicate alarms removed
hours = 24 * 7
tb = sum(before.values()); ta = tb - sum(remove.values())
print(f"week alarms before={tb} after={ta}")
print(f"per operator-hour before={tb/hours:.2f} after={ta/hours:.2f}")
top = max(before, key=before.get)
print(f"worst source before: {top} ({before[top]/tb:.0%} of load)")
Saída esperada:
week alarms before=556 after=176
per operator-hour before=3.31 after=1.05
worst source before: comm loss PLC-A (38% of load)
Caso sintético — Ashford Batch Plant. Uma equipe do Projeto Final II na turma de Lena entregou a distribuição de listas de permissões assinadas; Laboratório II verde; runbook atualizado no mesmo dia.
O projeto dessa equipe era separado do projeto final de Lena, o compilador. A documentação do compilador foi assinada pela operação antes da tag, e o seu tutorial do operador usa capturas de tela apenas do modelo sintético de nove condutos. Um engenheiro de operação seguiu o tutorial uma vez na cópia de bancada do modelo de nove condutos antes de assinar.
46.4 Erros e limites
Uma demonstração num laptop que apenas descreve a falha fechada, sem remover a política na bancada, não passa.
Na revisão do projeto final de Lena, a demonstração de um colega mostrou uma ferramenta de políticas funcionando num laptop, mas não conseguiu mostrar o que acontecia quando o arquivo de política estava ausente. Os examinadores marcaram o requisito de falha fechada como não atendido. A demonstração de Lena apagou a política na bancada e mostrou a negação com o seu código de motivo, depois a restaurou, porque as alegações sobre falha segura precisam ser mostradas sob falha, e não descritas enquanto tudo funciona.
Nota prática
Teste silencioso do runbook: um segundo engenheiro segue o runbook a frio, sobre dados sintéticos, enquanto o autor fica em silêncio. Os pontos em que ele empaca viram correções da documentação.
46.1b Roteiro da demonstração e passagem
A demonstração do Projeto Final II segue um roteiro sobre dados sintéticos: mostrar a falha fechada, mostrar o denominador da cobertura, mostrar a alcançabilidade do SIS. A demonstração termina restaurando a política e mostrando o tráfego permitido de novo. Ponha o hash da gravação da execução silenciosa no relatório do Laboratório II, para a auditoria do orientador.
A revisão do orientador assiste à gravação da execução silenciosa e registra problemas de documentação antes da aprovação. Um código de projeto final sem um dono operacional no merge está inacabado. Os problemas de documentação vindos da gravação trazem o timestamp em que o engenheiro empacou.
A demonstração de Lena seguiu exatamente esse roteiro. O seu dono operacional assinou no merge.
Nota de campo — travamento na execução silenciosa
A execução silenciosa do colega empacou na falta de documentação da chave da política de teste. A correção da documentação foi publicada no mesmo dia. O Projeto Final II não está concluído até que alguém que não escreveu o código consiga operar o caminho de parada apenas com o runbook.
A passagem para a operação nomeia a equipe dona no README e no CODEOWNERS antes da aprovação do Laboratório II.
Uma demonstração que se desvia do seu roteiro é refeita desde o início.
46.5 Exemplo resolvido — congelar e verificar (ABP sintética)
No congelamento do Projeto Final II, Lena marca o compilador com a tag v1.0 e roda de novo toda a verificação numa máquina limpa a partir da tag: 214 testes de unidade, 18 conjuntos de vetores de conformidade, a verificação de equivalência de alcançabilidade e a reprodução no firewall de bancada. Uma execução travou em silêncio porque a API do firewall de bancada limitou a taxa do carregador de vetores; a correção é um timeout com uma mensagem de falha explícita, em vez de um laço de novas tentativas. A documentação inclui o roteiro da demonstração, a lista de não objetivos e uma nota de passagem nomeando quais testes exigem hardware de bancada, para que um sucessor não confunda testes pulados com aprovações.
Exercícios
- EX136 — Congelamento. O que é permitido depois do congelamento de funcionalidades? Rubrica: 3 = só correções de segurança física; 2 = defeitos; 1 = funcionalidades; 0 = nada.
- EX137 — Artefatos. Cinco artefatos de entrega. Rubrica: 3 = cinco; 2 = três; 1 = só código; 0 = nada.
- EX138 — Operação. Por que a assinatura da operação é exigida ao lado do Laboratório II? Rubrica: 3 = titularidade/prontidão do runbook; 2 = vago; 1 = burocracia; 0 = nada.
Síntese
Congele, verifique, documente, nomeie a operação — e então opere.
Continue estudando — capítulo 46 de 50
← Capítulo 45 · Índice de capítulos do curso · Capítulo 47 →
Siga para a próxima lição escrita.