Ficha 02 · Implementação, testes e defesa
- Planear testes
- Documentar
- Estruturar relatório
- Preparar defesa
Parte I · Implementação
Exercício 1 · Por fases (10 pts)
Porque se deve implementar e validar por fases (ex.: DNS → AD → DHCP → ficheiros) em vez de configurar tudo e testar no fim?
Porque há dependências (o AD precisa de DNS; o DHCP autoriza-se no AD; os serviços dependem da rede). Validar cada fase antes de avançar localiza problemas cedo e evita ter de diagnosticar um sistema enorme onde "nada funciona". Reduz risco e tempo de depuração — princípio de isolar variáveis.
Exercício 2 · Git no projeto (10 pts)
Que vantagens tem versionar (Git) as configurações e a documentação desde o dia 1 de um projeto de infraestrutura/PAP?
- Histórico de o que mudou e quando (diffs) — facilita reverter e diagnosticar.
- Backup distribuído das configs e do relatório.
- Prova de processo — o histórico mostra evolução ao longo do tempo (essencial na PAP; "1 commit final" é sinal de alarme).
- Permite rollback e trabalhar com segurança (branches para experiências).
Parte II · Testes
Exercício 3 · Plano de testes (20 pts)
Para um projeto com VLANs (Alunos isolados da Secretaria), AD, DHCP e servidor de ficheiros, indica 5 testes (o que verificar e resultado esperado).
| # | Teste | Esperado |
|---|---|---|
| 1 | Cliente recebe IP por DHCP da sua VLAN | IP no intervalo correto, gateway/DNS certos |
| 2 | Login com conta de domínio | Autentica; máquina vê o AD |
| 3 | Aluno → recurso da Secretaria (ping/SMB) | Bloqueado (ACL) |
| 4 | Professor → servidor de ficheiros | Acede com permissões do grupo; escreve |
| 5 | Restauro de backup de uma pasta | Pasta recuperada corretamente |
| 6 | Acesso à Internet a partir de cada VLAN | Funciona (NAT) |
Documentar esperado vs obtido; incluir testes que devem falhar (isolamento).
Exercício 4 · Teste de recuperação (10 pts)
Porque é importante incluir um teste de recuperação (restaurar backup / failover) no plano, e não só testes funcionais?
Porque um sistema só está realmente fiável se se conseguir recuperá-lo quando falha. Backups e redundância "configurados" mas nunca testados muitas vezes não funcionam quando são precisos (backup corrompido, procedimento errado). Testar recuperação valida o RPO/RTO prometido e dá confiança real — é tão importante como o sistema funcionar no dia-a-dia.
Parte III · Documentação
Exercício 5 · Relatório (15 pts)
Lista a estrutura (capítulos) de um relatório técnico de projeto/PAP e o objetivo de cada um (1 frase).
- Introdução — contexto, motivação, objetivos.
- Requisitos — funcionais e não-funcionais.
- Projeto — topologia, endereçamento, serviços, segurança, decisões justificadas.
- Implementação — o que foi feito, dificuldades e soluções.
- Testes — plano e resultados (esperado vs obtido).
- Orçamento — material + mão de obra + IVA.
- Conclusões — objetivos atingidos, limitações, trabalho futuro.
- Anexos — configs, diagramas, runbooks.
Exercício 6 · Documentação viva (10 pts)
Porque deve a documentação (diagramas, endereçamento) ser atualizada a cada mudança e não só no fim?
Porque documentação desatualizada engana — numa avaria, agir com base num diagrama errado prolonga a indisponibilidade (mexe-se no equipamento errado, assume-se VLAN/IP que já mudou). Documentar à medida é também mais fácil (lembramo-nos das decisões) e evita o trabalho enorme — e impreciso — de "documentar tudo no fim". É parte do processo de gestão de mudança.
Parte IV · Defesa
Exercício 7 · Preparar a defesa (25 pts)
Vais defender o projeto/PAP perante um júri.
a) Lista 5 cuidados para a apresentação. (15 pts)
b) O júri pergunta "porque escolheste esta solução e não a alternativa X?". Como deves responder? (10 pts)
a) Cuidados: 1. Ensaiar e cronometrar (~15 min); falar com fluidez. 2. Começar pelo problema/utilidade, não pela tecnologia. 3. Demo (real/simulada) com plano B gravado caso falhe. 4. Slides limpos — diagramas e resultados, pouco texto. 5. Antecipar perguntas (segurança, escalabilidade, custo, recuperação). 6. Assumir limitações com consciência do que melhoraria; postura calma.
b) Não dizer "porque gosto mais". Responder com critérios objetivos: contexto/requisitos do cliente, custo vs benefício, competências disponíveis, escalabilidade e manutenção, riscos e como os mitiguei; reconhecer os pontos fortes da alternativa e explicar porque os trade-offs pendem para a solução escolhida neste caso. Mostrar que se ponderou, não que se escolheu ao acaso.