Capítulo 44 — Projeto final de engenharia I
Mapa da aula
Aula 44 publicada. Mapa, exemplo, EX130.
flowchart TD
N0["44.1 Proposta"]
N1["44.3 Marco 1"]
N2["44.2b Registro de riscos do projeto final"]
N3["44.3b Pontos de controle com o orientador"]
N4["44.1b Métricas de sucesso do projeto final"]
N5["Nota de prática"]
N6["44.4b Delimitar o projeto final com honestidade"]
N7["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX130"]
Desenho lógico
flowchart LR
N0["44.1 Proposta"]
N1["44.3 Marco 1"]
N2["44.2b Registro de riscos do projeto final"]
N3["44.3b Pontos de controle com o orientador"]
N4["44.1b Métricas de sucesso do projeto final"]
N5["Nota de prática"]
N6["44.4b Delimitar o projeto final com honestidade"]
N7["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX130"]
[44.1 Proposta]
|
v
[44.3 Marco 1]
|
v
[44.2b Registro de riscos do projeto final]
|
v
[44.3b Pontos de controle com o orientador]
|
v
[44.1b Métricas de sucesso do projeto final]
|
v
[Nota de prática]
|
v
[44.4b Delimitar o projeto final com honestidade]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX130]
Objetivos de aprendizagem
Você vai (1) propor um projeto final que entregue uma melhoria mensurável na plataforma; (2) definir escopo e não objetivos; (3) estabelecer um plano de verificação.
44.1 Proposta
Problema, usuários, requisitos (segurança primeiro), esboço de arquitetura, marcos, plano do laboratório de verificação, parágrafo de ética. Projetos finais que precisam de trabalho de exploit são rejeitados. Requisitos de segurança em primeiro lugar e um parágrafo de ética são portões, não enfeites. Propostas centradas em exploits voltam sem leitura. O modelo de Sam abre com os usuários e os requisitos de falha fechada antes de qualquer esboço de arquitetura, e é por isso que rascunhos de "auto-pwn" nunca passaram do primeiro ponto de controle. Os requisitos de segurança são numerados e rastreados até linhas do Laboratório II no mesmo documento. Propostas que falham nessa verificação voltam com a seção ausente indicada.
44.2 Não objetivos
Liste explicitamente o que você não vai construir (módulos de exploit, varredura de clientes ao vivo, oráculos de risco por ML). Escrever os não objetivos cedo é o que torna o congelamento possível depois. Módulos de exploit, varredura de clientes ao vivo e oráculos de risco por ML são nomeados para que uma demo de meio de período não possa contrabandeá-los. A proposta de Sam listou esses três explicitamente, e os orientadores avaliaram o escopo contra essa lista. As demos de meio de período são avaliadas contra essa lista antes que alguém assista ao vídeo. Acrescentar um não objetivo no meio do período exige aprovação do orientador registrada no registro de riscos.
44.3 Marco 1
Algo demonstrável com dados sintéticos na semana 3: p. ex., kill switch respeitado em ≤30 s, com um teste. "Spikes de pesquisa" vagos não são. O vídeo do marco 1 de Sam mostra o controle de parada, o tempo de parada medido e a cláusula das ROE que ele satisfaz, que é o padrão que avançou enquanto o "auto-pwn" era devolvido. Vídeos sem um tempo de parada medido reprovam no ponto de controle, mesmo que a interface pareça polida.
Caso sintético — Riverstone Transit. Propostas do Projeto Final I que mencionavam "auto-pwn" foram devolvidas; "distribuição de política assinada com falha fechada" avançou.
44.4 Erros e limites
O aumento de escopo é o principal assassino de projetos finais — congele os não objetivos. O aumento de escopo mata mais projetos finais do que bugs difíceis. Congelar os não objetivos e estacionar ideias de continuação é o controle. A revisão de meio de período de Sam rejeitou uma integração com sistema de tickets que não estava na proposta, mesmo que um mentor tenha gostado da demo. Ideias de continuação ganham um documento de estacionamento de uma página, datado no dia do congelamento. O dia do congelamento está no calendário compartilhado com a mesma seriedade de uma janela de engajamento. Os convites de calendário do congelamento incluem o orientador e o responsável de operações.
44.2b Registro de riscos do projeto final
Liste os riscos do projeto: aumento de escopo, atraso de dependências, indisponibilidade de revisores, confusão sobre a fronteira ética. Cada risco tem um alerta antecipado e uma mitigação. Revise o registro toda semana no ateliê. Alertas antecipados valem mais que heroísmo na semana onze. O registro de Sam sinalizou uma viagem do orientador na semana seis e antecipou o ponto de controle; a mitigação foi uma demo gravada, não um atraso silencioso. Riscos sem alertas antecipados são reescritos antes do fim da reunião. Cada mitigação nomeia quem age e até qual semana. Riscos encerrados ficam no registro com a data de encerramento, para que o relatório final mostre quais alertas dispararam e o que foi feito.
44.3b Pontos de controle com o orientador
O Projeto Final I tem pontos de controle obrigatórios: proposta aceita, demo do marco 1, verificação ética intermediária. Perder um ponto de controle congela a codificação até a recuperação — a deriva silenciosa produz pilhas impossíveis de revisar. A verificação ética no meio do projeto final de Sam pegou um plano de usar hostnames anonimizados, mas ainda internos do anfitrião; a codificação ficou congelada até que o conjunto sintético fosse substituído. A codificação congelada fica visível no quadro, para que colegas não façam merge de trabalho dependente. PRs dependentes de colegas ficam em rascunho enquanto o congelamento vale. Recuperar um ponto de controle perdido significa reunir-se com o orientador e obter a assinatura do portão, não apenas mandar um pedido de desculpas.
44.1b Métricas de sucesso do projeto final
Defina duas métricas que você vai mostrar na defesa (p. ex., tempo até negar tudo, percentual de merges com tickets AUTH). Se você não consegue nomeá-las no Projeto Final I, a proposta não está pronta. Sam escreveu "negar tudo ≤30 s após perda da política" e "100% das ampliações de escopo têm tickets AUTH" na primeira página da sua proposta. Cada métrica precisa de um método de medição e de uma meta que possa ser verificada com dados sintéticos antes da defesa. Metas vagas como "mais segurança" são devolvidas no ponto de controle da proposta. Sam também indicou como mediria cada uma: uma execução cronometrada do Laboratório II para o negar tudo e uma consulta ao histórico de merges para os tickets AUTH. As duas foram medidas uma vez com dados sintéticos antes de a proposta ser entregue, para que se soubesse que as metas eram alcançáveis.
Nota de prática
Propostas do Projeto Final I que não conseguem nomear uma linha do laboratório de verificação para cada requisito Must voltam para rascunho. Mapear requisitos para linhas do laboratório cedo evita desenhos bonitos que não conseguem mostrar falha fechada no Laboratório I.
Anexe o parágrafo de ética à proposta, para que os orientadores possam rejeitar escopo de uso dual antes de a codificação começar.
Demos de marco que pulam a falha fechada recebem zero naquele ponto de controle, seja qual for o polimento da interface.
Propostas sem o mapeamento para linhas do laboratório são devolvidas antes que o horário do ateliê seja reservado.
44.4b Delimitar o projeto final com honestidade
A proposta do projeto final declara o que será construído no tempo disponível — uma ferramenta de diff de escopo para o TrackScope, com testes e uma avaliação curta — e o que não será, como a integração com o sistema de tickets de cada cliente. Os orientadores julgam o projeto contra o escopo declarado, não contra um escopo maior imaginado. Os não objetivos de Sam incluíam "o sistema de tickets de cada cliente", o que impediu uma correria tardia para adicionar o Jira durante o congelamento. Os não objetivos ficam listados na proposta ao lado dos objetivos, para que as revisões de congelamento confiram novos pedidos contra eles. Uma funcionalidade que não aparece em nenhuma das listas volta ao orientador antes de qualquer código ser escrito. O orientador assina a lista no ponto de controle da proposta.
Exercícios
- EX130 — Não objetivo. Escreva três não objetivos para um projeto final sobre o PulseMap. Rubrica: 3 = três claros; 2 = dois; 1 = um; 0 = nada.
- EX131 — Marco. Um marco da semana 3 com teste de aceitação. Rubrica: 3 = demo + teste; 2 = só demo; 1 = vago; 0 = nada.
- EX132 — Ética. Parágrafo de ética de quatro frases. Rubrica: 3 = autorização, sintético, uso dual, divulgação; 2 = parcial; 1 = fraco; 0 = nada.
Síntese
Entregue valor de plataforma relevante para a segurança; congele os não objetivos cedo.
Continue estudando — capítulo 44 de 50
← Capítulo 43 (rascunho) · Índice de capítulos do curso · Capítulo 45 (rascunho) →