Capítulo 25 — Estúdio de projeto em equipe
Mapa da aula
Aula 25 publicada. Mapa, exemplo, EX073.
flowchart TD
N0["25.1 Encomenda"]
N1["25.2 Papéis"]
N2["25.3 Decisões de projeto"]
N3["25.4 Integração"]
N4["25.5 Revisão por pares"]
N5["25.6 Apresentação"]
N6["25.7 Retorno"]
N7["Gestão do projeto"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX073"]
Desenho lógico
flowchart LR
N0["25.1 Encomenda"]
N1["25.2 Papéis"]
N2["25.3 Decisões de projeto"]
N3["25.4 Integração"]
N4["25.5 Revisão por pares"]
N5["25.6 Apresentação"]
N6["25.7 Retorno"]
N7["Gestão do projeto"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX073"]
[25.1 Encomenda]
|
v
[25.2 Papéis]
|
v
[25.3 Decisões de projeto]
|
v
[25.4 Integração]
|
v
[25.5 Revisão por pares]
|
v
[25.6 Apresentação]
|
v
[25.7 Retorno]
|
v
[Gestão do projeto]
|
v
[Exemplo resolvido] --> [Exercício EX073]
Objetivos de aprendizagem
Você vai (1) trabalhar em equipe para desenhar um kit de triagem pericial; (2) dividir o trabalho e integrá-lo; (3) revisar o trabalho uns dos outros; (4) apresentar um projeto às partes interessadas.
25.1 Encomenda
A prefeitura de Alder Falls pede à equipe de quatro estudantes de Jonah que desenhe o "Kit de Triagem 2": um conjunto documentado e validado de ferramentas, scripts e procedimentos para quem chega primeiro à cena, construído a partir das lições do incidente. A encomenda nasce de uma necessidade real: durante o incidente, ninguém além de Renata sabia onde estava a ferramenta de memória nem como usá-la, e a coleta levou cerca de duas horas. O Kit de Triagem 2 deve permitir que qualquer pessoa treinada que chegue primeiro colete evidências corretamente a qualquer hora. A equipe escreve logo no início as condições de sucesso da encomenda, como uma coleta concluída por um não especialista apenas com o procedimento impresso, para que o projeto final possa ser julgado em relação a elas, e não à sensação de progresso da própria equipe.
25.2 Papéis
Jonah: scripts de manifesto e verificação. Priya-May: procedimentos e materiais de treinamento. Kofi: validação das ferramentas sobre imagens sintéticas. Lina: repositório de evidências e registros de custódia. Reuniões semanais de integração. Cada papel tem uma entrega clara e uma dependência clara em relação aos outros: os registros de custódia precisam do hash do manifesto, os procedimentos precisam das versões validadas das ferramentas, os materiais de treinamento precisam dos procedimentos. As reuniões semanais de integração existem porque essas dependências se quebram em silêncio quando as pessoas trabalham separadas. Cada integrante também mantém um log individual das tarefas feitas e do tempo gasto, o que sustenta uma avaliação justa e mostra ao orientador quem fez cada parte do trabalho.
25.3 Decisões de projeto
Somente a biblioteca padrão nos scripts; ferramentas escolhidas entre as que têm validação publicada ou foram testadas internamente; procedimentos impressos e plastificados; toda saída com hash e incluída num manifesto. Cada decisão é registrada com seu motivo no log de decisões. Scripts com a biblioteca padrão evitam instalar pacotes em máquinas que podem guardar evidências; ferramentas validadas significam que a prefeitura consegue explicar como cada resultado foi produzido; procedimentos impressos e plastificados funcionam quando as telas são desconhecidas ou não há um notebook disponível; calcular o hash de toda saída torna possível a verificação posterior. Registrar os motivos permite que uma equipe futura mude uma decisão de forma consciente, e não por acidente, e responde às perguntas das partes interessadas sem outra reunião.
25.4 Integração
O modelo de custódia de Lina precisa aceitar o hash de manifesto de Jonah; os testes de Kofi precisam cobrir as versões exatas das ferramentas citadas nos procedimentos de Priya-May. As divergências são registradas e resolvidas. A integração é o ponto em que partes separadas de um bom trabalho podem falhar juntas. Um hash de manifesto num formato que o modelo de custódia não aceita, ou um procedimento que cita uma versão de ferramenta que ninguém testou, quebraria o kit em uso, embora cada parte parecesse correta isoladamente. A equipe registra cada divergência com a data, as pessoas envolvidas e a correção, para que o mesmo problema não volte na próxima versão do kit.
25.5 Revisão por pares
Cada integrante revisa o trabalho de outro em relação à encomenda e às normas: os princípios da ISO/IEC 27037 para os procedimentos; a evidência de teste para as ferramentas. Revisar em relação à encomenda e às normas mantém o retorno específico: um revisor pergunta se um procedimento preserva a evidência e registra cada ação, como a ISO/IEC 27037 espera, ou se o teste de uma ferramenta cobre a versão listada. Os comentários são escritos e respondidos, para que o autor possa mostrar o que mudou. Alternar os revisores espalha o conhecimento pela equipe e pega suposições que uma pessoa compartilha com o autor.
25.6 Apresentação
A equipe apresenta o projeto a Renata e ao gerente de TI, com uma demonstração ao vivo numa máquina sintética. Uma demonstração ao vivo numa máquina sintética mostra às partes interessadas como é de fato usar o kit, inclusive quanto tempo leva cada passo e onde um operador poderia hesitar. Renata observa o tratamento da evidência; o gerente de TI observa o esforço e o custo. A equipe prepara, a partir do log de decisões, respostas para as perguntas prováveis, como por que o kit evita pacotes de terceiros.
25.7 Retorno
O gerente de TI pede uma versão que funcionários que não são de segurança consigam usar à noite; a equipe acrescenta um cartão rápido de uma página. Quem responde à noite costuma ser da equipe de operações de TI, e não especialista em segurança, e precisa dos passos essenciais numa única página: a quem ligar, o que não tocar, como capturar a memória e onde registrar os horários e os hashes. O cartão rápido é testado por alguém de fora da equipe antes de ser adotado, e sua versão é registrada junto com o restante do kit.
Gestão do projeto
A equipe mantém um quadro simples de tarefas, com responsáveis e prazos, e um log de decisões. Quando Kofi adoece por uma semana, o quadro mostra exatamente quais testes de validação faltam, e Lina assume dois deles. O log de decisões responde depois à pergunta do gerente de TI sobre por que o kit evita pacotes Python de terceiros, poupando uma reunião.
Exemplo resolvido
O teste de integração mostra que o procedimento de Priya-May cita uma versão de ferramenta que Kofi não tinha validado. A equipe ou valida essa versão ou muda o procedimento. Eles a validam, registram os resultados e atualizam os dois documentos juntos.
Caso sintético. A equipe e o projeto são inventados.
Erros e limites
Projetos em equipe podem esconder contribuições desiguais; logs individuais e avaliações entre pares mantêm o trabalho visível.
Exercícios
- EX073 — Papéis. Cite os quatro papéis da equipe. Rubrica: 3 = scripts, procedimentos, validação, repositório de evidências/custódia; 2 = três; 1 = um; 0 = nada.
- EX074 — Divergência de versão. Como foi resolvida a divergência de versão da ferramenta? Rubrica: 3 = validaram essa versão; atualizaram os dois documentos; 2 = parcial; 1 = ignorada; 0 = nada.
- EX075 — Cartão rápido. Por que foi acrescentado um cartão rápido? Rubrica: 3 = utilizável à noite por funcionários que não são de segurança; 2 = parcial; 1 = decoração; 0 = nada.
Síntese
Um projeto em equipe precisa de papéis claros, verificações de integração, revisão por pares e atenção aos usuários.
Continue estudando — capítulo 25 de 30
← Capítulo 24 (rascunho) · Índice de capítulos do curso · Capítulo 26 (rascunho) →