Capítulo 39 — Avaliação do projeto final
Mapa da aula
Aula 39 publicada. Mapa, exemplo, EX115.
flowchart TD
N0["39.1 Plano"]
N1["39.2 Independência"]
N2["39.3 Efeitos colaterais"]
N3["39.4 Risco residual"]
N4["39.5 Relatório"]
N5["39.6 Recomendação"]
N6["39.7 Declaração de independência"]
N7["39.8 Plano de adoção em homologação"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX115"]
Desenho lógico
flowchart LR
N0["39.1 Plano"]
N1["39.2 Independência"]
N2["39.3 Efeitos colaterais"]
N3["39.4 Risco residual"]
N4["39.5 Relatório"]
N5["39.6 Recomendação"]
N6["39.7 Declaração de independência"]
N7["39.8 Plano de adoção em homologação"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX115"]
[39.1 Plano]
|
v
[39.2 Independência]
|
v
[39.3 Efeitos colaterais]
|
v
[39.4 Risco residual]
|
v
[39.5 Relatório]
|
v
[39.6 Recomendação]
|
v
[39.7 Declaração de independência]
|
v
[39.8 Plano de adoção em homologação]
|
v
[Exemplo resolvido] --> [Exercício EX115]
Objetivos de aprendizagem
Você vai (1) avaliar contra métricas pré-registradas; (2) executar testes independentes; (3) declarar o risco residual.
39.1 Plano
Precision/recall em derivas plantadas; casos de falhar fechado. O plano de avaliação trava precision e recall nas derivas plantadas mais os casos de falhar fechado antes de qualquer execução começar. Sam congela as definições das métricas numa nota curta de pré-registro que o orientador assina. Inclusões, remoções e conflitos de tipo plantados fornecem a verdade de referência que o script consegue pontuar. Casos de falhar fechado são pontuados como passa ou falha, nunca como crédito parcial brando. Planos que inventam métricas depois de ver as pontuações reprovam no padrão do curso. Sam planta vinte derivas no par de inventários (oito inclusões, sete remoções e cinco conflitos de tipo), para que cada classe tenha casos suficientes para um intervalo significar alguma coisa.
39.2 Independência
Outro estudante executa o script de avaliação. Outro estudante executa o script de avaliação enquanto Sam fica longe do teclado. Independência é um protocolo social tanto quanto técnico. O executor assina uma declaração de uma linha de que Sam não editou os logs da execução. As declarações ficam no apêndice ao lado das saídas brutas. Execuções treinadas são tratadas como má conduta acadêmica, e não como colaboração prestativa. O executor recebe apenas o README, o script congelado e o pacote de fixtures; se travar, registra a pergunta por escrito, e a própria pergunta vira dado de avaliação sobre a documentação.
39.3 Efeitos colaterais
Tempo de usabilidade; carga de falsos alarmes. As medidas de efeitos colaterais incluem o tempo de usabilidade e a carga de falsos alarmes para os operadores. Uma ferramenta precisa que inundar os operadores de ruído não será adotada. Sam cronometra a triagem de conflitos na primeira vez num par fixo de inventários. Falsos alarmes são contados e discutidos mesmo quando a precision parece lisonjeira. Os efeitos colaterais pertencem ao relatório ao lado das pontuações de destaque. A primeira medição de Sam mostrou operadores gastando a maior parte do tempo em conflitos de tipo que eram variantes inofensivas de nomenclatura. Ele relatou esse custo com honestidade em vez de ajustá-lo para longe antes de a avaliação fechar, e a constatação entrou na lista da v2.
39.4 Risco residual
As declarações de risco residual dizem com clareza que a ferramenta ajuda a higiene do inventário e não substitui a disciplina das ROE. Sam recusa linguagem de marketing que implica que o teste autorizado pode ser automatizado. Leitores que pulam este parágrafo são os mais propensos a usar mal a ferramenta. A declaração é obrigatória tanto no resumo do relatório quanto no slide final. Auxílios de higiene continuam subordinados aos limites humanos de autorização. Um exemplo concreto ajuda: a ferramenta pode dizer que um host falta no escopo documentado, mas não pode dizer se testar esse host está autorizado. Esse julgamento permanece com o responsável pelas ROE.
39.5 Relatório
O relatório compara os resultados ao pré-registro e proíbe trocas de métrica a posteriori. Análises exploratórias só são permitidas num apêndice claramente rotulado. O modelo de Sam destaca qualquer métrica que não foi pré-registrada. Trocas de volta olímpica são reprovação mesmo que a métrica nova pareça mais gentil. A honestidade sobre falhas faz parte da ciência avaliada. Onde uma classe de deriva plantada pontuou mal, o relatório mostra as falhas pelo nome da fixture, para que os leitores possam inspecioná-las. O resultado mais baixo de Sam, nos conflitos de tipo, aparece no resumo, e não na última página.
39.6 Recomendação
Adotar primeiro em homologação. A recomendação é adoção em homologação primeiro, com responsáveis nomeados e um checklist de trinta dias. Ferramentas sem planos de adoção são hobbies, por mais engenhosas que sejam. Sam escreve como é o sucesso em homologação antes de alguém falar de produção. A promoção para produção espera evidência de execuções solo de operadores. Recomendações que pulam a homologação são rejeitadas pelo orientador. No plano de Sam, sucesso em homologação significa duas execuções solo de operadores sem ajuda do autor, sem regressões de falhar fechado e falsos alarmes abaixo do nível que os operadores disseram tolerar no estudo de tempo. Só então começa uma discussão de produção, com o responsável pelo serviço a presidindo.
39.7 Declaração de independência
Avaliadores independentes assinam uma declaração de uma linha de que Sam não editou os logs da execução. A declaração fica no apêndice. Avaliação confiável é um protocolo social tanto quanto um script. Scripts sozinhos não conseguem provar independência quando os autores ficam por perto. A linha assinada torna a regra social visível para os examinadores. Sam mantém distância durante as execuções mesmo quando a curiosidade coça. Declarações ausentes bloqueiam o encerramento do capítulo de avaliação. Ciência confiável é, em parte, papelada feita sem ressentimento. A redação é fixa, para que os executores não possam amaciá-la para "quase sem edição".
39.8 Plano de adoção em homologação
Os relatórios de avaliação incluem um plano de homologação de trinta dias com responsáveis. Ferramentas sem planos de adoção são hobbies. O plano de trinta dias nomeia datas, responsáveis e a evidência esperada em cada portão. Sam rejeita planos que só dizem monitorar em homologação. Checklists viram tickets, para que o trabalho não se esconda em marcadores de e-mail. Energia de hobby é bem-vinda nos laboratórios e indesejada nas alegações de adoção. Planos com equipe são como as ferramentas saem da tese e entram nas operações. O plano de Sam tem três portões: uma primeira execução solo até o dia dez, uma segunda até o dia vinte e uma revisão dos relatórios de quebra e das contagens de falsos alarmes no dia trinta. Cada portão nomeia o arquivo de evidência que prova que ele passou.
39.9 Responsáveis pela adoção
A adoção em homologação nomeia um responsável pelo serviço e um pela plataforma. Um nome só é insuficiente. Responsáveis pelo serviço sentem a dor operacional; responsáveis pela plataforma sentem a dor da ferramenta. Um nome só costuma significar que o estudante ainda é dono de tudo oficiosamente. Sam exige os dois papéis antes de o plano de homologação poder ser aprovado. A propriedade dividida evita o abandono silencioso quando o período termina. Nomenclatura insuficiente é tratada como uma recomendação incompleta. Na prática, o responsável pelo serviço decide se uma lista de conflitos é boa o bastante para agir, enquanto o da plataforma corrige problemas de parser e de empacotamento. Quando esses dois trabalhos compartilham um nome, reclamações operacionais tendem a ficar sem resposta porque a mesma pessoa também está ocupada corrigindo código.
39.10 Mira e Sam na adoção
O plano de adoção nomeia Mira para a propriedade do serviço e Sam para o suporte da plataforma. O checklist de trinta dias inclui duas execuções solo de operadores. Sem o nome de Mira, o plano seria ficção. O nome de Mira torna o plano real porque ela pode recusar trabalho que não está pronto. Duas execuções solo pegam lacunas de documentação que os testes unitários perdem. O papel de plataforma de Sam permanece de apoio, e não possessivo. Planos de ficção só com nomes de estudantes são um modo de falha conhecido. A cena é usada no treinamento de orientadores como um exemplo positivo.
39.11 Execução solo encontra lacuna de DNS
A segunda execução solo falhou porque o DNS diferia no perfil do operador. O README ganhou um preâmbulo de DNS. Execuções solo encontram bugs de documentação que as ferramentas perdem. Diferenças de perfil são entediantes até quebrarem um operador cuidadoso. Sam agradeceu a falha na retrospectiva em vez de culpar o operador. O texto do preâmbulo de DNS agora faz parte dos exemplos dourados do README. Execuções solo são testes de documentação vestidos de roupa operacional. Ferramentas podem passar nos testes unitários e ainda assim falhar com humanos no primeiro dia. O resolvedor do operador devolvia nomes curtos onde a fixture esperava nomes totalmente qualificados.
39.12 Itens do checklist como tickets
Os itens do checklist de trinta dias são tickets, não marcadores num e-mail. Tickets carregam responsáveis, datas de vencimento e anexos de evidência. Marcadores de e-mail evaporam quando as caixas de entrada rotacionam. O modelo de adoção de Sam abre tickets automaticamente a partir do checklist. Tickets encerrados sem evidência são reabertos por política. Tickets são como trinta dias se tornam responsabilizáveis em vez de aspiracionais. O checklist de Sam produz seis tickets: duas execuções solo, a revisão de falsos alarmes, uma revisão das mensagens de negação, a atualização do README e a retrospectiva do dia trinta. Cada um tem um responsável do plano de adoção e uma data de vencimento dentro dos trinta dias, para que o atraso fique visível no quadro antes de a janela fechar.
39.13 Evidência para autoencerramento
Tickets dos itens do checklist só se autoencerram quando a evidência da execução solo está anexada. Autoencerrar sem evidência recria o teatro de conclusão no papel. Sam configura a regra para que a conveniência não apague a exigência de prova. Os operadores aprendem a anexar as saídas enquanto a execução está fresca. Anexos ausentes mantêm o ticket barulhento de propósito. Encerramento com portão de evidência é higiene de adoção. A evidência aceitável é específica: o arquivo de saída de conflitos, a linha de comando do operador e o hash da versão da ferramenta. Uma captura de tela sozinha não conta, porque não consegue mostrar qual build rodou. Quando a evidência falta, o ticket continua aberto e avisa o responsável todas as manhãs.
39.14 Reescrever partes ignoradas do README
As retrospectivas de adoção no dia 30 perguntam aos operadores o que ignoraram no README. Seções ignoradas são apagadas ou reescritas, não defendidas. Defender parágrafos não lidos desperdiça a única atenção que os operadores ofereceram. Sam prefere encolher a documentação a dar palestra por quem passa os olhos. Ignorado significa que a escrita falhou no ambiente em que entrou. Retrospectivas que reescrevem são mais gentis do que retrospectivas que culpam. Atenção é o recurso escasso que a adoção precisa orçar. Na primeira retrospectiva, os operadores admitiram pular por completo a longa visão geral de arquitetura. Sam a cortou para três frases e moveu o exemplo do caminho de negação para o topo, já que era a parte de que as pessoas realmente precisavam na primeira execução.
39.15 Relatórios intencionais de quebra
A verificação de adoção do dia dez pede aos operadores que quebrem a ferramenta de propósito e registrem a quebra. Sam prefere ouvir a dor cedo a um silêncio educado. Dois relatórios intencionais de quebra na primeira turma melhoraram as mensagens de negação mais do que um mês de polimento especulativo teria. O silêncio educado é um antipadrão de adoção. Convidar quebras legitima más notícias cedo. Melhorias nas mensagens de negação a partir de confusão real vencem o polimento imaginado de UX. Sam trata os relatórios de quebra como entrada valorizada, e não como reclamações. Dor cedo é mais barata do que abandono quieto.
39.16 Tipo de ticket BREAK-ADOPT
Os relatórios intencionais de quebra têm o próprio tipo de ticket: BREAK-ADOPT. Um tipo distinto mantém a dor da adoção pesquisável depois. Sam revisa os tickets BREAK-ADOPT semanalmente durante a janela de homologação. Misturar quebras com bugs comuns as esconde sob o ruído do backlog. Tipagem torna o convito para quebrar operacionalmente real. Dor pesquisável vira melhoria; dor misturada vira lenda. Cada relatório registra o que o operador tentou, o que a ferramenta fez e o que ele esperava; a primeira turma achou mensagem vaga em inventário vazio, o que virou um conserto específico.
Exemplo resolvido (TRB sintético)
A avaliação independente mostra precision e recall nas derivas plantadas; Sam recomenda adoção primeiro em homologação, com Mira como responsável pelo serviço.
Caso sintético — Riverstone Transit Bank (TRB). O banco, Sam Ito, TrackScope/FindingsDesk/PulseMap e todos os números são inventados para fins didáticos.
Erros e limites
Este livro não concede nenhuma autoridade para testar bancos ou sistemas de pagamento reais. Os laboratórios usam apenas endereços de faixas de documentação e dados sintéticos; código de exploit nunca é fornecido.
Exercícios
- EX115 — Independência. Quem executa o script de avaliação? Rubrica: 3 = outro estudante ou testador independente; 2 = parcial; 1 = só Sam; 0 = nada.
- EX116 — Risco residual. O que a ferramenta não substitui? Rubrica: 3 = a disciplina das ROE ou as verificações de autorização; 2 = parcial; 1 = tudo; 0 = nada.
- EX117 — Pré-registro. As métricas podem mudar depois das pontuações? Rubrica: 3 = não; as métricas ficam como pré-registradas; 2 = não, sem justificativa; 1 = sim; 0 = nada.
Síntese
A avaliação trava métricas, exige independência e declara o risco residual sem substituir a disciplina das ROE.
Continue estudando — capítulo 39 de 40
← Capítulo 38 (rascunho) · Índice de capítulos do curso · Capítulo 40 (rascunho) →