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
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. Não é necessário nenhum relatório nesta fase, embora possam ser incluídas anotações nos diagramas, por forma a clarificar aspectos relevantes.
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 2012/2013.
Serão aplicados os seguintes critérios na avaliação da entrega UML.
Factores aditivos positivos:
- Conceitos: 0.70
- Herança: 0.30
- Associações: 0.50
- Atributos: 0.25
- Interface (métodos): 0.25
Factores aditivos negativos:
- Erros de notação: 0.5
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.
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 é a seguinte:
- Leitura, interpretação e armazenamento em memória (conceitos) do ficheiro textual (implica implementar classes do "core")
- Serialização dos elementos acima (necessário para criar o ficheiro "rest.import" -- necessário para testar o outlet) (implica que alguns comandos do manager tenham de funcionar, §3.1 "Guardar")
- Todos os comandos em todos os menus têm de estar implementados ("execute" pode estar vazio, excepto nos comandos §3.2.1, §3.3.1, §3.4.1, §3.5.1, que devem produzir as saídas adequadas)
Serão aplicados os seguintes critérios na avaliação da entrega intermédia do projecto.
Factores aditivos positivos:
- 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.30
- Separação textui/core: 0.50 (pode haver descontos na parte automática)
- Qualidade do projecto: 0.50
Factores aditivos negativos:
- Violação de regras de codificação Java: 0.15
- Não inclusão de Javadoc na classe que representa o conceito Restaurante: 0.15
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 implementado.
Esta entrega tem uma classificação máxima de 13 valores.
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 2012/2013.
Serão aplicados os seguintes critérios na avaliação da entrega final do projecto.
Factores aditivos positivos:
- 1.00 - Atributos (qualidade e acesso)
- 1.00 - Herança, polimorfismo, reutilização
- 1.00 - Factorização de código (evitar repetição de código)
- 1.00 - Estruturas de dados de suporte (Map vs. List, etc.)
- 0.50 - Atributos e métodos não "static" (excepto autorizados)
- 2.00 - Separação de responsabilidades, incluindo serialização (core vs. textui)
- 1.50 - 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")
- até 0.50 - Falta do ficheiro rel2.txt (relatório -- ver condições acima)
Não é necessária a realização de quaisquer testes JUnit nesta entrega (os testes serão realizados durante o teste prático).
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 2012/2013.
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.
Ver também: