Partilhar: WhatsApp
aulify · Mini-Projecto
UC UC00245 · T. Desenv. Software, T. Multimédia, T. Inform. Gestão
Versão · Aluno

Mini-Projecto · Sistema de Gestão Académica

Conceber, especificar e validar um algoritmo integrador para gerir as notas de uma turma do Curso Profissional
⏱ Duração estimada: 6 a 8 horas (≈ 4 aulas + trabalho autónomo) ↗ Referencial SNQ
Índice

Contexto e propósito

Este mini-projecto é o exercício integrador da unidade de competência UC00245 — Desenvolver algoritmos. Mobiliza, num único caso aplicado, todas as cinco realizações oficiais do referencial:

# Realização Fase do projecto
R1 Definir o problema Fase 1 · Análise
R2 Planear as etapas de criação do algoritmo Fase 2 · Decomposição e plano
R3 Estruturar algoritmos em pseudocódigo Fase 3 · Pseudocódigo
R4 Desenhar algoritmos em fluxograma Fase 4 · Fluxograma
R5 Testar e depurar algoritmos Fase 5 · Validação e testes

O trabalho é individual ou em pares e tem como deliverable final um dossier técnico com cinco capítulos (um por fase), apresentado em formato PDF ou impresso.

Cenário de aplicação

A direcção da tua escola pretende informatizar o registo e processamento de notas das turmas dos Cursos Profissionais. O sistema actual, em folhas de Excel, é propenso a erros, difícil de auditar e moroso de actualizar.

A escola decidiu contratar uma equipa de alunos finalistas para conceber o algoritmo que servirá de base ao futuro programa. Vais participar nessa equipa.

Importante. Nesta UC não vais escrever o programa: vais conceber e documentar o algoritmo, na forma de pseudocódigo e fluxograma, com os respectivos testes. A codificação em Python é uma etapa opcional (bónus), reservada para alunos que queiram aprofundar.

Requisitos do sistema

Requisitos funcionais

O algoritmo deve satisfazer todos os seguintes requisitos:

  1. Registar uma turma. Ler o nome da turma e o número de alunos.
  2. Registar alunos. Para cada aluno, registar o nome e três notas — Escrita (peso 50%), Oral (peso 20%) e Prática (peso 30%) — todas entre 0 e 20.
  3. Calcular a média ponderada de cada aluno.
  4. Classificar cada aluno segundo a escala oficial:

    Média Classificação
    0 – 9 Insuficiente
    10 – 13 Suficiente
    14 – 17 Bom
    18 – 20 Muito Bom
  5. Apresentar a pauta com os resultados de toda a turma (nome, três notas, média, classificação).

  6. Calcular e apresentar estatísticas da turma:
    • Número total de alunos.
    • Número e percentagem de aprovados (média ≥ 10).
    • Média geral da turma.
    • Aluno com melhor média (nome e média).
    • Aluno com pior média (nome e média).
    • Distribuição de classificações (quantos em cada nível).

Requisitos não-funcionais

  1. Validação. Toda a entrada de dados deve ser validada — nomes não vazios, notas entre 0 e 20, número de alunos positivo. Mensagens de erro claras e nova tentativa em caso de valor inválido.
  2. Robustez. Tratar correctamente o caso de turma vazia (n = 0) e o caso em que todos os alunos têm a mesma média (não há «melhor» nem «pior» distinguíveis).
  3. Legibilidade. Nomes de variáveis descritivos, constantes para os pesos das notas, indentação consistente.
  4. Documentação. Comentários no pseudocódigo explicando decisões não-óbvias.

As cinco fases

Fase 1 · 1h

Análise · Definir o problema

Objectivo: transformar o enunciado num documento técnico de requisitos não-ambíguos.

Tarefas:

Documento de 1 a 2 páginas com as quatro listas acima.

Fase 2 · 1h

Plano · Decomposição em etapas

Objectivo: decompor o problema em sub-problemas tratáveis separadamente.

Tarefas:

Tabela de módulos + diagrama de blocos (à mão ou em draw.io).

Procura aplicar o pilar da decomposição do pensamento computacional. Cada módulo deve ter uma responsabilidade clara e ser tão independente quanto possível.

Fase 3 · 2 a 3h

Pseudocódigo

Objectivo: traduzir o plano em pseudocódigo completo e correcto.

Tarefas:

Pseudocódigo completo do algoritmo principal + módulos auxiliares.

Não passes para a fase seguinte enquanto não tiveres a certeza de que o pseudocódigo cumpre todos os requisitos funcionais 1-6 e os não-funcionais 7-10. Volta atrás e revê.

Fase 4 · 1h

Fluxograma

Objectivo: representar visualmente o fluxo de execução do algoritmo principal.

Tarefas:

Fluxograma do algoritmo principal em PDF ou imagem (exportar do draw.io).

Fase 5 · 1 a 2h

Validação · Testes e depuração

Objectivo: demonstrar que o algoritmo funciona correctamente em diversos cenários.

Tarefas:

Tabela de testes com os 6 casos + indicação dos eventuais ajustes ao pseudocódigo.

Entregáveis e formato

O dossier final deve conter os seguintes elementos, por esta ordem:

  1. Capa — nome do(s) aluno(s), turma, disciplina, data, identificação do projecto.
  2. Índice.
  3. Fase 1 · Análise do problema — 1 a 2 páginas.
  4. Fase 2 · Plano e decomposição — tabela + diagrama.
  5. Fase 3 · Pseudocódigo — completo, indentado, comentado.
  6. Fase 4 · Fluxograma — do algoritmo principal.
  7. Fase 5 · Testes — 6 casos com trace tables resumidas.
  8. Reflexão final (½ página) — o que correu bem, o que foi difícil, o que ficou por fazer.
  9. (Opcional · bónus) Implementação em Python — código + screenshots de execução.

Entregar em PDF ou em folhas A4 impressas. A formatação livre, mas legível e profissional.

Critérios de avaliação

A avaliação segue o modelo CP da DGE (80% Conhecimentos e Capacidades + 20% Atitudes e Valores). A grelha específica deste projecto, com as ponderações entre fases, está disponível na folha Grelha · Instrumento desta UC.

Pesos sugeridos das fases:

Fase Peso Critério principal
Fase 1 · Análise 15 % Clareza e completude dos requisitos
Fase 2 · Plano 15 % Decomposição adequada e diagrama legível
Fase 3 · Pseudocódigo 30 % Correcção, cobertura dos requisitos, qualidade
Fase 4 · Fluxograma 15 % Uso correcto dos símbolos, legibilidade
Fase 5 · Testes 15 % Cobertura de casos limite, rigor
Reflexão final 5 % Auto-crítica fundamentada
Bónus Python até +10 % Implementação funcional

Calendarização sugerida

O dossier é entregue uma semana após a Aula 4.

Recursos disponíveis


Boas práticas de execução

Reflexão final

A reflexão de meia página deve responder a estas perguntas:

  1. Que parte do projecto foi mais difícil? Porquê?
  2. Que padrão algorítmico achaste mais útil e porquê?
  3. Que mudarias se voltasses a fazer este projecto?
  4. Que dúvidas ainda tens que gostarias de aprofundar?

Esta reflexão conta para a avaliação — não é decorativa. Demonstra meta-cognição (pensar sobre como pensaste), competência altamente valorizada em programação.