Instruções sobre Projeto Final

O projeto final tem como objetivo desenvolver a habilidade de programação orientada a objetos do aluno e expor uma oportunidade para o mesmo aplicar os conceitos adquiridos no curso, bem como se familiar com os detalhes e nuâncias da linguagem de programação utilizada.

Cada grupo deve desenvolver uma aplicação utilizando os conceitos de orientação a objetos, que atenda a algum objetivo de interesse do grupo. Exemplos: um jogo, uma aplicação OpenSocial para o Orkut, um gerenciador de finanças…

Grupos

Os alunos irão se dividir em grupos de 3 alunos, para a execução dos projetos. Além de propiciar interação entre os alunos, a divisão em grupos auxiliará os alunos a se ambientarem com a dinâmica e com as ferramentas para desenvolvimento colaborativo de software, uma realidade em qualquer atividade não-trivial de desenvolvimento de software.

2 ou mais grupos de 3 alunos poderão se unir para fazer um projeto mais amplo/ambicioso, no entanto as fronteiras de responsabilidade de cada grupo deverão ser bem definidas (ex.: numa aplicação cliente/servidor um fica responsável pelo cliente, outro pelo servidor). Os relatórios de cada grupo deverão ser fornecidos separadamente.

Todos os 3 integrantes do grupo deverão participar ativamente do desenvolvimento do software do projeto. É normal e esperado que haja uma divisão de tarefas dentro do grupo, mas esta divisão deve ser feita de forma que todos sejam responsáveis por uma parcela do código desenvolvido. Uma divisão de tarefas do tipo "2 fazem o código, 1 o relatório", não será aceita, e será interpretada como falta de DC (e logicamente passível desconto da nota dos envolvidos). Isto será verificado através dos logs de commit do SVN (ver abaixo).

Tema

Os temas serão livres, para estimular a criatividade e surgimento de aplicações úteis e interessantes. No entanto, deverão ser aprovados (após a entrega do documento de definição de tema) pelos professores. No entanto, os requisitos especificados abaixo devem ser atendidos pela aplicação, qualquer que seja o tema.

Requisitos

  • Deverá utilizar-se de algum tipo de conexão remota, preferencialmente via internet. É válido também o uso de aplicações web.
  • A linguagem utilizada deverá ser Orientada a Objetos (não restritas as utilizadas no curso) e o software deverá se utilizar de todos os recursos de orientação a objetos da mesma1.
    • Javascript é aceitável, mas deve-se utilizar o framework Prototype (ou simular), para que a linguagem tenha um comportamento OO tradicional.
  • Deverá utilizar pelo menos dois padrões de projeto dentre os abordados no curso (veja o cronograma).
    • Isto deverá ser documentado no relatório. O uso do padrão deve ser justificado ("por que estava nos requisitos" não é justificativa).
    • Não vale dizer que utilizou o padrão só porque fez uso de uma biblioteca ou API que faz o uso do padrão (ex.: Fiz uma GUI utilizando Java Swing e portanto utilizei o padrão composite). Os padrões devem ter sido aplicados nas classes desenvolvidas no seu programa.

Bonus

Receberão uma bonificação de nota ( nota x (1 + bônus) ) os projetos que tiverem as seguintes características.

  • Forem desenvolvidos para alguma plataforma móvel (ex.: Iphone, Google Android, JavaME), rodando em um emulador.
  • Forem desenvolvidos para a plataforma OpenSocial.
  • Fizerem o uso de Webservices (APIs do Google, Yahoo, etc) de forma que seja essencial ao funcionamento da aplicação2.
  • Utilizarem a linguagem Smalltalk (ou alguma outra linguagem substancialmente obscura/inovadora).

Não cumulativo. O bônus pode variar de 0.1 a 0.3 dependendo da extensão e qualidade do que for feito.

Código

O código da sua aplicação deverá ser disponibilizado em uma licença de código aberto. Se nenhuma licença for especificada pelo aluno (atraves de um arquivo license.txt na raiz do código da aplicação), o uso da licença MIT será inferido.

O código deverá ser disponibilizado num repositório de controle de versão aberto. Deverá ser utilizado o repositório Subversion do google code. Caso os membros desejem utilizar outro repositório ou software de controle de versão (como GIT, Mercurial, etc), deverão pedir autorização previamente e explicar a motivação/interesse.

O repositório SVN deverá ser utilizado durante todo desenvolvimento da aplicação. Consideraremos que o que acontece no repositório é o que aconteceu no desenvolvimento da aplicação. Ex: se todo código foi enviado ao repositório no último dia antes da entrega do trabalho, consideraremos que a aplicação foi desenvolvida de um dia para o outro (e a nota irá refletir esta crença).

Os logs de commit do subversion serão analisados e serão utilizados para determinar se algum dos 3 integrantes do grupo não participou ativamente do desenvolvimento da aplicação. Portanto, cada membro do grupo deverá estar cadastrado como "owner" do projeto no google code, para possuir "commit access" ao repositório, e deverá utilizar seu login para fazer commits de suas alterações no código.

Relatórios

Serão solicitados 3 documentos sobre o projeto. Todos eles deverão ser redigidos neste Wiki. Arquivos anexos (imagens, etc), também deverão ser postados no Wiki.

Definição do Tema/Grupo

O primeiro documento será para definir o grupo e qual será o tema/aplicação a ser desenvolvida. Espera-se que este relatório tenha cerca de 1 página de extensão. Este relatório será aprovado pelos professores da disciplina. Na conclusão do projeto, será utilizado para determinar se os objetivos traçados inicialmente foram estabelecidos.

O que não pode faltar:

  • Descrição funcional do software que será desenvolvido.
  • Descrição das linguagens, tecnologias e frameworks que serão utilizados.
  • Endereço do projeto do grupo no google code (já cadastrado e com os 3 integrantes registrados).

Relatórios Parcial

O segundo documento deverá descrever a experiência do grupo até então e estimar (percentualmente) quanto da aplicação já foi concluída, a divisão de tarefas (tanto do trabalho já realizado quanto do por realizar) entre os membros e alertar sobre possíveis mudanças de escopo em relação aos requisitos traçados originalmente. Deverá conter um diagrama UML de classes com o Design esperado da aplicação. Espera-se que este relatório tenha cerca de 2 páginas de extensão.

O que não pode faltar:

  • Mudanças em relação ao que foi traçado originalmente. Estas mudanças não podem desconfigurar o que foi planejado originalmente nem simplificar em demasiado a aplicação.
  • Descrição do que já foi feito (e por quem) vs. o que falta fazer.
  • Diagrama de classe UML
  • Descrição de quais padrões se deseja utilizar

Relatório Final

O último relatório deve ser mais completo e descrever todas as etapas de desenvolvimento do software (planejamento, modelagem, codificação, testes, etc). Espera-se que este relatório tenha cerca de 10 páginas de extensão. Encheção de lingüiça não será bem vista.

O que não pode faltar:

  • Tudo que estava presente nos documentos anteriores, mas refletindo o software final.
  • Descrição passo-a-passo de como compilar o seu software, incluindo a instalação de software de suporte (ferramentas, compiladores) requeridos.
  • Diagrama de classes completo da sua aplicação, explicitando a utilização dos padrões solicitados
  • Um relatório do kablame3 (ou ferramenta semelhante) mostrando quantas linhas de código cada membro do grupo escreveu.

Avaliação

Estes serão os critérios de avaliação do projeto. Tem mera função de orientação, podendo ser modificados sem aviso prévio. A nota final é de critério exclusivo do professor.

Geral:

  • Implementação (70%)
    • Design orientado a objetos da aplicação
    • Boa aplicação dos padrões
    • Qualidade do código
    • Estabilidade
    • "Valor agregado" da aplicação desenvolvida
  • Relatório e Apresentação (30%)
    • Completude (em relação ao que foi exigido)
    • Documentação dos padrões
    • Análise Crítica

Individual:

  • Participação no projeto
  • Conhecimento sobre o projeto (demonstrado na apresentação)
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License