Relatório De Aula Prática - Projeto De Software

O que realmente compõe um relatório de prática de projeto de software

Você já pegou qualquer relatório desses para corrigir e em cinco minutos sabe se o aluno entendeu ou só preencheu campos. A estrutura é sempre a mesma, mas o que separa um relatório bom de um ruim não é a formatação, é a capacidade de mostrar o processo, não apenas o produto final. Eu corriji relatórios durante anos e posso te dizer que a maioria dos alunos comete os mesmos erros desde o primeiro dia. O relatório de aula prática em projeto de software serve para documentar o desenvolvimento de um sistema durante um período letivo. Ele precisa cobrir requisitos, arquitetura, implementação, testes e avaliação. Mas a parte mais importante, e a que quase todos negligenciam, é a seção de decisões de design. É aí que o avaliador consegue ver se o aluno pensou ou só copiou um tutorial.

relatório de aula prática - projeto de software

Na prática, você vai construir esse documento com as seguintes seções obrigatórias na maioria das universidades brasileiras: Capa e identificação: título do projeto, nome da disciplina, nome do professor, nomes e RA dos integrantes, data de entrega. Parece óbvio, mas eu vi relatório sem o nome de pelo menos um integrante três vezes em um único semestre. Isso gera problema administrativo na hora do lanço de nota. Resumo ejecutivo: três a cinco linhas descrevendo o que foi construído, para quê e com quais tecnologias. Nada de encher linguiça. Se você precisar de mais de cinco linhas, provavelmente não sabe exatamente o que fez.

Introdução e contexto: qual é o problema que o software resolve. Não adianta falar que vai criar um sistema de gestão porque gestão é importante. Qual gestão? De quê? Para quem? Especificar o domínio é essencial. Eu vi um grupo que descreveu o sistema como "um aplicativo para organizar tarefas" e levou punição na avaliação porque não conseguiu delimitar se era para uso pessoal, empresarial ou educacional. Requisitos: divida em funcionais e não funcionais. Requisitos funcionais descrevem o que o sistema faz. Requisitos não funcionais descrevem como o sistema se comporta em termos de desempenho, segurança, usabilidade, disponibilidade. Um erro comum é transformar uma escolha tecnológica em requisito funcional. "O sistema deve ser feito em Java" não é requisito funcional, é restrição de implementação. Arquitetura e design: aqui entra a parte que mais diferencia um relatório competente de um amador. Mostre diagramas de classe, diagrama de sequência dos casos de uso principais, e justifique a escolha arquitetural. Se escolheu MVC, explique por que MVC e não alguma outra abordagem. Se escolheu uma arquitetura monolítica em vez de microsserviços, diga o motivo. A justificativa vale mais que a escolha em si.

Implementação: descreva os componentes principais, a estrutura de diretórios, dependências externas e frameworks utilizados. Inclua trechos de código relevantes, mas apenas os que ilustram decisões importantes. Colocar código inteiro de todas as classes é sinal de falta de critério. Um trecho de meia tela bem comentado vale mais que trinta telas de código sem explicação. Testes: apresente casos de teste cobrindo os requisitos funcionais. Inclua screenshots dos testes passando e, se possível, mencione a cobertura. Ferramentas como JUnit, pytest ou Selenium são comuns, mas o relatório precisa mostrar que o teste foi planejado antes da implementação, não Depois. Teste depois de implementar é registro, não garantia de qualidade. Resultados e discussão: compare o esperado com o obtido. O que funcionou, o que não funcionou, o que ficou para versão futura. Se algo deu errado, conte. Relatório que só mostra acertos parece fabricado. Eu recebi um relatório no qual o grupo afirmou que "todos os testes passaram na primeira tentativa" e fiquei desconfiado. Na defesa oral, descobriram que tinham refeito os testes duas vezes porque um framework estava configurado erroneamente. Se tivessem anotado isso no relatório, teriam ganho pontos por transparência.

Conclusão: brevemente, retome os objetivos e diga se foram alcançados. Não repita o resumo. A conclusão deve conter uma reflexão sobre o aprendizado técnico e processual do grupo. Referências: cite tudo o que usar. Documentação oficial, artigos, livros, tutoriais. Se copiou uma estrutura de código de algum lugar, cite. Plágio de código é motivo de reprovação direta em praticamente todas as instituições.

Pegadinhas que eu vejo todo semestre

Uma das armadilhas mais frequentes é a confusão entre escopo do projeto e escopo do relatório. O projeto pode ser grande, mas o relatório não precisa ser enorme. Relatórios de cinquenta páginas são comuns e quase sempre ruins. O tamanho ideal fica entre quinze e vinte e cinco páginas de conteúdo real, excluindo capa e anexos. Qualquer coisa além disso indica que o aluno não conseguiu filtrar o que é relevante. Outro erro crônico é a ausência de referências cruzadas entre as seções. Se você mencionou um requisito na seção dois, ele precisa aparecer nos testes na seção seis. Eu costumo verificar isso rapidamente percorrendo o relatório procurando os números dos requisitos e conferindo se cada um tem um caso de teste correspondente. Quando um requisito não tem teste, marco ponto negativo. Quando um teste não mapeia para nenhum requisito, marco outro ponto negativo. Essa verificação leva dois minutos e revela problemas sérios de planejamento. A seção de riscos também é negligenciada. Um relatório maduro lista os riscos identificados durante o projeto e como foram mitigados. Riscos técnicos, de prazo, de equipe. Se o grupo enfrentou uma dependência que caiu ou um membro saiu no meio do semestre, Anotar isso mostra amadurecimento. Anotar e não ter solução mostra ingenuidade. As duas coisas são melhores do que fingir que não aconteceram.

Sobre ferramentas, a maioria dos grupos usa Git para versionamento e GitHub ou GitLab para hospedar o repositório. O relatório deve mencionar o repositório e o link. Além disso, ferramentas de diagramação como Draw.io, PlantUML ou Mermaid facilitam a criação de diagramas consistentes. Evite fazer diagramas no Word ou PowerPoint, a menos que o projeto seja extremamente simples. Diagramas desenhados em editores de desenho genérico parecem amadores e frequentemente têm inconsistências que um gerador automático evitaria.

Um problema real que eu encontrei

No segundo semestre de 2023, um grupo entregou um relatório impecavelmente formatado com todos os diagramas bonitos e código limpo. A arquitetura era sólida. Na hora da apresentação, perguntei sobre uma decisão específica no módulo de autenticação e o integrante responsável disse que tinha sido escolha do colega que saiu do grupo. O relatório não registrava quem era responsável por qual módulo. Faltava uma tabela de distribução de tarefas assinada por todos. Como não havia registro documental da divisão, não dava para validar a contribuição individual. Cortei vinte por cento da nota de cada membro porque a ausência dessa informação impedia a aferição justa do trabalho de cada um. No semestre seguinte, exigi essa tabela como parte obrigatória do relatório e o problema desapareceu. O formato padrão de relatório funciona bem para projetos de semester único com grupos de três a cinco pessoas e prazos bem definidos. Ele sequestra quando o projeto é aberto, com contribuições não estruturadas ou quando a disciplina mistura múltiplas etapas com entregas parciais. Nesse caso, um diário de bordo atualizado semana a semana produz um relatório muito mais rico do que tentar reconstruir tudo de uma só vez no final. Eu recomendo que grupos nesse cenário mantenham um documento vivo, mesmo que simples, com datas, decisões, problemas e resoluções. Na hora de montar o relatório final, você já terá sessenta por cento do conteúdo pronto. Também há situações em que o relatório tradicional não capta o valor do trabalho. Projetos que envolvem muita pesquisa, prototipagem rápida com descarte de ideias, ou experimentação com tecnologias novas podem ter produzido mais aprendizado do que o artefato final sugere. Nessas ocasiões, inclua uma seção de aprendizados não técnicos ou um apêndice com protótipos descartados e o raciocínio por trás do descarte. Isso demonstra honestidade intelectual e dá ao avaliador material para uma avaliação mais justa.

Para entregar, verifique o edital da sua disciplina antes de começar a escrever. Algumas professors pedem ABNT, outros pedem um formato próprio. Alguns aceitam PDF, outros exigem Word editável. Alguns pedem relatório individual, outros coletivo. Seguir a especificação correta evita perda de pontos que nada tem a ver com o conteúdo. Se quiser um template pronto para começar, a maioria dos departamentos de computação mantém um template no repositório da disciplina ou no SIGAA. Não reinvente a estrutura. Use o template oficial e foque seu esforço no conteúdo. Um relatório bem escrito com formatação simples nota mais do que um relatório mal escrito com formatação impecável.