Perguntas do Júri numa Defesa de Tese de Engenharia Informática: Protótipo, Avaliação e Código (2026)

A arguição de uma tese de Engenharia Informática tem uma camada própria que não aparece numa tese teórica: o júri testa se o candidato sabe justificar as decisões técnicas do protótipo desenvolvido, se a avaliação experimental é rigorosa, e se compreende os limites do que construiu — incluindo perguntas que só surgem quando há uma demonstração ao vivo. Este guia mapeia essas perguntas específicas, além da mecânica geral de qualquer defesa.

Para a estrutura geral de uma arguição — categorias de perguntas, frameworks de resposta — o guia completo sobre arguição na defesa de mestrado cobre o que é comum a qualquer área. O que se segue aqui é a camada que a Engenharia Informática acrescenta.

Perguntas sobre decisões de arquitetura e tecnologia

É praticamente garantido que o júri pergunte porque escolheu uma determinada linguagem, framework, base de dados ou arquitetura, e não uma alternativa concorrente. Uma resposta fraca justifica a escolha só por familiaridade pessoal («já conhecia esta linguagem»); uma resposta forte argumenta com base em requisitos concretos do problema — desempenho necessário, ecossistema de bibliotecas disponíveis, restrições de implantação, ou compatibilidade com sistemas existentes que o protótipo precisava de integrar. Nomear explicitamente a alternativa mais próxima e explicar em que critério ela perdia é o que separa uma resposta de engenharia de uma resposta de conveniência.

Perguntas sobre a avaliação experimental

Uma tese de Engenharia Informática que afirma que o sistema desenvolvido «funciona bem» sem uma avaliação quantitativa rigorosa é um dos alvos mais previsíveis de perguntas do júri. Espere ser questionado sobre o baseline de comparação — contra que sistema ou abordagem alternativa os resultados foram comparados — e sobre a validade das métricas escolhidas para o problema em causa. Um erro comum é reportar apenas uma métrica favorável (por exemplo, tempo de execução) e omitir outras relevantes (por exemplo, uso de memória ou precisão), o que o júri interpreta como seleção enviesada de resultados. Declarar todas as métricas relevantes, mesmo as que não favorecem o sistema desenvolvido, é o que sustenta a credibilidade da avaliação.

Perguntas sobre limitações de escalabilidade e segurança

Um protótipo académico é, quase sempre, testado numa escala menor do que um sistema em produção real, e o júri sabe disso — a pergunta não é uma armadilha, é um teste de honestidade técnica. Uma resposta forte não promete que o sistema escalaria sem problemas «porque a arquitetura é modular», mas identifica com precisão onde o gargalo mais provável estaria — uma consulta à base de dados que não foi otimizada, um componente que não foi desenhado para execução distribuída — e explica que mudanças concretas seriam necessárias para lá chegar. O mesmo se aplica a segurança: nomear as vulnerabilidades mais óbvias para o tipo de sistema (injeção, autenticação, exposição de dados) e declarar honestamente o que ficou fora do âmbito é mais defensável do que afirmar que o sistema é seguro sem ter feito uma análise de segurança formal.

Um exemplo completo: sistema de recomendação para uma plataforma de e-learning

Para tornar a lógica concreta, veja como estes elementos se preparam numa tese sobre um sistema de recomendação de conteúdos para uma plataforma de e-learning.

Escolha tecnológica: algoritmo de filtragem colaborativa em vez de um modelo baseado em conteúdo, justificado pela disponibilidade de dados de interação de utilizadores mas escassez de metadados estruturados sobre os conteúdos.

Avaliação: comparação contra dois baselines — recomendação aleatória e recomendação por popularidade — usando métricas de precisão e cobertura (coverage), não apenas uma métrica isolada.

Limitação de escalabilidade declarada: o modelo foi testado com um conjunto de dados de dimensão moderada; o tempo de recálculo das recomendações cresce de forma que não foi caracterizada para volumes de utilizadores dez vezes maiores, o que é assumido explicitamente como limitação.

Trabalho relacionado: a contribuição é situada face a sistemas de recomendação já publicados para contextos educacionais, com a diferença específica (por exemplo, a combinação de dois sinais de interação pouco usados em conjunto) claramente nomeada.

A demonstração ao vivo do protótipo: o que pode correr mal

Quando a defesa inclui uma demonstração ao vivo do sistema, o risco técnico soma-se ao risco de argumentação. Ter um plano B testado — uma gravação de vídeo da demonstração a funcionar, preparada com antecedência — é a prática mais recomendada para o caso de falha de rede, de dependência externa indisponível, ou de qualquer imprevisto técnico no dia. Testar a demonstração no equipamento e na rede exatos que vão ser usados no dia da defesa, e não apenas no computador de desenvolvimento habitual, evita a maior parte das surpresas técnicas evitáveis. Se algo correr mal ao vivo, é mais eficaz mudar calmamente para o plano B do que tentar depurar o problema em tempo real perante o júri. Chegar mais cedo ao local da defesa para testar a ligação à rede e o projetor, quando a demonstração depende de acesso à internet ou a um servidor remoto, elimina uma das causas mais comuns de falha técnica no próprio dia.

A ligação entre a estrutura da tese e a arguição

As perguntas mais difíceis da arguição raramente surgem do nada — nascem quase sempre dos pontos que a própria tese deixou pouco desenvolvidos na secção de avaliação experimental ou de trabalho relacionado. Reler o capítulo de avaliação com os olhos de um revisor cético, perguntando «que dado eu, como leitor, gostaria de ver e não vejo aqui», é um exercício mais eficaz do que tentar adivinhar perguntas ao acaso. O guia sobre a estrutura da tese de Mestrado em Engenharia Informática detalha o que cada secção do capítulo de avaliação deve conter — e cada lacuna nessa estrutura é, tipicamente, uma pergunta do júri à espera de acontecer.

Perguntas sobre reprodutibilidade e disponibilização do código

Cada vez mais júris de Engenharia Informática perguntam diretamente se o código do protótipo está disponível para consulta ou reprodução — num repositório público ou entregue como anexo — e se os passos para reproduzir os resultados reportados estão documentados. Não ter uma resposta clara para esta pergunta, num campo onde a reprodutibilidade é cada vez mais valorizada, é visto como uma lacuna de rigor científico, independentemente da qualidade do sistema construído. Preparar um ficheiro README simples com os passos de instalação e execução, mesmo que o código não seja publicado abertamente por razões de propriedade intelectual, é uma prática que resolve esta pergunta antes de ela ser feita.

Ajustar as expectativas ao grau académico

Numa tese ou projeto final de licenciatura, o júri tende a focar-se em saber se o protótipo cumpre os requisitos definidos e se as escolhas tecnológicas básicas são razoáveis, sem esperar uma avaliação experimental muito sofisticada. Numa dissertação de mestrado, já se espera uma avaliação com baseline de comparação e métricas bem escolhidas, tal como consciência clara das limitações de escalabilidade e segurança. Numa tese de doutoramento, o júri tende a ir mais longe e a perguntar qual a contribuição científica do trabalho para além da engenharia — que problema ainda em aberto na literatura o sistema resolve, e como essa contribuição poderia ser generalizada além do protótipo específico construído.

Erros comuns a evitar

• Justificar escolhas tecnológicas só por familiaridade pessoal. O júri espera critérios técnicos, não conveniência.
• Reportar apenas as métricas de avaliação favoráveis. É lido como seleção enviesada de resultados.
• Prometer escalabilidade sem a ter testado ou analisado. Uma limitação declarada com honestidade é mais defensável do que uma promessa não verificada.
• Não ter um plano B para a demonstração ao vivo. Uma falha técnica não preparada custa mais tempo e credibilidade do que a maioria das perguntas difíceis.
• Não situar claramente a contribuição face ao trabalho relacionado. Uma lista de funcionalidades não é o mesmo que uma contribuição específica e nomeada.
• Não ter uma resposta preparada sobre reprodutibilidade do código. É uma das perguntas mais previsíveis em júris atentos a boas práticas de investigação.

Perguntas frequentes

Preciso de comparar o meu sistema com um baseline mesmo que seja simples?

Sim — mesmo um baseline simples (aleatório, ingénuo ou o método mais básico da área) dá contexto aos resultados e evita a acusação de que o desempenho reportado não tem termo de comparação.

O que fazer se a demonstração ao vivo falhar durante a defesa?

Mudar imediatamente para o plano B preparado (vídeo gravado ou capturas de ecrã), em vez de tentar depurar o problema perante o júri, e continuar a explicação com esse material de apoio.

É má ideia admitir que o sistema tem limitações de segurança não resolvidas?

Não — nomear as vulnerabilidades conhecidas e explicar porque ficaram fora do âmbito é mais valorizado do que afirmar que o sistema é seguro sem ter feito essa análise.

Quantas métricas de avaliação devo reportar?

O suficiente para cobrir as dimensões relevantes do problema (por exemplo, desempenho e qualidade do resultado), não apenas a métrica que favorece o sistema desenvolvido.

O júri vai testar o sistema pessoalmente?

Depende da instituição e do orientador — alguns júris preferem apenas assistir à demonstração conduzida pelo candidato, outros pedem para interagir diretamente com o sistema; confirme com antecedência qual é a prática esperada na sua instituição.

Em resumo

A arguição de uma tese de Engenharia Informática soma às perguntas mecânicas comuns a qualquer defesa uma camada própria: a justificação das escolhas tecnológicas, o rigor da avaliação experimental, a honestidade sobre limitações de escalabilidade e segurança, e a preparação técnica para uma eventual demonstração ao vivo. Preparar cada uma destas frentes com respostas testadas antecipadamente é o que separa uma defesa fluida de uma defesa hesitante.