Trabalho de Conclusão de Curso
Temido por 10 em 10 alunos de último ano
Janeiro 12, 2016No ano de 2015 tive a oportunidade de trabalhar pela primeira vez com a disciplina de Trabalho de Conclusão de Curso. Eram dois horários semanais onde tínhamos simplesmente que gerenciar o trabalho de desenvolvimento dos alunos.
Na divisão de disciplinas na instituição que trabalho os alunos já estudam metodologia científica em outro momento e já tem também conhecimento de linguagens de programação, banco de dados, engenharia de software, etc suficientes para desenvolvimento de um aplicativo.
O TCC deve ser desenvolvido individualmente ou em duplas e um software deve ser construído usando qualquer linguagem de programação, de preferência nas que foram estudadas durante o curso.
Era a primeira vez que trabalhava a disciplina mas já havia acompanhado historicamente outros alunos, inclusive orientandos, e a história parecia sempre se repetir. Tudo ficando para a última hora, trabalhos atropelados, entregas pela metade. Pedidos de concessões, dilações de prazo, etc.
Buscando uma forma de minimizar esse tipo de problema no primeiro dia de aula já havia montado todo o planejamento com todas as entregas a serem feitas durante todo o ano com datas o que era esperado para cada um desses momentos. Até a data e hora da apresentação da banca parcial (no meio do ano) e banca final já foram passados nesse primeiro dia.
A ideia era mostrar cada passo menor e não o trabalho como um todo, era "dividir para conquistar". Mas por mais que preparemos e orientemos o aluno precisa se envolver. Não é questão de motivação mas sim disciplina, empenho e comprometimento que cada um deve ter.
Alguns problema se mostraram da turma inicial esperada. Dois alunos simplesmente não apareceram em nenhuma aula. Um deles me enviou um email no final de abril perguntando o dia das orientações e que o software estava "praticamente pronto" porém nunca mais apareceu.
Acabamos ficando com 4 trabalhos diferentes cada um composto por dois alunos. Uma das duplas infelizmente desistiu logo após a entrega parcial. Os outros três trabalhos seguiram com as demais etapas, apresentaram e foram aprovados.
Alguns problemas que ocorreram durante o ano passado e talvez possa servir como um guia de cuidados a serem tomados:
Uma dupla na entrega parcial se confundiu com acrônimos e acabou falando conceitos totalmente distorcidos ao citar EAD (Educação a Distância). Dica: Apresente sozinho, em frente ao espelho, repasse os tópicos que serão falados e esteja preparado para o dia. Cara, por favor não leia! Use tópicos como orientação.
Um dos participantes não soube explicar o que seu software fazia. Escolheu uma área complexa e não conseguiu explicar. Dica: Não existe essa história de que "eu sei o que é mas não sei explicar". Você deve ser capaz de resumir o que seu programa faz em 1 frase. Se não conseguir tem alguma coisa errada.
Usar tecnologia ultrapassada. Eu trabalhei muitos anos com Visual Basic 6 e gostava demais na época em que desenvolvi com essa linguagem. Creio que foi quando sedimentei meu conhecimento de programação. Hoje você não deve usar VB6 para desenvolver um trabalho de conclusão de curso. Por mais que seja uma ferramenta bacana, pense que terá uma banca te avaliando.
Comentários em códigos. Você irá esquecer o que codificou e porque usou determinada estrutura. Use e abuse de comentários no seu código. Documente e saiba o que faz cada parte. Pense que seu código será lido antes e durante a apresentação.
Hoje temos UML e seus diagramas devem estar consistentes. Saiba o que cada diagrama faz, quando e como usá-los para documentar corretamente.
Programadores antigos não dão bola para UML mas se orientam muito mais pelo Diagrama Entidade Relacionamento ou até mesmo o esquema físico das tabelas. Saiba o que cada tabela faz e não cometa erros grosseiros de normalização. Aqui de novo: Seu banco de dados será analisado antes e durante a apresentação.
Já falei em outro artigo sobre "eu não gosto de programar" então não vou me alongar aqui, mas os dois integrantes do grupo precisam conhecer o código e saber comentar cada parte.
Por quê você programou assim? Por quê não usou o framework X que faz Y de forma mais eficiente? Tenha vivência na linguagem, converse com programaores e leia artigos para se ambientar mais na ferramenta que usará.
Ainda há espaço para aplicativos desktop, claro, mas dê preferência a aplicativos Web.
Não compile seu código na hora de apresentar, óbvio. Compile e teste tudo um dia antes. Tá eu sei que isso é óbvio mas o pessoal insiste em corrigir "só um errinho que tá acontecendo" na hora de apresentar.
Leve seu notebook com tudo funcionando. Talvez falte alguma biblioteca ou seja uma versão diferente no micro do laboratório. Leve seu ambiente com você e use-o para apresentar pois não será só uma apresentação em powerpoint mas um software rodando.
Já vi alunos 15 dias antes da apresentação ainda com problemas no funcionamento do CRUD do sistema. Se antecipe, comece antes. Sua primeira tarefa de gerenciamento de projetos (envolvendo gerenciamento de tempo, recursos, etc) é aqui no seu TCC. Leve isso a sério
Tem muito mais coisas para conversarmos sobre isso e apenas escrevi rapidamente alguns pontos que lembrei. Vamos esticar mais esse papo.
Cover image credit: http://unsplash.com/@carlheyerdahl