Método de Avaliação do Projecto
A avaliação relativa à componente do Projecto processa-se em várias fases:
- Entrega do modelo UML (ver condições abaixo)
- Entrega intermédia (ver condições abaixo)
- Entrega final (ver condições abaixo)
- Teste prático (ver condições abaixo)
O Projecto (trabalho conducente às entregas acima mencionadas e abaixo descritas) é realizado por grupos de exactamente 2 (dois) elementos, durante o período estabelecido. A inscrição do grupo é feita no agrupamento Projecto.
O Teste Prático é realizado individualmente, em data e local a agendar.
TODAS AS ENTREGAS SÃO REALIZADAS ATÉ ÀS 12:00 ("meio-dia") DAS RESPECTIVAS DATAS
Cálculo da Nota do Projecto e Condições de Aprovação
Componentes de avaliação:
- PRJ - nota final do projecto
- PU - nota da entrega do diagrama UML
- PI- nota da entrega intermédia
- PF- nota da entrega final
- TP - nota do teste prático
A nota do teste prático condiciona a distância ao mínimo entre as notas do teste prático e a do projecto: desde um mínimo de 12.5% de acréscimo à menor das duas (abaixo de 7.5 valores no TP), até um máximo de 25% (para 20 valores no TP). O acréscimo é linear entre 7.5 e 20.
Ou seja: PRJ = min(PU+PI+PF, TP) + | TP - PU - PI - PF | * max(12.5, TP+5) / 100
Condições necessárias para aprovação à disciplina (necessárias todas):
- PRJ >= 9.5 (sem arredondamento)
- PRJ != NA
- TP > 0
- TP != NA
Entrega do Modelo UML
A Entrega do Modelo UML avalia o estado do projecto relativamente à concepção do modelo.
Esta entrega tem uma classificação máxima de 2 valores.
Devem ser entregues diagramas correspondentes a todos os conceitos da aplicação, mesmo que esses conceitos venham a ser revistos/alterados futuramente. Deve ser entregue um relatório que explique as opções de desenho (ficheiro rel0.txt no CVS). Podem ainda ser incluídas anotações nos diagramas, por forma a clarificar outros aspectos relevantes. Não é necessária a inclusão de getters/setters/equals/toString (e outros métodos já definidos no Java).
A entrega dos diagramas em papel faz-se em qualquer aula teórica, horário de dúvidas, ou na recepção do INESC ID (Rua Alves Redol, 9), ao cuidado de David Matos, até à data limite.
Considerando que é uma ENTREGA CRUCIAL na concepção do projecto, a não realização desta entrega conduz automaticamente a uma classificação de 0 (zero) na componente de avaliação relativa ao Projecto e consequente exclusão da avaliação da disciplina no ano lectivo 2014/2015.
Serão aplicados os seguintes critérios na avaliação da entrega UML.
Factores aditivos positivos:
- 0.70 - Conceitos
- 0.30 - Herança
- 0.50 - Associações
- 0.25 - Atributos
- 0.25 - Interface (métodos das classes, interfaces, etc.)
Factores aditivos negativos:
- 0.50 - Erros de notação
A compreensão clara dos aspectos acima deve ser adquirida antes da entrega.
Entrega Intermédia
A Entrega Intermédia avalia o estado do projecto relativamente a um mínimo de funcionalidade.
Esta entrega tem uma classificação máxima de 5 valores (2.5 valores para testes automáticos).
Serão executados testes automáticos nesta entrega.
Os pormenores dos parâmetros de avaliação desta entrega serão anunciados em data próxima da entrega.
Para esta entrega, cada grupo deve produzir um relatório com um máximo de duas páginas de texto simples sem formatação e chamado rel1.txt (serão sumariamente ignorados relatórios noutros formatos). O relatório é entregue via CVS e deve descrever as estruturas de dados utilizadas, assim como a correspondente funcionalidade e limitações. Não devem ser incluídas descrições de nenhum material fornecido pelo corpo docente.
A não realização da Entrega Intermédia conduz automaticamente a uma classificação de 0 (zero) na componente correspondente (mas não globalmente no projecto).
A funcionalidade necessária para a entrega intermédia, além da abertura de todos os submenus (já implementada), é a seguinte:
- Leitura, interpretação e armazenamento em memória (nesta entrega, apenas utilizadores e directórios) do ficheiro textual "data.import" (implica implementar algumas classes do "core")
- Operações §2.1.1 "Criar", "Abrir" e "Guardar" (serialização do filesystem)
- Operação §2.1.2 "Login" (implica que parte da gestão de utilizadores esteja a funcionar)
- Operação §2.2.1 "Listar" (implica que parte da gestão de entradas esteja a funcionar -- nesta entrega, sem limitações, apenas directórios)
- Operação §2.2.7 "Mostrar Caminho Actual" (implica que o login esteja a funcionar -- ver operação §2.1.2 acima)
- Operação §2.3.2 "Listar" (utilizadores) (implica que parte da gestão de utilizadores esteja a funcionar)
- Todos os outros comandos em todos os menus têm de estar implementados ("execute" pode estar vazio). Não é má prática implementar os outros comandos, pois poupa esforço para a entrega final, mas não serão avaliados nesta entrega.
Serão aplicados os seguintes critérios na avaliação da entrega intermédia do projecto.
Factores aditivos positivos:
- 0.30 - Atributos não públicos
- 0.30 - Atributos e métodos não "static" (excepto onde autorizado)
- 0.30 - Atributos não repetidos
- 0.30 - Serialização
- 0.30 - Factorização e organização (não repetição) de código
- 0.50 - Separação textui/core (pode haver descontos na parte automática)
- 0.30 - Qualidade do projecto
- 0.20 - Comentários Javadoc na classe que representa o conceito de sistema de ficheiros.
Factores aditivos negativos:
- 0.15 - Violação de regras de codificação Java
Será aplicado um desconto até 1.00 pela existência de lixo no repositório CVS. Este "lixo" é apenas considerado se aparecer na cópia local durante um "checkout".
Será aplicado um desconto até 0.50 pela falta do ficheiro rel1.txt (relatório -- ver condições acima).
Entrega Final
A Entrega Final pressupõe que todo o projecto foi completamente implementado.
Esta entrega tem uma classificação máxima de 13 valores (6 valores para testes automáticos).
Serão executados testes automáticos nesta entrega.
Os testes correspondem a uma série de entradas a processar pelo projecto de cada grupo e cuja execução deve corresponder a um conjunto de resultados padrão.
Para esta entrega, cada grupo deve produzir um relatório com um máximo de quatro páginas de texto simples sem formatação e chamado rel2.txt (serão sumariamente ignorados relatórios noutros formatos). O relatório é entregue via CVS e deve descrever as estruturas de dados utilizadas, assim como a correspondente funcionalidade e limitações. Não devem ser incluídas descrições de nenhum material fornecido pelo corpo docente.
A não realização da Entrega Final conduz automaticamente a uma classificação de 0 (zero) na componente de avaliação relativa ao Projecto e consequente exclusão da avaliação da disciplina no ano lectivo 2014/2015.
Serão aplicados os seguintes critérios na avaliação da entrega final do projecto.
Factores aditivos positivos:
- 0.50 - Atributos (qualidade e acesso)
- 1.50 - Factorização e reutilização de código (evitar repetição de código: serialização, verificações, etc.)
- 0.50 - Atributos e métodos não "static" (excepto autorizados)
- 1.00 - Gestão das entradas especiais
- 1.00 - Utilização de estruturas de dados correctas
- 1.50 - Separação de responsabilidades, incluindo serialização (core vs. textui)
- 1.00 - Apreciação global
Factores aditivos negativos:
- até 1.00 - Violação de regras de codificação Java
- até 1.00 - Existência de lixo no repositório CVS (o "lixo" é apenas considerado se aparecer na cópia local durante um "checkout")
Será aplicado um desconto até 0.50 pela falta do ficheiro rel2.txt (relatório -- ver condições acima).
Note-se que não é considerada a entrega final se o repositório à data da entrega final contiver o mesmo código da entrega intermédia. Isso implica também a reprovação imediata dos alunos do grupo em causa (a entrega final é obrigatória).
Teste Prático
O Teste Prático consiste num conjunto de questões (correspondentes a pequenas alterações/extensões ao enunciado) a resolver com base na implementação submetida para a avaliação correspondente à entrega final.
Este teste é individual e avalia o conhecimento do aluno relativamente ao projecto entregue, assim como a sua capacidade de realizar alterações ao código do projecto.
A não realização do Teste Prático conduz automaticamente a uma classificação de 0 (zero) nacomponente de avaliação relativa ao Projecto e consequente exclusão da avaliação da disciplina no ano lectivo 2014/2015.
O teste prático contém uma prova eliminatória: o aluno deverá ser capaz de compilar e executar um pequeno programa em Java.
Considerações Adicionais sobre a Avaliação do Projecto
O projecto deverá ser desenvolvido atempadamente ao longo do semestre.
As versões intermédias registadas no CVS poderão ser testadas, pelo que deverão ser periodicamente actualizadas. O projecto é constituído por um projecto CVS designado pelo número do grupo que o executa. O repositório CVS disponibilizado já contém uma versão vazia do projecto. Apenas os ficheiros registados no projecto CVS serão considerados na avaliação. Na data limite para a conclusão do projecto deverá existir um relatório (nas condições indicadas acima), também sob o controlo do CVS.
Não serão consideradas quaisquer alterações aos ficheiros disponibilizados: eventuais cópias desses ficheiros serão automaticamente substituídas durante a avaliação da funcionalidade do código submetido.
A avaliação executa testes automáticos ao projecto a implementar: a nota reflectirá apenas os testes bem sucedidos. Chama-se especial atenção para o nome da classe que inicia a execução. As restantes componentes da nota são obtidas pela análise do código, relatórios e resultado do teste prático (realizado individualmente). O código é avaliado quanto à sua correcção, simplicidade, extensibilidade e legibilidade: devem existir comentários das partes mais complexas, mas não devem ser excessivos, nem óbvios (diminuem a legibilidade), nem muito escassos (impedem a compreensão). O teste prático avalia a capacidade de efectuar alterações ao código entregue.
Qualquer alteração à especificação providenciada no enunciado é penalizada, mesmo que possa ser entendida como um melhoramento.
Notar que o facto de os testes automáticos terem sido superados não reflecte a qualidade do código, quer do ponto de vista de engenharia de software, quer do ponto de vista da correcta aplicação dos princípios leccionados na disciplina. A funcionalidade do projecto final é de extrema importância, pelo que é preferível um projecto que realize, correctamente, apenas parte da funcionalidade a um quase completo mas que nem sequer compile ou que não processe nenhuma entrada correctamente.
Compromisso de Honra
A entrega de qualquer trabalho pressupõe o compromisso de honra que o trabalho correspondente foi realizado pelos alunos referenciados no grupo. A quebra deste compromisso, i.e., a tentativa de um grupo se apropriar de trabalho realizado por colegas, tem como consequência a reprovação de todos os alunos envolvidos (incluindo os que possibilitaram a ocorrência) neste ano lectivo, sem prejuízo de acções disciplinares previstas pelo IST.