O TCC de Análise e Desenvolvimento de Sistemas (ADS) quase sempre entrega um artefato — um sistema, aplicativo ou protótipo funcional — não apenas um texto analisando dados de terceiros. Por isso, a metodologia mais adequada raramente é a pesquisa empírica clássica: é o Design Science Research (DSR), que trata a construção do próprio software como a contribuição científica do trabalho. Este guia mostra como estruturar a metodologia do seu TCC de ADS pelo DSR, com um exemplo comentado.
Por que o DSR é o método mais adequado para o TCC de ADS
A pesquisa empírica tradicional (levantamento, estudo de caso, pesquisa quantitativa) avalia um fenômeno que já existe no mundo. O DSR avalia algo diferente: um artefato que você constrói para resolver um problema prático, e o rigor científico está em como você projeta, constrói e avalia esse artefato — não em medir um fenômeno externo. É por isso que a maioria dos TCCs de ADS que entregam um sistema funcional se encaixa melhor no DSR do que em qualquer desenho de pesquisa tradicional: o “resultado” do trabalho é o sistema em si, testado e avaliado contra critérios definidos previamente.
Se você ainda não conhece o método em profundidade, vale ler primeiro o guia geral sobre Design Science Research no TCC, que explica os quatro tipos de artefato e as seis etapas do processo. Este texto aplica esse método especificamente ao contexto de ADS, com exemplo de sistema.
ADS não é Sistemas de Informação nem Ciência da Computação: o que muda na metodologia
Os três cursos compartilham disciplinas de programação e banco de dados, mas o foco do TCC costuma diferir. Sistemas de Informação tende a enfatizar o alinhamento entre o sistema e o processo de negócio da organização; Ciência da Computação tende a permitir trabalhos mais teóricos, incluindo pesquisa sem artefato de software (algoritmos, modelos, provas). ADS, sendo um curso tecnólogo voltado à prática de desenvolvimento, costuma exigir um artefato funcional como núcleo do trabalho, com menos espaço para um TCC puramente teórico. Isso não muda o método (DSR continua sendo a opção mais natural para quem entrega um sistema), mas muda o peso relativo das seções: em ADS, a banca tende a dar mais peso à qualidade técnica e à avaliação do artefato do que à extensão do referencial teórico.
As seis etapas do DSR aplicadas a um projeto de ADS
- Identificação do problema — descreva o problema real que o sistema resolve, idealmente observado num contexto concreto (uma empresa, um processo manual ineficiente, uma lacuna entre sistemas existentes).
- Definição dos objetivos da solução — traduza o problema em requisitos funcionais (o que o sistema precisa fazer) e não funcionais (desempenho, segurança, usabilidade) mensuráveis.
- Projeto e desenvolvimento — descreva a arquitetura do sistema, as tecnologias escolhidas e por quê, e o processo de desenvolvimento (métodos ágeis, sprints, versionamento).
- Demonstração — mostre o artefato funcionando num cenário representativo, ainda que controlado ou simulado.
- Avaliação — meça se o artefato atende aos objetivos definidos na etapa 2, com critérios declarados previamente (testes funcionais, teste de usabilidade, métricas de desempenho).
- Comunicação — é o próprio TCC: o texto que relata o problema, o processo de construção e os resultados da avaliação para a comunidade acadêmica e para futuros desenvolvedores que herdem o sistema.
Exemplo comentado: sistema de gestão de estoque para pequeno comércio
Tema (ilustrativo): Desenvolvimento de um sistema web de gestão de estoque para micro e pequenas empresas do varejo, com alertas automáticos de reposição.
Problema identificado: pequenos comerciantes controlam estoque em planilhas ou cadernos, o que gera divergências entre o estoque físico e o registrado, e falta de aviso automático quando um item se aproxima do nível mínimo.
Requisitos funcionais (exemplo): cadastro de produtos e fornecedores; registro de entradas e saídas; geração de alerta quando o saldo de um item atinge o estoque mínimo definido; relatório de movimentação por período.
Requisitos não funcionais (exemplo): tempo de resposta das consultas abaixo de dois segundos (dado fictício, ilustrativo); interface responsiva para uso em celular; autenticação de usuário com controle de acesso por perfil.
Comentário: repare que os requisitos não funcionais têm critério mensurável (“abaixo de dois segundos”), não apenas qualificativo (“rápido”). É esse critério mensurável que permite, na etapa de avaliação, dizer objetivamente se o artefato atendeu ou não ao objetivo.
Avaliação (exemplo): testes funcionais cobrindo os casos de uso principais (cadastro, movimentação, geração de alerta), teste de usabilidade com um pequeno grupo de usuários representativos do público-alvo (comerciantes, não desenvolvedores), e medição do tempo de resposta das consultas mais frequentes sob carga simulada.
Que critérios de qualidade usar na avaliação do artefato
Quando o trabalho não define métricas próprias, um ponto de partida reconhecido é o modelo de qualidade de software da ISO/IEC 25010:2023, que organiza a qualidade em características como adequação funcional, eficiência de desempenho, usabilidade, confiabilidade, segurança, compatibilidade e manutenibilidade. Não é preciso avaliar todas as características do modelo — escolha as duas ou três mais relevantes para o problema que o seu sistema resolve (por exemplo, usabilidade e adequação funcional para um sistema voltado a usuários leigos, ou eficiência de desempenho e confiabilidade para um sistema de processamento de grande volume de dados) e declare por que essas foram as escolhidas.
Como declarar a arquitetura e a stack tecnológica
A metodologia precisa declarar, no mínimo: a arquitetura geral do sistema (cliente-servidor, monolítico, microsserviços — o que fizer sentido para o porte do projeto), as tecnologias de front-end e back-end escolhidas, o banco de dados e por que ele foi escolhido, e a ferramenta de controle de versão usada durante o desenvolvimento. Não é preciso justificar cada escolha tecnológica com uma revisão de literatura extensa, mas cada escolha relevante (por que esse banco de dados, por que esse framework) merece uma frase de justificativa técnica — “escolhido por X” é mais forte para a banca do que apenas “utilizamos X”.
Como documentar o processo ágil na metodologia
Se o desenvolvimento seguiu Scrum, Kanban ou outra metodologia ágil, a seção de metodologia do TCC pode (e deve) usar os artefatos do próprio processo como evidência: o backlog de requisitos, o histórico de sprints com as entregas de cada ciclo, e o board de tarefas (Trello, Jira, GitHub Projects) mostrando o fluxo de trabalho. Isso não é redundante com a descrição do sistema em si — é a evidência de que o processo de desenvolvimento foi conduzido de forma sistemática, o que reforça o rigor metodológico do trabalho aos olhos da banca. Um quadro-resumo com o número de sprints, a duração de cada um e as principais entregas costuma ser mais eficiente do que descrever cada sprint em texto corrido.
Erros mais comuns na metodologia de TCC de ADS
- Descrever apenas o processo de desenvolvimento, sem etapa de avaliação — um sistema que “funciona” não é o mesmo que um sistema avaliado contra critérios declarados previamente; sem avaliação, o trabalho não fecha o ciclo do DSR.
- Requisitos não funcionais sem critério mensurável — “sistema rápido e fácil de usar” não é um requisito testável; “tempo de resposta abaixo de X segundos” e “taxa de conclusão de tarefa acima de Y% no teste de usabilidade” são.
- Confundir DSR com desenvolvimento de software comum — todo projeto de sistema tem etapas de desenvolvimento; o que torna o trabalho uma pesquisa em DSR é a identificação explícita do problema, a definição prévia de critérios de avaliação e a reflexão sobre o que o artefato generaliza para além daquele caso específico.
- Usar dado de empresa real sem autorização — se o sistema foi desenvolvido para uma empresa real, confirme se é preciso autorização para usar o nome, os processos ou dados da empresa no TCC.
- Citar metodologia ágil sem mostrar evidência do processo — dizer “utilizamos Scrum” sem trazer nenhum artefato do processo (backlog, sprints, board) é uma afirmação sem sustentação, do mesmo jeito que citar uma norma sem referenciá-la.
DSR não é a única opção: quando considerar outro método
Nem todo TCC de ADS precisa ser um sistema construído do zero. Um trabalho que avalia sistemas já existentes no mercado (comparação de ferramentas, análise de desempenho de bancos de dados, auditoria de segurança de um sistema legado) pode se encaixar melhor num estudo de caso ou numa pesquisa comparativa tradicional, sem a construção de um artefato novo. A escolha certa depende do que o seu trabalho efetivamente entrega: se o produto final é um sistema novo, o DSR se aplica; se o produto final é uma análise sobre sistemas que já existem, um desenho de pesquisa tradicional costuma ser mais adequado — e mais fácil de defender perante a banca, porque não exige justificar a escolha de um método menos usual para um objetivo que não é a construção de um artefato.
Perguntas frequentes
Todo TCC de ADS precisa usar Design Science Research?
Não. O DSR é o método mais adequado quando o trabalho constrói um artefato novo (sistema, aplicativo, protótipo). Trabalhos que analisam ou comparam sistemas já existentes, sem construir algo novo, costumam se encaixar melhor num estudo de caso ou pesquisa comparativa tradicional.
Preciso de um número mínimo de usuários no teste de usabilidade?
Não há um número fixo definido em norma. O tamanho do grupo de teste depende do prazo, do acesso a usuários representativos e da orientação do seu professor — declare o critério usado e trate qualquer contagem específica como ilustrativa até validar com o orientador.
O código-fonte precisa entrar no TCC?
Normalmente não é anexado integralmente ao corpo do trabalho — a prática comum é disponibilizar o repositório de código (por exemplo, num link para um repositório privado ou público) e trazer apenas trechos relevantes como exemplo no corpo do texto ou em apêndice, conforme o regulamento do curso.
Posso usar um sistema desenvolvido em estágio ou emprego como TCC?
Depende da autorização da empresa e do regulamento do curso. Se o sistema foi desenvolvido para uma empresa real, você provavelmente vai precisar de autorização explícita para usar o nome da empresa, os dados de negócio e até partes do código no trabalho acadêmico.
Qual a diferença entre TCC de ADS e TCC de Sistemas de Informação?
Ambos costumam entregar artefatos de software, mas Sistemas de Informação tende a dar mais peso ao alinhamento entre o sistema e o processo de negócio da organização, enquanto ADS, curso tecnólogo voltado à prática de desenvolvimento, costuma dar mais peso à qualidade técnica e à avaliação funcional do artefato construído.
Que norma posso usar como referência para os critérios de qualidade do sistema?
A ISO/IEC 25010:2023 é a referência mais usada, com características como usabilidade, eficiência de desempenho, confiabilidade e segurança. Escolha apenas as características mais relevantes para o problema do seu sistema, em vez de tentar avaliar todas.