Avaliação · versão de rascunho

Como és avaliado

Duas componentes: um projeto final em grupo, construído por sprints ao longo do semestre, e um ou dois testes escritos de escolha múltipla sobre a componente teórica das aulas (número e datas a confirmar).

Rascunho Os pesos e as regras abaixo são a proposta do docente e ficam definitivos na primeira aula, depois de confirmados com a coordenação do curso. O que não muda é a estrutura: projeto em grupo mais testes escritos de escolha múltipla.

Componentes e pesos

Componente	Peso	Quando	Individual ou grupo
Projeto final: app entregue no GitHub	a confirmar	Freeze a 09/12, defesas a 14 e 16/12	Grupo, com ajuste individual
Defesa oral do projeto	a confirmar	14 e 16/12	Individual
Teste escrito 1	a confirmar	Qua 04/11, 16:00	Individual
Teste escrito 2 (se houver)	a confirmar	Seg 07/12, 16:00	Individual

Testes escritos

Em papel, escolha múltipla, sem consulta. Cada pergunta tem quatro opções e uma só correta.
Teste 1 (04/11): matéria teórica das aulas 1 a 19. Ecossistema mobile, Flutter e Dart, ciclo de vida, UX, estado, navegação, acessibilidade, network layer, arquitetura, resiliência, persistência, segurança, autenticação, performance, push notifications.
Teste 2 (07/12): matéria teórica das aulas 21 a 32. Localização e mapas, deep links, background, hardware, testes, observabilidade, distribuição a testers, platform channels, lojas e monetização, tamanho e arranque, build e assinatura, consolas das lojas.
Há uma aula de revisão com perguntas e respostas antes de cada teste (02/11 e 04/12).

Projeto final em grupo

Grupos de 2 a 3 pessoas. A app liga-se a uma API pública: a proposta principal é a Tempo Açores, sobre a API do IPMA através da API do curso; outra API aberta pode ser considerada. O enunciado completo, os requisitos mínimos e os extras são publicados antes do kickoff, na semana 7.

Rubrica (proposta)

Critério	O que se avalia	Peso no projeto
Funcionalidade	Requisitos mínimos completos e a funcionar no telemóvel; extras valorizados.	35%
Qualidade do código e arquitetura	Camadas claras, modelos, tratamento de erros, lints sem avisos, testes existentes e a passar no CI.	25%
Experiência de utilização	Estados de loading, erro e vazio; funcionamento offline; acessibilidade básica; coerência visual.	15%
Processo	Entregas por sprint, pull requests revistos por colegas, commits distribuídos pelos membros, uso da API do curso ao longo do tempo.	15%
Distribuição e apresentação	Build assinado distribuído a testers (Firebase App Distribution ou TestFlight), demo e resposta às perguntas.	10%

Nota individual dentro do grupo

A nota do projeto é do grupo, ajustada por pessoa com base em três sinais: os pull requests de cada um (autoria e revisões), a defesa oral com perguntas dirigidas a cada membro, e a distribuição de commits no histórico. A nota individual depende de cada membro conseguir explicar o código que entregou.

Acompanhamento durante o semestre

O docente acompanha semanalmente, por grupo, os commits e pull requests no GitHub e o uso da API do curso (cada grupo tem o seu client-id). Isto serve para dar feedback cedo, não para contar pedidos. Um grupo que ainda não chamou a API na semana 8 recebe um aviso do docente.

Transparência Os pedidos à API do curso ficam registados (grupo, endpoint, estado, hora, plataforma e versão da app). Não se guarda conteúdo pessoal. Falamos disto na primeira aula.

Regras

O código do projeto vive no repositório do grupo criado pelo GitHub Classroom. Código fora do repositório não conta.
Uso de IA (Copilot, ChatGPT, Claude, etc.) é permitido e incentivado, com uma condição: tens de saber explicar cada linha que entregas. A defesa serve para isso.
Plágio entre grupos anula a componente para os envolvidos.
Prazos de sprint são fixos. Entregas atrasadas são avaliadas, mas o atraso conta no critério de processo.