Temas para TCC em Engenharia de Software: 120 Ideias para sua Pesquisa

Escolher entre tantos temas para TCC em Engenharia de Software pode ser difícil porque a área envolve muito mais do que programação. Requisitos, arquitetura, testes, qualidade, DevOps, manutenção, métodos ágeis, segurança, inteligência artificial e evolução de sistemas são apenas algumas das possibilidades.

---

Atualizado em Setembro de 2026
Por Equipe Editorial do TCC&Monografia

---

O desafio é que uma tecnologia interessante ainda não representa, por si só, um problema de pesquisa.

“Inteligência artificial”, “microsserviços”, “DevOps”, “testes automatizados” ou “dívida técnica” podem funcionar como pontos de partida. Para se transformarem em um TCC, porém, esses assuntos precisam ganhar problema, contexto, recorte, evidências e metodologia.

É justamente essa transição que este guia pretende facilitar.

Além de apresentar 120 ideias de TCC em Engenharia de Software, organizadas em 10 áreas, você encontrará orientações para escolher um tema, delimitá-lo, formular uma pergunta pesquisável, selecionar uma metodologia, encontrar dados, utilizar repositórios de software e verificar a viabilidade do projeto antes de assumir um trabalho difícil de concluir.

Índice

• Como escolher um tema de TCC em Engenharia de Software?
• O que transforma uma tecnologia em problema de pesquisa?
• Quais são as principais áreas para um TCC em Engenharia de Software?
• 120 temas para TCC em Engenharia de Software
  • 1. Engenharia de Requisitos
  • 2. Arquitetura e Projeto de Software
  • 3. Qualidade e Testes de Software
  • 4. DevOps, CI/CD e Engenharia de Entrega
  • 5. Manutenção, Evolução e Dívida Técnica
  • 6. Desenvolvimento Ágil e Engenharia de Processos
  • 7. Inteligência Artificial na Engenharia de Software
  • 8. Segurança no Desenvolvimento de Software
  • 9. Experiência, Acessibilidade e Sustentabilidade de Software
  • 10. Métricas, Engenharia de Software Baseada em Evidências e Novas Fronteiras
• Quais são os temas mais atuais?
• Como transformar uma ideia em problema de pesquisa?
• Como delimitar o tema?
• Qual metodologia usar?
• É preciso desenvolver um software?
• Como avaliar um software cientificamente?
• Onde encontrar artigos, bases, datasets e projetos?
• Como usar GitHub e repositórios de software no TCC?
• Como saber se o tema é viável?
• Checklist para escolher o tema
• Perguntas frequentes
• Escolhi o tema. E agora?

Como escolher um tema de TCC em Engenharia de Software?

Um dos erros mais comuns na escolha do TCC é começar pela tecnologia e encerrar a decisão nesse mesmo ponto.

O estudante pensa:

• “quero fazer meu TCC sobre inteligência artificial”;
• “quero trabalhar com microsserviços”;
• “quero pesquisar DevOps”;
• “quero fazer alguma coisa com aplicativos”.

Essas ideias podem indicar interesses legítimos, mas ainda não informam o que será investigado.

Para escolher um tema mais consistente, é útil distinguir três elementos:

• tecnologia ou conceito: aquilo que desperta interesse;
• área: território da Engenharia de Software ao qual o assunto pertence;
• problema: fenômeno específico que poderá ser investigado.

Imagine um estudante interessado em automação de testes.

“Automação de testes” é um assunto. Dentro dele, poderiam existir problemas bastante diferentes:

• alto tempo de execução de suítes;
• instabilidade de testes automatizados;
• dificuldade de manutenção;
• baixa capacidade de detectar determinados defeitos;
• seleção inadequada de testes de regressão;
• qualidade de testes produzidos com assistência de inteligência artificial.

Cada problema poderia gerar perguntas, métodos e dados diferentes.

Assunto amplo, tema e problema não são a mesma coisa

Veja alguns exemplos de como uma área ampla pode evoluir para uma direção mais pesquisável:

Assunto amplo	Direção de pesquisa mais específica
Inteligência artificial	Avaliar a qualidade de código produzido com assistência de modelos generativos em condições definidas
Microsserviços	Investigar uma característica de qualidade em sistemas ou projetos baseados em microsserviços
DevOps	Analisar a relação entre determinada prática de entrega e indicadores definidos do processo de desenvolvimento
Dívida técnica	Investigar indicadores de dívida técnica em projetos selecionados e sua relação com determinado fenômeno de evolução
Métodos ágeis	Analisar uma prática específica em um contexto delimitado de equipe ou projeto

A diferença é importante porque o TCC precisa avançar da descrição para a investigação.

Use cinco critérios antes de confirmar o tema

Uma escolha promissora costuma equilibrar pelo menos cinco dimensões.

1. Interesse

Você passará meses lendo, analisando dados, escrevendo e revisando o mesmo problema. Algum interesse genuíno ajuda a sustentar o trabalho.

Isso não significa escolher exclusivamente aquilo que parece divertido. Interesse precisa ser combinado com viabilidade acadêmica.

2. Problema identificável

Você consegue explicar qual fenômeno pretende compreender, avaliar ou comparar?

Se a resposta ainda for apenas “quero estudar determinada tecnologia”, continue refinando.

3. Evidências acessíveis

De onde virão os dados?

Dependendo do projeto, as evidências podem vir de:

• código-fonte;
• repositórios;
• commits;
• issues;
• pull requests;
• testes;
• logs;
• métricas;
• experimentos;
• questionários;
• entrevistas;
• documentos;
• literatura científica.

Se o trabalho depende de dados aos quais você provavelmente não terá acesso, o tema pode se tornar inviável.

4. Método executável

O problema precisa poder ser investigado com um procedimento compatível com seu prazo, seus recursos e o nível do trabalho.

Um método sofisticado, mas impossível de executar adequadamente, não melhora o TCC.

5. Escopo compatível com o prazo

Quanto mais amplo o problema, maior tende a ser o volume de literatura, dados, variáveis e decisões metodológicas.

Um TCC não precisa explicar toda a Engenharia de Software. Precisa responder bem a uma pergunta suficientemente delimitada.

Se você ainda estiver comparando diferentes áreas e não tiver certeza sobre qual caminho seguir, consulte também o guia sobre como escolher um tema para TCC e o hub de temas para TCC.

O que transforma uma tecnologia em problema de pesquisa?

A Engenharia de Software possui forte dimensão aplicada. Por isso, é natural que estudantes se interessem por ferramentas, linguagens, frameworks, plataformas e técnicas.

O risco aparece quando o TCC se limita a:

• descrever uma tecnologia;
• mostrar como utilizá-la;
• desenvolver uma aplicação;
• listar funcionalidades;
• comparar superficialmente ferramentas.

Essas atividades podem fazer parte do trabalho, mas não substituem a formulação de um problema investigável.

Construir alguma coisa não define automaticamente a pesquisa

Imagine a proposta:

“Desenvolvimento de um sistema utilizando microsserviços.”

Ela informa o que será construído, mas deixa várias perguntas abertas:

• qual problema científico ou técnico será investigado?
• por que microsserviços são relevantes nesse problema?
• o que será observado?
• como o resultado será avaliado?
• com que evidência será possível chegar a uma conclusão?

Agora considere uma formulação mais investigativa:

“Análise da manutenibilidade de componentes em uma arquitetura baseada em microsserviços sob critérios previamente definidos.”

Ainda será necessário delimitar e formular a pergunta, mas já existe uma característica que poderá ser operacionalizada e avaliada.

Uma fórmula prática para construir o problema

Essa sequência não é uma norma obrigatória. Ela funciona como ferramenta de raciocínio para impedir que a escolha pare em um assunto genérico.

Área

É o território mais amplo no qual o trabalho se encontra.

Exemplos:

• Engenharia de Requisitos;
• Arquitetura de Software;
• Testes;
• Manutenção;
• DevOps;
• Segurança;
• Engenharia de Software empírica.

Problema

É a situação, relação, dificuldade ou incerteza que merece investigação.

Por exemplo:

• instabilidade de testes;
• dificuldade de manutenção;
• ambiguidade de requisitos;
• demora no feedback de integração;
• qualidade incerta de código gerado automaticamente.

Artefato ou processo

É aquilo sobre o qual a pesquisa obterá evidências.

Pode ser código, requisito, caso de teste, pipeline, pull request, issue, arquitetura, documentação ou processo de desenvolvimento.

Contexto

Define onde o fenômeno será observado.

Por exemplo:

• projetos open source;
• aplicações web;
• equipes ágeis;
• sistemas legados;
• tarefas controladas de programação;
• projetos desenvolvidos em determinado ecossistema.

Variável ou critério

Indica aquilo que será observado ou avaliado.

Exemplos:

• tempo;
• defeitos;
• cobertura;
• complexidade;
• manutenibilidade;
• latência;
• consumo de recursos;
• percepção dos participantes.

Recorte

Estabelece limites que tornam o trabalho executável.

O recorte pode envolver linguagem, período, quantidade de projetos, tipo de aplicação, população, versão, técnica ou outro critério justificado.

Método

Define como as evidências serão produzidas e analisadas.

Experimento, estudo de caso, survey, entrevistas, mineração de repositórios, análise de código e revisão da literatura são algumas possibilidades, dependendo da pergunta.

Exemplo: de “IA e programação” para uma pergunta pesquisável

Veja uma transformação progressiva.

Assunto amplo: inteligência artificial.

Área: IA aplicada ao desenvolvimento de software.

Atividade: geração de código.

Problema: incerteza sobre a qualidade das soluções produzidas com assistência de IA.

Artefato: código produzido em tarefas definidas.

Critério: por exemplo, correção funcional ou outra característica alinhada ao problema.

Contexto: tarefas de programação selecionadas segundo critérios explícitos.

Método possível: experimento comparativo.

A pergunta poderia então investigar diferenças observadas entre soluções produzidas sob condições definidas.

Perceba que “IA” continua presente, mas agora existe algo que pode ser medido, comparado e discutido.

Quais são as principais áreas para um TCC em Engenharia de Software?

Engenharia de Software cobre diferentes etapas do ciclo de vida e diferentes dimensões da construção, operação e evolução de sistemas.

Conhecer essas áreas ajuda a escolher um território antes de delimitar o problema.

Área	O que pode ser investigado
Engenharia de Requisitos	elicitação, especificação, validação, priorização, rastreabilidade e requisitos não funcionais
Arquitetura e Projeto	decisões arquiteturais, modularidade, acoplamento, APIs, padrões e atributos de qualidade
Qualidade e Testes	automação, cobertura, defeitos, regressão, integração, mutation testing e confiabilidade das suítes
DevOps e Entrega	CI/CD, pipelines, deploy, observabilidade, infraestrutura como código e feedback
Manutenção e Evolução	dívida técnica, refatoração, sistemas legados, dependências e evolução arquitetural
Processos de Desenvolvimento	métodos ágeis, revisão de código, colaboração, fluxo de trabalho e melhoria de processos
IA na Engenharia de Software	geração e revisão de código, testes, requisitos, documentação, defeitos e refatoração
Segurança no Desenvolvimento	Secure by Design, DevSecOps, dependências, análise de código, APIs e modelagem de ameaças
Experiência, Acessibilidade e Sustentabilidade	developer experience, acessibilidade, documentação, desempenho, recursos e Green Software
Métricas e Engenharia Baseada em Evidências	repositórios, métricas, replicação, datasets, estudos empíricos e novas fronteiras da disciplina

As áreas podem se sobrepor

Um mesmo problema pode atravessar mais de uma área.

Por exemplo, uma pesquisa sobre geração automática de testes com IA envolve simultaneamente:

• inteligência artificial;
• testes de software;
• qualidade;
• avaliação empírica.

Isso não é um problema.

O importante é identificar qual questão ocupa o centro do TCC.

Se o objetivo principal é avaliar a capacidade dos testes de detectar defeitos, o eixo central pode continuar sendo qualidade e testes, mesmo que IA faça parte da solução investigada.

Essa distinção também ajuda a evitar que o projeto tente estudar todas as áreas ao mesmo tempo.

120 temas para TCC em Engenharia de Software

As ideias abaixo estão distribuídas em 10 blocos com 12 sugestões cada. A organização facilita a exploração por área e reduz a repetição de propostas muito semelhantes.

Os temas foram formulados como pontos de partida. Dependendo da instituição, do orientador e do método escolhido, será necessário ajustar população, contexto, tecnologia, período, variável ou objeto analisado.

Ao avaliar qualquer uma das sugestões, faça uma pergunta adicional:

Que evidência permitiria responder à pergunta que estou formulando?

Essa pergunta simples ajuda a separar um assunto interessante de um projeto efetivamente pesquisável.

1. Temas para TCC em Engenharia de Requisitos

A Engenharia de Requisitos investiga como necessidades, expectativas, restrições e características desejadas de um sistema são descobertas, analisadas, documentadas, priorizadas, validadas e acompanhadas ao longo do desenvolvimento.

Essa área oferece boas possibilidades de TCC porque muitos problemas aparecem antes mesmo da implementação: requisitos ambíguos, mudanças frequentes, critérios de aceitação pouco claros, dificuldade de priorização e perda de rastreabilidade podem afetar etapas posteriores do projeto.

1. Uso de inteligência artificial generativa na elicitação de requisitos de software

Modelos generativos podem ser utilizados como apoio em atividades de descoberta, organização ou refinamento de requisitos. Um TCC pode investigar em quais condições esse apoio produz resultados úteis e quais limitações aparecem.

A pesquisa pode comparar requisitos obtidos ou refinados com e sem assistência de IA, considerando critérios previamente definidos, como completude, clareza, redundância ou identificação de necessidades relevantes.

Possível recorte: avaliar o uso de um modelo generativo como apoio à elaboração de perguntas de elicitação em cenários de software previamente definidos.

2. Qualidade de histórias de usuário em projetos ágeis

Histórias de usuário são amplamente utilizadas para representar necessidades em contextos ágeis, mas sua qualidade pode variar significativamente.

Um estudo pode investigar problemas como ambiguidade, falta de informação, baixa testabilidade, dependências ou critérios de aceitação insuficientes.

Possível recorte: analisar histórias de usuário de projetos selecionados utilizando critérios explícitos de qualidade e identificar os problemas mais frequentes.

3. Ambiguidade em requisitos de software e seus impactos no desenvolvimento

Requisitos escritos em linguagem natural podem permitir interpretações diferentes. Isso pode provocar dúvidas, retrabalho, decisões inconsistentes ou defeitos posteriores.

O TCC pode estudar tipos de ambiguidade, estratégias de identificação ou relações entre requisitos problemáticos e ocorrências observadas posteriormente no processo.

Possível recorte: classificar ambiguidades encontradas em um conjunto delimitado de especificações e analisar quais categorias aparecem com maior frequência.

4. Rastreabilidade de requisitos em projetos de software

A rastreabilidade procura estabelecer relações entre requisitos e outros artefatos, como código, testes, decisões, issues ou mudanças.

Uma pesquisa pode investigar a presença, ausência ou qualidade dessas relações e como elas apoiam manutenção, análise de impacto ou validação.

Possível recorte: avaliar como requisitos ou solicitações registradas em issues podem ser relacionados a commits e pull requests em projetos selecionados.

5. Gestão de mudanças de requisitos em projetos ágeis

Mudanças fazem parte da evolução de muitos projetos, mas alterações frequentes podem afetar planejamento, implementação, testes e documentação.

Em vez de perguntar simplesmente se “mudanças são boas ou ruins”, o estudante pode investigar como elas são registradas, priorizadas e incorporadas ao processo.

Possível recorte: analisar solicitações de mudança durante um período definido e classificá-las segundo origem, frequência, impacto ou momento de ocorrência.

6. Requisitos não funcionais em aplicações web

Desempenho, segurança, acessibilidade, confiabilidade e manutenibilidade são exemplos de características que podem aparecer como requisitos não funcionais.

Um TCC pode investigar como essas características são documentadas, priorizadas, testadas ou negligenciadas em determinado contexto.

Possível recorte: analisar como requisitos de desempenho são especificados e posteriormente verificados em um conjunto delimitado de projetos ou documentos.

7. Critérios de aceitação como mecanismo de redução de ambiguidades

Critérios de aceitação podem tornar expectativas mais explícitas e fornecer referências para validação e testes.

A pesquisa pode avaliar sua qualidade ou investigar relações entre critérios bem definidos e características das histórias de usuário às quais estão associados.

Possível recorte: comparar histórias com diferentes níveis de detalhamento nos critérios de aceitação e avaliar sua interpretação por participantes em um estudo controlado.

8. Priorização de requisitos em projetos com recursos limitados

Projetos raramente conseguem implementar simultaneamente todas as funcionalidades desejadas. Por isso, técnicas de priorização podem apoiar decisões sobre valor, custo, risco ou urgência.

Um TCC pode comparar técnicas, analisar critérios utilizados ou estudar como diferentes formas de priorização alteram a ordenação dos requisitos.

Possível recorte: aplicar duas técnicas de priorização ao mesmo conjunto de requisitos e analisar diferenças nos resultados e no esforço necessário.

9. Participação de usuários na validação de requisitos

A validação procura verificar se os requisitos representam adequadamente necessidades e expectativas relevantes.

O envolvimento de usuários pode ajudar, mas seu efeito depende do contexto, do perfil dos participantes e do procedimento adotado.

Possível recorte: investigar quais tipos de inconsistência são identificados por usuários durante uma atividade estruturada de validação de requisitos.

10. Prototipação como apoio à descoberta e validação de requisitos

Protótipos podem tornar ideias abstratas mais concretas e ajudar participantes a identificar necessidades, inconsistências ou expectativas não percebidas inicialmente.

O foco acadêmico pode estar na informação produzida durante a atividade, e não apenas na construção da interface.

Possível recorte: comparar requisitos registrados antes e depois da interação com um protótipo em um cenário delimitado.

11. Detecção automatizada de problemas em especificações de requisitos

Ferramentas baseadas em regras, processamento de linguagem natural ou inteligência artificial podem apoiar a identificação de ambiguidades, inconsistências e outros problemas textuais.

Um TCC pode avaliar a capacidade de determinada abordagem em um conjunto de requisitos previamente classificado.

Possível recorte: comparar resultados da detecção automática com uma referência produzida segundo critérios explícitos e analisar falsos positivos e falsos negativos.

12. Relação entre qualidade dos requisitos e defeitos identificados posteriormente

Uma hipótese recorrente em desenvolvimento de software é que problemas nos requisitos podem se refletir em dificuldades posteriores. Entretanto, estabelecer essa relação exige evidências adequadas.

O estudante pode investigar artefatos que permitam relacionar requisitos, mudanças e defeitos sem presumir previamente que uma relação causal existe.

Possível recorte: analisar um conjunto de requisitos e registros posteriores de defeitos, buscando associações entre características previamente definidas.

2. Temas para TCC em Arquitetura e Projeto de Software

Arquitetura de Software envolve decisões estruturais que influenciam como partes de um sistema são organizadas, relacionadas e evoluídas.

Esse campo oferece oportunidades para investigar atributos de qualidade, dependências, modularidade, APIs, decisões arquiteturais, padrões e evolução estrutural.

O cuidado principal é evitar comparações genéricas como “qual arquitetura é melhor?”. A resposta depende dos critérios e do contexto.

13. Microsserviços e manutenibilidade de sistemas de software

Arquiteturas baseadas em microsserviços podem alterar a forma como componentes são modificados, implantados e coordenados. Ao mesmo tempo, introduzem dependências distribuídas e novos desafios operacionais.

Um TCC pode investigar uma dimensão específica de manutenibilidade sem assumir que microsserviços são automaticamente superiores ou inferiores.

Possível recorte: analisar indicadores de mudança e dependência em serviços de projetos selecionados durante um período definido.

14. Comparação entre arquitetura monolítica e microsserviços em contexto delimitado

Comparações entre arquiteturas precisam estabelecer quais características serão avaliadas.

Desempenho, implantação, manutenção, complexidade operacional e consumo de recursos representam problemas diferentes e podem levar a conclusões distintas.

Possível recorte: implementar funcionalidades equivalentes em duas arquiteturas controladas e comparar uma característica claramente definida sob a mesma carga e ambiente.

15. Documentação de decisões arquiteturais em projetos de software

Decisões arquiteturais podem perder contexto ao longo do tempo. Registrar alternativas, justificativas e consequências pode facilitar a compreensão futura do sistema.

Uma pesquisa pode estudar como decisões são documentadas e quais informações aparecem ou deixam de aparecer nesses registros.

Possível recorte: analisar registros de decisões arquiteturais de projetos selecionados segundo categorias como contexto, decisão, alternativas e consequências.

16. Relação entre acoplamento e facilidade de manutenção do software

Acoplamento é frequentemente associado à manutenção, mas métricas estruturais não devem ser interpretadas isoladamente como prova de qualidade.

Um estudo pode investigar associações entre indicadores de acoplamento e evidências de mudança ou manutenção.

Possível recorte: comparar métricas de acoplamento com frequência de mudanças em módulos de projetos selecionados.

17. Modularidade como estratégia para evolução de sistemas

Modularidade procura organizar responsabilidades e reduzir dependências inadequadas entre partes do software.

Um TCC pode investigar como estruturas modulares se relacionam com padrões de mudança observados ao longo da evolução.

Possível recorte: analisar módulos de um sistema ao longo de diferentes versões e observar mudanças em dependências e coevolução.

18. Arquitetura orientada a eventos em sistemas distribuídos

Arquiteturas orientadas a eventos podem favorecer desacoplamento e processamento assíncrono, mas também criam desafios relacionados a rastreamento, consistência e diagnóstico.

A pesquisa deve selecionar uma dessas dimensões em vez de tentar avaliar a arquitetura como um todo.

Possível recorte: comparar estratégias de comunicação sob determinado cenário de carga, observando latência, vazão ou outra métrica alinhada à pergunta.

19. Qualidade de APIs e sua influência na integração entre sistemas

APIs funcionam como contratos de interação entre componentes e sistemas. Problemas de consistência, documentação ou desenho podem dificultar sua utilização.

Um TCC pode definir critérios de qualidade e analisar APIs selecionadas ou estudar tarefas de integração.

Possível recorte: avaliar documentação e consistência de APIs públicas utilizando um conjunto previamente definido de critérios.

20. Evolução de APIs e compatibilidade entre versões

Alterações em APIs podem afetar consumidores existentes, especialmente quando mudanças incompatíveis não são adequadamente tratadas.

Uma pesquisa pode analisar históricos de versões e identificar tipos de alteração que exigem adaptação dos consumidores.

Possível recorte: estudar releases de bibliotecas selecionadas e classificar mudanças de interface pública ao longo de um período.

21. Padrões arquiteturais e testabilidade de aplicações

Decisões de projeto podem facilitar ou dificultar isolamento de componentes, substituição de dependências e automação de testes.

O estudante pode investigar elementos estruturais associados à testabilidade em um contexto controlado ou em sistemas existentes.

Possível recorte: comparar duas estruturas de implementação equivalentes quanto ao esforço ou à facilidade necessária para criar determinados testes.

22. Arquitetura de software e desempenho em aplicações web

Decisões arquiteturais podem influenciar latência, utilização de recursos e capacidade de atender cargas específicas.

Entretanto, desempenho depende de diversos fatores, tornando necessário controlar ambiente, implementação e carga.

Possível recorte: comparar uma decisão arquitetural específica utilizando implementações equivalentes e um benchmark documentado.

23. Identificação de problemas arquiteturais em sistemas legados

Sistemas que evoluem durante longos períodos podem acumular dependências, responsabilidades mal distribuídas ou estruturas difíceis de modificar.

Uma pesquisa pode utilizar análise estática, histórico de mudanças ou avaliação estruturada para identificar padrões arquiteturais problemáticos.

Possível recorte: analisar módulos de um sistema legado selecionado combinando dependências estruturais e histórico de coevolução.

24. Relação entre decisões arquiteturais e dívida técnica

Algumas decisões podem atender necessidades imediatas e produzir custos de evolução posteriormente. Esse fenômeno pode ser estudado como parte da dívida técnica arquitetural.

O desafio é operacionalizar a dívida técnica em evidências observáveis, evitando tratá-la apenas como percepção subjetiva.

Possível recorte: analisar decisões arquiteturais documentadas e ocorrências posteriores de retrabalho ou mudança estrutural em um estudo de caso.

3. Temas para TCC em Qualidade e Testes de Software

Qualidade e testes oferecem um campo especialmente fértil para trabalhos empíricos porque muitos fenômenos podem ser observados por meio de código, suítes de testes, defeitos, mutações, histórico de execução e métricas.

Ao mesmo tempo, é importante evitar uma simplificação frequente: uma única métrica raramente representa toda a qualidade do software.

25. Cobertura de testes e capacidade de detectar defeitos

Alta cobertura pode indicar que grande parte do código foi exercitada, mas isso não garante automaticamente que a suíte consiga revelar comportamentos incorretos.

Um TCC pode investigar a relação entre cobertura e capacidade de detecção utilizando defeitos conhecidos ou outra referência adequada.

Possível recorte: comparar suítes com diferentes níveis ou tipos de cobertura e observar sua capacidade de revelar um conjunto controlado de defeitos.

26. Testes unitários e manutenção de código

Testes unitários podem apoiar alterações ao fornecer feedback sobre comportamentos existentes, mas também precisam ser mantidos.

Uma pesquisa pode investigar benefícios e custos relacionados à manutenção da suíte.

Possível recorte: analisar a coevolução entre código de produção e código de teste em projetos selecionados.

27. Automação de testes de regressão em projetos de software

À medida que sistemas evoluem, suítes de regressão podem crescer e aumentar o tempo necessário para fornecer feedback.

O TCC pode estudar estratégias de seleção, execução ou automação desses testes.

Possível recorte: analisar tempo de execução e capacidade de detecção de falhas de uma suíte de regressão em diferentes estratégias de seleção.

28. Mutation testing como estratégia para avaliar suítes de testes

Mutation testing introduz pequenas alterações artificiais no programa para verificar se os testes conseguem detectá-las.

Essa abordagem pode ajudar a avaliar a capacidade da suíte além da simples cobertura estrutural.

Possível recorte: comparar cobertura de código e mutation score em módulos selecionados, investigando em que situações os indicadores divergem.

29. Testes de integração em arquiteturas baseadas em serviços

Sistemas compostos por serviços possuem interações que podem falhar por contratos inconsistentes, indisponibilidade, mudanças de versão ou problemas de comunicação.

Uma pesquisa pode avaliar estratégias de teste voltadas especificamente a essas integrações.

Possível recorte: investigar a capacidade de uma estratégia de testes de integração em detectar alterações incompatíveis entre serviços.

30. Priorização de casos de teste para feedback mais rápido

Quando uma suíte é extensa, executar primeiro os testes com maior probabilidade de fornecer informação relevante pode reduzir o tempo até a identificação de falhas.

Um TCC pode comparar critérios de priorização utilizando históricos ou defeitos conhecidos.

Possível recorte: comparar duas estratégias de ordenação quanto ao tempo ou à posição em que defeitos são detectados.

31. Testes baseados em risco em aplicações de software

Testes baseados em risco procuram direcionar esforço para áreas em que falhas possuem maior probabilidade ou impacto.

O estudante pode investigar técnicas de classificação, priorização ou distribuição do esforço de teste.

Possível recorte: aplicar uma estratégia de priorização baseada em risco a um conjunto delimitado de funcionalidades e comparar seus resultados com uma abordagem de referência.

32. Geração de casos de teste com inteligência artificial

Modelos generativos podem produzir casos de teste a partir de código, requisitos ou descrições textuais. A questão científica relevante não é apenas se o modelo consegue gerar texto executável, mas qual é a qualidade dos testes produzidos.

Possível recorte: avaliar testes gerados para um conjunto de funções segundo correção, cobertura e capacidade de detectar defeitos.

33. Flaky tests e confiabilidade de suítes automatizadas

Flaky tests apresentam resultados diferentes sem que uma alteração relevante no código explique a mudança. Eles podem reduzir a confiança no feedback da automação.

Um TCC pode investigar frequência, causas, padrões ou estratégias de identificação.

Possível recorte: analisar históricos de execução de projetos selecionados e classificar padrões associados à instabilidade dos testes.

34. Relação entre complexidade do código e ocorrência de defeitos

Métricas de complexidade são frequentemente utilizadas como indicadores de dificuldade estrutural, mas sua relação com defeitos precisa ser investigada empiricamente.

O estudo pode comparar módulos com diferentes características e registros de defeitos.

Possível recorte: analisar métricas de complexidade e histórico de correções em módulos de projetos selecionados, controlando características relevantes quando possível.

35. Testes end-to-end: benefícios, custos e estabilidade

Testes end-to-end verificam fluxos mais completos, mas podem exigir maior tempo de execução e sofrer influência de múltiplas dependências.

Uma pesquisa pode investigar a relação entre alcance, custo e estabilidade desses testes.

Possível recorte: analisar duração, frequência de falhas e manutenção de testes end-to-end em um conjunto delimitado de projetos.

36. Comparação entre testes escritos por desenvolvedores e testes gerados com assistência de IA

A comparação entre testes humanos e testes produzidos com assistência de modelos generativos permite investigar diferentes dimensões de qualidade.

O estudo deve evitar assumir previamente que um dos grupos será superior.

Possível recorte: utilizar o mesmo conjunto de tarefas e comparar testes segundo correção, cobertura, capacidade de revelar defeitos e outras métricas previamente justificadas.

Como escolher entre Requisitos, Arquitetura e Testes?

As três áreas podem gerar excelentes TCCs, mas direcionam o olhar para momentos e artefatos diferentes do desenvolvimento.

Engenharia de Requisitos tende a ser uma boa direção quando o interesse está em necessidades, especificações, histórias de usuário, validação, mudanças ou rastreabilidade.

Arquitetura e Projeto aproxima-se de decisões estruturais, componentes, dependências, APIs, modularidade e atributos de qualidade.

Qualidade e Testes é especialmente adequada quando o estudante deseja trabalhar com suítes de testes, defeitos, métricas, experimentos e avaliação de técnicas.

Também é possível combinar áreas, desde que uma pergunta central mantenha o TCC coeso.

Por exemplo, um estudo sobre requisitos e testes pode investigar rastreabilidade entre histórias de usuário, critérios de aceitação e casos de teste. Um estudo sobre arquitetura e testes pode analisar como determinadas decisões estruturais afetam testabilidade.

Antes de escolher, vale realizar uma pequena busca em cada área. O guia sobre como fazer busca bibliográfica pode ajudar a verificar onde existem literatura, métodos e problemas mais alinhados ao seu interesse.

4. Temas para TCC em DevOps, CI/CD e Engenharia de Entrega

DevOps reúne princípios e práticas que procuram aproximar desenvolvimento, entrega e operação de software. Em um TCC, porém, o foco não precisa ser simplesmente instalar ferramentas ou construir um pipeline.

Uma pesquisa mais consistente procura investigar como determinada prática se relaciona com um resultado observável.

Dependendo do problema, podem ser analisados:

• tempo de entrega;
• frequência de disponibilização de versões;
• tempo necessário para identificar falhas;
• confiabilidade do processo de entrega;
• tempo de recuperação;
• qualidade do feedback;
• segurança;
• observabilidade;
• esforço operacional;
• reprodutibilidade de ambientes.

37. Integração contínua e tempo de identificação de falhas

A integração contínua procura fornecer feedback frequente sobre alterações realizadas no software. Entretanto, a velocidade desse feedback depende da estrutura do pipeline, da suíte de testes e das verificações executadas.

Um TCC pode investigar quanto tempo diferentes etapas levam para sinalizar problemas após uma alteração.

Possível recorte: analisar históricos de builds de projetos selecionados e medir o intervalo entre alterações e identificação de falhas em pipelines de integração contínua.

38. Entrega contínua e frequência de disponibilização de novas versões

Práticas de entrega contínua procuram manter o software em condições de ser disponibilizado com maior frequência. Isso não significa que toda organização deva implantar continuamente nem que maior frequência seja automaticamente melhor.

A pesquisa pode investigar relações entre práticas de automação e características observadas do processo de entrega.

Possível recorte: analisar a evolução da frequência de releases antes e depois da adoção documentada de determinada prática de automação em projetos selecionados.

39. Qualidade de pipelines de CI/CD em projetos de software

Um pipeline pode executar compilação, testes, análise estática, verificações de segurança, empacotamento e implantação. A simples existência dessas etapas, porém, não garante que o processo seja confiável ou eficiente.

O TCC pode definir critérios para avaliar configurações de CI/CD e investigar como elas aparecem em projetos reais.

Possível recorte: analisar pipelines públicos segundo critérios como presença de testes, verificações automatizadas, tratamento de falhas e organização das etapas.

40. Tempo de execução de pipelines e velocidade do feedback ao desenvolvedor

Pipelines muito demorados podem atrasar o retorno sobre alterações e influenciar o fluxo de desenvolvimento.

Por outro lado, simplesmente remover verificações para reduzir o tempo pode comprometer outros objetivos.

Possível recorte: identificar etapas responsáveis pela maior parcela do tempo de execução e avaliar estratégias de otimização em um pipeline controlado.

41. Infraestrutura como código e reprodutibilidade de ambientes

Infraestrutura como código permite representar configurações de ambiente por meio de artefatos versionados e automatizáveis.

Um TCC pode investigar em que medida essa prática ajuda a reproduzir ambientes ou reduzir inconsistências de configuração.

Possível recorte: comparar a reprodução de um ambiente utilizando procedimento manual e configuração declarativa sob critérios previamente definidos.

42. Observabilidade e diagnóstico de falhas em sistemas distribuídos

Sistemas distribuídos podem dificultar a identificação da origem de falhas porque uma requisição atravessa diferentes serviços e dependências.

Logs, métricas e traces podem fornecer evidências complementares sobre o comportamento do sistema.

Possível recorte: comparar estratégias de instrumentação quanto ao tempo ou à quantidade de informação necessária para diagnosticar cenários de falha previamente definidos.

43. Estratégias de rollback e recuperação após falhas de implantação

Uma implantação pode introduzir comportamento inesperado mesmo após verificações automatizadas. Estratégias de rollback procuram restaurar uma condição anterior quando necessário.

A pesquisa pode comparar procedimentos de recuperação sob cenários controlados.

Possível recorte: avaliar duas estratégias de reversão quanto ao tempo de recuperação, complexidade operacional ou consistência após uma falha simulada.

44. Testes automatizados como gate em pipelines de integração contínua

Testes podem funcionar como condições para impedir que determinadas alterações avancem no pipeline.

Um TCC pode investigar o equilíbrio entre velocidade de feedback e capacidade de detectar problemas.

Possível recorte: comparar diferentes conjuntos de testes utilizados como gate e observar tempo de execução e detecção de falhas em um cenário delimitado.

45. DevSecOps e integração de verificações de segurança ao ciclo de entrega

DevSecOps procura incorporar práticas de segurança ao fluxo de desenvolvimento e entrega, evitando concentrar verificações apenas ao final do processo.

Um trabalho acadêmico pode analisar como verificações automatizadas são integradas ao pipeline e quais tipos de resultados produzem.

Possível recorte: avaliar a inserção de uma categoria de análise de segurança em um pipeline controlado, observando tempo adicional, achados e falsos positivos.

46. Falhas em builds automatizados de projetos open source

Históricos de integração contínua podem revelar falhas associadas a testes, dependências, configuração, compilação e infraestrutura.

Esses registros podem servir como base para uma pesquisa empírica sobre padrões de falha.

Possível recorte: coletar builds com falha de projetos selecionados, classificá-los segundo critérios explícitos e analisar quais categorias aparecem com maior frequência.

47. Automação de deploy e confiabilidade do processo de entrega

Automatizar implantação pode reduzir etapas manuais, mas a confiabilidade depende do desenho do processo, das verificações e dos mecanismos de recuperação.

O TCC pode investigar ocorrências de erro, repetibilidade ou diferenças entre procedimentos.

Possível recorte: comparar implantação manual e automatizada em ambiente controlado, utilizando os mesmos artefatos e critérios de avaliação.

48. Relação entre práticas de entrega contínua e indicadores de desempenho do processo de desenvolvimento

Práticas de entrega podem ser relacionadas a diferentes indicadores, como frequência de releases, tempo de ciclo, falhas ou recuperação.

O cuidado metodológico é evitar atribuir causalidade automaticamente a partir de uma simples associação.

Possível recorte: analisar projetos com características comparáveis e investigar associações entre práticas documentadas de entrega e indicadores selecionados.

5. Temas para TCC em Manutenção, Evolução e Dívida Técnica

Grande parte da vida útil de um software acontece depois de sua primeira versão.

Sistemas recebem correções, novas funcionalidades, atualizações de dependências, refatorações, mudanças arquiteturais e adaptações a novos ambientes.

Esse histórico transforma manutenção e evolução em áreas especialmente interessantes para pesquisas baseadas em repositórios, porque muitas decisões deixam rastros observáveis ao longo do tempo.

49. Dívida técnica em projetos de software open source

Dívida técnica pode representar decisões ou soluções que facilitam determinado objetivo no curto prazo, mas criam custos ou dificuldades futuras.

O conceito é amplo, portanto o TCC precisa definir qual manifestação será estudada e como ela será identificada.

Possível recorte: investigar indicadores previamente definidos de dívida técnica em módulos de projetos open source selecionados e observar sua evolução entre versões.

50. Code smells e frequência de mudanças no código

Code smells são estruturas que podem indicar problemas de design ou oportunidades de melhoria, mas sua presença não significa automaticamente que o código possui baixa qualidade.

Uma pesquisa pode investigar se determinados smells aparecem com maior frequência em componentes que também sofrem mais alterações.

Possível recorte: detectar categorias específicas de code smells e relacioná-las ao histórico de mudanças dos mesmos arquivos ou classes.

51. Refatoração e evolução da complexidade do código

Refatoração busca alterar a estrutura interna preservando o comportamento observável. Uma das questões possíveis é verificar como métricas estruturais se comportam antes e depois dessas mudanças.

Possível recorte: identificar eventos de refatoração em projetos selecionados e comparar métricas de complexidade em versões imediatamente anteriores e posteriores.

52. Relação entre dívida técnica e ocorrência de defeitos

É possível investigar se determinados indicadores associados à dívida técnica também aparecem em módulos com histórico de correções.

Entretanto, associação estatística não deve ser automaticamente interpretada como causalidade.

Possível recorte: selecionar uma categoria de dívida técnica, medir sua ocorrência e analisar sua relação com registros de correções em módulos delimitados.

53. Atualização de dependências em sistemas de software

Bibliotecas e componentes externos evoluem continuamente. Atualizá-los pode trazer correções e novas funcionalidades, mas também exigir adaptações.

Um TCC pode investigar frequência, atraso, impacto ou padrões de atualização.

Possível recorte: acompanhar o histórico de dependências de projetos selecionados e medir o intervalo entre novas versões e sua adoção.

54. Dependências desatualizadas e manutenção de projetos

Manter versões antigas de dependências pode resultar de estabilidade, compatibilidade, falta de recursos ou outras decisões de projeto.

O estudo pode investigar características associadas à defasagem sem presumir que toda dependência antiga representa necessariamente um erro.

Possível recorte: analisar projetos de um mesmo ecossistema e relacionar defasagem de dependências com frequência de manutenção ou outros indicadores selecionados.

55. Modernização de sistemas legados

Sistemas legados podem continuar atendendo funções importantes enquanto acumulam tecnologias antigas, dependências e estruturas difíceis de modificar.

Modernização pode envolver refatoração, substituição gradual, migração arquitetural ou atualização tecnológica.

Possível recorte: realizar um estudo de caso sobre a modernização de um componente delimitado, registrando decisões, dificuldades e critérios de avaliação.

56. Migração gradual de sistemas monolíticos para arquiteturas distribuídas

Migrações arquiteturais raramente precisam acontecer de uma única vez. Estratégias graduais procuram reduzir risco e permitir transições progressivas.

Um TCC pode investigar critérios utilizados para selecionar componentes, efeitos sobre dependências ou desafios encontrados durante a migração.

Possível recorte: estudar a extração de um componente de um sistema monolítico e avaliar alterações em dependências, implantação e manutenção.

57. Manutenção de testes automatizados em sistemas em evolução

Testes também são software e precisam acompanhar alterações no sistema de produção.

Uma suíte pode exigir mudanças frequentes quando interfaces, regras ou arquitetura evoluem.

Possível recorte: analisar a coevolução entre arquivos de produção e arquivos de teste ao longo de releases selecionados.

58. Documentação técnica e manutenção de sistemas

Documentação pode apoiar compreensão, onboarding e realização de mudanças, mas sua utilidade depende de conteúdo, atualização e contexto.

Um estudo pode investigar qualidade, sincronização ou relação entre documentação e tarefas de manutenção.

Possível recorte: avaliar se alterações significativas no código são acompanhadas por atualizações em documentação técnica em projetos selecionados.

59. Predição de módulos propensos a mudanças

Histórico de versões pode ser utilizado para investigar quais características estão associadas a componentes modificados com maior frequência.

Esse tipo de pesquisa exige cuidado na seleção das variáveis e na avaliação dos modelos.

Possível recorte: utilizar métricas de código e histórico de alterações para avaliar modelos simples de classificação ou predição em projetos selecionados.

60. Evolução da arquitetura ao longo das versões de um sistema

Arquiteturas reais podem se modificar progressivamente conforme novas funcionalidades, dependências e restrições surgem.

Uma pesquisa pode reconstruir parte dessa evolução utilizando versões, dependências ou outros artefatos.

Possível recorte: selecionar releases representativos de um projeto e comparar mudanças em sua estrutura de dependências ao longo do tempo.

6. Temas para TCC em Desenvolvimento Ágil e Engenharia de Processos

Processos de desenvolvimento organizam atividades, responsabilidades, fluxo de trabalho, comunicação e mecanismos de feedback.

Em pesquisas acadêmicas, o objetivo não precisa ser demonstrar que determinado método é “melhor”. É mais útil investigar práticas específicas, condições de utilização, limitações e resultados observáveis.

Essa área permite combinar dados de ferramentas de desenvolvimento com surveys, entrevistas, estudos de caso e análise de processos.

61. Qualidade de histórias de usuário em equipes ágeis

Histórias de usuário podem ser analisadas tanto sob a perspectiva de requisitos quanto do processo de desenvolvimento.

Neste segundo enfoque, a pesquisa pode investigar como sua estrutura se relaciona com planejamento, execução ou retrabalho.

Possível recorte: analisar histórias de usuário concluídas durante um período e investigar associações entre características previamente definidas e ocorrências de reabertura ou mudança.

62. Estimativas de esforço em projetos ágeis

Equipes utilizam diferentes estratégias para estimar esforço ou complexidade relativa. Essas estimativas podem divergir do tempo efetivamente observado por diversos motivos.

O TCC pode investigar precisão, estabilidade ou fatores associados às diferenças.

Possível recorte: comparar estimativas registradas e tempo de ciclo de itens concluídos em um conjunto delimitado de sprints ou períodos.

63. Revisão de código e detecção de defeitos

Code review permite que alterações sejam examinadas antes da integração. Os comentários podem envolver defeitos, legibilidade, design, testes, documentação e outros aspectos.

Uma pesquisa pode analisar quais tipos de problema são identificados durante as revisões.

Possível recorte: classificar comentários de revisão em pull requests selecionados e identificar categorias recorrentes de alteração solicitada.

64. Tamanho de pull requests e eficiência da revisão de código

Pull requests muito extensos podem exigir maior esforço de compreensão, mas diversos fatores influenciam o tempo de revisão.

Um estudo pode investigar associações entre tamanho e indicadores do processo, controlando variáveis relevantes quando possível.

Possível recorte: relacionar tamanho de pull requests com tempo até a primeira revisão ou tempo até o merge em projetos selecionados.

65. Trabalho remoto e colaboração em equipes de desenvolvimento

Equipes distribuídas dependem de ferramentas e práticas de comunicação para coordenar trabalho técnico.

Um TCC pode estudar percepções, práticas, registros de colaboração ou desafios específicos, evitando generalizações sobre trabalho remoto como um todo.

Possível recorte: realizar survey ou estudo de caso sobre uma dimensão específica da colaboração remota, como comunicação assíncrona ou revisão de código.

66. Retrospectivas ágeis e melhoria contínua de processos

Retrospectivas procuram criar oportunidades para identificar problemas e propor melhorias. A realização da reunião, entretanto, não garante que ações sejam executadas.

Uma pesquisa pode acompanhar problemas identificados, ações propostas e seu acompanhamento posterior.

Possível recorte: analisar registros de retrospectivas de uma equipe e verificar quantas ações geradas foram posteriormente implementadas ou revisitadas.

67. Kanban e tempo de fluxo de atividades de desenvolvimento

Kanban utiliza visualização do trabalho e gestão de fluxo. Métricas como tempo de ciclo podem apoiar análises sobre o comportamento do processo.

O TCC pode investigar mudanças observadas após uma intervenção ou comparar categorias de trabalho.

Possível recorte: analisar o tempo de ciclo de itens antes e depois de uma alteração específica no fluxo de trabalho.

68. Limites de trabalho em progresso e desempenho do fluxo

Limitar trabalho em progresso procura reduzir acúmulo de atividades simultâneas e favorecer conclusão antes do início de novos itens.

Uma pesquisa pode estudar sua relação com tempo de fluxo, filas ou quantidade de itens simultâneos.

Possível recorte: observar indicadores de fluxo antes e depois da introdução de limites de WIP em um ambiente controlado ou estudo de caso.

69. Documentação em equipes ágeis de desenvolvimento de software

Agilidade não significa ausência de documentação. A questão relevante é identificar quais documentos são úteis, quando são atualizados e como apoiam o trabalho.

Possível recorte: investigar quais tipos de documentação são consultados durante tarefas de manutenção ou onboarding em um contexto delimitado.

70. Onboarding de novos desenvolvedores em projetos de software

Novos integrantes precisam compreender código, arquitetura, ferramentas, processos e convenções do projeto.

Um TCC pode investigar barreiras, fontes de informação e tempo necessário para realizar tarefas iniciais.

Possível recorte: estudar dificuldades relatadas por novos contribuidores de projetos selecionados ou observar tarefas controladas de onboarding.

71. Pair programming e qualidade das soluções produzidas

Pair programming envolve dois participantes colaborando na mesma atividade de desenvolvimento. Seus resultados podem depender da tarefa, experiência e dinâmica de interação.

Um estudo pode comparar condições controladas utilizando critérios explícitos.

Possível recorte: comparar soluções produzidas individualmente e em pares em tarefas equivalentes, observando critérios previamente definidos de correção, tempo ou qualidade.

72. Uso de métricas para melhoria de processos de desenvolvimento

Métricas podem apoiar decisões, mas também podem gerar comportamentos indesejados quando utilizadas fora de contexto ou transformadas em metas individuais simplistas.

O TCC pode investigar como indicadores são definidos, interpretados ou utilizados para acompanhar processos.

Possível recorte: selecionar métricas de fluxo de uma equipe ou projeto e analisar quais informações elas fornecem — e quais não fornecem — sobre o processo.

O que os temas 37–72 têm em comum?

DevOps, manutenção e processos mostram uma característica importante da Engenharia de Software: o software não termina quando o código é escrito.

Ele precisa ser integrado, testado, entregue, operado, modificado, compreendido e evoluído.

Isso cria oportunidades de pesquisa baseadas em artefatos produzidos durante o próprio ciclo de desenvolvimento.

Se você se interessa por…	Bloco mais próximo	Possíveis evidências
automação e entrega	DevOps e CI/CD	builds, pipelines, releases, logs e métricas de processo
sistemas legados	Manutenção e Evolução	commits, releases, código, dependências e defeitos
dívida técnica	Manutenção e Evolução	métricas, code smells, issues e histórico de mudanças
trabalho em equipe	Engenharia de Processos	pull requests, entrevistas, surveys e registros de processo
fluxo de trabalho	Desenvolvimento Ágil	tempo de fluxo, backlog, histórico de tarefas e observações

Esses dados podem parecer fáceis de obter, especialmente em projetos públicos, mas disponibilidade não elimina a necessidade de planejamento metodológico.

Um histórico com milhares de commits pode continuar inadequado se a pergunta exigir uma informação que esses commits não representam.

7. Temas para TCC em Inteligência Artificial na Engenharia de Software

A inteligência artificial passou a participar de diferentes atividades da Engenharia de Software: análise de requisitos, geração de código, testes, documentação, revisão, identificação de defeitos e manutenção.

Isso cria muitas possibilidades de TCC, mas também aumenta o risco de escolher temas excessivamente dependentes de uma ferramenta específica ou de uma tendência passageira.

Uma estratégia mais robusta é formular o trabalho em torno de uma tarefa de Engenharia de Software, um resultado observável, uma limitação ou um critério de avaliação.

Assim, o problema científico pode continuar relevante mesmo que a ferramenta utilizada no experimento seja posteriormente substituída.

73. Assistentes de programação baseados em IA e produtividade no desenvolvimento de software

Assistentes de programação podem sugerir código, explicar trechos, gerar testes e apoiar diferentes tarefas. Entretanto, “produtividade” é um conceito amplo e não deve ser reduzido automaticamente a quantidade de código produzido.

Um TCC pode definir uma tarefa específica e critérios adequados para observar diferenças entre condições com e sem assistência.

Possível recorte: comparar tempo de conclusão, correção e retrabalho em tarefas controladas realizadas sob condições com e sem assistência de IA.

74. Qualidade do código gerado por modelos de inteligência artificial

Modelos generativos conseguem produzir implementações para diferentes problemas, mas a qualidade pode variar conforme tarefa, linguagem, contexto e instruções fornecidas.

O estudo precisa definir o que significa qualidade: correção, legibilidade, complexidade, manutenibilidade, desempenho ou outra característica.

Possível recorte: gerar soluções para um conjunto delimitado de tarefas e avaliá-las segundo correção funcional e métricas estruturais previamente justificadas.

75. Segurança do código produzido com assistência de IA

Código funcional pode ainda apresentar práticas inseguras ou vulnerabilidades. Por isso, uma pesquisa pode investigar a presença de problemas de segurança em implementações produzidas sob condições controladas.

O trabalho deve permanecer em contexto acadêmico, autorizado e defensivo.

Possível recorte: analisar soluções geradas para tarefas controladas utilizando critérios ou ferramentas de análise defensiva e classificar os tipos de problemas encontrados.

76. Uso de IA na revisão de código

Modelos de IA podem sugerir problemas, melhorias ou explicações durante code review. A questão relevante é verificar a utilidade e a confiabilidade dessas sugestões.

Possível recorte: utilizar alterações previamente avaliadas e comparar observações produzidas pelo modelo com uma referência definida pelo estudo, registrando acertos, omissões e sugestões inadequadas.

77. Inteligência artificial na geração de documentação técnica

Documentação produzida automaticamente pode reduzir esforço inicial, mas pode conter informações incompletas, desatualizadas ou incorretas.

Um TCC pode avaliar diferentes dimensões da documentação gerada.

Possível recorte: gerar documentação para componentes selecionados e avaliar correção, completude e consistência em relação ao código utilizado como referência.

78. IA generativa na explicação de código para desenvolvedores

Explicações automáticas podem ajudar na compreensão de código desconhecido, especialmente em atividades de manutenção e onboarding.

Entretanto, uma explicação convincente não é necessariamente correta.

Possível recorte: avaliar explicações geradas para funções previamente selecionadas, comparando-as com comportamentos e características verificáveis do código.

79. Uso de IA na identificação e correção de defeitos de software

Modelos podem sugerir localização, causa ou correção de defeitos. Um TCC pode avaliar separadamente essas capacidades para evitar um escopo excessivamente amplo.

Possível recorte: utilizar um conjunto de defeitos conhecidos e medir quantos são corretamente localizados ou corrigidos sob um protocolo reproduzível.

80. IA generativa aplicada à refatoração de código

Refatoração pretende melhorar a estrutura interna preservando o comportamento externo. Sugestões automatizadas podem ser avaliadas quanto à preservação funcional e às mudanças estruturais produzidas.

Possível recorte: solicitar refatorações para trechos com características previamente identificadas e comparar métricas e resultados dos testes antes e depois das alterações.

81. Modelos generativos na análise de requisitos de software

IA pode apoiar classificação, resumo, identificação de ambiguidades e análise de requisitos. A pesquisa deve selecionar uma dessas tarefas e estabelecer uma referência de avaliação.

Possível recorte: avaliar a capacidade de um modelo em identificar requisitos potencialmente ambíguos em um conjunto previamente classificado.

82. Confiabilidade das respostas de assistentes de IA em tarefas de Engenharia de Software

Assistentes podem produzir respostas tecnicamente plausíveis, mas incorretas. Isso é particularmente relevante quando o usuário aceita sugestões sem verificação.

Um TCC pode estudar frequência e tipos de erro em tarefas delimitadas.

Possível recorte: construir um conjunto de perguntas técnicas com respostas verificáveis e classificar as respostas do assistente segundo critérios explícitos.

83. Dependência de assistência automatizada e compreensão do código

Uma questão emergente é se o uso intensivo de assistência automatizada modifica a compreensão que o desenvolvedor possui sobre a solução produzida.

Esse tipo de investigação pode envolver participantes e, portanto, exige desenho experimental e cuidados éticos adequados.

Possível recorte: comparar desempenho em perguntas de compreensão após tarefas realizadas com e sem assistência automatizada, controlando experiência dos participantes quando possível.

84. Comparação entre desenvolvimento com e sem assistência de IA

Comparações gerais entre “programar com IA” e “programar sem IA” são amplas demais. O estudo precisa especificar tarefa, população, ambiente e resultados observados.

Possível recorte: comparar condições em tarefas curtas e equivalentes utilizando tempo, correção e quantidade de retrabalho como critérios previamente definidos.

8. Temas para TCC em Segurança no Desenvolvimento de Software

Segurança não precisa ser tratada apenas depois que o sistema está pronto. Ela pode aparecer nos requisitos, no projeto, na implementação, na revisão de código, nos testes, nas dependências, nas APIs e nos pipelines de entrega.

Para um TCC em Engenharia de Software, uma abordagem produtiva é investigar como práticas de desenvolvimento podem apoiar prevenção, identificação e correção de problemas de segurança.

O trabalho deve permanecer em ambientes autorizados e utilizar finalidade acadêmica, preventiva e defensiva.

85. Secure by Design no desenvolvimento de aplicações

Secure by Design procura considerar segurança desde decisões iniciais de projeto, em vez de adicioná-la somente depois da implementação.

Um TCC pode investigar como princípios de segurança são incorporados a requisitos, arquitetura ou processo de desenvolvimento.

Possível recorte: avaliar a aplicação de um conjunto delimitado de princípios de Secure by Design durante o desenvolvimento de um protótipo controlado.

86. Requisitos de segurança em projetos de software

Requisitos de segurança podem representar autenticação, autorização, proteção de dados, auditoria e outras necessidades.

Quando são vagos ou ausentes, decisões importantes podem ser tomadas apenas durante a implementação.

Possível recorte: analisar especificações selecionadas e classificar como requisitos de segurança são descritos, detalhados e relacionados a critérios de aceitação.

87. Análise estática de código como apoio ao desenvolvimento seguro

Ferramentas de análise estática examinam código sem necessariamente executar a aplicação e podem identificar determinados padrões potencialmente problemáticos.

Um TCC pode avaliar sua capacidade de detecção em um conjunto controlado ou analisar resultados em projetos selecionados.

Possível recorte: aplicar ferramentas selecionadas a um conjunto de exemplos previamente classificados e comparar tipos de achados, cobertura e falsos positivos.

88. Falsos positivos em ferramentas de análise de segurança

Um grande volume de alertas irrelevantes pode aumentar esforço de revisão e reduzir confiança nos resultados de uma ferramenta.

Por isso, falsos positivos representam um problema de Engenharia de Software além da simples capacidade de detectar vulnerabilidades.

Possível recorte: classificar alertas produzidos por uma ferramenta em projetos selecionados e analisar quais categorias concentram maior proporção de resultados não confirmados.

89. Segurança de dependências de terceiros em projetos de software

Aplicações modernas utilizam bibliotecas e componentes externos. Problemas conhecidos nessas dependências podem afetar projetos consumidores.

Um TCC pode estudar atualização, monitoramento ou tratamento de alertas relacionados a dependências.

Possível recorte: analisar dependências declaradas em projetos selecionados e investigar como atualizações relacionadas a problemas conhecidos são incorporadas ao longo do tempo.

90. Atualização de dependências após divulgação de vulnerabilidades

Quando uma vulnerabilidade é divulgada e uma correção se torna disponível, projetos consumidores podem atualizar em ritmos diferentes.

Esse intervalo pode ser investigado empiricamente.

Possível recorte: selecionar eventos públicos e medir o tempo entre disponibilidade de uma versão corrigida e adoção por projetos definidos segundo critérios transparentes.

91. Segurança de APIs durante o desenvolvimento de software

APIs expõem operações e dados que precisam ser protegidos por decisões adequadas de autenticação, autorização, validação e configuração.

Um TCC pode avaliar práticas defensivas em ambientes controlados.

Possível recorte: desenvolver ou utilizar uma API de laboratório e avaliar a presença de controles previamente definidos por meio de testes autorizados.

92. Revisão de código orientada à segurança

Code review pode incluir critérios de segurança além de legibilidade e manutenção.

A pesquisa pode investigar checklists, tipos de problema encontrados ou diferenças entre estratégias de revisão.

Possível recorte: comparar uma revisão convencional com uma revisão apoiada por checklist de segurança em um conjunto controlado de alterações.

93. DevSecOps e automação de verificações de segurança

Integrar verificações ao pipeline pode fornecer feedback mais cedo, mas também aumenta tempo de execução e pode gerar alertas que precisam ser analisados.

Possível recorte: inserir uma verificação automatizada em pipeline de laboratório e avaliar custo temporal, quantidade de achados e necessidade de revisão manual.

94. Gestão de segredos em projetos de software

Credenciais, tokens e chaves não devem ser tratados como dados comuns no código-fonte. Práticas de gestão de segredos procuram reduzir exposição acidental.

Um TCC pode estudar mecanismos preventivos no processo de desenvolvimento.

Possível recorte: avaliar estratégias de prevenção de inclusão acidental de segredos em um repositório controlado, observando detecção e impacto no fluxo de trabalho.

95. Modelagem de ameaças no processo de desenvolvimento

Modelagem de ameaças procura identificar ativos, superfícies de ataque, possíveis ameaças e medidas de proteção antes ou durante o desenvolvimento.

A pesquisa pode avaliar como essa atividade modifica a identificação de requisitos ou decisões de projeto.

Possível recorte: aplicar uma abordagem de modelagem de ameaças a um sistema delimitado e analisar quais requisitos ou decisões adicionais são identificados.

96. Capacitação de desenvolvedores e prevenção de vulnerabilidades

Conhecimento de práticas seguras pode influenciar decisões de implementação, mas avaliar esse efeito exige um desenho adequado.

Possível recorte: realizar estudo controlado com atividade educacional previamente definida e comparar desempenho em tarefas defensivas antes e depois da intervenção, respeitando as exigências éticas aplicáveis.

9. Temas para TCC em Experiência, Acessibilidade e Sustentabilidade de Software

Engenharia de Software também envolve as condições em que pessoas utilizam, desenvolvem e mantêm sistemas, além dos recursos computacionais consumidos por esses sistemas.

Esse bloco reúne temas ligados à experiência do usuário e do desenvolvedor, acessibilidade e sustentabilidade, mantendo o foco na engenharia do produto e do processo.

97. Acessibilidade como requisito de qualidade em aplicações web

Acessibilidade pode ser tratada desde os requisitos e critérios de qualidade, em vez de aparecer apenas como correção posterior.

Um TCC pode investigar conformidade, defeitos recorrentes ou integração de critérios de acessibilidade ao desenvolvimento.

Possível recorte: avaliar páginas ou componentes selecionados segundo critérios definidos e classificar os problemas encontrados por categoria.

98. Testes automatizados de acessibilidade no processo de desenvolvimento

Ferramentas automatizadas podem identificar determinados problemas de acessibilidade, mas não substituem necessariamente avaliações manuais ou testes com usuários.

A pesquisa pode investigar cobertura e limitações dessas verificações.

Possível recorte: comparar resultados de uma ferramenta automatizada com uma avaliação de referência em um conjunto delimitado de páginas ou componentes.

99. Dívida de acessibilidade em sistemas em evolução

Problemas de acessibilidade podem se acumular quando novas funcionalidades são adicionadas sem critérios adequados de verificação.

Esse acúmulo pode ser estudado como uma forma de dívida relacionada à qualidade.

Possível recorte: acompanhar versões selecionadas de uma aplicação e observar a evolução de categorias específicas de problemas de acessibilidade.

100. Usabilidade de ferramentas utilizadas por desenvolvedores

Desenvolvedores também são usuários de ferramentas: IDEs, sistemas de build, plataformas de revisão, analisadores e utilitários internos.

Problemas de usabilidade podem aumentar esforço e erros durante atividades técnicas.

Possível recorte: avaliar uma tarefa específica em duas ferramentas ou interfaces utilizando tempo, erros e percepção dos participantes como critérios.

101. Experiência do desenvolvedor em processos de desenvolvimento de software

Developer Experience envolve aspectos que influenciam a capacidade de desenvolvedores compreenderem, executarem e evoluírem seu trabalho.

O conceito é amplo, portanto deve ser transformado em dimensões observáveis.

Possível recorte: investigar uma dimensão específica, como tempo de configuração do ambiente, facilidade de obter feedback ou clareza da documentação de contribuição.

102. Qualidade da documentação e experiência de novos contribuidores

Documentos de instalação, contribuição e arquitetura podem reduzir barreiras para quem entra em um projeto.

Uma pesquisa pode investigar quais informações são necessárias para executar tarefas iniciais.

Possível recorte: avaliar documentação de projetos selecionados por meio de uma tarefa de configuração ou contribuição controlada.

103. Consumo de energia de diferentes implementações de software

Soluções funcionalmente equivalentes podem apresentar diferentes padrões de uso de CPU, memória, tempo e energia.

Esse tipo de comparação exige controle do ambiente e repetição das medições.

Possível recorte: comparar implementações equivalentes de uma tarefa sob o mesmo hardware, carga e procedimento de medição.

104. Desempenho e consumo de recursos em aplicações de software

Otimizações podem reduzir tempo de execução, memória ou utilização de outros recursos, mas seus efeitos precisam ser medidos de forma reproduzível.

Possível recorte: avaliar versões alternativas de uma operação sob diferentes cargas, documentando ambiente, configuração e repetições.

105. Práticas de Green Software no desenvolvimento de aplicações

Green Software procura considerar eficiência de recursos e impactos relacionados à execução do software.

Em um TCC, é melhor selecionar uma prática ou decisão específica do que tentar avaliar toda a sustentabilidade de uma aplicação.

Possível recorte: comparar duas estratégias de implementação quanto a tempo de processamento e consumo de recursos em um ambiente controlado.

106. Relação entre desempenho e manutenibilidade em otimizações de código

Uma otimização pode melhorar desempenho e, ao mesmo tempo, aumentar complexidade ou reduzir legibilidade.

Isso cria uma oportunidade para investigar trade-offs entre diferentes características de qualidade.

Possível recorte: comparar versões antes e depois de uma otimização utilizando métricas de desempenho e indicadores estruturais previamente definidos.

107. Feedback de usuários como fonte para evolução de software

Relatos de usuários podem revelar defeitos, dificuldades, solicitações e novas necessidades. Entretanto, transformar feedback em decisões de desenvolvimento exige classificação e priorização.

Possível recorte: analisar um conjunto de feedbacks ou issues e investigar quais categorias resultam com maior frequência em alterações posteriores do software.

108. Integração de requisitos de usabilidade ao ciclo de desenvolvimento

Usabilidade pode ser incorporada como requisito, critério de aceitação e objeto de teste ao longo do desenvolvimento.

Um TCC pode investigar como essa integração modifica o processo de avaliação do produto.

Possível recorte: acompanhar um conjunto de requisitos de usabilidade desde sua especificação até a verificação em um projeto ou experimento delimitado.

10. Temas para TCC em Métricas, Engenharia de Software Baseada em Evidências e Novas Fronteiras

Projetos de software produzem grandes volumes de dados: código, commits, issues, pull requests, releases, resultados de testes, métricas e registros de colaboração.

Esses artefatos permitem realizar pesquisas empíricas sem necessariamente desenvolver um novo sistema.

O desafio é não confundir dado fácil de contar com evidência adequada para responder à pergunta.

109. Mineração de repositórios para identificar padrões de evolução de software

Históricos de versionamento podem revelar como arquivos, módulos, dependências e outros elementos se modificam ao longo do tempo.

Um TCC pode investigar padrões de evolução em uma amostra de projetos selecionada segundo critérios transparentes.

Possível recorte: analisar frequência e distribuição de mudanças entre módulos durante releases selecionados de projetos de um mesmo ecossistema.

110. Arquivos que mudam juntos como indicador de dependências de evolução

Arquivos modificados repetidamente nos mesmos commits podem sugerir relações de coevolução que não são necessariamente visíveis apenas pela estrutura estática do código.

Possível recorte: identificar pares ou grupos de arquivos que mudam conjuntamente e comparar esses padrões com dependências estruturais existentes.

111. Pull requests como fonte de evidências sobre colaboração em software

Pull requests registram alterações, comentários, revisões, solicitações de mudança e decisões de integração.

Esses registros podem apoiar estudos sobre revisão e colaboração, desde que sejam interpretados dentro das convenções de cada projeto.

Possível recorte: analisar pull requests de projetos selecionados e investigar relações entre tamanho, número de revisores, comentários e tempo de integração.

112. Issues como fonte para estudar defeitos e solicitações de funcionalidades

Issues podem representar defeitos, solicitações, perguntas, tarefas e diversos outros tipos de registro.

Antes da análise, o pesquisador precisa compreender como cada projeto utiliza seu sistema de issues.

Possível recorte: classificar issues fechadas durante um período e analisar diferenças entre categorias quanto ao tempo de resolução.

113. Predição de defeitos utilizando métricas de software

Métricas de código e histórico de mudanças podem ser utilizadas para construir modelos que tentam identificar componentes mais propensos a defeitos.

Um TCC precisa separar adequadamente dados de treinamento e avaliação e evitar conclusões maiores do que o desempenho observado permite.

Possível recorte: comparar modelos simples utilizando um conjunto delimitado de métricas em projetos selecionados.

114. Métricas de código como indicadores de manutenibilidade

Complexidade, acoplamento, coesão, tamanho e duplicação podem fornecer informações sobre características estruturais do código.

Nenhuma dessas medidas, isoladamente, representa toda a manutenibilidade.

Possível recorte: investigar a relação entre um conjunto pequeno de métricas e frequência de mudanças ou esforço de manutenção em módulos selecionados.

115. Reprodutibilidade de experimentos em Engenharia de Software

Para que resultados experimentais possam ser verificados, é importante documentar dados, ambiente, configurações, procedimentos e versões das ferramentas utilizadas.

Um TCC pode avaliar o quanto estudos selecionados fornecem informações ou artefatos suficientes para reprodução.

Possível recorte: selecionar artigos de um domínio específico e verificar a disponibilidade de datasets, scripts, configurações e instruções necessárias à reprodução.

116. Replicação de estudos empíricos em Engenharia de Software

Replicar um estudo pode verificar se determinados resultados se mantêm em outro contexto, amostra, período ou configuração.

Replicação não é simplesmente copiar um trabalho anterior: exige compreender o protocolo e justificar o que será mantido ou alterado.

Possível recorte: replicar um experimento publicado utilizando nova amostra ou versão tecnológica e comparar os resultados obtidos.

117. Qualidade de datasets utilizados em pesquisas de Engenharia de Software

Datasets podem conter dados ausentes, duplicados, rótulos inconsistentes, vieses de seleção ou informações cuja origem não está suficientemente documentada.

Um TCC pode investigar como essas características afetam uma análise.

Possível recorte: avaliar um dataset público quanto a completude, duplicação, distribuição das classes e documentação de origem antes de utilizá-lo em uma tarefa experimental.

118. Viés de seleção em estudos baseados em projetos open source

Selecionar apenas projetos muito populares, grandes ou ativos pode facilitar a coleta, mas limitar a representatividade das conclusões.

Um estudo pode investigar como diferentes critérios de seleção alteram a composição da amostra.

Possível recorte: construir duas amostras utilizando estratégias diferentes e comparar características como tamanho, idade, atividade e número de contribuidores.

119. Bots e automação da colaboração em repositórios de software

Bots podem atualizar dependências, rotular issues, executar verificações, responder a eventos e automatizar tarefas repetitivas.

Um TCC pode investigar tipos de atividade, frequência ou interação entre automação e contribuidores humanos.

Possível recorte: identificar pull requests produzidos por bots de atualização de dependências e analisar tempo de revisão, integração e rejeição em projetos selecionados.

120. Engenharia de Software para sistemas baseados em inteligência artificial

Sistemas que incorporam modelos de IA introduzem desafios relacionados a dados, versionamento, avaliação, monitoramento, reprodutibilidade e evolução.

O foco aqui não é apenas utilizar IA para programar, mas investigar como aplicar princípios de Engenharia de Software a sistemas que dependem de componentes de IA.

Possível recorte: estudar práticas de versionamento de modelos e dados, monitoramento de desempenho ou rastreabilidade de experimentos em um pipeline delimitado.

As 120 ideias são temas prontos para copiar?

Não.

As 120 sugestões funcionam como pontos de partida estruturados.

Mesmo uma formulação aparentemente específica ainda pode precisar de ajustes conforme:

• a literatura encontrada;
• os dados disponíveis;
• o método escolhido;
• o prazo;
• as exigências do curso;
• a orientação recebida.

Por exemplo, o tema:

“Qualidade do código gerado por modelos de inteligência artificial”

ainda deixa perguntas importantes:

• qual linguagem?
• qual tipo de tarefa?
• qual sistema ou modelo?
• o que significa qualidade?
• qual amostra?
• qual método?
• qual referência será utilizada?

Essas decisões fazem parte da delimitação.

Quais são os temas mais atuais para TCC em Engenharia de Software?

Um tema atual não precisa depender da tecnologia lançada mais recentemente.

Em muitos casos, os trabalhos mais consistentes combinam um problema duradouro da Engenharia de Software com um contexto tecnológico contemporâneo.

Testabilidade, manutenção, qualidade, segurança, confiabilidade, produtividade, requisitos e evolução continuam relevantes mesmo quando linguagens, frameworks e plataformas mudam.

Entre as frentes contemporâneas que podem gerar pesquisas estão:

• inteligência artificial aplicada ao desenvolvimento de software;
• qualidade e segurança de código produzido com assistência de IA;
• testes apoiados por modelos generativos;
• Engenharia de Software para sistemas que incorporam IA;
• DevSecOps;
• automação de integração e entrega;
• observabilidade;
• segurança da cadeia de dependências;
• experiência do desenvolvedor;
• Green Software;
• mineração de repositórios;
• reprodutibilidade de pesquisas empíricas.

Atualidade e viabilidade não são a mesma coisa

Um assunto pode ser muito recente e ainda assim resultar em um TCC difícil de executar.

Isso pode acontecer quando:

• existe pouca literatura científica;
• os dados não estão disponíveis;
• a tecnologia muda durante a pesquisa;
• o serviço depende de acesso pago;
• a infraestrutura necessária é incompatível com os recursos do estudante;
• a avaliação exige participantes difíceis de recrutar;
• o problema continua amplo demais;
• não existe critério claro para avaliar os resultados.

Como tornar um tema atual mais evergreen

Uma estratégia é formular o problema em torno do fenômeno e utilizar a ferramenta específica como objeto do estudo.

Formulação muito dependente da ferramenta	Formulação mais duradoura
Ferramenta X para escrever código	Assistentes de programação baseados em inteligência artificial
Plataforma Y para CI/CD	Automação de integração e entrega contínua
Scanner Z de vulnerabilidades	Análise automatizada de segurança durante o desenvolvimento
Plugin A de testes	Automação ou geração de casos de teste
Serviço B de monitoramento	Observabilidade e diagnóstico de falhas

Isso não significa esconder qual tecnologia foi utilizada.

Na metodologia, o estudante deve documentar ferramentas, versões, configurações e ambiente sempre que forem relevantes.

A diferença está em não construir todo o valor científico do trabalho sobre a expectativa de que uma marca, produto ou serviço continuará popular.

Como transformar uma ideia de Engenharia de Software em problema de pesquisa

Encontrar uma ideia interessante é apenas o início.

O passo seguinte é transformá-la em uma questão que possa ser investigada com evidências.

Isso é especialmente importante em Engenharia de Software porque muitos estudantes começam por assuntos amplos, como:

• inteligência artificial;
• microsserviços;
• DevOps;
• testes automatizados;
• métodos ágeis;
• dívida técnica;
• segurança;
• Green Software.

Todos podem originar bons trabalhos. Nenhum deles, sozinho, define o que será pesquisado.

Para avançar, utilize a seguinte sequência como ferramenta de raciocínio:

Você não precisa necessariamente definir esses elementos em uma única sessão. É comum que a revisão bibliográfica faça o estudante retornar às etapas anteriores e refine a pergunta.

1. Defina a área

Comece identificando em qual território da Engenharia de Software a ideia se encontra.

Por exemplo:

• Engenharia de Requisitos;
• Arquitetura;
• Qualidade;
• Testes;
• DevOps;
• Manutenção;
• Processos;
• Segurança;
• Engenharia de Software empírica.

A área funciona como um mapa inicial. Ela ainda não é o tema final.

2. Encontre um problema dentro da área

Pergunte o que existe de incerto, difícil, variável ou passível de avaliação.

Em testes de software, por exemplo, alguns problemas possíveis seriam:

• suítes muito demoradas;
• testes instáveis;
• baixa capacidade de detectar defeitos;
• alto esforço de manutenção;
• dificuldade de selecionar testes relevantes após uma mudança.

Perceba que “testes automatizados” deixou de ser apenas um assunto e começou a se desdobrar em fenômenos investigáveis.

3. Identifique o artefato ou processo observado

Depois, pergunte: onde o problema se manifesta?

O objeto pode ser:

• código;
• casos de teste;
• requisitos;
• issues;
• commits;
• pull requests;
• pipelines;
• APIs;
• documentação;
• arquitetura;
• processo de revisão;
• processo de entrega.

Definir o objeto ajuda a imaginar quais dados poderão ser coletados.

4. Defina o contexto

O mesmo fenômeno pode se comportar de maneiras diferentes conforme o contexto.

Você pode estudar:

• projetos open source;
• uma organização;
• aplicações web;
• bibliotecas;
• sistemas legados;
• equipes de desenvolvimento;
• tarefas experimentais;
• um conjunto de projetos de determinada linguagem ou ecossistema.

Quanto mais claro for o contexto, mais fácil será avaliar até onde as conclusões poderão ser aplicadas.

5. Escolha o que será observado ou avaliado

Palavras como “qualidade”, “eficiência”, “produtividade” e “melhor” são amplas.

É necessário perguntar o que essas expressões significarão na pesquisa.

Dependendo do problema, podem ser observados:

• tempo de execução;
• tempo de desenvolvimento;
• defeitos;
• cobertura de testes;
• mutation score;
• complexidade;
• acoplamento;
• consumo de memória;
• latência;
• consumo de recursos;
• frequência de mudanças;
• tempo de revisão;
• percepção dos participantes.

Uma variável fácil de medir não deve ser escolhida apenas porque está disponível. Ela precisa representar algo relevante para a pergunta.

6. Faça um recorte

O recorte impede que a pesquisa tente estudar um universo maior do que o TCC comporta.

Você pode limitar:

• quantidade de projetos;
• período;
• linguagem;
• tipo de aplicação;
• versões;
• participantes;
• categoria de defeito;
• tipo de requisito;
• técnica;
• característica de qualidade.

7. Escolha um método compatível

A metodologia deve surgir da pergunta e das evidências necessárias, e não apenas da preferência por uma técnica.

Por exemplo:

• comparar duas condições pode sugerir um experimento;
• compreender profundamente um projeto pode sugerir estudo de caso;
• investigar percepções pode exigir survey ou entrevistas;
• estudar evolução pode utilizar mineração de repositórios;
• sintetizar conhecimento existente pode exigir uma revisão da literatura.

8. Formule a pergunta de pesquisa

Somente depois desses refinamentos a pergunta tende a ganhar precisão.

Considere o assunto:

“Testes de regressão.”

Ele pode evoluir assim:

Área: testes de software.

Problema: suítes de regressão extensas podem fornecer feedback lentamente.

Artefato: suíte de testes.

Contexto: projetos ou sistemas definidos pelo estudo.

Variável: tempo até a detecção de falhas.

Recorte: estratégias específicas de priorização.

Método possível: experimento ou avaliação retrospectiva utilizando históricos adequados.

A pergunta poderia assumir uma formulação semelhante a:

“Como diferentes estratégias de priorização de testes afetam o tempo até a identificação de falhas em suítes de regressão selecionadas?”

A formulação final dependerá do desenho efetivamente adotado.

Se você não consegue completar essa frase, talvez ainda exista uma distância entre o tema escolhido e a forma como ele será investigado.

Para aprofundar essa etapa, consulte também o guia sobre como fazer o problema de pesquisa do TCC.

Exemplo 1: inteligência artificial aplicada à Engenharia de Software

Assunto: inteligência artificial.

Área: IA aplicada a testes de software.

Problema: incerteza sobre a qualidade de testes produzidos com assistência de modelos generativos.

Artefato: casos de teste.

Contexto: conjunto delimitado de tarefas ou funções.

Critérios: por exemplo, correção, cobertura e capacidade de detectar defeitos.

Método possível: experimento comparativo.

Agora o TCC já não é genericamente “sobre IA”. Ele investiga uma aplicação específica, em uma atividade da Engenharia de Software, utilizando critérios que podem ser observados.

Exemplo 2: microsserviços

Assunto: microsserviços.

Área: arquitetura e manutenção.

Problema: complexidade de manutenção associada a dependências entre serviços.

Artefato: serviços e suas dependências.

Contexto: projetos selecionados.

Critérios: acoplamento, coevolução ou outra característica coerente com a pergunta.

Método possível: mineração de repositórios ou estudo de caso.

A arquitetura passa a ser contexto de um problema específico, e não apenas um conceito a ser descrito.

Exemplo 3: métodos ágeis

Assunto: Kanban.

Área: Engenharia de Processos.

Problema: acúmulo de trabalho em progresso.

Processo: fluxo de atividades.

Critérios: tempo de ciclo e quantidade de itens simultâneos.

Contexto: equipe, projeto ou ambiente experimental delimitado.

Método possível: estudo longitudinal, estudo de caso ou experimento, conforme a pergunta e as condições disponíveis.

Isso permite investigar uma prática específica sem tentar concluir se “Kanban é melhor”.

Exemplo 4: dívida técnica

Assunto: dívida técnica.

Área: manutenção e evolução.

Problema: componentes com determinados indicadores podem exigir mudanças frequentes.

Artefato: código-fonte.

Indicadores possíveis: categorias específicas de code smells e frequência de mudanças.

Contexto: projetos open source selecionados.

Método possível: mineração de repositórios.

A pergunta pode investigar associação entre os indicadores, sem assumir previamente que um deles causa o outro.

Como delimitar um tema de TCC em Engenharia de Software

Delimitar não significa apenas “diminuir o tema”.

Significa estabelecer fronteiras claras para a investigação.

Essas fronteiras indicam o que será estudado e, igualmente importante, o que ficará fora do trabalho.

Uma boa delimitação ajuda a:

• reduzir o volume de literatura irrelevante;
• definir a coleta;
• selecionar métricas;
• escolher o método;
• planejar o cronograma;
• interpretar corretamente as conclusões.

Delimitação pelo objeto

Em vez de estudar “qualidade de software”, você pode estudar:

• código-fonte;
• testes;
• APIs;
• requisitos;
• pipelines;
• documentação;
• pull requests.

O objeto indica onde as evidências serão observadas.

Delimitação pela característica

“Qualidade” pode ser dividida em diferentes características.

Por exemplo:

• manutenibilidade;
• desempenho;
• confiabilidade;
• segurança;
• usabilidade;
• acessibilidade;
• eficiência de recursos.

Tentar avaliar todas simultaneamente pode tornar o TCC inviável.

Delimitação pelo contexto

Você pode restringir a investigação a:

• projetos open source;
• aplicações web;
• bibliotecas;
• uma organização;
• equipes ágeis;
• sistemas legados;
• tarefas experimentais.

O contexto também influencia até onde os resultados podem ser generalizados.

Delimitação temporal

Pesquisas baseadas em históricos podem analisar:

• determinado período;
• releases específicas;
• intervalos antes e depois de uma mudança;
• versões selecionadas segundo critérios definidos.

O período não deve ser escolhido apenas por conveniência. Explique por que ele é adequado ao problema.

Delimitação pela população ou amostra

Se o trabalho envolve projetos, participantes, issues, commits ou pull requests, defina critérios de inclusão e exclusão.

Em projetos open source, por exemplo, podem ser considerados:

• linguagem;
• idade do projeto;
• quantidade de releases;
• atividade recente;
• presença de testes;
• volume de histórico;
• tipo de licença;
• domínio da aplicação.

O objetivo não é selecionar uma amostra que confirme a hipótese, mas estabelecer critérios defensáveis e reproduzíveis.

Delimitação pela tecnologia

Linguagem, framework, arquitetura ou ferramenta podem fazer parte do recorte quando existe justificativa.

Por exemplo, estudar apenas projetos Java pode ser adequado se:

• a ferramenta de análise utilizada funciona nesse ecossistema;
• o fenômeno depende de características da linguagem;
• o universo da pesquisa foi explicitamente definido dessa forma.

O cuidado é não transformar uma conveniência técnica em uma generalização sobre todo o desenvolvimento de software.

Delimitação pelo método

O próprio desenho metodológico cria limites.

Um estudo de caso aprofundado possui objetivos diferentes de uma mineração de centenas de repositórios.

Da mesma forma, um experimento controlado pode oferecer maior controle sobre determinadas variáveis, mas representar um contexto mais artificial.

Exemplo de delimitação progressiva

Considere novamente um estudante interessado em IA.

Nível 1 — muito amplo:
Inteligência artificial na Engenharia de Software.

Nível 2:
Inteligência artificial na geração de código.

Nível 3:
Qualidade de código produzido com assistência de IA.

Nível 4:
Manutenibilidade de código produzido com assistência de IA.

Nível 5:
Comparação de indicadores de manutenibilidade entre soluções produzidas com e sem assistência de IA em tarefas controladas de programação.

O quinto nível já fornece muito mais informação sobre:

• o objeto;
• a comparação;
• a característica avaliada;
• o contexto.

Ainda assim, o estudante poderá precisar definir linguagem, tarefas, sistema de IA, indicadores e protocolo.

Também é possível delimitar demais

Reduzir o tema indefinidamente não garante uma pesquisa melhor.

Um recorte excessivamente estreito pode criar outros problemas:

• literatura insuficiente;
• amostra pequena demais para a análise pretendida;
• resultado dependente de uma configuração muito particular;
• dificuldade de justificar relevância acadêmica;
• estudo de uma única ocorrência sem justificativa metodológica.

O objetivo é encontrar um equilíbrio entre profundidade e viabilidade.

Faça o teste da frase única

Depois de delimitar, tente explicar o projeto em uma frase:

Exemplo:

“Quero investigar a relação entre determinadas categorias de code smells e frequência de mudanças em projetos open source selecionados, utilizando histórico de versões e métricas de código.”

A frase não precisa ser o título do TCC. Ela funciona como teste de clareza.

O título também melhora depois da delimitação

Compare:

Antes:
“Inteligência Artificial na Engenharia de Software”

Depois:
“Avaliação da manutenibilidade de código produzido com assistência de IA em tarefas controladas de programação”

O segundo título ainda pode ser refinado, mas já comunica melhor o objeto e a característica investigada.

Se precisar aprofundar esse processo, consulte o guia sobre como delimitar o tema do TCC.

Qual metodologia usar no TCC de Engenharia de Software?

Não existe uma metodologia única para TCC em Engenharia de Software.

A escolha depende principalmente de três perguntas:

• o que você pretende descobrir?
• que evidências seriam necessárias para responder à pergunta?
• como essas evidências podem ser obtidas e analisadas de maneira adequada?

Um erro comum é escolher primeiro uma metodologia porque ela parece simples e, depois, tentar adaptar o problema a ela.

O caminho mais consistente costuma ser o inverso:

Dependendo do objetivo, o TCC pode utilizar experimento, estudo de caso, survey, entrevistas, mineração de repositórios, análise de código, benchmark, revisão da literatura, desenvolvimento e avaliação de artefato ou combinações justificadas desses procedimentos.

Experimento

Experimentos são úteis quando o objetivo envolve comparar condições sob um protocolo definido.

Exemplos:

• comparar desenvolvimento com e sem assistência de IA;
• avaliar duas estratégias de priorização de testes;
• comparar desempenho de duas implementações;
• verificar resultados antes e depois de determinada intervenção.

Um experimento exige cuidado com:

• variáveis;
• condições comparadas;
• tarefas;
• amostra;
• ambiente;
• repetições;
• procedimento de coleta;
• ameaças à validade.

Se uma implementação é executada em condições diferentes da outra, por exemplo, pode ser difícil saber se a diferença observada veio realmente do fator que a pesquisa pretendia estudar.

Estudo de caso

O estudo de caso pode ser adequado quando o pesquisador pretende compreender um fenômeno em profundidade dentro de um contexto delimitado.

Esse contexto pode ser:

• um projeto;
• uma organização;
• uma equipe;
• um sistema;
• um processo;
• uma iniciativa de modernização;
• uma implantação de determinada prática.

Um estudo de caso não precisa ser tratado como uma descrição informal do que aconteceu. É importante definir questão, unidade de análise, fontes de evidência e procedimento de interpretação.

Survey

Surveys podem ser úteis quando a pesquisa busca informações sobre práticas, experiências, percepções ou opiniões de uma população.

Por exemplo:

• percepção de desenvolvedores sobre determinada prática;
• uso de ferramentas;
• dificuldades em revisão de código;
• experiência com documentação;
• adoção de determinadas técnicas.

O estudante precisa considerar construção do instrumento, população-alvo, forma de recrutamento, taxa de resposta, vieses e análise.

Também é importante distinguir percepção declarada de comportamento efetivamente observado.

Entrevistas

Entrevistas permitem explorar experiências e decisões com maior profundidade.

Elas podem ser adequadas quando a pergunta exige compreender:

• motivações;
• dificuldades;
• processos de decisão;
• interpretações;
• práticas que não aparecem completamente nos registros técnicos.

Pesquisas envolvendo participantes humanos devem observar as exigências éticas e institucionais aplicáveis.

Mineração de repositórios de software

Repositórios podem fornecer grande quantidade de dados sobre evolução de software.

Entre os possíveis artefatos estão:

• commits;
• arquivos;
• branches;
• tags;
• releases;
• issues;
• pull requests;
• comentários;
• revisões;
• configurações de automação.

Essa metodologia combina especialmente bem com problemas sobre manutenção, evolução, colaboração, revisão, defeitos e dependências.

Entretanto, a existência de dados públicos não significa que qualquer interpretação seja válida.

Um commit, por exemplo, pode representar uma pequena correção ou uma grande alteração. Por isso, contagens simples precisam ser contextualizadas.

Análise de código e métricas de software

O próprio código pode fornecer evidências sobre características estruturais.

Dependendo da pesquisa, podem ser analisados:

• complexidade;
• acoplamento;
• coesão;
• tamanho;
• duplicação;
• dependências;
• code smells;
• cobertura;
• outras métricas justificadas pelo problema.

O ponto central é evitar a interpretação automática de que uma métrica isolada representa “qualidade”.

Métricas são indicadores. Seu significado depende do constructo, do contexto e do procedimento de análise.

Benchmark

Benchmarks podem ser utilizados para comparar implementações, configurações, algoritmos, arquiteturas ou ferramentas sob condições controladas.

Um bom benchmark documenta elementos como:

• hardware;
• sistema operacional;
• versões;
• configurações;
• carga;
• dados utilizados;
• quantidade de repetições;
• procedimento de medição.

Sem esse controle, diferenças atribuídas à solução podem ter sido provocadas pelo ambiente.

Revisão da literatura

Nem todo TCC em Engenharia de Software precisa produzir dados primários.

Uma pesquisa pode organizar, comparar e sintetizar evidências já publicadas sobre determinado problema.

O tipo de revisão deve ser escolhido de acordo com a pergunta e com o nível de rigor exigido pelo trabalho.

Se esse for o caminho, consulte também os conteúdos sobre como fazer busca bibliográfica e como encontrar artigos científicos.

Desenvolvimento de artefato acompanhado de avaliação

Em cursos tecnológicos e de computação, é comum que o estudante desenvolva:

• aplicação;
• ferramenta;
• plugin;
• biblioteca;
• protótipo;
• pipeline;
• framework;
• método;
• ou outro artefato.

Esse desenvolvimento pode integrar uma pesquisa consistente quando o artefato é construído para responder a um problema e posteriormente avaliado com critérios compatíveis.

O artefato, portanto, pode ser parte do método ou resultado da pesquisa, mas sua existência não elimina a necessidade de investigação.

Métodos mistos

Em alguns trabalhos, combinar evidências quantitativas e qualitativas pode oferecer uma visão mais completa.

Por exemplo, um estudo sobre developer experience poderia combinar:

• tempo necessário para configurar um ambiente;
• quantidade de erros encontrados;
• questionário;
• entrevista sobre as dificuldades percebidas.

Entretanto, adicionar métodos aumenta o esforço.

A combinação deve existir porque ajuda a responder à pergunta, e não apenas para tornar a metodologia aparentemente mais sofisticada.

Como relacionar objetivo e metodologia

Objetivo predominante	Métodos que podem ser considerados
Comparar duas condições	Experimento, benchmark ou estudo comparativo
Compreender profundamente um contexto	Estudo de caso
Investigar percepções ou práticas declaradas	Survey e/ou entrevistas
Analisar evolução histórica de projetos	Mineração de repositórios
Avaliar características estruturais	Análise de código e métricas
Sintetizar o conhecimento científico existente	Revisão da literatura adequada à pergunta
Propor uma solução para um problema	Desenvolvimento de artefato acompanhado de avaliação

Para aprofundar essa etapa, consulte também o guia sobre como fazer a metodologia do TCC.

Um TCC de Engenharia de Software precisa desenvolver um software?

Não necessariamente.

O fato de o curso envolver desenvolvimento de software não significa que todo trabalho acadêmico precise resultar em uma nova aplicação.

Dependendo do problema, um TCC pode:

• analisar projetos existentes;
• minerar repositórios;
• avaliar técnicas;
• comparar abordagens;
• estudar um processo;
• investigar práticas de equipes;
• realizar experimento;
• executar benchmark;
• revisar a literatura;
• replicar um estudo;
• avaliar um dataset;
• desenvolver e avaliar um artefato.

As exigências específicas do curso ou da instituição devem ser verificadas, mas do ponto de vista metodológico desenvolver um sistema é apenas uma das possibilidades.

Quando desenvolver um software faz sentido?

O desenvolvimento é especialmente justificável quando existe uma relação clara entre o artefato e o problema de pesquisa.

Por exemplo:

• propor uma ferramenta para automatizar determinada análise;
• construir um protótipo para avaliar uma estratégia de interação;
• implementar duas soluções equivalentes para compará-las;
• desenvolver um plugin para testar uma técnica;
• criar um pipeline experimental;
• construir uma prova de conceito para avaliar viabilidade técnica.

Em todos esses casos, o desenvolvimento não encerra o trabalho.

Depois de construir, surge a pergunta:

como saber se o artefato atingiu aquilo que a pesquisa pretendia investigar?

Exemplo: projeto de sistema versus projeto de pesquisa

Considere duas propostas.

Proposta A:
“Desenvolver um aplicativo para gerenciamento de tarefas utilizando arquitetura de microsserviços.”

Essa proposta descreve um projeto de desenvolvimento. Ela pode ser adequada a determinadas disciplinas ou trabalhos práticos, mas ainda não deixa claro qual conhecimento será produzido.

Proposta B:
“Comparar o impacto de duas estratégias arquiteturais sobre uma característica de qualidade em implementações funcionalmente equivalentes de uma aplicação de gerenciamento de tarefas.”

Agora existe:

• comparação;
• critério de avaliação;
• necessidade de controle;
• evidências a serem produzidas;
• uma conclusão que dependerá dos resultados.

O software desenvolvido passa a funcionar como instrumento da investigação.

Um TCC sem sistema pode ser prático?

Sim.

Uma pesquisa baseada em repositórios reais, por exemplo, pode trabalhar com milhares de alterações produzidas durante desenvolvimento de software.

Um estudo experimental pode avaliar uma técnica de teste.

Um estudo de caso pode analisar uma migração arquitetural.

Uma pesquisa de code review pode investigar comentários e alterações reais.

Portanto, “prático” não deve ser interpretado exclusivamente como “criar um aplicativo”.

Como avaliar um software cientificamente?

Quando o TCC desenvolve, modifica ou compara software, a avaliação precisa ir além de afirmações como:

• “o sistema funcionou”;
• “a interface ficou boa”;
• “o programa ficou rápido”;
• “a solução foi eficiente”;
• “os usuários gostaram”.

Essas frases utilizam conceitos que precisam ser definidos e sustentados por evidências.

A avaliação começa antes da coleta, com uma pergunta:

qual característica do software é relevante para o problema da pesquisa?

Correção funcional

Se o objetivo envolve verificar se uma solução produz resultados corretos, podem ser utilizados:

• casos de teste;
• oráculos;
• resultados esperados;
• datasets com referência;
• comparação com implementação validada.

“Executou sem erro” não significa necessariamente “produziu o resultado correto”.

Desempenho

Dependendo do problema, desempenho pode envolver:

• tempo de resposta;
• tempo total de execução;
• vazão;
• latência;
• comportamento sob diferentes cargas.

Comparações precisam manter condições equivalentes sempre que possível.

Consumo de recursos

A avaliação pode considerar:

• CPU;
• memória;
• armazenamento;
• rede;
• energia, quando houver procedimento adequado de medição.

O ambiente deve ser documentado para que o leitor consiga interpretar os resultados.

Manutenibilidade

Manutenibilidade é multidimensional e dificilmente deve ser representada por uma única métrica.

Dependendo do desenho, podem ser consideradas evidências como:

• complexidade;
• acoplamento;
• coesão;
• frequência de mudanças;
• esforço para realizar tarefas de manutenção;
• quantidade de arquivos afetados;
• percepção de participantes.

É importante justificar por que cada indicador é relevante.

Confiabilidade

Dependendo do sistema, podem ser observados:

• falhas;
• erros;
• estabilidade;
• comportamento repetido;
• recuperação após falhas;
• disponibilidade em cenários controlados.

Usabilidade

Usabilidade não deve ser concluída apenas porque o autor considera a interface intuitiva.

A avaliação pode utilizar:

• tarefas com participantes;
• taxa de conclusão;
• tempo;
• erros;
• questionários adequados;
• observações;
• entrevistas.

Acessibilidade

A avaliação de acessibilidade pode combinar:

• critérios reconhecidos;
• inspeção;
• ferramentas automatizadas;
• avaliação manual;
• testes com usuários, quando apropriado.

Ferramentas automatizadas podem apoiar a análise, mas não necessariamente detectam todos os problemas.

Segurança

Em pesquisas de segurança, podem ser utilizados critérios, análises e testes defensivos em ambientes autorizados.

O procedimento deve respeitar limites éticos, legais e institucionais.

Eficiência energética e de recursos

Quando o problema envolve sustentabilidade, o estudo pode observar consumo de recursos ou energia sob condições controladas.

Esse tipo de avaliação precisa documentar hardware, carga, ambiente, repetições e método de medição.

Percepção dos participantes

Em alguns problemas, a percepção é uma evidência legítima.

Por exemplo:

• facilidade percebida;
• satisfação;
• dificuldade;
• confiança;
• utilidade percebida.

Entretanto, percepção e desempenho objetivo não são a mesma coisa.

Uma ferramenta pode ser percebida como rápida e, ainda assim, não reduzir o tempo medido. Da mesma forma, pode melhorar um indicador técnico sem ser bem aceita pelos participantes.

Defina o critério antes de olhar o resultado

Uma boa prática é estabelecer previamente:

• o que será medido;
• como será medido;
• em quais condições;
• quantas observações serão realizadas;
• como os dados serão analisados;
• quais limitações são esperadas.

Isso reduz o risco de escolher, depois da coleta, apenas os indicadores que favorecem a conclusão desejada.

Evite confundir métrica com conceito

Considere a afirmação:

“O sistema A possui melhor qualidade porque tem menor complexidade ciclomática.”

A conclusão é ampla demais.

A métrica informa algo sobre determinada característica estrutural, mas não representa automaticamente toda a qualidade do sistema.

Uma formulação mais cuidadosa seria descrever exatamente o que foi medido e limitar a conclusão a essa evidência.

Ameaças à validade também fazem parte da avaliação

Todo estudo possui limitações.

Em Engenharia de Software, algumas perguntas úteis são:

• a métrica realmente representa o conceito que quero estudar?
• a diferença observada pode ter sido causada por outro fator?
• a amostra é adequada ao tipo de conclusão?
• o ambiente experimental é muito diferente de situações reais?
• os projetos selecionados representam apenas um tipo específico de software?
• as ferramentas de coleta podem produzir erros?
• o procedimento pode ser repetido?

Reconhecer essas limitações não enfraquece automaticamente o TCC.

Pelo contrário: demonstra que o estudante entende até onde suas evidências permitem concluir.

Exemplo: avaliando uma ferramenta criada no TCC

Imagine que o estudante desenvolveu uma ferramenta para identificar determinado problema em código.

A avaliação poderia envolver:

1. selecionar um conjunto de casos com referência conhecida;
2. executar a ferramenta sob protocolo documentado;
3. registrar os resultados;
4. comparar achados com a referência;
5. identificar acertos, omissões e falsos alertas;
6. analisar limitações;
7. discutir em quais condições a ferramenta pode ser útil.

Perceba que a contribuição não está apenas no fato de a ferramenta existir.

Existe um processo sistemático para avaliar o que ela consegue — e o que não consegue — fazer.

Desenvolver, avaliar, analisar e concluir são etapas diferentes

Uma forma simples de visualizar a lógica é:

• desenvolver = construir ou modificar o artefato;
• avaliar = produzir evidências sobre seu comportamento ou características;
• analisar = interpretar essas evidências à luz da pergunta;
• concluir = responder à pergunta dentro dos limites do estudo.

Onde encontrar artigos, bases, datasets e projetos para o TCC?

Um tema de Engenharia de Software pode parecer excelente até o estudante descobrir que não consegue obter as evidências necessárias para investigá-lo.

Por isso, a disponibilidade de fontes não deve ser verificada apenas depois que o tema estiver completamente fechado.

Ela faz parte da própria avaliação de viabilidade.

Dependendo da pergunta, você pode precisar de:

• artigos científicos;
• livros e capítulos acadêmicos;
• normas e documentos técnicos;
• datasets;
• código-fonte;
• histórico de versões;
• issues;
• pull requests;
• resultados de testes;
• documentação;
• logs;
• participantes;
• dados de uma organização.

Essas fontes cumprem funções diferentes.

Um artigo pode ajudar a construir fundamentação teórica e identificar métodos. Um repositório pode fornecer dados empíricos. Um dataset pode permitir replicação ou comparação. Uma entrevista pode fornecer evidências sobre decisões e experiências que não aparecem no código.

Comece pela literatura científica

Mesmo quando o TCC será fortemente prático, a literatura ajuda a entender:

• como o problema já foi estudado;
• quais conceitos precisam ser definidos;
• quais métricas já foram utilizadas;
• quais métodos são comuns;
• quais limitações foram encontradas;
• quais lacunas permanecem abertas.

Isso reduz o risco de criar um projeto baseado apenas em intuição.

Uma busca inicial também ajuda a descobrir a terminologia utilizada pela comunidade científica.

Por exemplo, um estudante pode procurar inicialmente por “testes que falham às vezes” e descobrir que a literatura utiliza a expressão flaky tests. A partir daí, novas palavras-chave e estudos se tornam acessíveis.

Google Acadêmico

O Google Acadêmico pode ser utilizado para uma busca exploratória e para localizar artigos, dissertações, teses e outras publicações acadêmicas.

Ele também pode ajudar a:

• identificar autores recorrentes;
• localizar trabalhos relacionados;
• acompanhar citações;
• descobrir diferentes versões de uma publicação;
• refinar palavras-chave.

Se você ainda está estruturando sua estratégia de busca, consulte o guia sobre como usar o Google Acadêmico no TCC.

Portal de Periódicos CAPES

O Portal de Periódicos CAPES pode ampliar o acesso a bases, periódicos e publicações acadêmicas, conforme as condições de acesso disponíveis ao estudante e à instituição.

Ele pode ser especialmente útil quando o artigo identificado não está disponível diretamente em acesso aberto.

Veja também o guia sobre como usar o Portal de Periódicos CAPES.

Bases bibliográficas da área

Dependendo da instituição e do problema, bases bibliográficas especializadas em computação e áreas relacionadas podem ajudar a localizar estudos relevantes.

O ponto principal não é utilizar o maior número possível de bases.

É construir uma estratégia de busca que possa ser explicada e que seja adequada ao objetivo do trabalho.

Termos, combinações, filtros, período e critérios de seleção precisam ser coerentes com o tipo de revisão ou levantamento realizado.

Referências encontradas em bons artigos

Um artigo altamente relevante pode indicar outros trabalhos importantes por meio de suas referências.

Da mesma forma, trabalhos posteriores que o citaram podem mostrar como a discussão evoluiu.

Essa exploração pode complementar a busca principal, especialmente durante a fase inicial de compreensão do tema.

Datasets públicos

Datasets podem reduzir o esforço de coleta e permitir comparações ou replicações.

Entretanto, antes de utilizar um conjunto de dados, verifique:

• quem o produziu;
• como os dados foram coletados;
• qual é a unidade de análise;
• quais critérios de inclusão foram utilizados;
• se existem dados ausentes;
• se existem duplicações;
• como os rótulos foram produzidos;
• qual licença ou condição de uso se aplica;
• se o dataset realmente representa o problema que você pretende estudar.

Um dataset popular não é automaticamente adequado para qualquer pergunta.

Projetos open source

Projetos públicos podem fornecer artefatos reais de desenvolvimento e evolução.

Entre as possibilidades estão:

• código;
• histórico de commits;
• issues;
• pull requests;
• releases;
• testes;
• documentação;
• arquivos de configuração;
• registros de automação.

Entretanto, a seleção dos projetos precisa ser justificada.

Escolher apenas os primeiros resultados encontrados ou apenas os projetos mais populares pode introduzir vieses importantes.

Dados de organizações

Quando o TCC depende de dados de uma empresa, laboratório ou instituição, confirme o acesso antes de construir todo o projeto em torno deles.

Pergunte:

• a autorização realmente existe?
• quais dados poderão ser utilizados?
• eles poderão aparecer no trabalho?
• existem informações confidenciais?
• será necessário anonimizar dados?
• o acesso continuará disponível durante o TCC?

Um projeto metodologicamente excelente pode se tornar inviável se sua única fonte de dados deixar de estar acessível.

Como avaliar se uma fonte é adequada?

A pergunta não deve ser apenas “essa fonte é confiável?”.

Também pergunte:

• ela é adequada ao tipo de afirmação que pretendo fazer?
• é suficientemente atual para esse aspecto do tema?
• possui metodologia identificável?
• os dados são rastreáveis?
• há limitações declaradas?
• é uma fonte primária ou apenas reproduz informação de terceiros?

Para aprofundar essa avaliação, consulte como escolher fontes confiáveis para o TCC.

Organize as referências desde o começo

Esperar o final do trabalho para organizar referências pode gerar:

• fontes perdidas;
• duplicações;
• citações sem referência correspondente;
• dificuldade para localizar novamente um artigo;
• inconsistências bibliográficas.

Registre os trabalhos relevantes durante a busca e mantenha uma organização mínima desde as primeiras leituras.

O guia sobre como organizar referências bibliográficas no TCC pode ajudar nessa etapa.

Como usar GitHub e repositórios de software em um TCC?

Repositórios de software podem funcionar como verdadeiros registros históricos do desenvolvimento.

Isso torna plataformas de hospedagem de código especialmente interessantes para pesquisas sobre Engenharia de Software.

Mas utilizar um repositório em um TCC não significa simplesmente “baixar dados do GitHub”.

O primeiro passo continua sendo definir qual pergunta será respondida.

Que dados podem ser encontrados em um repositório?

Dependendo do projeto e da plataforma, podem estar disponíveis:

• commits;
• autores e datas;
• arquivos modificados;
• mensagens de commit;
• branches;
• tags;
• releases;
• issues;
• labels;
• pull requests;
• comentários;
• revisões de código;
• testes;
• documentação;
• configurações de CI/CD;
• metadados do projeto.

Nem todo repositório possui todos esses elementos, e nem todos são utilizados da mesma maneira.

Commits

Commits podem ajudar a investigar evolução e mudanças no código.

Por exemplo, é possível estudar:

• arquivos que mudam juntos;
• frequência de alterações;
• evolução de módulos;
• mudanças em testes;
• alterações de dependências.

Entretanto, commits possuem granularidades diferentes.

Um desenvolvedor pode agrupar várias alterações em um commit, enquanto outro pode produzir diversos commits pequenos para uma única tarefa.

Issues

Issues podem registrar:

• defeitos;
• solicitações de funcionalidade;
• tarefas;
• dúvidas;
• melhorias;
• discussões.

Antes de utilizá-las, entenda como o projeto organiza seus registros.

Em alguns repositórios, labels distinguem defeitos de funcionalidades. Em outros, a classificação pode ser incompleta ou inconsistente.

Pull requests

Pull requests podem ser úteis para estudar:

• revisão de código;
• tempo de integração;
• comentários;
• alterações solicitadas;
• participação de revisores;
• automação;
• tamanho das mudanças.

Mais uma vez, a unidade precisa ser interpretada no contexto do projeto.

Releases e tags

Releases podem ajudar a estabelecer recortes temporais e comparar versões representativas.

Elas também podem ser úteis em pesquisas sobre:

• evolução arquitetural;
• dependências;
• mudanças de API;
• métricas de código;
• testes;
• documentação.

Histórico de código

O histórico permite observar como estruturas evoluem.

Isso pode ser utilizado para estudar:

• complexidade;
• acoplamento;
• code smells;
• refatorações;
• dependências;
• coevolução;
• dívida técnica.

Uma pesquisa longitudinal precisa definir quais versões ou períodos serão comparados e por quê.

Testes

Repositórios que possuem suítes de testes podem permitir pesquisas sobre:

• cobertura;
• evolução dos testes;
• flaky tests;
• mutation testing;
• relação entre código de produção e testes;
• manutenção das suítes.

Configurações de automação

Arquivos de configuração de pipelines podem ser utilizados para estudar práticas de integração, entrega, testes e verificações automatizadas.

Entretanto, a presença de uma configuração no repositório não garante que ela esteve ativa durante todo o período analisado.

Quando possível, combine diferentes fontes de evidência.

Como selecionar projetos para a pesquisa?

A seleção precisa ser reproduzível e coerente com a pergunta.

Critérios possíveis incluem:

• linguagem;
• domínio;
• licença;
• idade;
• atividade;
• quantidade mínima de commits;
• quantidade de contribuidores;
• presença de releases;
• presença de testes;
• uso de determinada prática;
• disponibilidade dos artefatos necessários.

Não é necessário utilizar todos esses critérios. Escolha aqueles que possuem relação metodológica com o estudo.

Popularidade não deve ser o único critério

Projetos com muitas estrelas ou grande visibilidade podem possuir documentação e históricos ricos, mas representam um subconjunto particular do universo de software.

Se a pesquisa utiliza apenas projetos muito populares, essa escolha precisa ser reconhecida na interpretação dos resultados.

Dados públicos ainda precisam de interpretação

Um dos maiores riscos na mineração de repositórios é transformar aquilo que é fácil de contar em algo que o dado não representa.

Exemplos:

• mais commits ≠ automaticamente mais produtividade;
• mais linhas de código ≠ automaticamente maior contribuição;
• mais issues ≠ automaticamente software de pior qualidade;
• mais pull requests ≠ automaticamente maior colaboração;
• mais testes ≠ automaticamente melhor cobertura de comportamento;
• mais comentários ≠ automaticamente melhor revisão.

A interpretação precisa estar vinculada ao problema e apoiada por literatura.

Documente a coleta para permitir reprodução

Imagine que o TCC afirma:

“Foram analisados projetos Java disponíveis no GitHub.”

Essa descrição ainda é insuficiente.

Outro pesquisador não sabe:

• quando a busca foi feita;
• qual consulta foi utilizada;
• quantos projetos apareceram;
• quais filtros foram aplicados;
• quais projetos foram excluídos;
• quais versões foram analisadas;
• como os dados foram processados.

Uma coleta mais reproduzível documenta, quando aplicável:

• data ou período da coleta;
• consulta utilizada;
• critérios de inclusão;
• critérios de exclusão;
• lista ou identificação dos projetos;
• versões, releases ou commits analisados;
• scripts de coleta;
• versões das ferramentas;
• filtros;
• transformações;
• tratamento de dados ausentes ou duplicados.

Faça um piloto antes de coletar centenas de projetos

Antes de automatizar a coleta em larga escala, experimente o procedimento em poucos casos.

O piloto pode revelar:

• campos ausentes;
• limites de API;
• inconsistências;
• diferenças entre projetos;
• problemas de classificação;
• tempo de processamento;
• volume de armazenamento;
• dificuldades de reprodução.

Descobrir esses problemas com cinco projetos costuma ser muito mais fácil do que descobri-los depois de coletar quinhentos.

Como saber se um tema de Engenharia de Software é viável?

Viabilidade é uma das etapas mais importantes da escolha do tema.

Um assunto pode ser interessante, atual e academicamente relevante, mas ainda assim não caber no prazo, nos recursos ou nas condições reais do estudante.

Antes de confirmar a proposta, faça uma auditoria prática.

1. Existe literatura científica suficiente?

Faça uma busca exploratória.

Você não precisa encontrar dezenas de trabalhos idênticos ao que pretende fazer. Porém, deve existir literatura suficiente para:

• definir os conceitos principais;
• entender o problema;
• identificar métodos;
• justificar escolhas;
• comparar resultados.

Se quase nada aparece, verifique se:

• os termos de busca estão inadequados;
• o problema é novo;
• a terminologia utilizada pela literatura é diferente;
• o tema está específico demais.

2. Os dados realmente estão acessíveis?

Não basta saber que os dados existem.

Você precisa conseguir obtê-los em formato e condições compatíveis com a pesquisa.

Por exemplo:

• o repositório é público?
• o histórico necessário está disponível?
• as issues possuem classificação utilizável?
• o dataset pode ser utilizado?
• a empresa autorizou o acesso?
• os participantes podem ser recrutados?

3. Você consegue definir a unidade de análise?

A unidade pode ser:

• projeto;
• arquivo;
• classe;
• função;
• commit;
• pull request;
• issue;
• participante;
• tarefa;
• release.

Se você não sabe exatamente o que será observado, a coleta ainda está indefinida.

4. O método cabe no prazo?

Considere não apenas o tempo de coleta, mas também:

• preparação;
• limpeza dos dados;
• implementação de scripts;
• recrutamento;
• execução;
• análise;
• redação;
• revisão.

Um projeto pode parecer pequeno até que essas etapas sejam colocadas no cronograma.

5. Você possui os recursos técnicos necessários?

Alguns estudos exigem:

• hardware específico;
• grande capacidade computacional;
• serviços pagos;
• licenças;
• ambientes controlados;
• dispositivos;
• armazenamento;
• acesso a APIs.

Confirme esses recursos antes de tornar a pesquisa dependente deles.

6. O projeto depende demais de um serviço externo?

APIs, plataformas e modelos podem:

• mudar;
• alterar preços;
• reduzir limites;
• encerrar funcionalidades;
• modificar resultados.

Quando o estudo depende de um serviço externo, planeje como documentar essa dependência e considere alternativas quando possível.

7. A avaliação está definida?

Se você pretende desenvolver ou comparar alguma solução, precisa saber antecipadamente como o resultado será avaliado.

Evite chegar ao fim do desenvolvimento e somente então perguntar:

“Agora, como vou provar que isso funciona?”

A avaliação deve fazer parte do desenho desde o início.

8. O tamanho da amostra é administrável?

Mais dados não significam automaticamente pesquisa melhor.

Uma amostra muito grande pode criar:

• custos de processamento;
• dificuldade de limpeza;
• erros de coleta;
• problemas de armazenamento;
• análises superficiais.

O tamanho deve ser compatível com a pergunta, o método e os recursos disponíveis.

9. Você consegue explicar as limitações?

Todo recorte exclui alguma coisa.

Se o estudo analisa apenas projetos Java, isso limita a generalização.

Se utiliza estudantes em um experimento, isso precisa ser considerado ao discutir contextos profissionais.

Se analisa apenas projetos populares, a amostra pode não representar projetos pequenos.

Antecipar essas limitações ajuda a formular conclusões mais responsáveis.

10. Existe tempo para imprevistos?

Projetos de software e pesquisas empíricas podem apresentar:

• bugs em scripts;
• dados incompletos;
• problemas de ambiente;
• mudanças em APIs;
• dificuldades de recrutamento;
• necessidade de refazer análises.

Um cronograma sem margem pode transformar um pequeno problema técnico em atraso significativo.

Teste rápido de viabilidade

Um tema começa a se tornar mais seguro quando você consegue responder claramente:

• qual problema será investigado?
• qual é a unidade de análise?
• quais evidências serão necessárias?
• onde essas evidências serão obtidas?
• qual método será utilizado?
• como os resultados serão avaliados?
• quais recursos serão necessários?
• quais são as principais limitações?
• quanto tempo cada etapa pode consumir?

Se várias dessas respostas ainda dependem de “vou descobrir depois”, o tema provavelmente precisa de mais preparação antes de ser confirmado.

Essa fórmula não garante que o TCC ficará livre de dificuldades.

Ela reduz a chance de escolher um projeto que dependa de condições que o estudante não consegue controlar.

Checklist para escolher um tema de TCC em Engenharia de Software

Depois de explorar as 120 ideias e compreender como transformar um assunto em problema de pesquisa, vale fazer uma última verificação antes de confirmar o tema.

O objetivo deste checklist não é encontrar um tema “perfeito”.

Ele ajuda a identificar riscos enquanto ainda existe tempo para ajustar escopo, método, dados ou pergunta.

1. Consigo explicar o problema sem citar apenas uma tecnologia?

Experimente explicar o TCC sem depender do nome de uma ferramenta, linguagem ou plataforma.

Se a única descrição possível for:

“Meu TCC será sobre a ferramenta X.”

ainda falta identificar o problema.

Uma formulação mais madura seria:

“Quero avaliar como determinada forma de assistência automatizada influencia uma característica específica durante uma tarefa de desenvolvimento.”

A tecnologia pode continuar no estudo, mas passa a ocupar um papel metodológico ou contextual.

2. Minha pergunta de pesquisa está específica o suficiente?

Uma pergunta como:

“Qual é o impacto da inteligência artificial no desenvolvimento de software?”

é ampla demais para um TCC típico.

Ela não informa:

• qual atividade;
• qual tipo de IA;
• qual contexto;
• qual impacto;
• qual população;
• qual evidência.

Quanto mais específica for a pergunta, mais fácil será planejar uma forma coerente de respondê-la.

3. Consigo identificar claramente minha unidade de análise?

Pergunte:

o que exatamente será observado?

A unidade pode ser:

• um projeto;
• um arquivo;
• uma classe;
• uma função;
• um commit;
• uma issue;
• um pull request;
• um teste;
• uma release;
• uma tarefa;
• um participante;
• uma equipe.

Se você ainda não sabe qual é a unidade, provavelmente a coleta também não está suficientemente definida.

4. Sei quais evidências preciso coletar?

Complete a frase:

“Para responder à minha pergunta, preciso de dados sobre ______.”

Se o espaço continuar indefinido, retorne ao problema.

A pesquisa precisa conectar pergunta e evidência.

5. Essas evidências estão realmente acessíveis?

Não basta saber que o dado existe em algum lugar.

Verifique se você consegue utilizá-lo dentro das condições reais do TCC.

Exemplos:

• o repositório está acessível?
• o histórico necessário existe?
• o dataset possui condições adequadas de uso?
• a empresa autorizou o acesso?
• os participantes podem ser recrutados?
• a API estará disponível?

6. Existe literatura científica suficiente?

Faça uma busca exploratória antes de fechar o tema.

Procure trabalhos que ajudem a:

• definir conceitos;
• compreender o problema;
• identificar métodos;
• escolher métricas;
• comparar resultados;
• reconhecer limitações.

Se você só encontra blogs, vídeos ou páginas comerciais, talvez seja necessário rever os termos de busca ou o próprio recorte.

7. O método escolhido consegue responder à pergunta?

Não escolha a metodologia apenas porque parece mais fácil.

Por exemplo:

• uma pergunta sobre percepção pode exigir participantes;
• uma pergunta sobre evolução pode exigir histórico;
• uma comparação controlada pode sugerir experimento;
• uma pergunta sobre estrutura do código pode exigir análise estática ou métricas;
• uma pergunta sobre conhecimento acumulado pode exigir revisão da literatura.

O método precisa produzir o tipo de evidência necessário para a conclusão pretendida.

8. Consigo definir o que significa “melhor”, “eficiente” ou “qualidade”?

Essas palavras parecem claras, mas podem representar coisas diferentes.

“Melhor” pode significar:

• mais rápido;
• mais correto;
• mais fácil de manter;
• mais seguro;
• mais acessível;
• mais econômico em recursos;
• mais bem avaliado por usuários.

Se o TCC utiliza um conceito amplo, transforme-o em critérios observáveis e justificáveis.

9. Estou tentando avaliar coisas demais?

Um projeto que pretende comparar simultaneamente:

• desempenho;
• segurança;
• usabilidade;
• manutenibilidade;
• confiabilidade;
• produtividade;

pode ultrapassar facilmente o escopo de um TCC.

Escolher uma ou poucas dimensões centrais geralmente permite análise mais profunda.

10. Meu TCC depende de fatores externos que não controlo?

Verifique se o projeto depende de:

• uma API comercial;
• um serviço pago;
• dados de empresa;
• hardware emprestado;
• grande número de participantes;
• acesso institucional;
• uma ferramenta específica.

Quanto maior a dependência externa, maior a necessidade de um plano alternativo.

11. Tenho os recursos técnicos necessários?

Considere:

• hardware;
• software;
• armazenamento;
• capacidade de processamento;
• conhecimento de programação;
• ferramentas de análise;
• tempo de aprendizagem.

Um tema não precisa ser abandonado porque exige aprendizado, mas esse aprendizado precisa caber no cronograma.

12. Consigo executar um piloto?

O piloto é uma das formas mais eficientes de verificar viabilidade.

Você pode:

• analisar três ou cinco repositórios;
• executar um benchmark pequeno;
• testar uma consulta;
• processar uma parte do dataset;
• avaliar algumas tarefas;
• experimentar o protocolo de coleta.

Problemas descobertos nessa fase custam menos do que problemas descobertos depois da coleta completa.

13. O tamanho da amostra é compatível com meu método e meus recursos?

Não existe um número universal de projetos, participantes, commits ou issues que torne automaticamente uma pesquisa adequada.

O tamanho precisa ser justificado conforme:

• pergunta;
• método;
• desenho;
• variabilidade dos dados;
• tipo de análise;
• recursos disponíveis.

Evite escolher uma quantidade apenas porque “parece grande”.

14. Consigo terminar dentro do prazo?

Não considere apenas o tempo de implementação.

Inclua:

• levantamento bibliográfico;
• refinamento do projeto;
• preparação da coleta;
• piloto;
• coleta;
• limpeza;
• análise;
• redação;
• revisões;
• correções solicitadas pela orientação.

Um tema menor concluído com profundidade costuma ser preferível a um projeto enorme executado superficialmente.

15. Minha conclusão poderá ser sustentada pelos dados?

Imagine que a coleta terminou.

Pergunte:

“Que tipo de conclusão essas evidências realmente me permitiriam apresentar?”

Se você analisa cinco projetos open source, por exemplo, talvez consiga discutir padrões observados nesses projetos, mas não necessariamente afirmar que todos os projetos de software se comportam da mesma forma.

A conclusão precisa respeitar o desenho e as limitações da pesquisa.

Monte uma ficha inicial do projeto

Depois do checklist, você pode condensar as decisões em uma ficha simples.

Elemento	Exemplo
Área	Qualidade e testes de software
Problema	Incerteza sobre a capacidade de testes gerados com assistência de IA em detectar defeitos
Objeto	Casos de teste
Contexto	Conjunto delimitado de tarefas de programação
Evidências	Correção, cobertura e defeitos detectados
Método possível	Experimento comparativo
Principal risco	Definição inadequada da amostra ou mudança do sistema de IA durante a pesquisa

Essa ficha ainda não substitui o projeto de pesquisa, mas ajuda a verificar se as principais decisões estão conectadas.

Perguntas frequentes sobre temas para TCC em Engenharia de Software

Qual é um bom tema para TCC em Engenharia de Software?

Um bom tema é aquele que combina interesse do estudante, relevância acadêmica ou prática, literatura suficiente, evidências acessíveis, metodologia compatível e escopo executável dentro do prazo.

Em vez de procurar apenas um assunto “diferente”, procure um problema que possa ser investigado.

Quais são os temas mais atuais para TCC em Engenharia de Software?

Entre as frentes contemporâneas estão IA aplicada ao desenvolvimento, qualidade e segurança de código gerado com assistência de IA, testes apoiados por modelos generativos, Engenharia de Software para sistemas baseados em IA, DevSecOps, observabilidade, segurança de dependências, developer experience, Green Software, mineração de repositórios e reprodutibilidade de pesquisas empíricas.

Atualidade, entretanto, não substitui viabilidade metodológica.

Posso fazer meu TCC de Engenharia de Software sobre inteligência artificial?

Sim. O ideal é evitar “inteligência artificial” como tema isolado.

Relacione IA a uma atividade específica, como:

• geração de código;
• testes;
• revisão;
• requisitos;
• documentação;
• detecção de defeitos;
• refatoração.

Depois, defina o que será avaliado e como.

Um TCC de Engenharia de Software precisa criar um sistema?

Não necessariamente.

O trabalho pode analisar projetos existentes, realizar experimento, minerar repositórios, conduzir estudo de caso, executar benchmark, investigar práticas, fazer revisão da literatura ou utilizar outras metodologias adequadas.

As regras específicas do curso devem ser verificadas com a instituição e a orientação.

Posso analisar projetos open source no TCC?

Sim. Projetos open source podem fornecer código, histórico, issues, pull requests, releases, testes e documentação.

É importante definir critérios de seleção e explicar até onde os resultados podem ser generalizados.

Posso usar GitHub como fonte de dados para o TCC?

Sim, quando os dados disponíveis forem adequados à pergunta de pesquisa.

O procedimento de coleta deve ser documentado, incluindo critérios de seleção, período, filtros e transformações relevantes.

Dados públicos também não eliminam automaticamente considerações éticas, legais, de licença, privacidade ou interpretação.

Quantos projetos preciso analisar no TCC?

Não existe um número universal.

A quantidade depende da pergunta, do método, da variabilidade dos dados, da análise pretendida e dos recursos disponíveis.

Uma amostra menor e bem justificada pode ser mais adequada do que centenas de projetos selecionados sem critérios metodológicos claros.

Um TCC de Engenharia de Software precisa ser prático ou pode ser teórico?

Isso depende das regras do curso e do objetivo da pesquisa.

Mesmo um trabalho sem desenvolvimento de sistema pode possuir forte componente empírico, como mineração de repositórios, análise de código ou estudo de caso.

Da mesma forma, revisões da literatura podem produzir contribuições relevantes quando seguem um método adequado à pergunta.

Posso comparar duas linguagens de programação no TCC?

Sim, mas “qual linguagem é melhor?” costuma ser uma pergunta ampla e pouco precisa.

Defina:

• qual tipo de tarefa;
• qual característica será comparada;
• qual ambiente;
• quais implementações;
• quais métricas;
• quais limitações.

O objetivo não deve ser declarar uma vencedora universal, mas produzir evidências dentro de condições delimitadas.

Posso comparar frameworks no TCC?

Sim, desde que exista um problema de pesquisa além da comparação descritiva de funcionalidades.

Você pode investigar, por exemplo, desempenho sob determinado cenário, esforço para executar uma tarefa, consumo de recursos ou outra característica justificável.

Posso fazer estudo de caso em uma empresa?

Sim, se houver acesso adequado e se o desenho estiver alinhado à pergunta.

Confirme antecipadamente autorização, disponibilidade dos dados, confidencialidade e eventuais exigências éticas ou institucionais.

É melhor escolher um tema fácil ou inovador?

A escolha não precisa ser reduzida a esse contraste.

Um bom TCC precisa ser relevante e executável.

Uma ideia extremamente ambiciosa que não pode ser avaliada adequadamente pode ser menos útil do que uma pergunta mais delimitada investigada com rigor.

O tema do TCC precisa ser inédito?

O TCC não precisa necessariamente investigar um assunto sobre o qual ninguém jamais pesquisou.

A contribuição pode surgir de:

• novo contexto;
• nova amostra;
• nova comparação;
• replicação;
• atualização;
• aplicação de método existente a outro cenário;
• combinação justificável de evidências.

O nível de originalidade esperado deve ser confirmado com a orientação e as normas do curso.

Como saber se meu tema está amplo demais?

Alguns sinais são:

• você precisa estudar várias áreas ao mesmo tempo;
• não consegue identificar a unidade de análise;
• não sabe quais dados coletar;
• utiliza palavras como “impacto”, “qualidade” ou “eficiência” sem defini-las;
• a pergunta poderia gerar vários TCCs independentes.

Nesse caso, delimite objeto, contexto, característica, período, amostra ou método.

Como saber se delimitei demais o tema?

O recorte pode estar estreito demais quando praticamente não existe literatura relacionada, a amostra se torna inadequada à análise ou o problema perde relevância.

Delimitar significa estabelecer fronteiras úteis, e não reduzir o trabalho até restar apenas uma ocorrência sem justificativa.

Devo escolher primeiro a tecnologia ou o problema?

Você pode começar seu processo de descoberta por uma tecnologia de que gosta, mas o projeto acadêmico deve evoluir para um problema.

Em vez de:

“Quero fazer TCC sobre microsserviços.”

avance para:

“Qual característica relacionada a microsserviços quero investigar, em qual contexto e por meio de quais evidências?”

Existe tema de TCC em Engenharia de Software sem muita programação?

Sim.

Dependendo do curso e da metodologia aceita, há possibilidades envolvendo:

• Engenharia de Requisitos;
• processos;
• estudos de caso;
• surveys;
• entrevistas;
• revisões da literatura;
• análise de documentação;
• mineração de dados já disponíveis.

Algumas dessas pesquisas ainda podem exigir scripts ou ferramentas de apoio, mas não necessariamente o desenvolvimento de uma aplicação completa.

Como escolher entre requisitos, arquitetura, testes, DevOps e manutenção?

Pense primeiro no tipo de problema que mais desperta seu interesse.

Se você gosta de entender necessidades e especificações, requisitos pode ser um bom ponto de partida.

Se prefere estrutura e decisões técnicas, arquitetura pode fazer mais sentido.

Se gosta de avaliação e defeitos, considere testes e qualidade.

Se o interesse está em automação de entrega e operação, explore DevOps.

Se prefere estudar evolução histórica, dívida técnica e mudanças, manutenção oferece muitas possibilidades.

Depois, verifique literatura, dados e método antes de confirmar a escolha.

O orientador pode pedir para mudar o tema?

Sim. Durante a orientação, o tema pode ser ajustado por razões de escopo, relevância, metodologia, disponibilidade de dados, cronograma ou aderência às exigências do curso.

Alterar o recorte durante o planejamento não significa que o projeto deu errado. Muitas pesquisas ficam mais claras justamente após as primeiras buscas e discussões metodológicas.

Quando posso considerar que o tema está realmente escolhido?

Um sinal importante é quando você consegue explicar, com clareza:

• qual problema será investigado;
• qual é a pergunta;
• qual é o recorte;
• quais evidências serão necessárias;
• onde elas serão obtidas;
• qual método pode ser utilizado;
• como o resultado será avaliado;
• quais são as principais limitações e riscos.

O título ainda poderá ser refinado, mas a pesquisa já possui uma estrutura suficientemente concreta para avançar.

Escolhi um tema de TCC em Engenharia de Software. E agora?

Escolher o tema é uma etapa importante, mas ainda existe uma diferença entre ter uma boa ideia e possuir um projeto de pesquisa pronto para execução.

Depois da escolha inicial, o objetivo é transformar a ideia em uma sequência de decisões coerentes.

Uma forma prática de avançar é seguir esta jornada:

1. Refine a ideia escolhida

Volte à sugestão que chamou sua atenção e pergunte:

• qual parte desse assunto realmente me interessa?
• qual problema existe dentro dele?
• o que eu conseguiria observar?
• que tipo de evidência poderia utilizar?

Não se preocupe em encontrar imediatamente o título definitivo.

É mais importante esclarecer a lógica da pesquisa.

2. Transforme o assunto em problema de pesquisa

O problema deve mostrar o que será investigado, e não apenas qual tecnologia aparecerá no trabalho.

Considere:

Assunto:
Assistentes de programação baseados em IA.

Possível problema:
Ainda é necessário avaliar, dentro de condições claramente delimitadas, como a assistência automatizada se relaciona com determinada característica do código ou da atividade de desenvolvimento.

A partir daí, podem surgir perguntas específicas sobre correção, tempo, manutenção, testes ou outro critério relevante.

Se você ainda estiver nessa etapa, consulte o guia sobre como fazer o problema de pesquisa do TCC.

3. Delimite antes de aumentar o projeto

Depois de encontrar o problema, estabeleça as fronteiras.

Defina, quando fizer sentido:

• objeto;
• contexto;
• característica;
• população ou amostra;
• período;
• tecnologia;
• método;
• evidências.

Uma boa delimitação não empobrece o TCC. Ela permite investigar uma pergunta com maior profundidade.

Veja também como delimitar o tema do TCC.

4. Faça uma busca bibliográfica exploratória

Antes de fechar definitivamente o projeto, procure literatura científica relacionada.

Nessa fase, a busca pode ajudar a descobrir:

• terminologia utilizada pelos pesquisadores;
• conceitos importantes;
• trabalhos semelhantes;
• métodos já empregados;
• métricas;
• datasets;
• limitações recorrentes;
• lacunas que podem orientar o recorte.

Se a busca não encontra praticamente nada, não conclua imediatamente que o tema é “totalmente inédito”.

Primeiro verifique se você está utilizando os termos adequados.

O guia sobre como fazer busca bibliográfica pode ajudar a organizar essa etapa.

5. Defina o objetivo da pesquisa

Depois de formular o problema, esclareça o que o trabalho pretende fazer para respondê-lo.

Dependendo da pergunta, o objetivo pode envolver:

• avaliar;
• comparar;
• analisar;
• investigar;
• identificar;
• caracterizar;
• propor e avaliar;
• replicar;
• sintetizar evidências.

Evite objetivos tão amplos que não possam ser verificados ao final.

6. Desdobre o objetivo geral em objetivos específicos

Os objetivos específicos podem representar etapas necessárias para atingir o objetivo geral.

Em uma pesquisa empírica, por exemplo, eles podem envolver:

1. selecionar a amostra segundo critérios definidos;
2. coletar os artefatos necessários;
3. aplicar determinado procedimento de análise;
4. comparar os resultados;
5. discutir os achados em relação à literatura.

Não transforme os objetivos específicos em uma lista de tarefas administrativas.

Eles devem contribuir diretamente para responder ao problema.

7. Defina a metodologia antes da coleta

Não espere acumular dados para decidir o que fará com eles.

Antes da coleta, estabeleça:

• unidade de análise;
• amostra ou população;
• fontes;
• procedimento;
• variáveis ou categorias;
• instrumentos;
• forma de análise;
• limitações esperadas.

Se precisar estruturar essa etapa, consulte como fazer a metodologia do TCC.

8. Faça um piloto

O piloto pode ser uma das decisões mais econômicas do projeto.

Antes de processar centenas de repositórios, experimente alguns.

Antes de executar dezenas de benchmarks, teste o protocolo.

Antes de depender de uma API, confirme o acesso e a estrutura dos dados.

Antes de utilizar um instrumento de coleta, verifique sua adequação conforme as exigências metodológicas e éticas aplicáveis.

O objetivo é descobrir problemas cedo.

9. Leve uma proposta estruturada ao orientador

Em vez de apresentar apenas:

“Quero fazer um TCC sobre DevOps.”

tente chegar à orientação com algo semelhante a:

• área: DevOps;
• problema: feedback tardio de falhas em determinado processo;
• objeto: pipelines de integração;
• contexto: projetos selecionados;
• evidências possíveis: duração, resultado dos builds e momento de identificação de falhas;
• método possível: análise empírica de históricos.

Mesmo que o orientador proponha alterações, a conversa começa em um nível muito mais produtivo.

10. Organize a pesquisa para permitir rastreabilidade

Ao longo do TCC, registre decisões importantes.

Dependendo do estudo, preserve:

• consultas de busca;
• critérios de inclusão e exclusão;
• datas de coleta;
• versões;
• configurações;
• scripts;
• datasets;
• transformações;
• motivos para exclusões;
• alterações no protocolo.

Essa organização facilita:

• reprodução;
• revisão;
• redação da metodologia;
• identificação de erros;
• explicação das decisões ao orientador e à banca.

Temas relacionados para ampliar sua pesquisa

Engenharia de Software possui fronteiras próximas de outras áreas da computação. Dependendo do problema escolhido, pode ser útil comparar as ideias deste guia com outros conjuntos de temas.

Temas para TCC em Análise e Desenvolvimento de Sistemas

Se seu interesse está mais próximo da construção de aplicações, soluções para organizações e práticas de desenvolvimento aplicadas à formação tecnológica, consulte também os temas para TCC em ADS.

Temas para TCC em Ciência da Computação

Problemas envolvendo algoritmos, fundamentos computacionais, inteligência artificial, processamento e outras áreas podem se aproximar mais da Ciência da Computação.

Nesse caso, veja os temas para TCC em Ciência da Computação.

Temas para TCC em Sistemas de Informação

Quando o problema enfatiza sistemas nas organizações, processos de negócio, gestão da informação, adoção ou uso organizacional de tecnologia, vale explorar também os temas para TCC em Sistemas de Informação.

Temas para TCC em Tecnologia da Informação

Para uma visão mais ampla de infraestrutura, gestão, serviços e aplicações de tecnologia, consulte os temas para TCC em Tecnologia da Informação.

Continue aprendendo

Se você ainda está construindo o projeto, os próximos conteúdos podem ajudar em cada etapa da jornada acadêmica:

• Temas para TCC: ideias para diferentes cursos e áreas — para explorar outras possibilidades antes de confirmar a escolha;
• Como escolher um tema para TCC — para avaliar interesse, relevância, fontes e viabilidade;
• Como delimitar o tema do TCC — para transformar assuntos amplos em recortes executáveis;
• Como fazer o problema de pesquisa do TCC — para converter o tema em uma pergunta investigável;
• Como fazer busca bibliográfica — para estruturar a procura por literatura científica;
• Como encontrar artigos científicos — para localizar trabalhos relevantes para a fundamentação;
• Como fazer a metodologia do TCC — para relacionar pergunta, evidências, coleta e análise;
• Como organizar referências bibliográficas no TCC — para manter as fontes sob controle desde o início.

Conclusão

Escolher entre tantos temas para TCC em Engenharia de Software pode parecer difícil porque a área reúne requisitos, arquitetura, desenvolvimento, testes, qualidade, DevOps, manutenção, processos, inteligência artificial, segurança, experiência, sustentabilidade e pesquisa empírica.

Essa diversidade, porém, também representa uma vantagem.

Existem oportunidades de pesquisa para estudantes que gostam de programar, analisar código, estudar processos, trabalhar com dados, realizar experimentos, investigar repositórios, compreender experiências de desenvolvedores ou sintetizar literatura científica.

As 120 ideias apresentadas neste guia foram organizadas para funcionar como pontos de partida, não como títulos que precisam ser copiados literalmente.

Depois de identificar uma área de interesse, avance gradualmente:

1. encontre um problema;
2. identifique o objeto ou processo;
3. defina o contexto;
4. escolha o que será observado;
5. delimite o escopo;
6. verifique a literatura;
7. confirme o acesso às evidências;
8. escolha um método compatível;
9. faça um piloto quando possível;
10. discuta a proposta com seu orientador.

Não é necessário escolher o assunto mais complexo, a tecnologia mais recente ou desenvolver o maior sistema.

Um TCC consistente pode nascer de uma pergunta relativamente específica quando ela é investigada com clareza metodológica, evidências adequadas e conclusões proporcionais aos dados.

Também não existe problema em ajustar o tema durante as primeiras buscas.

Ao encontrar nova literatura, testar a coleta ou conversar com o orientador, você pode perceber que determinada variável precisa ser modificada, que a amostra deve ser reduzida ou que outro método responde melhor à pergunta.

Esse refinamento faz parte do processo de pesquisa.

Nota editorial

Este conteúdo foi desenvolvido com finalidade educacional para auxiliar estudantes na escolha, delimitação e planejamento inicial de temas para trabalhos acadêmicos em Engenharia de Software.

As sugestões apresentadas devem ser adaptadas às normas da instituição, às exigências do curso, ao nível acadêmico do trabalho, aos recursos disponíveis e às orientações do professor orientador.

As orientações apresentadas refletem práticas comuns no ambiente universitário e podem variar conforme as regras específicas de cada instituição de ensino.

Recomenda-se sempre consultar o manual acadêmico da faculdade e o professor orientador para orientações oficiais.

Conteúdo revisado editorialmente pela Equipe Editorial do TCC&Monografia.

Última atualização: Setembro de 2026

Quando a pesquisa envolver participantes, dados institucionais, informações pessoais, segurança de sistemas, serviços externos, datasets, código de terceiros ou repositórios públicos, também devem ser observadas as exigências éticas, legais, metodológicas e de licenciamento aplicáveis ao caso.

Ferramentas, plataformas, modelos de inteligência artificial e práticas tecnológicas podem mudar ao longo do tempo. Por esse motivo, o artigo prioriza conceitos e problemas de Engenharia de Software que podem ser adaptados a diferentes tecnologias e contextos.

Referências e fontes para aprofundamento

Para compreender a abrangência da Engenharia de Software e suas diferentes áreas de conhecimento, uma referência institucional útil é o Software Engineering Body of Knowledge (SWEBOK), da IEEE Computer Society.

O SWEBOK organiza conhecimentos relacionados à Engenharia de Software e pode servir como ponto de partida para compreender áreas, conceitos e terminologia da disciplina.

Na construção do TCC, a fonte institucional deve ser combinada com literatura científica diretamente relacionada ao problema escolhido.

Para essa etapa, consulte também:

• Como fazer busca bibliográfica;
• Como escolher fontes confiáveis para o TCC;
• Como organizar referências bibliográficas no TCC.

Ao utilizar artigos, livros, documentos técnicos, datasets, repositórios e outras fontes, registre desde o início as informações necessárias para identificação, citação e referência conforme as normas adotadas pela sua instituição.