INF2102 Projeto Final de Programação
É objetivo do projeto final de programação averiguar se o aluno sabe empregar técnicas eficazes para especificar, projetar, desenvolver, controlar a qualidade e documentar programas, que tenham um nível de complexidade pelo menos mediano. Os programas devem ser confiáveis, úteis e utilizáveis e devem possuir elevada qualidade de engenharia.
O resultado do projeto de programação pode ser qualquer programa que sirva para demonstrar a capacidade do aluno de desenvolver e testar racionalmente programas satisfazendo os objetivos acima.
O programa será útil na medida que realize um serviço de interesse a alguém que não seja exclusivamente o aluno. A utilidade do programa será avaliada pelo professor orientador (ver mais adiante). Sugere-se que o trabalho tenha alguma relação com a dissertação de mestrado ou tese de doutorado a ser elaborada. São exemplos de aplicações:
aplicações para engenharia
componentes de compiladores
ferramentas de apoio ao desenvolvimento de software
frameworks
interfaces gráficas animadas
jogos eletrônicos
produtos de software
programas re-engenheirados
sistemas “e-qualquer coisa”
sistemas de supervisão e controle
sistemas web
transformadores, validadores, formatadores de representações
A complexidade envolve tamanho e natureza do problema resolvido pelo programa. Cabe ao professor orientador (ver mais adiante) assegurar a satisfação deste requisito.
A garantia de qualidade depende do processo de especificação, projeto, programação e teste empregado. Depende ainda da forma da solução adotada (programação lógica, procedural, dirigida por tabela, etc.). No entanto, a documentação entregue ao final do projeto deve deixar nenhuma dúvida quanto ao fato de ter sido empregado um processo de desenvolvimento racional, bem como ao fato que tenha sido empregado um processo de controle de qualidade (teste, inspeção) sistemático. Ideal seria ter sido utilizada alguma forma de teste automatizado (JUnit, CPPUnit e similares).
A linguagem de programação utilizada pode ser qualquer uma (ex. Lisp, Modula, C, C++, Lua, Java, Prolog etc.). Também pode ser qualquer uma a plataforma utilizada (ex. DOS, Windows, Mac, Unix, VM, etc.). Sendo de interesse do aluno, o trabalho pode ser desenvolvido utilizando alguma ferramenta CASE.
Antes de mais nada encontre um professor orientador do projeto de programação. Este é necessariamente um professor do Departamento de Informática da PUC-Rio. Não precisa ser o coordenador da disciplina.
Defina, junto com o professor orientador, o objetivo do trabalho. Isto deve ser feito antes do início do semestre.
Envie ao professor coordenador da disciplina, prof. Carlos José P. de Lucena, até o dia 26/outubro/2007, uma mensagem, contendo:
o número de matrícula e o nome do aluno
o nome do professor orientador
o nome do projeto
um resumo (um parágrafo) descrevendo o objetivo do projeto
O título deve ser INF2102-Proposta-NomeAluno
obviamente a parte NomeAluno deve ser substituída pelo respectivo nome, sem utilizar caracteres em branco ou diacríticos (acentuados).
Entregue ao coordenador da disciplina, até o dia 10/dezembro/2007:
1. uma folha contendo (ver apêndice):
o número de matrícula e o nome do aluno
o nome do professor orientador
a avaliação do trabalho feita pelo professor orientador (tipicamente um parágrafo de texto). Esta avaliação deve dizer se:
o programa satisfaz os requisitos de complexidade assumidos para projetos finais de programação
o programa é confiável e utilizável
o programa atende aos objetivos funcionais traçados se os testes foram abrangentes e satisfatórios
eventuais comentários a respeito do trabalho
assinatura do professor orientador
2. a documentação final do projeto. Pode ser entregue em CD. Se entregue em CD não será necessário entregar a documentação impressa. Composta por:
mini-acompanhamento da execução: seqüência de tarefas de desenvolvimento utilizadas junto com estatísticas de tempo e esforço por tarefa.
especificação do programa
objetivos, requisitos
diagramas de especificação, por exemplo use-cases e diagrams de seqüência.
projeto modular do programa
critérios de projeto utilizados
diagramas de arquitetura e/ou segmentação do programa, por exemplo UML.
organização do programa (componentes, módulos, classes,...), por exemplo diagramas de classe UML.
diagramas de organização dos dados, por exemplo diagramas de modelagem de dados, ou entidade e relacionamentos.
código fonte cuidadosamente comentado
comentários cabeçalho de módulos, classes e funções
comentários de controle de versão
assertivas para dados e procedimentos
pseudo instruções
procure estabelecer e/ou adotar padrões de programação. Os apêndices do livro Staa, A.v.; Programação Modular, Campus 2000; contêm uma extensa lista de padrões de programação que pode servir de exemplo para a adaptação às características específicas do trabalho.
roteiro de teste efetuado, composto de:
critérios de teste utilizado
descrição dos casos teste
na medida do possível procure utilizar testes automatizados
scripts de teste automatizado
logs gerados pelo teste automatizado
documentação para o usuário
O formato da documentação técnica varia em função da linguagem de programação utilizada. Não obstante, o programa deverá ser especificado e projetado antes de ser implementado. Ou seja, a organização e a composição do programa deverão estar definidas antes de iniciar a codificação. Da mesma forma os testes dependem da linguagem e do ambiente de execução. Apesar disto, deve ser projetado um conjunto de experimentos sistemáticos que sirvam para atestar que o programa atinge os objetivos a que se destina e que é confiável.
Não serão aceitos trabalhos sem a folha de avaliação produzida pelo professor orientador.
As notas máximas serão:
10 trabalho satisfatório e entregue no prazo, ou seja até, no máximo, 10/dezembro/2007
8 trabalho satisfatório e entregue após a matrícula do semestre subseqüente e antes da data limite imposta pela PUC: 28/janeiro/2008.
zero se não for entregue até no máximo dia: 28/janeiro/2008. Esta data está em sintonia com a data limite estabelecida pela PUC-Rio para preenchimento de graus IN do semestre anterior.
Atentem para a regra da CCPG: O aluno tem 60 dias a partir do final do semestre (Término das atividades acadêmicas do semestre) para completar o incompleto. Como são necessárias as avaliações dos professores orientador e coordenador, a data limite 28/janeiro/2008 é estabelecida de modo que se tenha folga para as avaliações necessárias.
Se você acha que não vai conseguir terminar no prazo, cancele a disciplina. Não se matricule em Projeto Final de Programação sem saber quem será o orientador e qual será o trabalho!
Trabalhos que não forem entregues até 10/dezembro/2007, recebem automaticamente IN (incompleto). Trabalhos que não forem entregues até a 28/janeiro/2008 recebem automaticamente zero, com todas as implicações que isto possa ter, como, por exemplo, jubilamento por falta de média no período.
Causam a perda de pontos:
entrega atrasada. Para evitar a perda de pontos só se matricule depois que souber quem é o orientador, qual é o trabalho, e se você tem condições de terminar o trabalho no semestre. Afinal saber planejar faz parte da vida profissional do Informático... Se durante o semestre você perceber que não conseguirá terminar, cancele a disciplina.
inexistência de avaliação feita pelo orientador, o trabalho não será aceito sem a avaliação do professor.
inexistência de especificação.
inexistência de projeto.
inexistência de um roteiro de teste para fins de teste sistemático. Deve estar explicitado o método de teste utilizado. Dê preferência a testes automatizados.
inexistência de evidência de que foram realizados testes segundo o roteiro. Procure produzir um laudo de teste. O teste automatizado deve produzir logs.
inexistência de documentação para o usuário.
código mal organizado e/ou mal comentado.
1