Projeto de Investigação em Engenharia Informática: da Proposta ao Protótipo (Tese 2026)

A proposta de tese de Engenharia Informática tem uma armadilha específica que outras áreas não têm da mesma forma: é fácil escrever um documento tecnicamente impressionante que promete construir “uma plataforma que usa IA para otimizar X” sem nunca dizer o que exatamente vai ser avaliado, e como. Este guia mostra como escrever uma proposta de investigação que sobrevive à primeira reunião com o orientador — porque já responde à pergunta “como é que vai saber se funcionou?”.

1. O problema técnico (não uma área de interesse)

“Quero trabalhar com aprendizagem automática aplicada a deteção de anomalias” é uma área de interesse, não um problema. Um problema técnico nomeia o que ainda não funciona bem: “os métodos atuais de deteção de anomalias em séries temporais de sensores IoT têm elevada taxa de falsos positivos quando os dados têm sazonalidade múltipla, o que limita a sua aplicação prática em manutenção preditiva industrial.” A diferença é que o segundo já sugere, implicitamente, o que a sua contribuição vai fazer — e é sobre isso que o orientador vai perguntar primeiro. Para organizar a literatura recolhida enquanto delimita este problema, o comparativo de ferramentas de gestão bibliográfica ajuda a escolher entre Zotero, Mendeley e outras opções antes de a lista de referências crescer descontroladamente.

2. Estado da arte e a lacuna

Não precisa de uma revisão sistemática completa nesta fase — precisa de mapear as três a cinco abordagens mais relevantes ao seu problema, identificar o que cada uma resolve e o que não resolve, e nomear explicitamente a lacuna. Cite trabalhos de conferências e journals de referência da sua subárea (por exemplo, para sistemas distribuídos, OSDI e SOSP; para IA aplicada, NeurIPS e as respetivas conferências de domínio) — usar apenas artigos genéricos ou desatualizados é um sinal de revisão superficial que o orientador nota de imediato.

Como organizar a tabela de estado da arte

Uma forma eficaz de apresentar o estado da arte, mesmo nesta fase preliminar, é uma tabela comparativa com uma linha por trabalho relevante e colunas para: abordagem/técnica usada, dataset ou domínio de aplicação, métricas reportadas, e limitação principal face ao seu problema. Esta tabela cumpre duas funções: força-o a ler criticamente cada trabalho (em vez de o resumir superficialmente), e dá ao orientador uma visão imediata de onde a sua proposta se posiciona face ao que já existe. Evite tabelas com mais de seis ou sete linhas nesta fase — o objetivo é mostrar as referências mais relevantes, não uma revisão exaustiva.

3. Arquitetura ou abordagem proposta

Descreva, em alto nível e com um diagrama simples se possível, a arquitetura do sistema ou a abordagem algorítmica que pretende desenvolver — sem entrar em detalhes de implementação que ainda vão mudar. O objetivo desta secção é mostrar que já pensou na viabilidade técnica: que componentes existentes vai reutilizar (bibliotecas, frameworks, datasets públicos) e o que é novidade real no seu trabalho. Uma proposta que promete construir tudo de raiz sem justificar porque é que as soluções existentes não servem é um sinal de alerta para o orientador.

4. O plano de avaliação: a secção que mais falta

Esta é a secção mais frequentemente omitida ou tratada superficialmente, e a mais importante. Antes de começar a implementar, defina: que métricas vai usar (precisão, recall, latência, throughput, consumo de memória — conforme o problema), contra que baseline vai comparar (um método existente, não apenas “sem o seu sistema”), em que dataset ou ambiente de teste (público, quando existir um de referência na área, para permitir comparação), e que desenho experimental vai seguir (validação cruzada, teste em ambiente real, estudo de utilizadores). Uma tese de engenharia sem plano de avaliação definido à partida corre o risco de implementar primeiro e só depois descobrir que não é possível avaliar rigorosamente o que foi construído.

Exemplo trabalhado

Os dados abaixo são ilustrativos, construídos para mostrar a lógica de construção da proposta.

Problema: “Os sistemas de recomendação baseados em filtragem colaborativa têm desempenho degradado em cenários de arranque a frio (cold start) para novos utilizadores, com poucos estudos a avaliar abordagens híbridas em contexto de comércio eletrónico de moda em português.”

Abordagem proposta: um sistema híbrido que combina filtragem colaborativa com um modelo baseado em conteúdo (atributos do produto), com um mecanismo de transição gradual à medida que o histórico do utilizador cresce.

Plano de avaliação: comparação offline contra três baselines (filtragem colaborativa pura, baseada em conteúdo pura, e um modelo popular de referência), medindo precisão@k e recall@k num dataset público de e-commerce, complementada por um pequeno estudo de utilizadores (n=20) para avaliar a perceção subjetiva de relevância das recomendações em cenário de arranque a frio.

Comentário: repare que o plano de avaliação combina uma métrica objetiva (precisão@k, recall@k contra baselines definidos) com uma componente subjetiva (estudo de utilizadores) — esta combinação é frequentemente o que separa uma avaliação convincente de uma puramente técnica que não diz nada sobre a experiência real do utilizador.

5. Cronograma de implementação

Distribua o tempo disponível em fases claras: revisão do estado da arte e definição final da arquitetura (semanas iniciais), implementação do protótipo (a fase mais longa, com marcos intermédios verificáveis — por exemplo, “versão mínima funcional” antes de “versão completa com todas as funcionalidades”), execução da avaliação experimental, e redação. Reserve sempre tempo explícito para depuração e ajustes — a fase de implementação em Engenharia Informática atrasa quase sempre mais do que o previsto inicialmente, e um cronograma que não reconhece isso não convence o orientador. Para a lógica geral de construção de um cronograma de tese realista, aplicável também aqui, o artigo sobre o projeto de investigação de uma tese de Gestão mostra um exemplo de cronograma com margem explícita para atrasos que se transpõe diretamente para um projeto de engenharia.

Viabilidade computacional: o detalhe que se esquece

Antes de submeter a proposta, verifique se tem acesso real aos recursos computacionais que o seu plano exige — treino de modelos de grande escala pode exigir GPU dedicada, que nem sempre está disponível sem pedido prévio à instituição; testes com grandes volumes de dados podem exigir armazenamento e capacidade de processamento que o seu portátil pessoal não tem. Nomear explicitamente na proposta onde vai correr as experiências (cluster da universidade, serviços cloud com créditos académicos, hardware próprio) evita descobrir, a meio da implementação, que o plano de avaliação definido não é exequível com os recursos reais disponíveis.

Escolher orientador pela área de investigação real

Um erro comum é escolher orientador pela disponibilidade ou pela simpatia, sem verificar se a área de investigação ativa desse docente corresponde ao problema que pretende estudar. Antes de propor um tema, consulte as publicações recentes (últimos três a cinco anos) do potencial orientador — se o seu problema não se enquadra em nenhuma delas, é provável que o acompanhamento técnico seja mais superficial do que gostaria, mesmo que o orientador seja tecnicamente competente numa área adjacente. Um orientador ativo na sua subárea concreta também facilita o acesso a recursos (datasets, contactos, acesso computacional) que muitas vezes não estão disponíveis de forma genérica.

Erros que mais atrasam a aprovação

Três erros recorrentes: primeiro, um âmbito demasiado ambicioso para o tempo de uma tese de mestrado — prometer construir um sistema completo de produção em vez de um protótipo que valida a ideia central; segundo, ausência de baseline claro na avaliação, o que torna impossível argumentar que a solução proposta é melhor do que o que já existe; terceiro, escolher uma tecnologia ou framework pela novidade em vez de pela adequação ao problema, o que a defesa da tese vai questionar diretamente. Para as perguntas específicas que o júri costuma fazer sobre estas escolhas na defesa, veja o artigo sobre perguntas do júri numa defesa de tese de Engenharia Informática, e para a estrutura completa do capítulo de implementação e avaliação que sucede a esta proposta, veja o guia sobre tese de mestrado em Engenharia Informática.

Perguntas Frequentes