a. Definição do grupo (máx. de 5 pessoas), nomes dos integrantes e repositório no GITHUB
b. Documento com descrição básica dos requisitos (modelo de documento de requisitos fornecido). O documento deve deixar bem clara qual a funcionalidade principal do sistema
Modelo de documento para entrega: LINK
a. Diagrama de classes de domínio em UML (contém somente as classes básicas e os relacionamentos entre elas). Sugestões de ferramenta: Visual Paradigm Community Edition [mais profissional], www.gliffy.com ou www.draw.io. O documento deve conter uma imagem legível do diagrama.
b. Código inicial das classes básicas do sistema, assim, como definidas no diagrama de classes do domínio.
c. Modelo navegacional contendo todas as telas do sistema e a navegabilidade entre elas (não há modelos para este artefato, usem ferramentas simples para isso que demonstrem o planejamento de quais telas existirão no sistema). Este artefato pode inclusive ser feito em papel mesmo. A ideia é que o conteúdo das telas esteja definido e como as telas estão conectadas entre si.
Modelo de documento para entrega: LINK
a. Entrega e breve apresentação da 1ª. versão do sistema com código disponível no GITHUB e foco na funcionalidade principal do sistema. Espera-se que todos os CRUDs do sistema já estejam plenamente funcionais nessa entrega. A apresentação será feita por grupo em laboratório. O professor irá passar de grupo a grupo para fazer a avaliação do sistema.
b. O projeto deverá ser submetido no AVA, como um zip contendo todo o código-fonte além de disponível em repositório no github com acesso concedido ao professor.
a. Apresentação pública de 15 minutos por grupo demonstrando o funcionamento prático do sistema e respondendo a arguição do professor para todos os integrantes do grupo. A presença é obrigatória com assinatura de ata de presença.
b. O projeto COMPLETO (incluindo todos os artefatos gerados durante sua execução) deverá ser submetido no AVA, como um zip contendo todo o código-fonte além de disponível em repositório no github com acesso concedido ao professor.
Os projetos serão corrigidos seguindo os seguintes critérios: critérios de avaliação.
Os projetos devem seguir o padrão de codificação Java documentado em (todos apresentam basicamente o mesmo padrão apresentado de formas distintas):
- (em en-US) Padrão Google: https://google.github.io/styleguide/javaguide.html
- (em PT-BT) Padrão de codificação: http://siep.ifpe.edu.br/anderson/blog/?page_id=950
- (em PT-BR) Padrão de codificação desenvolvido na UFPE: http://bit.ly/1iTOJYR
Os projetos devem seguir os seguintes fatores de qualidade:
- (em PT-BR): Fatores de qualidade de projetos Java: http://bit.ly/1nNUY8v
As versões parciais do sistema devem plenamente submetidas ao sistema de controle de versão escolhido até a data de entrega combinada, observando estritamente os seguintes aspectos:
Quaisquer outras ideias podem conversar diretamente com o professor.