Mini-Projecto · Desenvolver um software de raiz
Contexto
O clube desportivo da tua escola precisa de uma aplicação de consola simples para gerir os seus sócios e as quotas. Como não têm orçamento para software comercial, foste tu o/a contratado/a para o desenvolver de raiz, seguindo todas as fases de um projeto de software.
Trabalhas individualmente ou a pares, em Python (consola), com Git, e entregas o programa a funcionar mais um dossiê técnico (requisitos, algoritmo/fluxograma, modelo de dados e testes).
Requisitos
Funcionais
O programa, com um menu, deve permitir: - Adicionar um sócio (nome, número, email). - Listar todos os sócios. - Registar o pagamento da quota de um sócio. - Listar os sócios com quota em atraso. - Guardar os dados num ficheiro (para não se perderem ao fechar). - Sair.
Não-funcionais
- Código organizado em funções com nomes claros.
- Tratamento de erros (opções inválidas, sócio inexistente).
- Repositório Git com commits ao longo do trabalho.
- README e comentários no código.
Fases
Fase 1 · Análise (2h) Levantar requisitos (funcionais, não-funcionais) e escrever 3–4 user stories.
Fase 2 · Desenho (4h) Algoritmo do menu em pseudocódigo, fluxograma do fluxo principal e modelo de dados (que campos tem um sócio).
Fase 3 · Ambiente (1h) Preparar o IDE (VS Code), criar o repositório Git e a estrutura do projeto.
Fase 4 · Codificação (7h) Implementar as funções uma a uma, com commits frequentes. Guardar/ler os dados de um ficheiro.
Fase 5 · Debug e testes (4h) Testar cada função (casos normais, limites e inválidos), corrigir erros e voltar a testar.
Fase 6 · Documentação e entrega (2h) README, comentários, e apresentação do programa e do dossiê.
Critérios de avaliação
| Critério | Peso |
|---|---|
| Análise (requisitos, user stories) | 10% |
| Desenho (algoritmo, fluxograma, dados) | 20% |
| Funcionalidade (menu completo a funcionar) | 30% |
| Debug e testes (casos + correções) | 20% |
| Git, código organizado e tratamento de erros | 10% |
| Documentação e apresentação | 10% |
Erros comuns
- Começar a codificar sem desenhar o algoritmo e os dados.
- Não guardar em ficheiro — os dados perdem-se ao fechar.
- Não tratar opções inválidas / sócio inexistente → o programa rebenta.
- Testar só o caso normal.
- Um único commit gigante no fim, em vez de commits ao longo do trabalho.
Bónus (opcional)
- Pesquisar sócio por nome.
- Total de quotas recebidas vs em atraso.
- Exportar a lista de sócios para CSV.
- Interface gráfica simples (ex.:
tkinter).
Reflexão
No dossiê, responde: porque é que desenhar o algoritmo e o modelo de dados antes de codificar te poupou tempo? E dá um exemplo de um erro de lógica que só apanhaste nos testes.