Projectos de programação

Apresentação

UC02837 (50h · 4,5 pts) é a UC capstone do curso TDS. Não introduz uma tecnologia nova: ensina a conduzir um projecto de software completo — do levantamento à entrega — integrando tudo o que foi aprendido. É o ensaio directo da PAP (Prova de Aptidão Profissional).

Ciclo de vida do software

Fases

1. Levantamento de requisitos — perceber o problema e o que o sistema tem de fazer.
2. Análise e desenho — modelo de dados, arquitectura, fluxos.
3. Planeamento — tarefas, estimativas, cronograma.
4. Implementação — escrever código em iterações.
5. Testes — unitários, integração, aceitação.
6. Entrega / deploy — pôr em produção.
7. Manutenção — correcções, melhorias, evolução.

Os modelos ágeis percorrem estas fases em ciclos curtos repetidos, não uma só vez de forma linear.

Requisitos

Funcionais — o que o sistema faz:

"O utilizador pode criar uma conta com email e senha." "O administrador pode exportar relatórios em CSV."

Não-funcionais — qualidades do sistema:

"Páginas carregam em menos de 2 segundos." "O sistema suporta 500 utilizadores simultâneos." "Os dados pessoais são encriptados (RGPD)."

User stories — formato centrado no utilizador:

Como [papel], quero [objectivo] para [benefício]. "Como aluno, quero ver as minhas notas para acompanhar o meu progresso."

Critérios de aceitação — quando a story está "pronta":

Dado que estou autenticado, quando abro /notas, então vejo a lista das minhas notas ordenadas por data.

Estimativa e planeamento

• Quebrar o trabalho em tarefas pequenas (idealmente < 1 dia).
• Estimar — horas ou story points (relativos).
• MVP primeiro — Minimum Viable Product: a menor versão útil.
• Priorizar com MoSCoW:
• Must — sem isto não há produto.
• Should — importante mas não crítico.
• Could — bom ter.
• Won't — fora de âmbito (por agora).
• Adicionar margem (~30%) para imprevistos. Programadores subestimam sistematicamente.

Metodologias

Cascata (Waterfall)

Fases sequenciais: requisitos → desenho → implementação → testes → entrega. Cada fase termina antes da seguinte começar.

• Prós: simples, documentação forte, bom quando requisitos são estáveis.
• Contras: mudança é cara; problemas só aparecem no fim; rígido.

Adequado a projectos com requisitos muito bem definidos e estáveis (raro em software moderno).

Ágil

Filosofia (Manifesto Ágil): indivíduos e interacções, software funcional, colaboração com o cliente, resposta à mudança.

Iterações curtas, entrega incremental, feedback contínuo. Domina a indústria em 2026.

Scrum

Framework ágil mais usado.

• Sprint — iteração fixa (1-4 semanas) que produz incremento utilizável.
• Product Backlog — lista priorizada de tudo o que o produto pode precisar.
• Sprint Backlog — subconjunto escolhido para o sprint.
• Cerimónias:
• Sprint Planning — o que fazer este sprint.
• Daily Scrum — sincronização de ~15 min.
• Sprint Review — mostrar o incremento.
• Retrospective — o que melhorar no processo.
• Papéis: Product Owner (prioridades), Scrum Master (facilita), Equipa de Desenvolvimento.

Kanban

Fluxo contínuo visualizado num quadro:

To Do  │ In Progress │ Review │ Done

• Limitar WIP (Work In Progress) — não começar tudo ao mesmo tempo.
• Foco em terminar antes de começar.
• Ferramentas: Trello, GitHub Projects, Jira, Notion.

Para projectos individuais (como a PAP), um Kanban simples é frequentemente suficiente.

Controlo de versões com Git

Porquê

• Histórico completo — voltar atrás a qualquer ponto.
• Colaboração — várias pessoas sem se atropelarem.
• Branches — experimentar sem partir o que funciona.
• Backup distribuído.

Para a PAP, Git serve também de prova de processo — o histórico mostra a evolução do trabalho ao longo do tempo (não tudo no último dia).

Comandos essenciais

git init                       # criar repositório
git clone <url>                # copiar repositório remoto
git status                     # estado actual
git add ficheiro.py            # preparar (stage)
git add .                      # preparar tudo
git commit -m "feat: login"    # gravar snapshot
git push origin main           # enviar para o remoto
git pull                       # trazer alterações
git log --oneline              # histórico resumido
git diff                       # ver alterações

Branches e Pull Requests

git checkout -b feature/carrinho   # criar e mudar de branch
# ... trabalhar, commitar ...
git push -u origin feature/carrinho
# No GitHub/GitLab: abrir Pull Request → revisão → merge
git checkout main
git pull

Modelo simples (GitHub Flow): - main está sempre funcional. - Cada funcionalidade numa feature/.... - Pull Request com revisão antes de juntar a main.

Conventional commits

Mensagens padronizadas e legíveis:

feat: adiciona autenticação por email
fix: corrige cálculo do total do carrinho
docs: actualiza README com instruções de deploy
refactor: extrai lógica de pagamento para serviço
test: adiciona testes ao módulo de utilizadores
chore: actualiza dependências

Verbo no imperativo, presente, curto. Explica o quê no título; o porquê no corpo se necessário.

.gitignore

Nunca versionar:

venv/
__pycache__/
node_modules/
.env
*.sqlite3
.DS_Store
dist/
build/

Secrets (.env) nunca no Git. Se acontecer: revogar credenciais e limpar histórico (BFG / git filter-repo).

Qualidade

Testes

• Unitários — funções/classes isoladas.
• Integração — módulos a trabalhar juntos (ex.: API + BD).
• Aceitação / E2E — fluxos completos do ponto de vista do utilizador.

Para a PAP, ter testes — mesmo que poucos — demonstra maturidade e cobre os pontos críticos.

Integração Contínua (CI)

Testes correm automaticamente a cada push.

# .github/workflows/ci.yml (resumo)
name: CI
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
      - run: pip install -r requirements.txt
      - run: pytest

Build falhado → não fazer merge. Garante que main está sempre funcional.

Qualidade de código

• Nomes claros e consistentes.
• Funções pequenas com uma responsabilidade.
• DRY — não repetir lógica.
• Comentar o porquê, não o óbvio.
• Linters/formatters — ruff/black (Python), eslint/prettier (JS).
• Code review — segundo par de olhos apanha bugs e melhora design.
• Documentação — README, docstrings, comentários úteis.

Segurança (recap)

• Validação no servidor; nunca confiar no cliente.
• Prepared statements / ORM (sem SQL injection).
• Escape de output (sem XSS).
• Hash de senhas, secrets em variáveis de ambiente.
• Dependências auditadas.

Documentação do projecto

README

Primeiro contacto com o projecto. Deve responder rápido:

1. O que é e para que serve.
2. Tecnologias usadas.
3. Como instalar e correr localmente.
4. Como correr os testes.
5. Estrutura do projecto.
6. Autor, licença.

Documentação técnica

• Diagrama de arquitectura.
• Modelo de dados (ER).
• Decisões importantes e porquê.
• Manual de utilizador (se aplicável).

A Prova de Aptidão Profissional (PAP)

O que é

Projecto transversal e individual, parte integrante e obrigatória dos cursos profissionais (Portaria 235-A/2018). O aluno concebe, realiza e defende um projecto que demonstra as competências do curso, perante um júri.

Componentes: - Projecto — software funcional. - Relatório escrito. - Defesa oral perante o júri.

Escolher o tema

Características de um bom tema: - Problema real e concreto. - Âmbito adequado — exequível no tempo disponível (nem trivial nem impossível). - Integra várias competências do curso. - Demonstrável ao vivo. - Motivação genuína do aluno (vai trabalhar nisto muitos meses).

Exemplos: sistema de gestão para um negócio local, plataforma de apoio ao estudo, app móvel útil, ferramenta de automatização.

O relatório

Estrutura típica:

1. Introdução — contexto, motivação, objectivos.
2. Análise de requisitos — funcionais e não-funcionais.
3. Tecnologias e arquitectura — escolhas e justificação.
4. Desenvolvimento — implementação, decisões, dificuldades e como foram resolvidas.
5. Testes — estratégia e resultados.
6. Conclusões — objectivos atingidos, limitações, trabalho futuro.
7. Bibliografia e anexos.

Escrita técnica clara, português cuidado, diagramas e capturas, referências às UCs aplicadas.

A defesa oral

• Ensaiar e cronometrar (tipicamente ~15 min de apresentação).
• Slides limpos — pouco texto, mostrar o produto a funcionar.
• Demo ao vivo — com plano B gravado caso algo falhe.
• Antecipar perguntas do júri: porquê esta tecnologia? como garantes segurança? como escalaria? o que farias diferente?
• Honestidade — assumir limitações e mostrar consciência do que melhoraria.
• Postura — calmo, claro; o júri quer ver o melhor de ti.

Gestão do tempo da PAP

Um projecto acabado e modesto vale muito mais do que um ambicioso por terminar.

• Definir um MVP cedo e entregá-lo.
• Versionar em Git desde o dia 1.
• Documentar à medida, não na última semana.
• Pedir feedback ao orientador frequentemente.
• Planear marcos intermédios; não deixar para o fim.

Integração das competências

A PAP/projecto final aplica, na prática, todas as UCs do curso:

Apêndices

A · Checklist de projecto

• [ ] Requisitos escritos (funcionais + não-funcionais).
• [ ] Repositório Git desde o início, com .gitignore.
• [ ] MVP definido e priorizado.
• [ ] Modelo de dados desenhado.
• [ ] Commits pequenos e descritivos ao longo do tempo.
• [ ] Testes nos pontos críticos.
• [ ] README completo.
• [ ] Segurança básica (validação, secrets, hash).
• [ ] Deploy funcional ou instruções claras.
• [ ] Relatório a acompanhar o desenvolvimento.
• [ ] Defesa ensaiada com plano B.

B · Glossário

Backlog. Lista priorizada de trabalho. CI. Integração Contínua. MVP. Minimum Viable Product. PAP. Prova de Aptidão Profissional. Pull Request. Pedido de revisão/merge de uma branch. Scrum / Kanban. Frameworks ágeis. Sprint. Iteração de tempo fixo (Scrum). User story. Requisito no formato "como… quero… para…".

C · Recursos

• Pro Git (livro gratuito) · git-scm.com/book.
• Atlassian Agile · atlassian.com/agile.
• Conventional Commits · conventionalcommits.org.
• Portaria 235-A/2018 · enquadramento legal da PAP.
• GitHub Skills · skills.github.com.