Como Citar Software nas Normas ABNT: Programas, Aplicativos e Ferramentas

Saber como citar software nas normas ABNT exige mais do que encontrar um modelo de referência e substituir o nome do programa. Antes de formatar qualquer referência, é necessário identificar exatamente qual recurso foi utilizado, qual versão participou da pesquisa, quem é responsável pelo software e qual função ele desempenhou no trabalho acadêmico.

---

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

---

Essa diferença é importante porque um software pode aparecer em um TCC, monografia, dissertação ou artigo científico de maneiras muito diferentes. Ele pode ser apenas uma ferramenta operacional, pode executar uma análise estatística, processar dados, apoiar uma análise qualitativa, realizar uma simulação, produzir mapas, implementar um algoritmo ou até constituir o próprio objeto da pesquisa.

Programas e ambientes como R, Python, SPSS, jamovi, IRaMuTeQ, NVivo, ATLAS.ti, MAXQDA, MATLAB, Stata, SAS, QGIS, ArcGIS, JASP, G*Power, GraphPad Prism, Excel, Zotero e Mendeley, portanto, não devem ser tratados automaticamente da mesma maneira.

Além disso, existe uma distinção essencial entre mencionar um software, citá-lo no texto, incluí-lo na lista de referências e descrevê-lo na metodologia. Dependendo da situação, uma pesquisa pode exigir apenas algumas dessas ações ou uma combinação delas.

Na edição de 2025 da ABNT NBR 6023, os programas de computador estão contemplados entre os documentos de acesso exclusivo em meio eletrônico. A elaboração da referência deve partir dos elementos disponíveis para identificar o recurso, sem inventar informações ausentes apenas para completar um modelo.

Ao mesmo tempo, a referência bibliográfica não resolve sozinha toda a documentação metodológica. Em pesquisas computacionais, a versão, os pacotes utilizados, determinados parâmetros ou até o ambiente de execução podem ser importantes para compreender ou reproduzir o procedimento.

Preciso citar o software utilizado no TCC?

Nem todo software utilizado durante a elaboração de um TCC precisa automaticamente se transformar em uma referência bibliográfica. A decisão depende principalmente da função que a ferramenta desempenhou na pesquisa.

Um editor de texto utilizado apenas para escrever o trabalho ocupa uma posição diferente de um programa que executou as análises estatísticas responsáveis pelos resultados apresentados.

Da mesma forma, uma planilha utilizada apenas para organizar nomes de participantes não possui necessariamente a mesma relevância metodológica de uma planilha contendo fórmulas, macros ou procedimentos analíticos determinantes para os resultados.

Antes de decidir se um programa precisa ser citado ou referenciado, faça as perguntas abaixo.

1. O software participou diretamente do método?

Se a ferramenta foi utilizada para executar uma etapa relevante do procedimento científico, sua identificação tende a adquirir maior importância.

Isso pode ocorrer quando o software foi utilizado para:

• análise estatística;
• análise qualitativa;
• análise textual;
• processamento de imagens;
• geoprocessamento;
• simulações;
• modelagem;
• cálculo amostral;
• aprendizado de máquina;
• bioinformática;
• processamento de sinais;
• extração ou transformação de dados;
• triagem de estudos em uma revisão;
• geração de resultados científicos.

2. O software interferiu nos resultados?

Quanto maior a influência do programa sobre os resultados, maior tende a ser a importância de identificá-lo adequadamente.

Se diferentes versões, algoritmos, configurações ou módulos podem produzir resultados diferentes, a documentação do software passa a ter uma função metodológica relevante.

3. Outro pesquisador precisaria saber qual programa foi utilizado?

Essa é uma pergunta particularmente útil para avaliar a relevância do software.

Imagine que outro pesquisador queira compreender ou reproduzir o procedimento. Saber apenas que “os dados foram analisados em um computador” seria suficiente?

Se a resposta for não, provavelmente o programa utilizado faz parte das informações importantes do método.

4. O software é o próprio objeto da pesquisa?

Quando o trabalho analisa, compara, testa ou avalia um programa, aplicativo ou sistema, sua identificação é evidentemente central.

Isso pode ocorrer, por exemplo, em pesquisas que:

• avaliam a usabilidade de um aplicativo;
• comparam dois programas;
• investigam desempenho de versões diferentes;
• analisam uma ferramenta educacional;
• estudam um sistema de apoio à decisão;
• avaliam um software de saúde;
• investigam um algoritmo implementado em determinado programa.

5. O programa foi apenas uma ferramenta operacional?

Nem toda ferramenta usada durante a produção do trabalho precisa receber o mesmo tratamento.

Programas utilizados exclusivamente para:

• digitar o texto;
• ler arquivos PDF;
• enviar e-mails;
• navegar na internet;
• compactar arquivos;
• preparar os slides da defesa;

normalmente possuem relevância metodológica muito menor.

Fluxo rápido: preciso citar ou documentar este software?

O fluxo abaixo ajuda a tomar a decisão de maneira mais objetiva.

Etapa 1 — O software participou da coleta, processamento, análise ou geração dos resultados?

Se sim, registre seus dados e avalie sua inclusão na documentação metodológica e bibliográfica.

Etapa 2 — A versão ou configuração pode influenciar o procedimento?

Se sim, registre a versão efetivamente utilizada e, quando necessário, os componentes relevantes.

Etapa 3 — Houve pacote, biblioteca, módulo, plugin ou extensão essencial?

Se sim, verifique se esse componente possui metadados ou orientação própria de citação.

Etapa 4 — O projeto fornece uma orientação oficial de citação?

Se sim, utilize-a como fonte para identificar corretamente autores, título, versão, ano, DOI ou outros metadados. Depois, adapte a apresentação ao padrão bibliográfico aplicável ao trabalho.

Etapa 5 — O software foi apenas operacional?

Se sua função foi apenas periférica, sua relevância bibliográfica pode ser muito menor.

Índice

• O que a ABNT diz sobre referência de software?
• Qual norma ABNT usar para citar software?
• Software utilizado no TCC precisa ser citado?
• Mencionar, citar, referenciar e documentar software: qual a diferença?
• Quais dados registrar antes de citar um software?
• Como fazer referência de software nas normas ABNT?
• Como citar software no texto?
• Como citar R nas normas ABNT?
• Como citar Python nas normas ABNT?
• Como citar SPSS nas normas ABNT?
• Como citar jamovi nas normas ABNT?
• Como citar IRaMuTeQ nas normas ABNT?
• Como citar outros softwares utilizados em pesquisa?
• Preciso citar Zotero ou Mendeley?
• Como citar aplicativo nas normas ABNT?
• Como citar software online e SaaS?
• Como citar software livre e open source?
• Como citar software desenvolvido pelo pesquisador?
• Software, manual, documentação ou artigo científico: o que citar?
• Software e inteligência artificial: quando muda a documentação?
• Como mencionar software na metodologia do TCC?
• Por que a versão do software é importante?
• Exemplos práticos de como citar e documentar software
• Erros comuns ao citar software nas normas ABNT
• Passo a passo para citar software nas normas ABNT
• Matriz de decisão: preciso citar este software?
• Diagnóstico rápido por tipo de software
• Checklist final para citar software no TCC
• Matriz final: onde colocar cada informação?
• Auditoria rápida em 2 minutos
• Perguntas frequentes
• Conclusão
• Continue aprendendo
• Boa prática científica na citação de software
• Referências e documentos consultados
• Nota editorial

O que a ABNT diz sobre programas de computador?

Para compreender como referenciar um software, é importante separar o que decorre das normas bibliográficas do que pertence às boas práticas metodológicas de documentação da pesquisa.

A ABNT NBR 6023:2025, responsável pela elaboração de referências, contempla os programas de computador no tratamento dos documentos de acesso exclusivo em meio eletrônico.

Essa categoria é importante porque um software não precisa ser tratado simplesmente como uma página da internet. O fato de um programa possuir um site oficial ou ser baixado pela internet não transforma automaticamente o site no objeto que deve ser referenciado.

O objeto relevante pode ser o próprio programa.

Software e site não são necessariamente o mesmo objeto

Imagine um programa científico disponibilizado em um site institucional.

Nesse cenário existem, potencialmente, pelo menos dois objetos diferentes:

• o software;
• a página da internet que apresenta ou distribui esse software.

Também podem existir outros objetos relacionados:

• manual;
• documentação técnica;
• artigo científico;
• repositório de código;
• release;
• pacote;
• conjunto de dados;
• registro com DOI.

Antes de elaborar qualquer referência, portanto, identifique qual desses objetos realmente sustenta a informação ou procedimento apresentado no trabalho.

Quais elementos podem identificar um programa de computador?

Na estrutura normativa aplicável aos documentos de acesso exclusivo em meio eletrônico, a identificação do recurso considera os elementos disponíveis para caracterizá-lo bibliograficamente.

No caso de software, isso pode envolver informações como:

• responsabilidade pelo recurso;
• título;
• versão ou edição, quando existente;
• local, quando aplicável;
• data;
• descrição do meio eletrônico;
• informações de acesso, quando se tratar de recurso online.

O ponto decisivo é a expressão “quando aplicável” ou a disponibilidade efetiva dos elementos.

Nem todo software apresenta seus metadados da mesma forma. Um programa comercial instalado localmente, um pacote do R, uma biblioteca Python, um projeto hospedado em repositório e uma aplicação executada exclusivamente no navegador podem possuir estruturas de identificação muito diferentes.

A versão merece atenção especial

Em software científico, a versão pode ser muito mais relevante do que em diversos outros tipos de fonte.

Uma atualização pode alterar:

• algoritmos;
• funções;
• procedimentos estatísticos;
• valores padrão;
• compatibilidade com pacotes;
• tratamento de dados;
• resultados produzidos em determinadas condições.

Por isso, quando a versão estiver disponível e for relevante para identificar o recurso utilizado, ela deve ser registrada com cuidado.

O pesquisador também deve evitar um erro muito comum: consultar o site meses depois da análise e utilizar na referência a versão atual, quando a pesquisa foi executada em uma versão anterior.

Qual norma ABNT é usada para citar software?

Duas normas cumprem funções particularmente importantes neste assunto.

ABNT NBR 6023:2025 — referências

A ABNT NBR 6023:2025 estabelece princípios para a elaboração das referências.

É nessa camada que se encontra a questão de como identificar bibliograficamente o recurso utilizado e organizar os elementos necessários para que o leitor possa reconhecê-lo.

Quando falamos em “referência do software”, portanto, estamos principalmente no campo da NBR 6023.

ABNT NBR 10520:2023 — citações

A ABNT NBR 10520:2023 trata da apresentação das citações em documentos.

Ela entra em cena quando uma fonte é chamada no corpo do trabalho, seja por meio de uma citação integrada à redação, seja por outra forma prevista no sistema adotado.

Isso significa que referência e citação não são sinônimos.

A referência identifica a fonte na lista correspondente. A citação estabelece, no texto, a relação entre determinada afirmação e a fonte utilizada.

E a metodologia?

A metodologia acrescenta uma terceira camada.

Mesmo que um software esteja corretamente identificado nas referências e seja citado adequadamente no texto, o leitor ainda pode precisar saber:

• para que o programa foi utilizado;
• qual análise foi executada;
• qual versão participou do procedimento;
• quais pacotes ou módulos foram empregados;
• quais parâmetros foram definidos;
• como os dados foram preparados;
• qual etapa da pesquisa dependeu da ferramenta.

Essas informações não devem ser confundidas com a simples elaboração da referência bibliográfica.

ABNT, manual institucional e boas práticas não são a mesma coisa

Outro cuidado importante é não atribuir à ABNT toda recomendação encontrada sobre documentação de software.

Existem pelo menos quatro níveis que podem influenciar a maneira como um programa é registrado em um trabalho acadêmico:

Camada	Função principal
Norma ABNT	Orienta aspectos de referências, citações e apresentação documental dentro de seu respectivo escopo.
Manual institucional	Pode estabelecer regras complementares para TCCs, dissertações, teses e outros trabalhos da instituição.
Política de periódico ou programa	Pode exigir informações adicionais sobre software, código, dados e reprodutibilidade.
Boa prática metodológica	Ajuda a documentar suficientemente o procedimento para compreensão, avaliação ou reprodução da pesquisa.

Uma recomendação pode ser excelente e ainda assim não constituir uma exigência literal da ABNT.

Por exemplo, registrar versões de bibliotecas, parâmetros, ambiente computacional ou identificadores persistentes pode ser extremamente importante em determinadas pesquisas. Isso não autoriza, porém, transformar cada uma dessas boas práticas em uma suposta “regra universal da ABNT”.

Software precisa ser citado no TCC?

Não existe uma resposta adequada baseada apenas no fato de o estudante ter utilizado determinado programa.

A necessidade de citar, referenciar ou documentar um software depende principalmente de como a ferramenta participou da pesquisa, além das regras aplicáveis ao trabalho.

Em termos práticos, quanto maior a participação do programa na produção dos resultados ou na execução do método, maior tende a ser a importância de identificá-lo adequadamente.

Software utilizado em análise estatística

Quando um programa executa testes estatísticos, estima parâmetros, ajusta modelos, calcula intervalos, realiza regressões ou produz outras análises que sustentam os resultados do estudo, sua identificação metodológica normalmente é relevante.

Isso ocorre, por exemplo, em pesquisas que utilizam:

• SPSS;
• R;
• jamovi;
• Stata;
• SAS;
• JASP;
• GraphPad Prism;
• Python com bibliotecas estatísticas;
• outros ambientes de análise.

Entretanto, escrever apenas “os dados foram analisados no software X” costuma ser insuficiente.

O leitor também pode precisar saber quais procedimentos foram executados, quais critérios foram adotados e, dependendo da pesquisa, quais módulos, pacotes ou configurações participaram da análise.

Software utilizado em análise qualitativa

Programas como NVivo, ATLAS.ti e MAXQDA podem apoiar diferentes etapas de uma pesquisa qualitativa.

Eles podem auxiliar na:

• organização do corpus;
• codificação;
• categorização;
• recuperação de segmentos;
• organização de memorandos;
• construção de matrizes;
• visualização de relações entre códigos;
• gestão do material analisado.

A utilização do programa, contudo, não determina automaticamente qual método qualitativo foi adotado.

Um software pode apoiar uma análise de conteúdo, uma análise temática ou outro procedimento, mas a fundamentação metodológica precisa ser apresentada separadamente.

Software utilizado em análise textual

Ferramentas destinadas ao processamento e à análise de textos também podem assumir papel central na metodologia.

Quando um programa como o IRaMuTeQ é utilizado para analisar um corpus, não basta registrar seu nome. É necessário explicar como o material foi preparado e quais procedimentos foram executados.

Dependendo do estudo, podem ser relevantes informações sobre:

• constituição do corpus;
• preparação dos textos;
• segmentação;
• variáveis utilizadas;
• tipo de análise;
• critérios de interpretação;
• versão do software.

Software utilizado no processamento de dados

Um programa também pode ser relevante mesmo quando não executa diretamente o teste estatístico final.

Ele pode participar de etapas anteriores, como:

• limpeza dos dados;
• transformação de variáveis;
• conversão de formatos;
• normalização;
• tratamento de valores ausentes;
• integração de bases;
• automatização de procedimentos;
• extração de informações.

Se essas operações interferem no conjunto de dados analisado, documentá-las pode ser essencial para compreender o caminho entre os dados originais e os resultados finais.

Software utilizado para produzir resultados

Em algumas pesquisas, a ferramenta computacional não apenas organiza os dados: ela participa diretamente da produção do resultado apresentado.

Isso pode ocorrer em:

• simulações;
• modelagem matemática;
• processamento de imagens;
• reconstrução tridimensional;
• análise de sinais;
• bioinformática;
• geoprocessamento;
• aprendizado de máquina;
• otimização;
• cálculos científicos.

Nessas situações, software, versão, componentes e parâmetros podem se tornar informações metodológicas importantes.

Software como objeto da pesquisa

A necessidade de identificação é ainda mais evidente quando o próprio software constitui o objeto investigado.

Imagine um TCC cujo objetivo seja:

• comparar dois aplicativos;
• avaliar a usabilidade de um sistema;
• testar a precisão de um programa;
• comparar resultados entre versões;
• avaliar um software educacional;
• analisar funcionalidades de uma plataforma;
• estudar um sistema de apoio à decisão.

Nesses casos, identificar exatamente qual recurso foi estudado é indispensável para delimitar o objeto da pesquisa.

Software utilizado em simulações e modelagem

Em estudos de simulação, registrar apenas o nome do programa raramente é suficiente.

Além da versão, podem ser importantes:

• modelo utilizado;
• condições iniciais;
• parâmetros;
• solver;
• tolerâncias;
• número de iterações;
• hipóteses;
• módulos;
• bibliotecas;
• scripts;
• configurações relevantes.

Esses dados não precisam necessariamente integrar a referência bibliográfica. Muitos pertencem à metodologia.

Essa separação evita um problema recorrente: tentar colocar dentro da referência tudo aquilo que deveria ser explicado no método.

Software utilizado em geoprocessamento

Pesquisas geográficas, ambientais, agronômicas, urbanas e de engenharia podem utilizar programas como QGIS e ArcGIS para processamento e análise espacial.

Nesse cenário, é importante distinguir pelo menos:

• o software;
• a versão;
• eventuais plugins;
• os dados geográficos;
• as bases cartográficas;
• imagens de satélite;
• serviços de mapas;
• procedimentos de processamento.

Citar o programa de geoprocessamento não substitui a identificação das fontes dos dados espaciais.

Software desenvolvido pelo próprio pesquisador

Também pode acontecer de o estudante desenvolver um script, programa, aplicativo ou sistema para executar uma parte da pesquisa.

Nesse caso, é necessário distinguir entre:

• um pequeno script metodológico;
• um conjunto estruturado de códigos;
• um software independente;
• um programa formalmente publicado;
• um recurso depositado em repositório;
• um software que recebeu versão e identificador persistente.

Quanto mais independente e recuperável for o recurso, maior a possibilidade de ele constituir um objeto bibliográfico próprio.

Já um script criado especificamente para executar determinada etapa do TCC pode precisar principalmente de documentação metodológica, disponibilização em apêndice ou depósito em repositório, conforme o contexto.

Word, PowerPoint e programas operacionais precisam ser citados?

Em geral, ferramentas utilizadas apenas para escrever o trabalho, preparar slides, abrir PDFs ou executar outras tarefas administrativas não possuem a mesma relevância metodológica de um software científico responsável pela análise.

Isso não significa que exista uma lista universal de programas que “nunca devem ser citados”.

O que importa é a função.

Se uma ferramenta normalmente operacional desempenhou uma função específica e relevante no método, o contexto pode justificar sua documentação.

E o Excel?

O Excel é um bom exemplo de por que respostas automáticas podem ser inadequadas.

Considere duas situações:

Situação A: uma planilha foi utilizada apenas para armazenar nomes e organizar informações administrativas.

Situação B: a planilha contém fórmulas, macros, transformações, cálculos ou modelos que participaram diretamente da produção dos resultados.

A relevância metodológica é claramente diferente.

Mencionar, citar, referenciar ou documentar software: qual é a diferença?

Uma das principais fontes de confusão neste tema é utilizar as palavras mencionar, citar, referenciar e documentar como se fossem sinônimas.

Elas podem representar ações diferentes dentro de um trabalho acadêmico.

Mencionar o software

Mencionar significa informar ao leitor que determinada ferramenta foi utilizada ou está sendo discutida.

Exemplo didático:

Os dados foram organizados e analisados com auxílio do software Analytica Research, versão X.

A frase identifica o programa no contexto metodológico.

Essa menção, isoladamente, não responde necessariamente a todas as questões bibliográficas ou metodológicas.

Citar o software

Quando o software é tratado como uma fonte ou recurso bibliograficamente identificado e existe uma chamada correspondente no texto, entramos no campo da citação.

A forma da chamada deve ser coerente com o sistema de citações utilizado no trabalho e com a responsabilidade bibliográfica identificada para o recurso.

Não é recomendável inventar uma autoria apenas para produzir uma chamada autor-data visualmente conveniente.

Referenciar o software

Referenciar significa construir a entrada bibliográfica correspondente ao recurso na lista de referências.

Essa entrada deve ser baseada nos metadados do software efetivamente utilizado.

Dependendo do recurso, podem existir informações como:

• autor ou entidade responsável;
• título;
• versão;
• data;
• local, quando aplicável;
• descrição do recurso eletrônico;
• URL;
• data de acesso;
• DOI ou outro identificador.

Documentar metodologicamente o software

Documentar o uso do programa na metodologia significa explicar sua participação no procedimento científico.

Isso pode exigir informações que não pertencem necessariamente à referência bibliográfica, como:

• função desempenhada;
• procedimento executado;
• pacotes;
• bibliotecas;
• módulos;
• plugins;
• parâmetros;
• configurações;
• scripts;
• ambiente computacional;
• critérios analíticos.

Comparação rápida

Ação	Pergunta respondida	Exemplo de função
Mencionar	Qual ferramenta foi utilizada?	Informar o nome do programa na metodologia.
Citar	Qual fonte ou recurso está sendo chamado no texto?	Relacionar a afirmação ao recurso bibliograficamente identificado.
Referenciar	Como identificar e localizar o recurso?	Construir a entrada correspondente na lista de referências.
Documentar metodologicamente	Como o programa participou da pesquisa?	Explicar versão, função, procedimentos, componentes e parâmetros relevantes.

Software, manual, documentação e artigo científico são objetos diferentes

Um mesmo projeto pode disponibilizar vários materiais relacionados.

Por exemplo:

• o próprio software;
• um manual;
• uma documentação online;
• um artigo científico que descreve o programa;
• um artigo que valida determinado algoritmo;
• um repositório de código;
• uma página institucional.

Esses objetos não devem ser fundidos automaticamente em uma única referência.

Se o pesquisador utilizou o programa, consultou o manual para configurar determinado procedimento e citou um artigo para fundamentar o método, pode haver razões legítimas para referências diferentes.

Exemplo didático: um mesmo software em quatro funções

Imagine um programa fictício chamado Analytica Research.

Ele poderia aparecer no TCC de maneiras diferentes.

Na metodologia:

As análises foram realizadas no software Analytica Research, versão X, utilizando o módulo estatístico Y.

Como referência do programa: seria construída uma entrada a partir dos metadados oficiais da versão utilizada.

Como fonte de uma instrução técnica: o pesquisador poderia precisar citar o manual ou a documentação correspondente.

Como fundamentação científica: um artigo sobre o algoritmo implementado poderia ser citado separadamente.

Nenhum desses objetos substitui automaticamente os demais.

Quais dados registrar antes de citar um software?

A maneira mais segura de elaborar uma referência de software é coletar primeiro os metadados e formatar depois.

Começar diretamente pela referência aumenta o risco de encaixar informações erradas em um modelo pronto.

1. Nome oficial do software

Registre o nome exatamente como o projeto o identifica oficialmente.

Evite:

• abreviações inventadas;
• nomes informais encontrados em fóruns;
• grafia baseada apenas no nome do arquivo executável;
• traduções não oficiais do título do programa.

Se houver diferença entre nome do produto, nome da plataforma e nome da empresa, identifique corretamente cada função.

2. Autor ou entidade responsável

Procure descobrir como o próprio projeto atribui responsabilidade ao software.

Ela pode pertencer a:

• uma pessoa;
• vários desenvolvedores;
• uma equipe;
• uma universidade;
• um laboratório;
• uma empresa;
• uma fundação;
• uma organização;
• um projeto colaborativo formalmente identificado.

Não presuma que o site de hospedagem, a loja de aplicativos ou a empresa mais conhecida relacionada ao produto seja automaticamente a autora bibliográfica.

3. Versão

Registre a versão que efetivamente participou da pesquisa.

Ela pode aparecer em locais como:

• menu “Sobre”;
• tela inicial;
• propriedades do programa;
• documentação;
• linha de comando;
• gerenciador de pacotes;
• página da release;
• arquivo de metadados;
• registro do repositório.

Em ambientes computacionais, a versão também pode ser recuperada por comandos específicos.

4. Edição, quando aplicável

Versão e edição não devem ser tratadas automaticamente como sinônimos.

Alguns recursos podem apresentar uma edição formal, enquanto outros trabalham apenas com versões, releases ou números de compilação.

Utilize a terminologia adotada pelo próprio recurso sempre que possível.

5. Data

A data exige atenção porque várias datas diferentes podem aparecer em torno de um software.

Podem existir:

• data de lançamento inicial;
• data da versão utilizada;
• data da última atualização;
• data da página da internet;
• data do artigo científico associado;
• data de copyright;
• data de acesso.

Essas datas não são automaticamente intercambiáveis.

6. Local, quando aplicável

Alguns recursos apresentam informação de local de maneira clara; outros não.

Não tente deduzir uma cidade apenas pela sede atual da empresa, pelo domínio do site ou por informações encontradas em fontes não relacionadas à versão utilizada.

Quando determinado elemento não estiver disponível, a solução deve seguir o tratamento bibliográfico aplicável, e não uma suposição.

7. Descrição do meio eletrônico

A caracterização do recurso eletrônico ajuda a indicar a natureza do objeto referenciado.

Ela deve ser coerente com o recurso efetivamente utilizado.

Esse cuidado é particularmente importante para não confundir:

• programa de computador;
• aplicativo;
• arquivo;
• página da internet;
• documentação;
• base de dados;
• código-fonte.

8. URL

Quando o recurso é acessado online ou a referência requer informação de disponibilidade, prefira endereços capazes de levar o leitor a uma fonte apropriada.

Entre as opções possíveis estão:

• site oficial;
• página oficial do software;
• documentação oficial;
• repositório oficial;
• release específica;
• registro persistente.

Evite, sempre que possível, sites de download de terceiros quando existe uma fonte oficial.

9. Data de acesso

Para recursos consultados online, registre a data de acesso quando ela fizer parte da estrutura aplicável à referência.

A data de acesso informa quando o recurso foi consultado. Ela não deve ser confundida com a data de lançamento ou publicação do software.

10. DOI ou outro identificador persistente

Alguns softwares, releases ou depósitos em repositórios científicos possuem DOI.

Antes de utilizá-lo, confirme exatamente qual objeto o identificador representa.

Um DOI encontrado próximo ao nome do software pode corresponder a:

• uma versão específica;
• um registro geral do projeto;
• um artigo científico;
• um conjunto de dados;
• um manual;
• outro objeto relacionado.

Não atribua ao software o DOI de um artigo apenas porque o artigo descreve o programa.

11. Pacotes e bibliotecas

Em ambientes como R e Python, registrar apenas o ambiente principal pode não ser suficiente para documentar a análise.

Pacotes ou bibliotecas metodologicamente relevantes podem possuir:

• autores próprios;
• versões próprias;
• documentação própria;
• artigos associados;
• DOI;
• orientações específicas de citação.

Isso não significa listar todas as dependências instaladas no computador. A seleção deve considerar a relevância para o método.

12. Módulos, plugins, toolboxes e extensões

O mesmo raciocínio vale para componentes adicionais de um programa.

Um plugin pode implementar justamente a função responsável pelo resultado central do estudo.

Nesse caso, citar apenas o software principal pode deixar de fora uma informação metodologicamente importante.

13. Artigo científico associado

Muitos projetos científicos indicam um artigo que deve ou pode ser citado quando o software é utilizado.

Registre essa orientação, mas mantenha a distinção:

artigo sobre o software ≠ software.

O artigo pode ser necessário para atribuição científica, fundamentação ou descrição do método, enquanto a identificação da versão do programa cumpre outra função.

14. Manual ou documentação técnica

Se uma instrução, configuração ou procedimento foi obtido no manual, registre também os dados desse documento.

Não transforme a referência do manual na referência do software apenas porque ambos pertencem ao mesmo projeto.

15. Orientação oficial de citação

Verifique se o projeto disponibiliza uma seção como:

• How to cite;
• Cite this software;
• Citation;
• Referencing;
• Publications;
• Acknowledgements.

Essa orientação pode fornecer informações valiosas sobre autoria, versão, artigo recomendado, DOI e outros elementos.

Entretanto, o formato oferecido pelo projeto pode seguir APA, Chicago, Vancouver, BibTeX ou outro padrão.

Portanto:

16. Arquivos CITATION.cff, BibTeX, RIS e outros formatos

Projetos de software podem disponibilizar metadados em formatos estruturados.

Entre eles:

• CITATION.cff;
• BibTeX;
• RIS;
• EndNote;
• arquivos de metadados do repositório.

Esses arquivos podem ser excelentes fontes para identificar autores, título, versão, DOI e outros dados.

Mas um registro BibTeX, por exemplo, não deve ser colado mecanicamente no TCC como se sua estrutura já estivesse automaticamente de acordo com a ABNT.

17. Função desempenhada pelo software

Embora essa informação normalmente pertença à metodologia e não à referência, registre-a junto com os metadados.

Escreva, em poucas palavras, para que o recurso foi utilizado:

• análise estatística;
• codificação qualitativa;
• processamento de imagens;
• triagem de estudos;
• geoprocessamento;
• simulação;
• cálculo amostral;
• gerenciamento bibliográfico;
• visualização;
• outra função.

Essa anotação ajuda posteriormente a decidir quanto detalhe será necessário na metodologia.

18. Componentes necessários à reprodutibilidade

Dependendo da pesquisa, também pode ser útil registrar:

• sistema operacional;
• versão de linguagem;
• ambiente virtual;
• sementes aleatórias;
• parâmetros;
• hardware relevante;
• drivers;
• dependências;
• scripts;
• arquivos de configuração.

Esses elementos não são universalmente necessários em todo TCC.

Eles devem ser registrados quando ajudam a compreender ou reproduzir o procedimento.

Checklist de metadados antes de construir a referência

Antes de começar a formatar, verifique se você conseguiu identificar:

• nome oficial do software;
• responsável ou responsáveis;
• versão utilizada;
• edição, quando aplicável;
• data correspondente ao recurso;
• local, quando aplicável e disponível;
• natureza do recurso eletrônico;
• URL apropriada, quando pertinente;
• data de acesso, quando aplicável;
• DOI ou outro identificador persistente;
• pacotes relevantes;
• bibliotecas relevantes;
• módulos, plugins ou extensões importantes;
• artigo científico recomendado pelo projeto;
• manual ou documentação efetivamente consultados;
• orientação oficial de citação;
• função desempenhada pelo programa;
• informações adicionais necessárias à compreensão ou reprodução do procedimento.

Onde encontrar a versão do software?

A localização varia conforme o recurso.

Procure inicialmente em:

• menu “Ajuda”;
• menu “Sobre”;
• tela inicial;
• documentação;
• terminal ou linha de comando;
• gerenciador de pacotes;
• histórico de releases;
• repositório oficial;
• arquivo de instalação;
• registro persistente.

Em linguagens e ambientes científicos, também podem existir comandos capazes de retornar a versão e informações da sessão.

E se eu não souber qual versão utilizei?

Primeiro tente reconstruir essa informação a partir dos registros da pesquisa.

Verifique:

• computador em que a análise foi executada;
• arquivos de projeto;
• logs;
• scripts;
• relatórios exportados;
• histórico do ambiente;
• arquivos de dependências;
• capturas de tela;
• datas de instalação;
• registros do repositório.

Se a versão realmente não puder ser determinada, não substitua essa lacuna pela versão atualmente disponível no site.

Essa prática criaria uma precisão falsa.

O site oficial sempre possui todos os dados necessários?

Não.

O site oficial é uma fonte importante, mas pode apresentar apenas a versão atual, enquanto a pesquisa utilizou uma versão anterior.

Em outros casos, os metadados mais precisos podem estar:

• na documentação;
• em uma release;
• no repositório oficial;
• em um arquivo CITATION.cff;
• em um depósito científico;
• no próprio software;
• em um comando interno de citação.

O objetivo não é encontrar apenas uma página oficial, mas localizar a fonte oficial ou confiável que melhor identifica o objeto efetivamente utilizado.

Posso copiar a referência de outro TCC?

Não é recomendável utilizar outro trabalho acadêmico como fonte principal dos metadados do software.

O autor daquele TCC pode ter utilizado:

• outra versão;
• outro ano;
• outro módulo;
• outra edição;
• outra URL;
• um padrão institucional diferente;
• uma referência incorreta.

Uma referência encontrada em outro trabalho pode servir como pista para a investigação, mas deve ser conferida contra os dados do recurso realmente utilizado.

Como fazer referência de software nas normas ABNT?

Depois de identificar corretamente o software e reunir seus metadados, é possível iniciar a construção da referência.

Essa ordem é importante.

O pesquisador não deveria começar procurando um modelo pronto para depois tentar encaixar o programa nele. O procedimento mais seguro é o contrário:

1. identificar exatamente o recurso utilizado;
2. coletar os metadados disponíveis;
3. confirmar a responsabilidade pelo software;
4. registrar a versão efetivamente utilizada;
5. verificar datas, identificadores e informações de acesso;
6. consultar a orientação oficial de citação, quando existir;
7. somente então organizar os elementos segundo o padrão bibliográfico aplicável.

A ABNT NBR 6023:2025 contempla programas de computador entre os documentos de acesso exclusivo em meio eletrônico. Entretanto, isso não significa que todos os softwares apresentem exatamente os mesmos elementos bibliográficos.

Um programa instalado localmente, uma biblioteca científica, um aplicativo, um software executado no navegador, uma release hospedada em repositório e um programa desenvolvido pelo próprio pesquisador podem apresentar metadados bastante diferentes.

Estrutura didática geral para referência de software

Como ferramenta de compreensão, podemos representar a lógica geral da referência desta forma:

RESPONSABILIDADE. Título do software. Versão/edição, quando houver. Local, quando aplicável: responsável pela publicação/distribuição, quando identificável e pertinente, data. Descrição do recurso eletrônico. Informações de disponibilidade e acesso, quando aplicáveis.

Essa estrutura é didática.

Ela não deve ser tratada como uma fórmula rígida em que todos os campos precisam obrigatoriamente ser preenchidos para qualquer software.

Os elementos dependem do objeto e dos metadados efetivamente disponíveis.

O exemplo da própria norma ajuda a entender a lógica

A NBR 6023:2025 apresenta exemplos dentro da categoria de documentos de acesso exclusivo em meio eletrônico, incluindo programa de computador.

O valor didático desses exemplos está em mostrar que o software deve ser tratado como um objeto bibliográfico identificável, e não simplesmente como uma página da internet.

Entretanto, um exemplo normativo não deve ser transformado em um molde mecânico para qualquer programa.

Os metadados de um sistema operacional comercial podem ser muito diferentes dos metadados de:

• um pacote do R;
• uma biblioteca Python;
• um projeto open source;
• um aplicativo móvel;
• um software científico com DOI;
• uma aplicação SaaS;
• um script criado pelo pesquisador.

A lógica é identificar corretamente cada objeto.

Como referenciar software com autor pessoal?

Alguns programas possuem uma pessoa ou um grupo de pessoas claramente indicado como responsável pelo recurso.

Nesse caso, utilize os dados oficiais fornecidos pelo próprio projeto para determinar a responsabilidade bibliográfica.

Não conclua que o primeiro desenvolvedor listado em uma página é necessariamente o único autor da versão utilizada.

Projetos de software podem apresentar:

• autor principal;
• coautores;
• desenvolvedores;
• mantenedores;
• colaboradores;
• organização responsável;
• grupo de desenvolvimento.

Essas categorias não são automaticamente equivalentes.

Quando o projeto fornece uma orientação oficial de citação, ela costuma ser uma das melhores fontes para compreender como a própria equipe atribui responsabilidade ao software.

Como referenciar software com autoria institucional?

Muitos programas são desenvolvidos ou mantidos por empresas, universidades, laboratórios, institutos, fundações ou outras organizações.

Nesses casos, a responsabilidade pode ser institucional.

Entretanto, não escolha uma entidade apenas porque seu logotipo aparece no site.

É necessário verificar qual organização está efetivamente associada à responsabilidade pelo recurso.

E quando não existe um autor pessoal evidente?

A ausência de um nome pessoal não significa que o estudante deva inventar um autor.

Antes de concluir que o software não possui responsabilidade identificável, consulte:

• site oficial;
• documentação;
• seção “Sobre”;
• arquivo CITATION.cff;
• repositório oficial;
• página da release;
• manual;
• artigo recomendado pelo projeto;
• registro em repositório científico;
• metadados do DOI.

Em projetos colaborativos, a forma de atribuição pode estar expressamente indicada em um desses locais.

Somente depois dessa investigação é possível avaliar corretamente como o recurso deve entrar na referência.

O nome da empresa é sempre o autor?

Não.

Uma empresa pode ocupar diferentes posições em relação ao software.

Ela pode ser:

• desenvolvedora;
• proprietária;
• distribuidora;
• mantenedora;
• publicadora;
• adquirente de um projeto desenvolvido anteriormente por terceiros.

Essas funções precisam ser verificadas nos metadados do recurso.

O mesmo cuidado vale para universidades, fundações e comunidades de desenvolvimento.

Como informar a versão?

Utilize a versão efetivamente empregada na pesquisa.

Dependendo do software, ela pode aparecer como:

• versão 4.2;
• version 4.2;
• release 4.2;
• v4.2;
• 2026.1;
• build específico;
• identificador de release.

Na coleta dos dados, preserve a informação de maneira suficientemente precisa para identificar o recurso.

Não substitua automaticamente a terminologia do projeto por outra categoria.

Versão e edição são a mesma coisa?

Não necessariamente.

Alguns recursos utilizam formalmente o conceito de edição. Outros trabalham com versão, release, build ou distribuição.

Se o software informa “versão”, não existe vantagem em transformar arbitrariamente essa informação em “edição” apenas para imitar a estrutura de uma referência de livro.

O objeto deve ser descrito de acordo com sua natureza.

Como referenciar software sem versão?

Primeiro confirme se a versão realmente não existe ou se apenas não foi localizada.

Verifique:

• menu “Sobre”;
• documentação;
• histórico de versões;
• página da release;
• repositório;
• arquivo de citação;
• linha de comando;
• metadados do aplicativo;
• propriedades do programa.

Se o recurso não trabalha com uma versão identificável ou se a informação não puder ser legitimamente recuperada, não invente um número.

Em ferramentas continuamente atualizadas, outras informações — como data ou período de utilização — podem adquirir maior importância metodológica, conforme o contexto.

Como referenciar software sem local?

O mesmo princípio vale para o local.

Não deduza uma cidade simplesmente a partir:

• da sede atual da empresa;
• do endereço de contato;
• do país do domínio;
• do local em que o pesquisador baixou o programa;
• de uma referência encontrada em outro TCC.

Quando o local não puder ser determinado a partir dos metadados aplicáveis, utilize o tratamento bibliográfico adequado ao caso e às orientações institucionais, sem fabricar a informação.

Como referenciar software sem data?

A primeira etapa é descobrir qual data realmente precisa ser identificada.

Um projeto pode apresentar:

• data de lançamento inicial;
• data da versão;
• data da release;
• data da última atualização;
• data do artigo associado;
• data da página;
• ano de copyright;
• data de acesso.

Essas informações não são automaticamente equivalentes.

Quando a data pertinente ao objeto não puder ser determinada, siga o tratamento bibliográfico previsto pelo padrão e pelo manual institucional aplicável, em vez de escolher arbitrariamente outro ano disponível.

Posso usar o ano do artigo científico como ano do software?

Não automaticamente.

Um artigo pode ter sido publicado em determinado ano enquanto a versão do software utilizada na pesquisa foi lançada muito depois.

Também pode acontecer o contrário: o programa existir antes da publicação do artigo de apresentação ou validação.

Portanto:

data do artigo ≠ necessariamente data do software.

Posso usar o ano de copyright do site?

Não automaticamente.

Um rodapé como “© 2026” pode indicar apenas o ano corrente do site.

Ele não prova que determinada versão do software tenha sido publicada naquele ano.

Use datas que estejam realmente relacionadas ao objeto bibliográfico identificado.

Como referenciar software online?

Quando o software é acessado pela internet, é necessário identificar o recurso e também registrar as informações de disponibilidade e acesso pertinentes.

Uma estrutura didática pode seguir esta lógica:

RESPONSABILIDADE. Título do software. Versão, quando houver. Data. Descrição do recurso eletrônico. Disponível em: endereço apropriado. Acesso em: data.

Novamente, esse modelo serve para visualizar os tipos de informação que podem estar presentes. Os elementos concretos dependem do recurso.

Qual URL devo utilizar?

Prefira um endereço que ajude o leitor a localizar o objeto referenciado.

Conforme o caso, pode ser:

• página oficial do software;
• release oficial;
• repositório oficial;
• registro persistente;
• página oficial de distribuição;
• documentação que identifica inequivocamente o recurso.

Evite utilizar um site de download de terceiros quando existe uma fonte oficial mais adequada.

A página inicial da empresa é suficiente?

Nem sempre.

Se uma empresa possui dezenas de produtos, a página inicial institucional pode não identificar adequadamente o software utilizado.

Uma página específica do produto, uma release ou um registro persistente pode fornecer uma identificação muito melhor.

Software online é a mesma coisa que site?

Não necessariamente.

Um programa executado no navegador pode possuir interface web e ainda assim constituir uma aplicação ou serviço computacional distinto da página institucional que o apresenta.

Essa diferença se torna particularmente importante em:

• calculadoras científicas;
• plataformas de análise;
• ferramentas de visualização;
• aplicações estatísticas;
• serviços de processamento;
• software como serviço — SaaS.

Antes de construir uma referência de site, confirme se o objeto relevante não é, na realidade, uma aplicação.

Como referenciar software com DOI?

Alguns projetos de software são depositados em repositórios científicos e recebem identificadores persistentes.

Isso pode facilitar a identificação e a recuperação do recurso.

Entretanto, é indispensável verificar qual objeto o DOI identifica.

O identificador pode corresponder a:

• uma versão específica do software;
• um registro geral do projeto;
• um artigo científico;
• um conjunto de dados;
• um manual;
• outro produto de pesquisa.

Não inclua um DOI na referência apenas porque ele aparece próximo ao nome do programa.

DOI do artigo é DOI do software?

Não.

Se o DOI resolve para um artigo científico, ele identifica aquele artigo.

O fato de o artigo apresentar, validar ou descrever o software não transforma seu DOI em identificador do programa.

DOI de versão e DOI geral do projeto

Alguns repositórios podem fornecer identificadores para versões específicas e, ao mesmo tempo, um identificador associado ao conjunto do projeto.

Quando a finalidade é documentar exatamente a versão utilizada em uma pesquisa, um identificador específico daquela versão pode oferecer maior precisão.

Essa é uma boa prática de identificação e reprodutibilidade, e não deve ser apresentada como se todo software precisasse obrigatoriamente possuir DOI.

Como referenciar software hospedado no GitHub?

O GitHub pode hospedar o código-fonte, a documentação, as releases e os arquivos de metadados de um projeto.

Entretanto:

GitHub não é automaticamente o autor do software.

Antes de construir a referência, verifique:

• quem mantém o projeto;
• quais autores ou organizações são indicados;
• qual release foi utilizada;
• se existe arquivo CITATION.cff;
• se há DOI;
• se existe depósito em repositório científico;
• se o projeto fornece instruções de citação.

O endereço do GitHub pode participar da recuperação do recurso, mas a plataforma de hospedagem não deve ser confundida com a responsabilidade bibliográfica pelo programa.

O que é CITATION.cff?

Alguns projetos mantêm um arquivo chamado CITATION.cff, criado para fornecer metadados estruturados de citação.

Esse arquivo pode indicar, entre outros dados:

• título do software;
• autores;
• versão;
• data;
• DOI;
• repositório;
• mensagem recomendada de citação.

Ele pode ser uma excelente fonte de metadados.

Entretanto, não significa que o formato exibido por uma plataforma já esteja automaticamente ajustado às normas ABNT.

Posso usar a opção “Cite this repository” do GitHub?

Ela pode ajudar a recuperar informações de citação quando o projeto fornece os metadados correspondentes.

Mas é necessário verificar se o repositório:

• é realmente o recurso utilizado;
• corresponde à versão empregada;
• é o repositório oficial;
• possui metadados adequados;
• não representa apenas o código em desenvolvimento quando a pesquisa utilizou uma release específica.

A conveniência de um botão de citação não elimina a necessidade de verificar o objeto.

Software comercial precisa de URL?

A resposta depende da forma como o recurso é identificado e acessado e da estrutura bibliográfica aplicável.

Um software instalado localmente pode apresentar características diferentes de uma aplicação acessada exclusivamente online.

Não acrescente uma URL apenas porque “toda referência moderna precisa ter link”.

Da mesma forma, não omita informações de acesso quando elas forem necessárias para identificar e recuperar o recurso online.

O nome comercial é suficiente?

Nem sempre.

Um produto pode possuir diferentes:

• versões;
• edições;
• módulos;
• plataformas;
• distribuições;
• modalidades de acesso.

Escrever apenas o nome comercial pode deixar o recurso insuficientemente identificado para fins metodológicos.

Preciso informar todos os números de build?

Não necessariamente.

O nível de precisão deve ser proporcional à relevância da informação.

Em alguns estudos, a versão principal é suficiente. Em outros, uma build específica pode ser importante porque contém uma correção ou alteração que interfere no procedimento.

A pergunta útil é:

esse nível de detalhe ajuda a identificar ou reproduzir o recurso realmente utilizado?

Posso criar uma referência usando dados de várias páginas?

É possível que seja necessário consultar mais de uma fonte para compreender os metadados do software.

Por exemplo:

• o programa informa a versão;
• o site informa a organização responsável;
• a release informa a data;
• o CITATION.cff informa os autores;
• o repositório científico informa o DOI.

O cuidado está em confirmar que todos esses dados descrevem o mesmo objeto ou a mesma versão.

Não combine elementos pertencentes a versões diferentes apenas para produzir uma referência mais completa.

Modelo didático para software instalado localmente

Quando os metadados correspondentes estiverem disponíveis, a lógica pode ser visualizada assim:

RESPONSABILIDADE. Nome do software. Versão. Local, quando aplicável: responsável pertinente, data. Programa de computador.

Não copie essa estrutura substituindo palavras mecanicamente. Utilize apenas os elementos que correspondam legitimamente ao recurso.

Modelo didático para software disponível online

RESPONSABILIDADE. Nome do software. Versão, quando houver. Data. Programa de computador. Disponível em: endereço. Acesso em: data.

A estrutura concreta pode variar de acordo com os metadados e com a natureza do recurso.

Modelo didático para software com identificador persistente

RESPONSABILIDADE. Nome do software. Versão. Data. Programa de computador. Identificador persistente, quando correspondente ao objeto referenciado.

O DOI ou outro identificador não deve ser acrescentado sem verificar o que ele resolve.

Modelo didático para software desenvolvido pelo próprio pesquisador

Quando o programa foi formalmente publicado, versionado e depositado, a lógica bibliográfica pode envolver:

RESPONSABILIDADE. Nome do software. Versão. Data. Programa de computador. Repositório ou identificador persistente, quando aplicável.

Se o recurso consiste apenas em um script não publicado utilizado internamente na pesquisa, talvez a questão principal seja sua documentação metodológica e disponibilização em apêndice ou repositório, e não a criação artificial de uma referência de software publicado.

Modelo didático para aplicativo

Aplicativos também devem ser tratados de acordo com seus metadados reais.

A lógica pode envolver:

RESPONSABILIDADE. Nome do aplicativo. Versão. Data. Aplicativo. Informações de disponibilidade e acesso, quando aplicáveis.

A loja em que o aplicativo foi obtido não deve ser transformada automaticamente em autora.

Modelo didático para pacote ou biblioteca científica

Pacotes e bibliotecas podem possuir autoria, versão, documentação, artigos e identificadores próprios.

Uma estrutura didática pode ser representada por:

RESPONSABILIDADE. Nome do pacote ou biblioteca. Versão. Data. Recurso computacional. Informações de disponibilidade ou identificador, quando aplicáveis.

Em vez de confiar nesse esquema genérico, consulte preferencialmente a orientação oficial do projeto.

O que fazer quando o software recomenda citar um artigo?

Considere essa recomendação seriamente.

O artigo pode ser a forma indicada pelo projeto para atribuir crédito científico aos desenvolvedores ou descrever o método implementado.

Entretanto, verifique se o artigo cumpre a mesma função que você precisa documentar.

Em determinadas pesquisas pode ser adequado:

• citar o software;
• citar o artigo recomendado;
• ou citar ambos, cada um por uma razão diferente.

Essa situação será detalhada mais adiante neste guia.

Como citar software no texto do TCC?

Depois de construir a referência, surge outra dúvida: como o software deve aparecer no corpo do trabalho?

Antes de tudo, diferencie uma simples menção metodológica de uma citação bibliográfica.

Menção metodológica

Quando o objetivo é informar qual ferramenta foi utilizada, o nome do programa pode aparecer naturalmente na descrição do método.

Exemplo didático:

Os dados foram analisados no software [NOME], versão [X], utilizando os procedimentos [DESCREVER].

Nesse caso, a frase informa ao leitor qual recurso participou da análise.

A necessidade de chamada bibliográfica adicional dependerá de como o recurso está sendo tratado no trabalho e das orientações aplicáveis.

Citação narrativa

Quando existe uma fonte bibliográfica correspondente e a responsabilidade pelo recurso participa da redação, a chamada pode ser integrada à frase de acordo com o sistema de citações adotado.

A estrutura deve utilizar a responsabilidade bibliográfica real do objeto, e não uma autoria criada apenas para facilitar a frase.

Citação parentética

Também pode ocorrer uma chamada entre parênteses quando a fonte bibliográfica sustenta determinada informação.

Novamente, a forma concreta depende da responsabilidade identificada e do sistema de citações adotado no trabalho.

E quando a autoria é institucional?

Se uma organização é legitimamente responsável pelo recurso, a chamada deve respeitar essa responsabilidade.

Não substitua o nome institucional por uma pessoa apenas porque o formato autor-data parece mais familiar.

E quando não existe autoria pessoal evidente?

Não invente um autor.

Investigue primeiro como o recurso é bibliograficamente identificado.

Em alguns casos, a responsabilidade pode ser institucional. Em outros, o tratamento da entrada pode depender de outros elementos do próprio recurso.

O importante é manter coerência entre:

• objeto utilizado;
• responsabilidade identificada;
• chamada no texto;
• entrada na lista de referências.

Preciso colocar número de página ao citar software?

Não invente paginação para um recurso que não possui páginas.

Se a informação citada provém de um manual, artigo ou documentação paginada, a situação é diferente: nesse caso, o objeto citado é aquele documento.

Esse é mais um motivo para distinguir:

• software;
• manual;
• artigo;
• documentação;
• site.

Posso fazer citação direta de um software?

Software, por si só, não deve ser tratado como se fosse automaticamente um texto paginado do qual se retiram frases.

Se você reproduziu uma afirmação escrita encontrada:

• no manual;
• na documentação;
• em uma página oficial;
• em um artigo;

a fonte textual correspondente deve ser identificada.

Não atribua ao programa uma frase que, na realidade, foi retirada de outro documento.

O nome do software deve ficar em itálico?

Não transforme uma convenção visual encontrada em determinado manual, periódico ou estilo internacional em uma suposta regra universal da ABNT sem verificar a orientação aplicável.

A padronização tipográfica deve seguir as regras adotadas pelo trabalho e pela instituição.

O mais importante é manter consistência e identificar corretamente o recurso.

Preciso repetir a versão toda vez que mencionar o programa?

Normalmente não há necessidade de repetir mecanicamente a versão em todas as ocorrências.

Uma estratégia clara é identificar o recurso de maneira completa na primeira ocorrência metodologicamente relevante e utilizar posteriormente uma forma mais fluida, desde que não surja ambiguidade.

Exemplo:

As análises foram realizadas no software [NOME], versão [X]. Em seguida, o software foi utilizado para…

Se versões diferentes foram utilizadas em etapas diferentes, essa distinção precisa ser explicitada.

Software citado no texto precisa aparecer nas referências?

Quando uma ocorrência funciona efetivamente como citação bibliográfica, deve existir correspondência adequada com a lista de referências.

Entretanto, nem toda menção ao nome de um programa possui automaticamente a mesma função bibliográfica.

Por isso, durante a revisão final, verifique:

• quais ocorrências são simples menções;
• quais são descrições metodológicas;
• quais constituem chamadas bibliográficas;
• quais entradas precisam aparecer nas referências.

Um modelo em cinco etapas para documentar software no texto

Quando o programa possui papel relevante, uma metodologia pode ser organizada seguindo esta sequência:

1. identifique a ferramenta;
2. informe a versão quando relevante;
3. explique sua função;
4. descreva procedimentos, componentes ou parâmetros necessários;
5. inclua a documentação bibliográfica correspondente quando aplicável.

Exemplo didático:

Os dados foram processados no software [NOME], versão [X]. A ferramenta foi utilizada para [FUNÇÃO]. Foram empregados [PACOTE/MÓDULO/PROCEDIMENTO], com [PARÂMETROS OU CRITÉRIOS RELEVANTES].

Essa estrutura é propositalmente genérica. Ela deve ser adaptada ao método real, sem inserir informações que não sejam relevantes para a pesquisa.

Como citar R nas normas ABNT?

O R merece atenção especial porque não funciona apenas como um programa isolado. Ele constitui um ambiente de computação estatística e gráfica capaz de trabalhar com milhares de pacotes desenvolvidos para diferentes finalidades científicas.

Por isso, em uma pesquisa realizada em R podem existir pelo menos três níveis de documentação:

• o próprio R;
• os pacotes metodologicamente relevantes;
• o ambiente ou interface utilizada, quando essa informação tiver importância para o procedimento.

A primeira regra é simples: não copie uma referência de R encontrada em outro TCC sem verificar a instalação efetivamente utilizada.

Como descobrir a versão do R utilizada?

O próprio ambiente permite consultar informações sobre a versão instalada.

Uma opção é:

R.version.string

Também é possível consultar informações da sessão por meio de:

sessionInfo()

Esses registros podem ser particularmente úteis porque ajudam a reconstruir o ambiente em que determinada análise foi realizada.

Como descobrir a forma recomendada de citar R?

O R possui um mecanismo próprio para consultar a informação de citação correspondente ao ambiente instalado.

Utilize:

citation()

O comando retorna informações bibliográficas recomendadas pelo próprio projeto para a instalação correspondente.

Essa é uma fonte muito mais segura de metadados do que copiar uma referência encontrada em um artigo, fórum, blog ou TCC antigo.

Posso copiar exatamente a saída de citation()?

A saída é extremamente útil para identificar os metadados recomendados pelo projeto, mas o formato apresentado não deve ser presumido automaticamente como uma referência pronta nas normas ABNT.

O procedimento mais seguro é:

1. executar citation();
2. identificar corretamente responsabilidade, título, versão, data e demais dados;
3. preservar esses metadados;
4. adaptar sua apresentação ao padrão bibliográfico adotado no trabalho.

Como mencionar R na metodologia?

Uma descrição metodológica deve indicar não apenas que o R foi utilizado, mas também qual função desempenhou.

Exemplo didático:

As análises estatísticas foram realizadas no ambiente R, versão [X], utilizando os procedimentos descritos a seguir.

Se pacotes específicos executaram partes relevantes da análise, eles podem ser informados no mesmo trecho ou em uma descrição posterior.

Exemplo:

As análises foram realizadas no ambiente R, versão [X], com utilização do pacote [PACOTE], versão [Y], para [FUNÇÃO].

O modelo deve ser adaptado ao método real.

Preciso citar os pacotes do R?

Nem todo pacote instalado ou carregado durante uma sessão precisa automaticamente receber uma referência própria.

A decisão deve considerar a contribuição do pacote para a pesquisa.

Um pacote pode:

• implementar o teste estatístico central;
• executar um modelo;
• realizar análise textual;
• processar dados;
• gerar visualizações analíticas;
• implementar algoritmos;
• realizar importação ou exportação de arquivos;
• funcionar apenas como dependência de outro pacote.

Essas funções não possuem necessariamente a mesma relevância metodológica.

Quanto mais diretamente um pacote participa do procedimento científico ou dos resultados, maior tende a ser a importância de documentá-lo adequadamente.

Como descobrir a citação recomendada para um pacote do R?

Muitos pacotes fornecem informações próprias de citação.

No R, utilize:

citation("nomeDoPacote")

Substitua nomeDoPacote pelo nome correspondente.

O resultado pode indicar:

• autores;
• título;
• ano;
• artigo recomendado;
• manual;
• DOI;
• outras informações de atribuição.

Mais uma vez, utilize esses dados como fonte dos metadados e adapte a apresentação bibliográfica quando necessário.

Como descobrir a versão de um pacote do R?

Uma forma de verificar a versão instalada é:

packageVersion("nomeDoPacote")

Esse dado pode ser especialmente importante quando mudanças entre versões alteram funções, argumentos, algoritmos ou resultados.

R e pacote do R são a mesma referência?

Não.

O ambiente R e um pacote desenvolvido para funcionar nele são recursos diferentes.

Eles podem possuir:

• autores diferentes;
• versões diferentes;
• datas diferentes;
• documentação diferente;
• artigos associados diferentes;
• orientações de citação diferentes.

Citar R não significa automaticamente atribuir crédito aos pacotes que executaram uma análise específica.

Preciso citar todos os pacotes carregados?

Normalmente, não.

Uma sessão pode carregar diversos pacotes, incluindo dependências internas que o pesquisador nem utilizou diretamente.

Transformar cada dependência técnica em referência pode criar uma lista extensa sem melhorar a compreensão do método.

Priorize os componentes que:

• executaram procedimentos relevantes;
• implementaram métodos centrais;
• foram utilizados diretamente;
• influenciaram resultados;
• possuem orientação própria de citação que se aplica ao uso realizado.

E os pacotes utilizados apenas para gráficos?

Depende da função da visualização.

Se o pacote foi utilizado apenas para produzir uma apresentação estética simples de resultados já calculados, sua relevância pode ser diferente daquela de um pacote que executou análise ou transformação científica.

Entretanto, determinadas visualizações constituem parte importante do procedimento analítico.

Não existe vantagem em criar uma regra absoluta. Avalie a função real desempenhada pelo componente.

Preciso citar o RStudio?

R e RStudio não são o mesmo recurso.

O R executa a computação estatística; o RStudio funciona como um ambiente integrado de desenvolvimento utilizado para trabalhar com R e outras ferramentas.

Em muitos trabalhos, a informação metodologicamente essencial é a versão do R e dos pacotes utilizados, enquanto a interface de desenvolvimento possui importância secundária.

Em outros contextos, o ambiente pode ser relevante para descrever o fluxo de trabalho.

A decisão deve considerar a contribuição efetiva do RStudio para o procedimento que precisa ser documentado.

R Markdown, Quarto e outros componentes precisam ser citados?

Novamente, depende da função.

Ferramentas de publicação reproduzível podem participar de:

• integração entre código e texto;
• geração automatizada de relatórios;
• execução de análises;
• produção de tabelas;
• documentação do fluxo computacional.

Quando essa infraestrutura é metodologicamente relevante, sua identificação pode ser útil.

Se foi apenas uma forma conveniente de escrever o relatório final, a importância pode ser menor.

Como documentar uma análise realizada com vários pacotes?

Evite transformar a metodologia em uma lista desconectada de nomes.

Uma descrição melhor relaciona cada pacote à função desempenhada.

Exemplo didático:

As análises foram realizadas no R, versão [X]. O pacote [A], versão [Y], foi empregado para [FUNÇÃO]; o pacote [B], versão [Z], foi utilizado para [FUNÇÃO]; e o pacote [C] foi empregado na etapa de [FUNÇÃO].

Se a lista for extensa, uma tabela metodológica ou arquivo suplementar pode ser mais legível, dependendo das regras do trabalho.

Preciso informar o sistema operacional em uma análise com R?

Somente quando essa informação for relevante para compreender ou reproduzir o ambiente.

Em determinados estudos, o sistema operacional pode afetar:

• compilação de pacotes;
• bibliotecas externas;
• caminhos de arquivos;
• processamento paralelo;
• compatibilidade;
• resultados dependentes de implementação.

Em outros trabalhos, essa informação pode ser desnecessária.

Preciso informar a versão de todas as dependências?

Não em todo TCC.

Em projetos altamente computacionais, entretanto, pode ser interessante registrar o ambiente de forma mais completa em um arquivo de dependências ou mecanismo de gerenciamento de ambiente.

A metodologia principal deve permanecer legível, enquanto detalhes adicionais de reprodutibilidade podem ser documentados de maneira complementar quando necessário.

O que guardar para tornar uma análise em R mais reproduzível?

Dependendo da pesquisa, preserve:

• scripts;
• versão do R;
• versões dos pacotes centrais;
• informações da sessão;
• sementes aleatórias;
• arquivos de entrada;
• parâmetros;
• etapas de limpeza dos dados;
• configurações relevantes;
• documentação do ambiente.

Esses elementos não constituem, por si só, requisitos bibliográficos universais da ABNT. Eles pertencem principalmente à documentação científica e à reprodutibilidade.

Como citar Python nas normas ABNT?

Python apresenta um desafio semelhante ao R, mas com uma característica importante: muitas pesquisas utilizam Python principalmente como linguagem e ambiente para executar bibliotecas científicas específicas.

Por isso, escrever apenas “os dados foram analisados em Python” pode fornecer pouca informação sobre o procedimento.

Uma análise pode depender, por exemplo, de bibliotecas destinadas a:

• manipulação de dados;
• computação numérica;
• estatística;
• aprendizado de máquina;
• visualização;
• processamento de imagens;
• processamento de linguagem natural;
• bioinformática;
• simulação;
• otimização.

Como descobrir a versão do Python?

Uma opção no terminal é:

python --version

Em alguns ambientes, também pode ser utilizado:

python3 --version

Dentro do próprio Python, é possível consultar informações de versão, por exemplo:

import sys
print(sys.version)

O objetivo é registrar a versão que efetivamente executou o procedimento.

Python precisa aparecer na metodologia?

Quando a linguagem participou diretamente do processamento ou análise, sua identificação normalmente ajuda a compreender o ambiente computacional.

Exemplo didático:

O processamento dos dados foi realizado em Python, versão [X], utilizando as bibliotecas [A], [B] e [C] para as etapas de [DESCREVER].

Essa estrutura é superior a uma lista de tecnologias porque relaciona cada recurso à função científica desempenhada.

Python e suas bibliotecas são a mesma coisa?

Não.

Python é a linguagem e o ambiente de execução. Bibliotecas adicionam funcionalidades específicas.

Entre os exemplos conhecidos estão:

• NumPy;
• pandas;
• SciPy;
• Matplotlib;
• scikit-learn.

Esses projetos possuem ciclos de desenvolvimento, versões, autores, documentação e orientações próprias.

Citar Python não significa automaticamente documentar todas as bibliotecas utilizadas.

Preciso citar bibliotecas Python?

Quando uma biblioteca executa uma parte cientificamente relevante da análise, sua documentação pode ser apropriada.

Considere duas situações.

Situação 1: Python foi utilizado apenas para renomear centenas de arquivos.

Situação 2: uma biblioteca implementou o algoritmo de aprendizado de máquina responsável pelo resultado principal do estudo.

A importância metodológica do componente é claramente diferente.

Como citar NumPy?

Não utilize uma referência congelada encontrada em outro trabalho como modelo permanente.

Consulte a documentação e as orientações oficiais do projeto correspondentes ao período e à versão utilizados.

Além da referência bibliográfica, registre a versão quando ela for metodologicamente relevante.

Como citar pandas?

O mesmo princípio se aplica ao pandas.

Identifique:

• versão utilizada;
• função desempenhada;
• orientação oficial de citação disponível;
• eventual artigo ou identificador recomendado pelo projeto.

Se pandas foi utilizado apenas para uma operação periférica, o nível de detalhamento pode ser diferente daquele necessário quando transformações fundamentais dos dados dependeram da biblioteca.

Como citar SciPy?

Quando SciPy participa diretamente de cálculos científicos ou procedimentos metodológicos, verifique a orientação oficial do projeto e a versão efetivamente utilizada.

Também é importante distinguir a biblioteca de métodos científicos específicos implementados por suas funções.

Utilizar uma função de otimização, integração ou estatística não elimina a necessidade de fundamentar cientificamente o procedimento quando isso for exigido pelo desenho da pesquisa.

Como citar Matplotlib?

Matplotlib pode participar da produção de gráficos e visualizações.

A relevância de documentá-lo depende do papel desempenhado.

Uma visualização puramente ilustrativa pode exigir tratamento diferente de uma visualização que constitui parte central do procedimento analítico.

Consulte a orientação oficial do projeto em vez de presumir que qualquer referência encontrada na internet permanece adequada para todas as versões.

Como citar scikit-learn?

Em pesquisas de aprendizado de máquina, simplesmente mencionar scikit-learn pode ser insuficiente.

Dependendo do estudo, também podem ser importantes:

• versão da biblioteca;
• algoritmo utilizado;
• hiperparâmetros;
• estratégia de validação;
• métrica de desempenho;
• pré-processamento;
• divisão dos dados;
• semente aleatória;
• procedimentos de ajuste.

A biblioteca identifica a implementação utilizada. A metodologia precisa explicar o experimento.

Biblioteca Python e artigo científico são a mesma referência?

Não.

Um projeto pode recomendar um artigo científico para atribuição ou fundamentação.

Esse artigo pode explicar:

• arquitetura;
• desenvolvimento;
• algoritmos;
• desempenho;
• histórico;
• filosofia do projeto.

A versão da biblioteca utilizada, entretanto, constitui outra informação.

Dependendo do contexto, pode ser apropriado documentar a biblioteca e citar também o artigo recomendado.

Como descobrir a versão de uma biblioteca Python?

O procedimento varia conforme a biblioteca e o ambiente.

Algumas bibliotecas disponibilizam a informação por atributos internos. Gerenciadores de pacotes também podem mostrar as versões instaladas.

Por exemplo, dependendo do ambiente, comandos como estes podem auxiliar:

pip show nome-da-biblioteca

ou:

pip freeze

Ambientes gerenciados por outras ferramentas possuem mecanismos equivalentes.

O importante é registrar o ambiente realmente utilizado, não o ambiente atual meses depois.

Preciso citar todas as bibliotecas instaladas?

Não.

Um ambiente Python pode conter dezenas ou centenas de pacotes.

Muitos são dependências indiretas e não foram utilizados conscientemente pelo pesquisador.

Para a metodologia principal, priorize bibliotecas que:

• implementaram procedimentos centrais;
• foram chamadas diretamente pelo código;
• interferiram na produção dos resultados;
• precisam ser conhecidas para compreender o fluxo analítico.

Em pesquisas computacionais mais complexas, a lista completa de dependências pode ser preservada em arquivo próprio para fins de reprodutibilidade.

Jupyter Notebook precisa ser citado?

Jupyter Notebook pode ser utilizado como ambiente para combinar código, resultados, texto e visualizações.

Se sua função foi apenas oferecer uma interface para executar Python, sua relevância pode ser secundária em comparação com a linguagem e as bibliotecas responsáveis pelos cálculos.

Entretanto, quando notebooks constituem parte importante do fluxo reproduzível, da documentação ou do material disponibilizado, sua identificação pode ser pertinente.

Mais uma vez, a decisão deve ser orientada pela função desempenhada.

Anaconda precisa ser citado?

Anaconda pode atuar como distribuição e ambiente de gerenciamento de pacotes e dependências.

Em muitos trabalhos, o elemento científico central será Python e as bibliotecas utilizadas.

Em pesquisas nas quais a distribuição ou o ambiente específico influencia a reprodução do procedimento, essa informação pode ser documentada adicionalmente.

Não confunda:

• Python;
• distribuição;
• gerenciador de ambientes;
• interface;
• bibliotecas científicas.

Conda, pip e ambientes virtuais precisam aparecer no TCC?

Não necessariamente no corpo principal.

Mas, em pesquisas altamente computacionais, registrar o ambiente pode ser extremamente útil para reprodução.

Isso pode envolver arquivos como:

• requirements.txt;
• environment.yml;
• outros registros de dependências.

Esses arquivos podem ser disponibilizados junto ao código ou em repositório quando o desenho da pesquisa justificar esse nível de documentação.

Preciso informar a versão do sistema operacional?

Somente quando ela tiver relevância para o procedimento.

Alguns pacotes ou bibliotecas dependem de:

• sistema operacional;
• arquitetura;
• drivers;
• compiladores;
• bibliotecas externas;
• hardware específico.

Em outros estudos, essas diferenças não afetam o resultado de maneira relevante.

E quando a pesquisa utiliza GPU?

Em aprendizado de máquina, processamento de imagens, simulação ou computação de alto desempenho, informações sobre hardware e bibliotecas associadas podem ser importantes para reprodução ou desempenho.

Dependendo do projeto, pode ser pertinente registrar:

• modelo de GPU;
• bibliotecas de aceleração;
• versões relevantes;
• framework utilizado;
• configurações determinantes.

Esses elementos pertencem principalmente à documentação metodológica, e não à estrutura básica de uma referência ABNT de software.

Como mencionar Python e bibliotecas na metodologia?

Uma formulação adaptável pode seguir esta lógica:

O processamento foi realizado em Python, versão [X]. A biblioteca [A], versão [Y], foi utilizada para [FUNÇÃO], enquanto [B], versão [Z], foi empregada para [FUNÇÃO]. Os parâmetros relevantes foram [DESCREVER].

Se a pesquisa utilizar muitas bibliotecas, evite uma frase excessivamente longa.

Uma tabela pode ser mais clara:

Recurso	Versão	Função na pesquisa
Python	[versão]	Ambiente de execução
[Biblioteca A]	[versão]	[função]
[Biblioteca B]	[versão]	[função]
[Biblioteca C]	[versão]	[função]

Como documentar um projeto Python para reprodutibilidade?

Dependendo do estudo, preserve:

• código-fonte;
• versão do Python;
• versões das bibliotecas centrais;
• arquivo de dependências;
• sementes aleatórias;
• parâmetros;
• dados de entrada ou instruções de acesso;
• etapas de pré-processamento;
• ambiente de execução;
• informações de hardware quando relevantes.

Essa documentação pode ser distribuída entre:

• metodologia;
• apêndice;
• material suplementar;
• repositório;
• arquivo de ambiente.

Não é necessário sobrecarregar o corpo do TCC com detalhes técnicos que não ajudam o leitor. O objetivo é encontrar o nível adequado de documentação para o método.

R ou Python: existe diferença na lógica de citação?

Os projetos possuem ecossistemas diferentes, mas a lógica metodológica geral é semelhante:

Questão	R	Python
Ambiente principal	R	Python
Componentes adicionais	Pacotes	Bibliotecas/pacotes
Versão principal	Registrar quando relevante	Registrar quando relevante
Versões dos componentes	Importantes quando afetam o método	Importantes quando afetam o método
Orientação de citação	Pode ser consultada no próprio ambiente e nos pacotes	Deve ser verificada nos projetos oficiais correspondentes
Descrição metodológica	Explicar análises, pacotes e parâmetros	Explicar bibliotecas, algoritmos e parâmetros
Reprodutibilidade	Scripts, sessão e ambiente podem ser relevantes	Código, dependências e ambiente podem ser relevantes

Preciso citar o código que escrevi em R ou Python?

O código criado pelo próprio pesquisador precisa ser analisado de acordo com sua natureza.

Um pequeno script interno utilizado para automatizar uma etapa pode ser documentado metodologicamente e, quando pertinente, disponibilizado em apêndice ou repositório.

Um software independente, formalmente versionado, publicado e depositado pode constituir um objeto bibliográfico próprio.

Portanto, código escrito em R ou Python não se transforma automaticamente em uma referência apenas porque existe como arquivo.

GitHub substitui a documentação do ambiente?

Não.

Depositar o código em um repositório é útil, mas não garante sozinho que outra pessoa consiga reproduzir a análise.

O repositório pode precisar conter informações como:

• versão da linguagem;
• dependências;
• instruções de instalação;
• parâmetros;
• dados ou instruções de acesso;
• versão/release correspondente à pesquisa.

Além disso, um repositório em desenvolvimento pode mudar depois da conclusão do TCC.

Quando a precisão da versão for importante, releases, tags ou depósitos persistentes podem ajudar a identificar o estado utilizado.

Uma referência perfeita garante reprodutibilidade?

Não.

Uma referência pode identificar corretamente Python, R ou uma biblioteca e ainda assim ser insuficiente para reproduzir a pesquisa.

Reprodutibilidade pode depender de:

• código;
• dados;
• versões;
• parâmetros;
• sementes;
• dependências;
• configurações;
• hardware;
• sequência das etapas.

A referência é apenas uma das peças desse registro.

Como citar SPSS nas normas ABNT?

O SPSS é frequentemente utilizado em trabalhos acadêmicos para análise estatística, preparação de dados e execução de diferentes procedimentos quantitativos.

Ao documentar seu uso, existem pelo menos três perguntas diferentes:

1. qual versão do software foi utilizada;
2. como identificar bibliograficamente o recurso;
3. quais análises foram executadas no programa.

Essas perguntas não devem ser respondidas pela mesma informação.

Qual versão do SPSS devo informar?

Registre a versão efetivamente utilizada durante a pesquisa.

Não consulte apenas a página atual do produto e suponha que a versão exibida seja a mesma instalada no período da análise.

A versão pode ser verificada no próprio programa e em informações da instalação.

Quem é o responsável pelo SPSS?

Ao elaborar a referência, utilize os metadados oficiais correspondentes ao produto e à versão utilizada.

Não determine a responsabilidade bibliográfica apenas com base em uma referência copiada de outro TCC.

Softwares comerciais podem passar por mudanças de:

• propriedade;
• nome;
• marca;
• distribuição;
• responsabilidade institucional;
• forma de licenciamento.

Por isso, os dados devem ser conferidos para o recurso efetivamente utilizado.

Como mencionar SPSS na metodologia?

Uma formulação genérica pode seguir esta lógica:

As análises estatísticas foram realizadas no software [NOME OFICIAL], versão [X]. Foram empregados os procedimentos [DESCREVER], considerando [CRITÉRIOS RELEVANTES].

A frase deve ser adaptada ao estudo.

O nome do software não substitui a descrição de:

• teste estatístico;
• nível de significância;
• modelo;
• variáveis;
• tratamento dos dados;
• pressupostos;
• procedimentos de comparação;
• critérios analíticos.

Preciso citar SPSS e também o método estatístico?

Quando o método exige fundamentação científica, sim, são funções diferentes.

O software identifica a implementação computacional utilizada.

A literatura metodológica pode fundamentar:

• o teste;
• o modelo;
• os pressupostos;
• o procedimento de estimação;
• os critérios de interpretação.

Citar o programa não transforma seu fabricante em referência metodológica para toda técnica estatística executada nele.

Preciso informar módulos do SPSS?

Se um módulo específico foi determinante para o procedimento e sua identificação ajuda a compreender o método, essa informação pode ser relevante.

Não existe necessidade de listar componentes que não tiveram participação significativa na pesquisa.

Como citar jamovi nas normas ABNT?

O jamovi é utilizado em pesquisas acadêmicas para análises estatísticas por meio de uma interface gráfica e de módulos que ampliam suas funcionalidades.

Por isso, sua documentação pode envolver:

• o próprio jamovi;
• a versão utilizada;
• módulos relevantes;
• procedimentos estatísticos executados.

Como descobrir os dados para citar jamovi?

Consulte preferencialmente:

• o próprio programa;
• site oficial;
• documentação oficial;
• orientação de citação do projeto;
• informações da versão utilizada.

Se o projeto oferece uma referência recomendada, utilize-a para recuperar os metadados corretos e depois adapte a apresentação ao padrão bibliográfico aplicável.

Preciso informar a versão do jamovi?

Quando a versão estiver disponível e for relevante para identificar o recurso utilizado, registre-a.

Atualizações podem alterar:

• funcionalidades;
• módulos;
• opções de análise;
• comportamento de procedimentos;
• interface;
• dependências.

Preciso citar módulos do jamovi?

Um módulo pode implementar justamente o procedimento central da pesquisa.

Quando isso acontece, verifique:

• nome do módulo;
• versão;
• responsáveis;
• orientação de citação;
• artigo ou documentação recomendados.

Não trate automaticamente um módulo como se fosse apenas uma parte indistinguível do programa principal.

Como mencionar jamovi na metodologia?

Exemplo adaptável:

As análises estatísticas foram realizadas no jamovi, versão [X]. Para [PROCEDIMENTO], foi utilizado o módulo [NOME], versão [Y], adotando-se [CRITÉRIOS/PARÂMETROS].

Se nenhum módulo adicional metodologicamente relevante tiver sido utilizado, não é necessário inventar esse nível de detalhe.

Como citar IRaMuTeQ nas normas ABNT?

O IRaMuTeQ é utilizado em pesquisas que trabalham com análise textual e diferentes procedimentos aplicados a corpora.

Seu uso exige um cuidado especial: citar ou mencionar o software não substitui a explicação de como o corpus foi construído e analisado.

O que documentar ao utilizar IRaMuTeQ?

Dependendo do desenho do estudo, podem ser importantes:

• versão do IRaMuTeQ;
• constituição do corpus;
• preparação dos textos;
• codificação das variáveis;
• procedimento analítico;
• critérios de retenção ou interpretação;
• tratamento do material;
• outros componentes do ambiente quando metodologicamente relevantes.

IRaMuTeQ e R são a mesma coisa?

Não.

Embora exista relação técnica entre as ferramentas, elas não devem ser tratadas bibliograficamente como se fossem o mesmo objeto.

Se a pesquisa utilizou IRaMuTeQ por meio de um ambiente que depende de R, isso não significa automaticamente que citar apenas R documenta o IRaMuTeQ — nem que citar apenas IRaMuTeQ documenta todos os componentes técnicos do ambiente.

O nível de detalhamento deve acompanhar a importância de cada componente para o procedimento.

Como mencionar IRaMuTeQ na metodologia?

Exemplo adaptável:

O corpus foi processado no software IRaMuTeQ, versão [X], para realização de [TIPO DE ANÁLISE]. O material foi preparado conforme [DESCREVER PROCEDIMENTO], considerando [CRITÉRIOS RELEVANTES].

O trecho deve explicar a análise real executada.

Como citar outros softwares utilizados em pesquisa?

O mesmo raciocínio aplicado a R, Python, SPSS, jamovi e IRaMuTeQ pode ser utilizado para outros programas científicos.

Em vez de memorizar dezenas de modelos de referência, aplique uma sequência comum:

1. identifique o recurso;
2. confirme a versão;
3. descubra a responsabilidade;
4. consulte a orientação oficial de citação;
5. registre os componentes relevantes;
6. explique a função do software na metodologia;
7. separe software, manual, documentação e artigos associados.

Como citar NVivo?

Em pesquisas qualitativas, NVivo pode ser utilizado para organizar, codificar, recuperar e explorar materiais.

Ao documentá-lo, verifique:

• nome oficial do produto;
• versão utilizada;
• responsabilidade correspondente à versão;
• função desempenhada;
• recursos específicos metodologicamente relevantes.

Uma metodologia não deveria apresentar o software como substituto do método qualitativo.

Exemplo:

O material foi organizado e codificado com auxílio do software [NOME], versão [X], no contexto da análise [MÉTODO], realizada conforme [FUNDAMENTAÇÃO/PROCEDIMENTO].

Como citar ATLAS.ti?

O ATLAS.ti também pode apoiar diferentes procedimentos de pesquisa qualitativa.

Registre a versão efetivamente utilizada e explique quais funções participaram da análise.

Isso pode incluir:

• codificação;
• organização de documentos;
• recuperação de segmentos;
• relações entre códigos;
• memorandos;
• visualizações.

Não descreva automaticamente qualquer uma dessas funções se ela não tiver sido utilizada no estudo.

Como citar MAXQDA?

A mesma lógica se aplica ao MAXQDA.

O pesquisador deve distinguir:

• o software;
• a versão;
• os recursos efetivamente utilizados;
• o método científico que orientou a análise.

O programa pode apoiar a análise, mas não define sozinho o referencial metodológico.

NVivo, ATLAS.ti e MAXQDA determinam o método qualitativo?

Não.

Um mesmo software pode ser utilizado em pesquisas orientadas por diferentes abordagens.

Por isso, frases como estas são metodologicamente frágeis:

Foi realizada análise qualitativa pelo software X.

Uma descrição mais informativa separa:

1. método ou abordagem;
2. procedimento analítico;
3. software utilizado como apoio;
4. versão;
5. operações realizadas.

Como citar MATLAB?

MATLAB pode ser utilizado em cálculos numéricos, modelagem, processamento de sinais, processamento de imagens, simulação, otimização e diversas aplicações científicas.

Ao documentá-lo, verifique:

• versão ou release;
• responsabilidade oficial;
• toolboxes relevantes;
• função desempenhada;
• parâmetros e configurações quando necessários.

Preciso citar toolboxes do MATLAB?

Se uma toolbox implementou uma função central da pesquisa, sua identificação pode ser metodologicamente importante.

Imagine que a análise principal dependa de uma toolbox especializada em processamento de sinais.

Nesse caso, escrever apenas “foi utilizado MATLAB” pode não explicar suficientemente o ambiente responsável pelo procedimento.

Por outro lado, não existe necessidade de listar toolboxes instaladas que não participaram da pesquisa.

Como citar Stata?

Ao utilizar Stata, registre a versão efetivamente empregada e os metadados oficiais correspondentes.

Na metodologia, descreva os procedimentos estatísticos executados.

Se comandos, extensões ou componentes adicionais foram essenciais, avalie a necessidade de documentá-los separadamente.

Como citar SAS?

O SAS pode envolver diferentes produtos, módulos e componentes.

Portanto, escrever apenas “SAS” pode ser insuficiente em determinados estudos.

Verifique:

• produto utilizado;
• versão;
• módulos relevantes;
• procedimentos executados;
• responsabilidade correspondente ao recurso.

Como citar JASP?

JASP pode ser utilizado em diferentes análises estatísticas.

Consulte a orientação oficial do projeto para obter os metadados adequados e registre a versão efetivamente utilizada.

Na metodologia, explique quais análises foram realizadas e os critérios adotados.

Como citar G*Power?

G*Power é frequentemente utilizado em cálculos relacionados a tamanho de amostra e poder estatístico.

Quando ele participa do planejamento metodológico, o nome do software não é suficiente para explicar o cálculo.

Dependendo do estudo, devem ser descritos elementos como:

• tipo de teste;
• tamanho de efeito;
• nível de significância;
• poder desejado;
• número de grupos;
• outras entradas do cálculo.

O programa executa o cálculo; a metodologia precisa informar quais pressupostos e parâmetros foram utilizados.

Como citar GraphPad Prism?

GraphPad Prism pode ser empregado em análises estatísticas, organização de dados e visualizações.

Registre:

• versão utilizada;
• metadados oficiais;
• função desempenhada;
• procedimentos analíticos relevantes.

Não confunda o uso do programa com a fundamentação dos testes estatísticos realizados.

Como citar GeoGebra?

GeoGebra pode aparecer em pesquisas de matemática, educação e áreas relacionadas tanto como ferramenta quanto como objeto de estudo.

Essas duas situações devem ser distinguidas.

Como ferramenta: explique para que foi utilizado.

Como objeto de pesquisa: identifique claramente a versão, plataforma ou recurso investigado e descreva o contexto da análise.

Como citar QGIS?

QGIS é amplamente utilizado em geoprocessamento e análise espacial.

Ao documentá-lo, podem ser relevantes:

• versão;
• plugins;
• algoritmos;
• sistema de referência de coordenadas;
• procedimentos de geoprocessamento;
• fontes dos dados espaciais.

Entretanto, essas informações não cumprem todas a mesma função.

A versão identifica o ambiente. Plugins e algoritmos ajudam a documentar o procedimento. O sistema de coordenadas descreve o tratamento espacial. As fontes identificam os dados utilizados.

Citar QGIS significa citar os dados geográficos?

Não.

O software e os dados são objetos diferentes.

Se o pesquisador utilizou:

• shapefiles;
• imagens de satélite;
• modelos digitais de elevação;
• dados censitários;
• bases cartográficas;
• serviços geográficos;

essas fontes precisam ser documentadas de acordo com sua natureza.

Como citar ArcGIS?

O ArcGIS pode envolver diferentes produtos, aplicações e serviços.

Por isso, identifique exatamente qual recurso foi utilizado.

Dependendo da pesquisa, pode ser necessário registrar:

• produto;
• versão;
• extensões;
• ferramentas;
• procedimentos;
• fontes dos dados.

Evite utilizar “ArcGIS” como um rótulo genérico quando a precisão do produto ou ambiente for relevante para a pesquisa.

QGIS e ArcGIS: software, mapa e fonte de dados são coisas diferentes

Essa distinção merece ser reforçada.

Elemento	O que representa
QGIS ou ArcGIS	Ferramenta computacional utilizada no processamento ou análise.
Mapa produzido	Resultado cartográfico elaborado a partir de dados e procedimentos.
Base geográfica	Dados utilizados para produzir ou analisar a informação espacial.
Imagem de satélite	Fonte de dados de sensoriamento remoto.
Plugin/extensão	Componente adicional que pode executar determinada função.

Uma pesquisa pode precisar documentar vários desses elementos simultaneamente.

Como citar Excel?

Excel exige uma análise contextual porque seu uso varia de tarefas administrativas simples a procedimentos analíticos complexos.

Considere três níveis.

Excel usado apenas para armazenar dados

Se a planilha foi utilizada apenas para organizar informações antes da análise em outro programa, a relevância metodológica do Excel pode ser pequena.

Excel utilizado para transformar dados

Se fórmulas, funções, macros ou procedimentos da planilha alteraram os dados antes da análise, essa etapa pode precisar ser descrita.

Exemplos:

• recodificação;
• normalização;
• cálculo de índices;
• tratamento de datas;
• agregação;
• classificação;
• automatização por macros.

Excel utilizado para produzir resultados

Quando cálculos analíticos, modelos ou procedimentos responsáveis pelos resultados são executados na planilha, a relevância metodológica aumenta.

Nesse caso, pode ser necessário explicar:

• versão;
• fórmulas;
• funções;
• macros;
• procedimentos;
• critérios utilizados.

Software comercial e software livre são citados de maneiras completamente diferentes?

A natureza da licença não elimina a necessidade de identificar corretamente o recurso.

Tanto um programa comercial quanto um projeto livre podem possuir:

• responsáveis;
• versões;
• datas;
• documentação;
• artigos;
• identificadores;
• orientações de citação.

A diferença é que projetos open source frequentemente disponibilizam metadados adicionais em repositórios, releases e arquivos estruturados.

Isso será aprofundado adiante.

Comparação prática: o que verificar em cada tipo de software?

Tipo de recurso	O que verificar	O que explicar na metodologia
Software estatístico	Versão, responsabilidade, módulos	Testes, modelos, critérios e parâmetros
Software qualitativo	Versão e recursos utilizados	Método, codificação, categorias e procedimentos
Análise textual	Versão e ambiente relevante	Corpus, preparação e tipo de análise
Simulação	Versão, módulos e componentes	Modelo, parâmetros, condições e configurações
GIS	Versão, plugins e ferramentas	Processamento, projeção, dados e operações espaciais
Cálculo amostral	Versão do programa	Entradas e pressupostos do cálculo
Planilha	Versão quando relevante	Fórmulas, transformações, macros e cálculos importantes
Software desenvolvido pelo pesquisador	Versão, depósito e identificador quando existentes	Funcionamento, finalidade, código e validação pertinente

E quando vários softwares são usados na mesma pesquisa?

Isso é comum.

Uma pesquisa pode utilizar:

• Excel para organização inicial;
• Python para limpeza;
• R para análise estatística;
• QGIS para análise espacial;
• um programa gráfico para preparar figuras.

Não transforme a metodologia em um inventário de marcas.

Relacione cada ferramenta à etapa em que ela realmente participou.

Exemplo didático:

Os dados foram inicialmente organizados em [RECURSO]. A etapa de limpeza e transformação foi realizada em [RECURSO], versão [X]. As análises estatísticas foram conduzidas em [RECURSO], versão [Y], enquanto o processamento espacial foi realizado em [RECURSO], versão [Z].

Em seguida, detalhe os procedimentos necessários para compreender cada etapa.

O software substitui a referência do método?

Não.

Esse é um dos princípios mais importantes de todo este guia.

Se o pesquisador realizou:

• regressão;
• análise de sobrevivência;
• análise temática;
• classificação hierárquica;
• modelagem;
• teste de hipótese;
• análise espacial;
• aprendizado de máquina;

a identificação do programa não substitui a fundamentação científica necessária ao procedimento.

Preciso citar Zotero ou Mendeley no TCC?

Zotero e Mendeley são utilizados principalmente para organizar referências, armazenar documentos, inserir citações e gerar listas bibliográficas. O simples fato de uma dessas ferramentas ter sido utilizada durante a elaboração do TCC não significa, por si só, que ela precise receber o mesmo tratamento de um software responsável pela produção dos resultados científicos.

Mais uma vez, a decisão depende da função desempenhada.

Quando Zotero ou Mendeley são apenas ferramentas operacionais

Se o estudante utilizou o gerenciador apenas para:

• armazenar artigos;
• organizar pastas;
• guardar PDFs;
• inserir citações no editor de texto;
• montar automaticamente a lista de referências;

a ferramenta geralmente possui relevância metodológica muito menor do que um programa utilizado para analisar os dados.

Isso é semelhante ao uso de um editor de texto: a ferramenta ajudou a produzir o documento, mas não necessariamente participou do método científico.

Quando o gerenciador pode adquirir relevância metodológica?

Existem situações em que Zotero, Mendeley ou outra ferramenta de gerenciamento bibliográfico participa de maneira mais direta do fluxo de pesquisa.

Isso pode ocorrer, por exemplo, quando o software é utilizado para:

• gerenciar resultados de buscas bibliográficas;
• identificar duplicatas;
• organizar registros recuperados em bases de dados;
• exportar conjuntos de referências para outras ferramentas;
• apoiar etapas documentadas de uma revisão;
• constituir o próprio objeto de comparação ou avaliação.

Nesses casos, mencionar a ferramenta na metodologia pode ajudar a reconstruir o fluxo da pesquisa.

O gerenciador garante que a referência esteja correta?

Não.

Gerenciadores bibliográficos trabalham a partir dos metadados disponíveis.

Se os dados importados estiverem errados, incompletos ou classificados incorretamente, a referência gerada também poderá apresentar problemas.

Erros comuns incluem:

• autor no campo incorreto;
• título com capitalização inadequada;
• nome do periódico incompleto;
• DOI ausente;
• tipo de documento incorreto;
• data errada;
• edição ausente;
• instituição cadastrada como pessoa;
• metadados importados de uma página intermediária.

Como citar aplicativo nas normas ABNT?

Aplicativos podem desempenhar funções muito diferentes em uma pesquisa.

Um app pode ser:

• instrumento de coleta de dados;
• ferramenta de intervenção;
• meio de comunicação com participantes;
• instrumento de medição;
• plataforma educacional;
• objeto da pesquisa;
• ferramenta de apoio;
• recurso utilizado apenas operacionalmente.

Antes de elaborar a referência, identifique qual dessas funções se aplica.

Quais dados registrar de um aplicativo?

Dependendo do recurso, procure identificar:

• nome oficial;
• responsável;
• versão;
• plataforma;
• data correspondente à versão;
• site oficial;
• página oficial de distribuição;
• informações de acesso;
• outros metadados fornecidos pelo desenvolvedor.

A App Store ou o Google Play é o autor do aplicativo?

Não automaticamente.

A loja de aplicativos funciona como plataforma de distribuição.

O responsável pelo aplicativo pode ser:

• uma empresa;
• uma universidade;
• um desenvolvedor;
• uma organização;
• uma equipe;
• outra entidade.

Utilize os metadados do recurso para identificar corretamente essa responsabilidade.

Aplicativo utilizado como instrumento de pesquisa

Se o app participou da coleta, medição ou intervenção, a metodologia deve explicar sua função.

Exemplo adaptável:

Os dados foram coletados com auxílio do aplicativo [NOME], versão [X], utilizado para [FUNÇÃO]. O procedimento consistiu em [DESCREVER].

Se o aplicativo produz uma medida científica, também pode ser necessário discutir:

• validade;
• confiabilidade;
• procedimento de medição;
• limitações;
• fundamentação do instrumento.

A referência do aplicativo não substitui essa avaliação metodológica.

Aplicativo como objeto da pesquisa

Quando o objetivo do estudo é avaliar o próprio aplicativo, a identificação precisa ser ainda mais cuidadosa.

Registre, quando pertinente:

• versão;
• sistema operacional;
• data ou período da avaliação;
• funcionalidades analisadas;
• plataforma;
• condições de uso.

Isso é especialmente importante porque aplicativos podem receber atualizações frequentes.

O que fazer quando o aplicativo é atualizado continuamente?

Registre o máximo possível sobre o estado efetivamente analisado.

Dependendo do caso, isso pode incluir:

• número da versão;
• data da versão;
• data da coleta;
• sistema operacional;
• capturas de tela;
• descrição das funcionalidades avaliadas.

A data de acesso sozinha pode não ser suficiente para reconstruir a versão de um aplicativo que muda continuamente.

Como citar software online?

Software online é uma das situações em que mais ocorrem confusões entre programa, site, plataforma e serviço.

O fato de uma ferramenta funcionar no navegador não significa automaticamente que ela deva ser tratada apenas como uma página da internet.

Software online e página institucional

Imagine uma plataforma que permite carregar um conjunto de dados, executar uma análise e exportar os resultados.

Podem existir simultaneamente:

• o software executado no navegador;
• a página institucional do projeto;
• a documentação;
• o manual;
• um artigo científico;
• uma API;
• o serviço de processamento.

Antes de citar, determine qual objeto participou da pesquisa.

Como documentar software como serviço — SaaS?

Aplicações SaaS apresentam um desafio adicional porque podem ser atualizadas sem que o usuário instale uma nova versão.

Quando o estado do sistema é relevante, procure registrar informações como:

• nome do serviço;
• responsável;
• versão, quando informada;
• data ou período de utilização;
• função desempenhada;
• configurações relevantes;
• URL;
• data de acesso.

Como citar calculadora online?

Primeiro verifique se a ferramenta é apenas uma página com conteúdo estático ou uma aplicação que executa um cálculo.

Se o cálculo for metodologicamente relevante, não basta indicar o endereço.

Explique também:

• qual cálculo foi realizado;
• quais valores foram inseridos;
• quais pressupostos foram adotados;
• qual resultado foi obtido;
• qual método científico fundamenta o cálculo.

A ferramenta computacional não substitui a descrição do procedimento.

Software online sem número de versão

Não invente uma versão.

Registre as informações que realmente podem ser confirmadas e, quando metodologicamente importante, informe o período ou a data em que o recurso foi utilizado.

Também pode ser útil preservar registros da interface ou das configurações quando o desenho da pesquisa exigir rastreabilidade.

Posso usar apenas a URL do software online?

Uma URL isolada geralmente não identifica suficientemente o recurso.

Sempre que disponíveis, procure também:

• responsabilidade;
• nome oficial;
• versão;
• data;
• natureza do recurso;
• outros metadados pertinentes.

Como citar software livre e open source?

Softwares livres e projetos open source podem oferecer informações bibliográficas particularmente ricas, porque muitos mantêm publicamente:

• repositório de código;
• histórico de versões;
• releases;
• lista de contribuidores;
• documentação;
• arquivo CITATION.cff;
• DOI;
• depósitos em repositórios científicos.

Ao mesmo tempo, essa abundância de informações pode criar dúvidas sobre qual delas utilizar.

Quem é o autor de um software open source?

Não existe uma resposta universal.

Um projeto pode atribuir responsabilidade a:

• um ou mais autores;
• uma equipe;
• uma comunidade formalmente nomeada;
• uma fundação;
• uma instituição;
• um grupo de pesquisa.

A lista de contribuidores de um repositório não deve ser convertida automaticamente em lista de autores bibliográficos.

Procure a forma de atribuição recomendada pelo próprio projeto.

GitHub é o autor?

Não.

O GitHub é uma plataforma de hospedagem e colaboração em código.

Um projeto hospedado no GitHub pode ter autoria completamente independente da plataforma.

Repositório é a mesma coisa que software?

Não necessariamente.

Um repositório pode conter:

• código-fonte;
• documentação;
• arquivos de configuração;
• dados de teste;
• versões em desenvolvimento;
• releases;
• histórico de alterações.

O software utilizado pelo pesquisador pode corresponder a uma release específica dentro desse repositório.

Por isso, citar apenas a página principal do repositório pode ser menos preciso do que identificar a versão realmente empregada.

O que é uma release?

Uma release representa um estado identificado do software disponibilizado pelo projeto.

Ela pode possuir:

• número de versão;
• data;
• arquivos específicos;
• notas de lançamento;
• tag;
• metadados próprios.

Quando a pesquisa depende de uma versão específica, a release pode oferecer um ponto de identificação mais preciso do que a página principal de um repositório em constante desenvolvimento.

Preciso informar o commit?

Não em toda pesquisa.

Um identificador de commit pode ser útil quando:

• não existe release correspondente;
• o código muda rapidamente;
• a análise depende de um estado exato do repositório;
• a reprodução exige aquela revisão específica.

Essa é principalmente uma decisão de documentação e reprodutibilidade. Não deve ser apresentada como uma exigência universal da ABNT.

GitHub ou Zenodo: qual usar?

As plataformas podem cumprir funções diferentes.

Um repositório de desenvolvimento como GitHub facilita:

• versionamento;
• colaboração;
• issues;
• histórico de alterações;
• distribuição do código.

Um repositório científico como Zenodo pode ser utilizado para preservar depósitos e atribuir identificadores persistentes a objetos depositados.

Projetos podem integrar esses recursos.

Quando existir um depósito persistente correspondente exatamente à versão utilizada, ele pode oferecer vantagens de recuperação e estabilidade.

Software depositado no Zenodo

Antes de utilizar o registro, confirme:

• título;
• autores ou responsáveis;
• versão;
• data;
• DOI;
• relação entre o depósito e o software utilizado.

O simples fato de encontrar um nome semelhante no repositório não garante que seja o mesmo objeto.

DOI específico da versão ou DOI geral?

Quando o repositório fornece diferentes identificadores, verifique o significado de cada um.

Em determinados sistemas, pode existir:

• um identificador associado a uma versão específica;
• outro associado ao conjunto das versões do projeto.

Para documentar exatamente o software utilizado em um experimento, o identificador da versão específica pode oferecer maior precisão.

Para falar sobre o projeto de forma geral, a finalidade pode ser diferente.

Preciso citar a licença do software?

A licença e a referência bibliográfica cumprem funções diferentes.

Licenças tratam das condições sob as quais o software pode ser utilizado, modificado ou redistribuído.

A referência trata da identificação e atribuição do recurso.

Dependendo do projeto, a licença pode ser relevante para a descrição do material ou para a disponibilização de código, mas ela não substitui a referência.

Software gratuito é a mesma coisa que software open source?

Não.

Um programa pode ser disponibilizado gratuitamente sem que seu código-fonte seja aberto sob uma licença que permita estudo, modificação ou redistribuição.

Da mesma forma, um software open source pode possuir modelos comerciais associados.

Essas classificações não devem ser utilizadas como sinônimos.

Preciso citar software livre de maneira diferente apenas por ele ser livre?

Não existe razão para abandonar os princípios gerais de identificação bibliográfica.

Continue verificando:

• responsabilidade;
• título;
• versão;
• data;
• identificadores;
• informações de acesso;
• orientação oficial de citação.

A vantagem é que projetos abertos frequentemente oferecem mais mecanismos para recuperar esses dados.

Como citar software desenvolvido pelo próprio pesquisador?

Nem todo código criado durante uma pesquisa precisa ser transformado artificialmente em uma publicação de software.

Antes de decidir como documentá-lo, determine a natureza do recurso.

Pequeno script criado para o TCC

Imagine um script curto utilizado para:

• renomear arquivos;
• converter formatos;
• limpar uma base;
• automatizar uma operação;
• calcular uma variável;
• executar uma etapa específica.

Nesse caso, a questão central pode ser explicar o procedimento e, quando pertinente, disponibilizar o código.

Não é necessário fingir que o script constitui um software formalmente publicado se isso não corresponde à realidade.

Conjunto de scripts que implementa o método

Quando vários scripts executam etapas importantes da análise, a documentação deve ser mais cuidadosa.

Considere registrar:

• linguagem;
• versão da linguagem;
• bibliotecas;
• versões relevantes;
• sequência de execução;
• parâmetros;
• entradas;
• saídas;
• local de disponibilização do código.

Software independente desenvolvido na pesquisa

Se o estudante desenvolveu um programa com identidade própria, interface, funcionalidades e ciclo de versões, ele pode constituir um produto de pesquisa independente.

Nesse caso, pode ser apropriado estabelecer:

• nome oficial;
• autoria;
• versão;
• data;
• documentação;
• repositório;
• licença;
• identificador persistente, quando houver.

Posso referenciar meu próprio software?

Se o software constitui um objeto formalmente identificável e recuperável, ele pode ser tratado como produção do próprio pesquisador.

A referência deve representar o objeto real.

Não crie ficticiamente:

• editora;
• cidade;
• versão;
• DOI;
• data de publicação;

apenas para que a entrada pareça mais completa.

Preciso publicar o software antes de citá-lo?

Nem todo código precisa ser publicado formalmente para ser descrito em uma pesquisa.

Mas a capacidade de recuperar o objeto influencia a forma como ele pode ser tratado bibliograficamente.

Se o objetivo é tornar o software citável e reutilizável, práticas como versionamento e depósito em repositório apropriado podem melhorar sua identificação.

Posso colocar o código no apêndice?

Quando o código foi elaborado pelo próprio autor e sua extensão permite, um apêndice pode ser uma possibilidade.

Entretanto, códigos extensos podem prejudicar a legibilidade do trabalho.

Nesses casos, pode ser mais adequado disponibilizar o código em repositório e utilizar o texto acadêmico para:

• explicar a função;
• descrever o método;
• informar a versão;
• indicar como o recurso pode ser recuperado.

Apêndice ou anexo?

Quando o material foi elaborado pelo próprio autor do trabalho, ele se enquadra conceitualmente de maneira diferente de um documento produzido por terceiros.

Antes de inserir o código, siga também as regras de apresentação de trabalhos acadêmicos adotadas pela instituição.

Software próprio depositado em repositório

Quando o programa é depositado, registre os metadados de maneira consistente.

Procure incluir, quando aplicável:

• autores;
• título;
• versão;
• data;
• descrição;
• licença;
• repositório;
• DOI ou outro identificador;
• documentação.

Preciso criar uma release?

Uma release pode ser útil quando o repositório continuará recebendo alterações depois da conclusão da pesquisa.

Ela ajuda a estabelecer um estado específico do código correspondente ao estudo.

Isso é especialmente relevante quando o software participa diretamente da produção dos resultados.

Software próprio com DOI

Se o software foi depositado em um serviço que atribui DOI, verifique se o identificador corresponde:

• à versão utilizada;
• ao conjunto do projeto;
• ou a outro objeto.

Utilize o identificador de acordo com a finalidade da referência.

E se o código não puder ser disponibilizado?

Existem situações em que o código contém:

• dados sensíveis;
• informações confidenciais;
• segredos comerciais;
• credenciais;
• componentes proprietários;
• restrições contratuais;
• elementos sujeitos a limitações éticas.

Nesses casos, a impossibilidade de disponibilização não elimina a necessidade de documentar adequadamente o método.

Explique o que puder ser informado e respeite as restrições aplicáveis.

Software modificado pelo pesquisador

Outra situação ocorre quando o pesquisador parte de um software existente e realiza modificações.

É importante documentar:

• software de origem;
• versão de origem;
• modificações realizadas;
• versão modificada, quando houver;
• licença aplicável;
• local do código;
• efeito das alterações sobre o método.

Fork de projeto open source

Se o pesquisador criou um fork e realizou alterações relevantes, não apresente o projeto modificado como se fosse exatamente a versão original.

O leitor precisa compreender:

• qual projeto serviu de base;
• qual estado foi utilizado;
• o que foi alterado;
• qual versão modificada produziu os resultados.

Como mencionar software próprio na metodologia?

Uma estrutura adaptável pode ser:

Para a etapa de [FUNÇÃO], foi desenvolvido pelos autores um software em [LINGUAGEM], utilizando [BIBLIOTECAS/COMPONENTES RELEVANTES]. A versão [X] foi empregada nas análises apresentadas neste trabalho. O programa executou [DESCREVER PROCEDIMENTO].

Se houver repositório ou depósito:

O código correspondente à versão utilizada foi depositado em [REPOSITÓRIO/LOCAL], sob o identificador [IDENTIFICADOR], observadas as condições de acesso e licenciamento aplicáveis.

Adapte o texto à situação real.

Como documentar software na metodologia: ficha prática

Uma maneira eficiente de evitar lacunas é criar uma ficha para cada recurso metodologicamente importante.

Campo	O que registrar
Nome	Nome oficial do software, aplicativo, pacote ou biblioteca.
Versão	Versão efetivamente utilizada na pesquisa.
Responsabilidade	Pessoa, equipe, projeto ou organização identificada nos metadados.
Função	O que o recurso fez na pesquisa.
Componentes	Pacotes, bibliotecas, plugins, módulos ou extensões relevantes.
Procedimento	Operação científica executada.
Parâmetros	Configurações necessárias para compreender ou reproduzir a operação.
Fonte dos metadados	Site oficial, programa, documentação, release, CITATION.cff, repositório ou depósito.
Identificador	DOI, release, tag ou outro identificador, quando aplicável.
Referência recomendada	Orientação de citação fornecida pelo projeto, quando existente.
Material relacionado	Manual, documentação ou artigo científico efetivamente utilizados.
Observações	Informações adicionais necessárias à metodologia ou à reprodutibilidade.

Cinco perguntas para revisar a documentação metodológica

Depois de preencher a ficha, responda:

1. O leitor sabe qual software foi utilizado?
2. Consegue identificar a versão relevante?
3. Entende qual função o programa desempenhou?
4. Conhece os componentes e parâmetros necessários para compreender o procedimento?
5. Consegue distinguir o software das fontes científicas que fundamentam o método?

Se a resposta for positiva para essas perguntas, a documentação tende a estar muito mais sólida do que uma simples menção ao nome do programa.

Software, manual ou artigo científico: o que devo citar?

Um dos erros mais frequentes na documentação de software é imaginar que existe apenas uma fonte relacionada a cada programa.

Na prática, um mesmo projeto pode possuir:

• o próprio software;
• manual;
• documentação online;
• artigo científico de apresentação;
• artigo metodológico;
• repositório de código;
• release;
• pacote;
• plugin;
• base de conhecimento;
• site institucional.

Esses objetos podem estar relacionados, mas não são bibliograficamente idênticos.

A pergunta correta não é apenas “qual referência o software recomenda?”, mas também:

qual objeto sustenta a informação que estou apresentando?

Quando referenciar o próprio software?

A referência do software é particularmente pertinente quando o objetivo é identificar o recurso computacional utilizado.

Ela pode ajudar a registrar:

• nome oficial;
• responsabilidade;
• versão;
• data;
• release;
• identificador persistente;
• recurso efetivamente utilizado.

Esse registro responde principalmente à pergunta:

qual software participou da pesquisa?

Quando citar o manual?

O manual pode ser a fonte adequada quando a informação utilizada foi obtida especificamente nele.

Por exemplo, o pesquisador pode recorrer ao manual para compreender:

• configuração de uma função;
• procedimento de instalação;
• significado de uma opção;
• interpretação de determinada saída;
• configuração de um módulo;
• funcionamento técnico de um recurso.

Nesse caso, o manual é o documento que sustenta a informação.

Se precisar estruturar esse tipo de referência, consulte também o guia Como Citar Manual nas Normas ABNT.

Quando citar a documentação online?

A documentação pode ser apropriada quando determinada informação técnica está publicada diretamente no conjunto de páginas mantidas pelo projeto.

Isso pode ocorrer com:

• descrição de funções;
• argumentos;
• parâmetros;
• exemplos;
• comportamento de APIs;
• requisitos;
• mudanças entre versões.

Entretanto, não transforme automaticamente a documentação inteira em substituta da referência do software.

Quando citar o artigo científico associado ao software?

Muitos projetos acadêmicos publicam artigos que:

• apresentam o software;
• descrevem sua arquitetura;
• explicam os algoritmos;
• validam o programa;
• documentam determinado método;
• apresentam desempenho;
• registram o desenvolvimento do projeto.

O próprio software pode recomendar que seus usuários citem um desses artigos.

Essa recomendação deve ser considerada, principalmente para atribuição científica adequada.

Mas o artigo continua sendo um objeto diferente do programa.

Para revisar a estrutura desse tipo de fonte, consulte Como Citar Artigo Científico nas Normas ABNT.

Posso citar software e artigo científico juntos?

Sim, quando cada referência cumpre uma função legítima.

Por exemplo:

• a referência do software identifica a versão utilizada;
• o artigo recomendado atribui crédito ao desenvolvimento científico;
• outro artigo fundamenta o método aplicado.

Essas três referências podem coexistir sem redundância se estiverem documentando objetos ou funções diferentes.

Exemplo didático: software + artigo

Imagine um programa fictício chamado ModelResearch.

O projeto disponibiliza:

• ModelResearch versão 4.2;
• um artigo científico publicado anos antes;
• uma documentação online;
• um manual técnico.

O pesquisador utilizou a versão 4.2 para executar determinada análise.

Nesse cenário:

• o software identifica a implementação utilizada;
• o artigo pode apresentar ou fundamentar cientificamente o projeto;
• a documentação pode sustentar informações sobre determinada função;
• o manual pode explicar configurações específicas.

Não existe motivo para misturar os quatro objetos em uma única referência.

Não crie uma referência híbrida

Uma referência híbrida surge quando o estudante reúne informações pertencentes a documentos diferentes.

Por exemplo:

• autor retirado do artigo;
• título retirado do software;
• ano retirado do manual;
• DOI retirado do artigo;
• URL retirada da página institucional.

O resultado pode parecer completo, mas não representa nenhum objeto real.

O artigo recomendado substitui a versão do software?

Não necessariamente.

Um artigo pode ter sido publicado anos antes da versão utilizada.

Se a versão é relevante para compreender ou reproduzir o procedimento, ela continua sendo uma informação importante.

Software, manual e artigo podem ter anos diferentes?

Sim.

Isso não representa uma inconsistência quando cada data pertence ao seu respectivo objeto.

Por exemplo:

• artigo de apresentação: ano A;
• manual consultado: ano B;
• versão utilizada: ano C.

O erro seria transferir arbitrariamente a data de um objeto para outro.

Qual fonte usar em cada situação?

O que você precisa documentar?	Fonte que pode ser apropriada
Qual programa foi utilizado	Software ou registro oficial correspondente
Qual versão foi utilizada	Software, release ou metadados oficiais da versão
Como uma função opera	Manual ou documentação
Como o software foi desenvolvido	Artigo científico ou documentação técnica correspondente
Fundamentação de um método científico	Literatura metodológica apropriada
Estado específico do código	Release, depósito ou repositório identificado
Componente específico	Pacote, biblioteca, plugin ou módulo correspondente

Software e site também não são a mesma coisa

A mesma separação deve ser aplicada à página institucional.

Se você consultou uma página para obter informações sobre o produto, isso não significa que a página seja o próprio programa.

Antes de criar uma referência de site, pergunte:

estou citando uma informação publicada nesta página ou estou tentando identificar o software utilizado?

A resposta muda o objeto bibliográfico.

Software e algoritmo são a mesma coisa?

Não.

Um algoritmo pode possuir existência conceitual independente da implementação utilizada.

Um mesmo algoritmo pode ser implementado em:

• R;
• Python;
• MATLAB;
• software comercial;
• software desenvolvido pelo pesquisador.

Citar a ferramenta computacional não substitui necessariamente a fonte científica do algoritmo.

Software e método científico são a mesma coisa?

Também não.

Um programa pode implementar:

• regressão;
• teste de hipótese;
• análise de sobrevivência;
• clusterização;
• análise temática assistida;
• modelagem;
• simulação;
• processamento espacial.

O software identifica uma implementação ou ferramenta. O método precisa ser descrito e fundamentado de acordo com as necessidades da pesquisa.

Software e inteligência artificial são citados da mesma forma?

Não é recomendável tratar toda ferramenta de inteligência artificial como se fosse simplesmente um software convencional.

Essa diferença se torna especialmente importante no caso de inteligência artificial generativa.

Por que IA generativa exige cuidados adicionais?

Ferramentas generativas podem envolver questões que ultrapassam a simples identificação de um programa.

Dependendo do contexto, podem ser relevantes:

• modelo utilizado;
• versão ou variante disponível;
• data da interação;
• conteúdo produzido;
• prompt ou instrução;
• possibilidade de recuperação da interação;
• transparência sobre o uso;
• política institucional;
• integridade acadêmica;
• proteção de dados;
• autoria e responsabilidade pelo texto final.

Por isso, aplicar mecanicamente uma referência de programa de computador a qualquer uso de IA pode ser insuficiente.

O tema possui implicações próprias e foi desenvolvido separadamente no guia Como Citar Inteligência Artificial nas Normas ABNT.

Todo software com inteligência artificial deve ser tratado como IA generativa?

Não.

Um software pode utilizar técnicas de inteligência artificial internamente sem que a interação do pesquisador envolva geração de conteúdo.

Por exemplo, um programa pode incorporar:

• classificação automatizada;
• detecção de padrões;
• segmentação de imagens;
• reconhecimento;
• predição;
• otimização.

Nesse caso, o tratamento deve considerar a função concreta do recurso na pesquisa.

Modelo de machine learning é a mesma coisa que software?

Não necessariamente.

Uma pesquisa pode envolver simultaneamente:

• linguagem de programação;
• biblioteca;
• framework;
• modelo;
• conjunto de dados;
• pesos treinados;
• código;
• ambiente de execução.

Esses objetos podem exigir formas diferentes de documentação.

ChatGPT deve ser tratado simplesmente como qualquer software?

Não é recomendável aplicar automaticamente ao ChatGPT ou a outra IA generativa o mesmo tratamento utilizado para um programa estatístico tradicional.

O uso de IA generativa pode exigir transparência sobre:

• finalidade do uso;
• natureza da interação;
• conteúdo produzido;
• revisão humana;
• regras da instituição;
• forma de documentação.

Por isso, esse caso deve ser analisado dentro do contexto específico da inteligência artificial generativa.

Comparação rápida: software tradicional, software com IA e IA generativa

Recurso	Questão central de documentação
Software tradicional	Identificação, versão, função, componentes e procedimentos.
Software que incorpora IA	Além da identificação, pode ser necessário explicar algoritmo, modelo ou função automatizada relevante.
IA generativa	Pode exigir também transparência sobre interação, conteúdo produzido, modelo, data, políticas institucionais e integridade acadêmica.

Como mencionar software na metodologia do TCC?

A metodologia é o local em que o leitor deve compreender como o software participou da pesquisa.

Uma boa descrição não é necessariamente longa, mas precisa conter os detalhes necessários para que o procedimento seja compreendido.

As cinco perguntas essenciais

Para cada software metodologicamente relevante, procure responder:

1. Qual recurso foi utilizado?
2. Qual versão participou da pesquisa?
3. Para que ele foi utilizado?
4. Como o procedimento foi executado?
5. Quais componentes ou parâmetros são necessários para compreender o resultado?

Nem todo estudo precisará responder essas perguntas com o mesmo nível de detalhe.

Modelo para software estatístico

Estrutura adaptável:

As análises estatísticas foram realizadas no software [NOME], versão [X]. Foram aplicados [TESTES/MODELOS], considerando [PRESSUPOSTOS, CRITÉRIOS E PARÂMETROS RELEVANTES].

Se módulos específicos foram utilizados:

Para [PROCEDIMENTO], foi utilizado o módulo [NOME], versão [X], com [CONFIGURAÇÕES RELEVANTES].

Modelo para análise qualitativa

O material foi organizado e codificado com auxílio do software [NOME], versão [X]. A análise foi conduzida segundo [ABORDAGEM/MÉTODO], sendo o programa utilizado para [FUNÇÕES EFETIVAMENTE REALIZADAS].

Esse modelo evita atribuir ao software aquilo que pertence ao método e à interpretação do pesquisador.

Modelo para análise textual

O corpus foi processado no software [NOME], versão [X]. Após [DESCREVER PREPARAÇÃO], foi realizada [TIPO DE ANÁLISE], considerando [CRITÉRIOS/PARÂMETROS].

Quando necessário, explique também:

• segmentação;
• variáveis;
• unidades textuais;
• critérios de retenção;
• procedimentos de interpretação.

Modelo para R

As análises foram realizadas no ambiente R, versão [X]. O pacote [A], versão [Y], foi empregado para [FUNÇÃO], enquanto o pacote [B], versão [Z], foi utilizado para [FUNÇÃO]. Foram adotados [PARÂMETROS/CRITÉRIOS].

Não liste pacotes que não sejam relevantes para compreender o método.

Modelo para Python

O processamento dos dados foi realizado em Python, versão [X]. A biblioteca [A], versão [Y], foi utilizada para [FUNÇÃO], e a biblioteca [B], versão [Z], para [FUNÇÃO]. Os procedimentos foram executados com [PARÂMETROS/CRITÉRIOS RELEVANTES].

Modelo para aprendizado de máquina

Em machine learning, apenas informar o software costuma ser insuficiente.

Uma descrição pode precisar incluir:

• linguagem;
• biblioteca ou framework;
• algoritmo;
• versão;
• pré-processamento;
• divisão dos dados;
• validação;
• hiperparâmetros;
• métricas;
• semente aleatória;
• procedimento de ajuste.

Modelo adaptável:

Os modelos foram implementados em [AMBIENTE], versão [X], utilizando [BIBLIOTECA/FRAMEWORK], versão [Y]. Foi empregado o algoritmo [NOME], com [HIPERPARÂMETROS RELEVANTES]. O conjunto de dados foi dividido por [PROCEDIMENTO], e o desempenho foi avaliado por [MÉTRICAS].

Modelo para simulação

As simulações foram realizadas no software [NOME], versão [X], utilizando [MÓDULO/SOLVER, QUANDO RELEVANTE]. Foram definidos [PARÂMETROS], sob as condições [DESCREVER], com [CRITÉRIO DE CONVERGÊNCIA/ITERações/TOLERÂNCIA, QUANDO APLICÁVEL].

O objetivo é permitir que o leitor compreenda o experimento computacional, não apenas o programa utilizado.

Modelo para geoprocessamento

O processamento espacial foi realizado no software [NOME], versão [X]. Os dados provenientes de [FONTE] foram processados no sistema de referência [INFORMAR QUANDO RELEVANTE], utilizando [FERRAMENTAS/ALGORITMOS/PLUGINS] para [PROCEDIMENTO].

Software e fonte dos dados devem permanecer claramente separados.

Modelo para cálculo amostral

O tamanho amostral foi estimado no software [NOME], versão [X], considerando [TIPO DE TESTE], tamanho de efeito de [VALOR], nível de significância de [VALOR], poder estatístico de [VALOR] e [OUTROS PARÂMETROS RELEVANTES].

Não informe valores fictícios apenas para preencher o modelo.

Modelo para software de análise de imagens

As imagens foram processadas no software [NOME], versão [X]. Foram aplicadas as etapas de [PROCEDIMENTOS], utilizando [PLUGIN/MÓDULO, QUANDO RELEVANTE] e os parâmetros [DESCREVER].

Modelo para aplicativo utilizado na coleta

A coleta foi realizada com auxílio do aplicativo [NOME], versão [X], instalado em [PLATAFORMA, QUANDO RELEVANTE]. O aplicativo foi utilizado para [FUNÇÃO], seguindo o procedimento [DESCREVER].

Modelo para software online

A etapa de [FUNÇÃO] foi realizada por meio da ferramenta online [NOME], acessada em [PERÍODO/DATA QUANDO RELEVANTE]. Foram utilizados [CONFIGURAÇÕES/PARÂMETROS], conforme o procedimento [DESCREVER].

Se não houver versão identificável, não invente uma.

Modelo para software desenvolvido pelo pesquisador

Para [FINALIDADE], foi desenvolvido um software em [LINGUAGEM], versão [X], utilizando [BIBLIOTECAS/COMPONENTES]. O programa executou [PROCEDIMENTO], a partir de [ENTRADAS], produzindo [SAÍDAS].

Quando houver repositório:

O código correspondente à versão utilizada foi disponibilizado em [REPOSITÓRIO/DEPÓSITO], sob [IDENTIFICADOR, QUANDO EXISTENTE].

Modelo para software utilizado em revisão sistemática

Ferramentas podem participar de diferentes etapas de uma revisão, como:

• organização das referências;
• remoção de duplicatas;
• triagem;
• extração;
• análise;
• meta-análise.

Modelo adaptável:

Os registros recuperados foram gerenciados em [SOFTWARE], versão [X]. A etapa de [TRIAGEM/ORGANIZAÇÃO/OUTRA FUNÇÃO] foi realizada utilizando [FERRAMENTA], conforme os critérios de elegibilidade previamente definidos.

Quando a ferramenta utilizada for o Rayyan, o guia específico sobre Rayyan pode complementar a descrição do fluxo.

Para o contexto metodológico mais amplo, consulte também O que é Revisão Sistemática e Seleção e Triagem dos Estudos.

Modelo para bioinformática

Os dados foram processados utilizando [SOFTWARE], versão [X], com [BANCO/BIBLIOTECA/PIPELINE] para [FUNÇÃO]. Foram adotados os parâmetros [DESCREVER], conforme [FUNDAMENTAÇÃO METODOLÓGICA].

Modelo para processamento de sinais

Os sinais foram processados no software [NOME], versão [X]. Foram aplicadas as etapas de [FILTRAGEM/SEGMENTAÇÃO/TRANSFORMAÇÃO/OUTRAS], utilizando os parâmetros [DESCREVER].

Quando vários softwares participam do método

Se o fluxo utilizar várias ferramentas, organize a descrição por etapa, e não por marca.

Etapa da pesquisa	Recurso	Versão	Função
Preparação dos dados	[Software A]	[versão]	[função]
Análise	[Software B]	[versão]	[função]
Visualização	[Software C]	[versão]	[função]
Processamento adicional	[Software D]	[versão]	[função]

Essa organização ajuda o leitor a compreender o fluxo sem transformar a metodologia em uma sequência de marcas comerciais.

O que não fazer na metodologia

Evite descrições como:

Foram utilizados Excel, Python, SPSS e R.

Essa frase não informa:

• qual programa executou cada etapa;
• quais versões foram utilizadas;
• quais análises foram realizadas;
• como os dados foram transformados;
• quais parâmetros foram adotados.

Uma redação metodológica útil deve conectar cada recurso à sua função.

Por que a versão do software é tão importante?

A versão não é apenas um detalhe administrativo.

Em determinados estudos, ela ajuda a identificar exatamente qual implementação participou da produção dos resultados.

O que pode mudar entre versões?

Atualizações podem modificar:

• algoritmos;
• valores padrão;
• funções;
• interfaces;
• formatos de arquivo;
• dependências;
• correções de erros;
• procedimentos estatísticos;
• precisão numérica;
• compatibilidade;
• resultados em determinadas condições.

Por isso, a versão pode ser uma informação essencial para interpretar ou reproduzir uma análise.

A versão sempre precisa aparecer?

A relevância depende do recurso e do contexto.

Quando a versão está disponível e ajuda a identificar o software utilizado, registrá-la é uma prática importante.

Em aplicações continuamente atualizadas, entretanto, pode não existir um número de versão visível ao usuário.

Nesses casos, não invente a informação.

Atualização automática pode causar problema?

Sim.

Imagine que o pesquisador realize parte da análise, o software seja atualizado automaticamente e outra etapa seja executada posteriormente.

Se a atualização alterou o comportamento relevante do programa, podem existir duas versões dentro do mesmo estudo.

Quando isso ocorrer e for metodologicamente importante, registre a mudança.

Preciso informar o sistema operacional?

Somente quando ele influencia o procedimento ou ajuda significativamente na reprodução.

Isso pode ocorrer em:

• programas com comportamento dependente da plataforma;
• ambientes de compilação;
• processamento de alto desempenho;
• softwares dependentes de drivers;
• aplicações que possuem versões diferentes para cada sistema.

Preciso informar o hardware?

Na maioria dos TCCs, não.

Entretanto, hardware pode ser relevante em pesquisas envolvendo:

• machine learning;
• GPU;
• simulações intensivas;
• benchmark;
• processamento de alto desempenho;
• tempo de execução como variável;
• desempenho computacional.

Preciso informar parâmetros?

Quando eles alteram o procedimento ou o resultado, sim, sua documentação metodológica pode ser importante.

Exemplos:

• hiperparâmetros;
• limiares;
• tolerâncias;
• número de iterações;
• sementes aleatórias;
• configurações de filtros;
• resolução;
• opções de otimização;
• parâmetros de segmentação.

Essas informações não precisam ser inseridas na referência bibliográfica do software. Elas pertencem principalmente à descrição metodológica.

Preciso repetir a versão em todas as ocorrências?

Não é necessário transformar o texto em uma repetição mecânica.

Identifique a versão claramente na primeira ocorrência metodologicamente relevante e repita-a quando houver risco de ambiguidade ou mudança de versão.

Versão do software e versão do pacote podem ser diferentes?

Sim.

Um ambiente principal e seus componentes possuem ciclos de desenvolvimento próprios.

Por exemplo:

• R possui uma versão;
• cada pacote pode possuir outra;
• Python possui uma versão;
• cada biblioteca pode possuir outra;
• um software pode possuir uma versão;
• um plugin pode possuir outra.

Quando o componente é metodologicamente relevante, registre a versão correspondente a ele.

Exemplos práticos de como citar e documentar software no TCC

Os exemplos a seguir não devem ser copiados mecanicamente como referências prontas. Eles funcionam como modelos de decisão para ajudar a identificar qual recurso precisa ser documentado, quais informações devem ser verificadas e como relacionar o software à metodologia.

Campos entre colchetes devem ser substituídos pelos dados reais da pesquisa.

Exemplo 1 — Software estatístico utilizado na análise

Imagine um estudo quantitativo no qual determinado programa foi utilizado para executar os testes estatísticos.

Na metodologia:

As análises estatísticas foram realizadas no software [NOME], versão [X]. Foram empregados [TESTES/MODELOS], considerando [CRITÉRIOS E PARÂMETROS RELEVANTES].

Antes de elaborar a referência, verifique:

• nome oficial;
• responsabilidade;
• versão;
• data correspondente;
• orientação oficial de citação;
• eventual identificador persistente.

A referência identifica o programa. A metodologia explica os testes e procedimentos.

Exemplo 2 — SPSS utilizado na análise estatística

Se a pesquisa utilizou SPSS, registre a versão efetivamente empregada.

Modelo metodológico:

Os dados foram analisados no [NOME OFICIAL DO PRODUTO], versão [X]. Foram realizados [TESTES/MODELOS], adotando-se [CRITÉRIOS].

Não copie automaticamente uma referência antiga do programa, porque o nome do produto, responsabilidade e versão podem não corresponder ao recurso utilizado.

Se módulos adicionais tiveram participação metodológica relevante, registre-os quando necessário.

Exemplo 3 — R utilizado sem pacote metodologicamente central

Imagine uma análise relativamente simples realizada diretamente no ambiente R, sem que um pacote adicional precise ser destacado como componente científico central.

Metodologia:

As análises foram realizadas no ambiente R, versão [X], utilizando [DESCREVER PROCEDIMENTOS].

Para recuperar os metadados de citação correspondentes ao ambiente instalado, consulte:

citation()

Também pode ser útil preservar:

sessionInfo()

Isso ajuda a documentar o ambiente efetivamente utilizado.

Exemplo 4 — R com um pacote central

Agora imagine que o método principal foi implementado por um pacote específico.

Metodologia:

As análises foram realizadas no R, versão [X], utilizando o pacote [PACOTE], versão [Y], para [FUNÇÃO].

Consulte a orientação de citação do pacote por meio de:

citation("nomeDoPacote")

E verifique sua versão com:

packageVersion("nomeDoPacote")

Nesse cenário, documentar apenas R pode ocultar justamente o componente que implementou o método central.

Exemplo 5 — R com vários pacotes relevantes

Se vários pacotes participaram de etapas diferentes, não os apresente como uma lista sem função.

Exemplo:

As análises foram realizadas no R, versão [X]. O pacote [A], versão [Y], foi utilizado para [FUNÇÃO]; [B], versão [Z], para [FUNÇÃO]; e [C], versão [W], para [FUNÇÃO].

Não é necessário incluir na redação principal todas as dependências instaladas automaticamente.

Priorize os componentes necessários para compreender o método.

Exemplo 6 — Python utilizado no processamento dos dados

Quando Python participa diretamente da pesquisa, registre a versão utilizada e descreva sua função.

Metodologia:

O processamento dos dados foi realizado em Python, versão [X], por meio de scripts desenvolvidos para [FUNÇÃO].

Se bibliotecas científicas foram centrais, elas devem ser consideradas separadamente.

Exemplo 7 — Python com biblioteca científica central

Imagine que uma biblioteca implementou o algoritmo responsável pela análise principal.

Metodologia:

A análise foi implementada em Python, versão [X], utilizando a biblioteca [NOME], versão [Y]. Foi aplicado o procedimento [MÉTODO/ALGORITMO], com [PARÂMETROS RELEVANTES].

Consulte a documentação oficial do projeto para identificar:

• autoria ou responsabilidade;
• versão;
• orientação de citação;
• artigo recomendado;
• DOI, quando existente.

Não transfira automaticamente o DOI de um artigo para a biblioteca.

Exemplo 8 — Software para análise qualitativa

Considere uma pesquisa que utiliza NVivo, ATLAS.ti, MAXQDA ou ferramenta semelhante.

Metodologia:

O material foi organizado e codificado com auxílio do software [NOME], versão [X]. A análise foi conduzida segundo [MÉTODO/ABORDAGEM], sendo o programa utilizado para [FUNÇÕES].

Essa formulação evita dizer que o software “realizou” sozinho a análise qualitativa.

Exemplo 9 — IRaMuTeQ em análise textual

Metodologia:

O corpus foi processado no IRaMuTeQ, versão [X], para realização de [TIPO DE ANÁLISE]. O material foi preparado por meio de [PROCEDIMENTOS], considerando [CRITÉRIOS].

Dependendo da pesquisa, documente também:

• constituição do corpus;
• segmentação;
• variáveis;
• critérios analíticos;
• ambiente computacional relevante.

Exemplo 10 — G*Power para cálculo amostral

Informar apenas que “o cálculo foi realizado no G*Power” não permite compreender como o tamanho da amostra foi determinado.

Metodologia:

O tamanho amostral foi estimado no software [NOME], versão [X], considerando [TIPO DE TESTE], tamanho de efeito de [VALOR], nível de significância de [VALOR], poder estatístico de [VALOR] e [OUTRAS ENTRADAS].

O programa executa o cálculo. Os valores inseridos e seus fundamentos pertencem à metodologia.

Exemplo 11 — Aplicativo utilizado para coleta de dados

Imagine que um aplicativo registre respostas, medidas ou observações.

Metodologia:

A coleta foi realizada com auxílio do aplicativo [NOME], versão [X], utilizado para [FUNÇÃO]. Os participantes [DESCREVER PROCEDIMENTO].

Verifique também:

• responsável pelo aplicativo;
• plataforma;
• versão;
• data ou período de utilização;
• condições de funcionamento relevantes.

Exemplo 12 — Aplicativo como objeto de estudo

Nesse caso, a versão é ainda mais importante porque o próprio aplicativo está sendo analisado.

Metodologia:

Foi analisada a versão [X] do aplicativo [NOME], disponível para [PLATAFORMA], durante o período de [PERÍODO]. Foram avaliadas as funcionalidades [DESCREVER] segundo os critérios [CRITÉRIOS].

Se o aplicativo recebeu atualizações durante o estudo, registre esse fato quando ele puder alterar a interpretação dos resultados.

Exemplo 13 — Software online sem versão visível

Não invente uma versão.

Metodologia:

A etapa de [FUNÇÃO] foi realizada por meio da ferramenta online [NOME], mantida por [RESPONSÁVEL], utilizada em [DATA/PERÍODO]. Foram aplicadas as configurações [DESCREVER].

Na referência, utilize os metadados efetivamente disponíveis e registre as informações de acesso quando aplicáveis.

Exemplo 14 — Software open source hospedado no GitHub

Suponha que um programa esteja hospedado no GitHub e possua releases próprias.

Não utilize “GitHub” automaticamente como autor.

Procure:

• autores ou responsáveis;
• nome oficial;
• release;
• versão;
• data;
• arquivo CITATION.cff;
• documentação de citação;
• DOI, quando existente.

Metodologia:

Foi utilizada a versão [X] do software [NOME] para [FUNÇÃO]. A versão empregada corresponde à release [IDENTIFICAÇÃO], utilizada com [PARÂMETROS/CONFIGURAÇÕES].

Exemplo 15 — Software open source com DOI de versão

Se determinada release foi arquivada em repositório científico e recebeu DOI próprio, verifique se esse DOI corresponde exatamente à versão utilizada.

Antes de referenciar:

1. abra o registro do DOI;
2. confirme o título;
3. confirme autores ou responsáveis;
4. confirme a versão;
5. confirme a data;
6. confirme a relação entre o depósito e o software utilizado.

Não utilize o DOI apenas porque ele aparece na página do projeto.

Exemplo 16 — Software desenvolvido pelo pesquisador

Imagine que o próprio autor tenha desenvolvido um programa específico para o estudo.

Metodologia:

Para [FINALIDADE], foi desenvolvido um software em [LINGUAGEM], versão [X], utilizando [COMPONENTES]. O programa recebeu [ENTRADAS] e executou [PROCEDIMENTO], produzindo [SAÍDAS].

Se o software não foi publicado formalmente, não invente uma referência com editora, DOI ou local inexistentes.

Descreva o objeto real.

Exemplo 17 — Software próprio depositado em repositório

Se o programa foi versionado e depositado:

O software desenvolvido para a pesquisa, versão [X], foi depositado em [REPOSITÓRIO] sob o identificador [DOI/OUTRO IDENTIFICADOR].

Confirme que o identificador corresponde à versão utilizada nos resultados.

Exemplo 18 — Software e artigo científico associados

Suponha que o software recomende um artigo científico para citação.

O pesquisador pode precisar documentar:

• a versão do software;
• o artigo recomendado pelo projeto;
• o método científico empregado.

Esses elementos não devem ser fundidos em uma referência híbrida.

Na metodologia:

A análise foi realizada no software [NOME], versão [X], utilizando o procedimento [MÉTODO]. O recurso e o método foram documentados pelas fontes correspondentes.

Exemplo 19 — Software e manual técnico

Imagine que determinada configuração tenha sido definida com base no manual oficial.

Nesse caso:

• o software identifica o programa;
• o manual sustenta a informação técnica consultada.

As duas referências podem coexistir quando cada uma é efetivamente utilizada.

Para a estrutura bibliográfica do segundo objeto, consulte Como Citar Manual nas Normas ABNT.

Exemplo 20 — QGIS ou ArcGIS com dados geográficos externos

Considere uma pesquisa que utiliza software GIS para processar uma base cartográfica produzida por uma instituição.

Metodologia:

O processamento espacial foi realizado no software [NOME], versão [X]. Os dados geográficos provenientes de [FONTE] foram processados utilizando [FERRAMENTAS/ALGORITMOS], no sistema de referência [INFORMAR QUANDO RELEVANTE].

Nesse caso, existem pelo menos dois objetos distintos:

• o software;
• a base de dados geográficos.

Citar apenas o software não atribui crédito à fonte dos dados.

Exemplo 21 — Excel utilizado apenas para organizar os dados

Imagine que o estudante tenha digitado ou organizado a base em uma planilha e depois realizado toda a análise em outro programa.

Nesse caso, Excel pode ter desempenhado função meramente operacional.

Não existe necessidade de transformar automaticamente toda ferramenta operacional em referência bibliográfica.

Se a organização dos dados envolver procedimentos metodologicamente relevantes, descreva-os.

Exemplo 22 — Excel utilizado para produzir resultados

A situação muda quando fórmulas, macros ou recursos analíticos da planilha produzem resultados utilizados no estudo.

Metodologia:

Os dados foram processados em [SOFTWARE], versão [X], utilizando [FÓRMULAS/FUNÇÕES/MACROS] para [PROCEDIMENTO].

Quanto maior a influência da planilha sobre os resultados, maior a necessidade de explicar o que foi feito nela.

Exemplo 23 — Word utilizado para escrever o TCC

Utilizar um editor de texto para redigir o trabalho não significa automaticamente que ele precise ser citado como recurso metodológico.

O mesmo raciocínio vale para:

• editor de PDF;
• corretor ortográfico;
• software de impressão;
• ferramenta de compactação;
• aplicativos puramente administrativos.

Não transforme as referências em um inventário de todos os programas instalados no computador.

Exemplo 24 — PowerPoint ou outro programa usado apenas na defesa

O software utilizado para criar os slides da apresentação geralmente não integra o método científico do TCC.

Portanto, seu uso operacional não cria automaticamente necessidade de referência.

Exemplo 25 — Software de transcrição

Imagine uma pesquisa qualitativa em que entrevistas foram convertidas de áudio para texto com auxílio de software.

A ferramenta pode ser metodologicamente relevante porque participa da preparação do corpus.

Metodologia:

Os arquivos de áudio foram transcritos com auxílio do software [NOME], versão [X]. As transcrições foram posteriormente [REVISADAS/CONFERIDAS] por [PROCEDIMENTO].

Dependendo do recurso, explique também:

• se a transcrição foi automática;
• se houve revisão humana;
• como erros foram corrigidos;
• como informações sensíveis foram tratadas.

Exemplo 26 — Software de tradução

Se uma ferramenta de tradução participou do tratamento de dados, documentos, questionários ou corpus, a metodologia pode precisar registrar seu uso.

É diferente de utilizar ocasionalmente uma ferramenta apenas para compreender uma palavra durante a escrita.

Quando a tradução afeta o material analisado, descreva:

• qual recurso foi utilizado;
• em qual etapa;
• como o resultado foi revisado;
• quais controles de qualidade foram aplicados.

Exemplo 27 — Software em revisão sistemática

Revisões sistemáticas podem utilizar diferentes ferramentas em diferentes etapas.

Por exemplo:

• gerenciador bibliográfico para registros;
• software para remoção de duplicatas;
• plataforma para triagem;
• planilha ou sistema para extração;
• software estatístico para meta-análise.

Não é necessário tratar todos esses recursos da mesma maneira.

Relacione cada ferramenta à etapa em que foi utilizada.

Para aprofundar o desenho metodológico, consulte O que é Revisão Sistemática.

Exemplo 28 — Rayyan utilizado na triagem

Quando Rayyan é utilizado para auxiliar a seleção dos estudos, sua função pode ser descrita no fluxo metodológico.

Exemplo:

Os registros foram importados para o Rayyan para apoio à etapa de triagem por título e resumo, conforme os critérios de inclusão e exclusão previamente estabelecidos.

Detalhes do procedimento podem incluir:

• número de revisores;
• processo de resolução de conflitos;
• critérios de elegibilidade;
• etapas da seleção.

Consulte também Rayyan e Seleção e Triagem dos Estudos.

Exemplo 29 — Software utilizado em meta-análise

O nome do programa não substitui a descrição do modelo estatístico.

Metodologia:

A meta-análise foi realizada no software [NOME], versão [X], utilizando [MODELO], medida de efeito [MEDIDA], método de estimação [MÉTODO] e [OUTROS PARÂMETROS RELEVANTES].

Os métodos estatísticos devem ser fundamentados pelas fontes científicas adequadas.

Exemplo 30 — Software de simulação

Em uma pesquisa baseada em simulação, o programa pode influenciar diretamente os resultados.

Metodologia:

As simulações foram executadas no software [NOME], versão [X], sob as condições [DESCREVER], utilizando [MODELO/MÓDULO/SOLVER] e os parâmetros [DESCREVER].

Dependendo do estudo, registre também:

• condições iniciais;
• número de iterações;
• tolerância;
• critérios de convergência;
• sementes aleatórias;
• configurações de hardware relevantes.

Exemplo 31 — Software como objeto central da pesquisa

Imagine um TCC que compara a usabilidade de dois programas.

Nesse caso, os softwares não são apenas ferramentas: são os próprios objetos analisados.

Documente cuidadosamente:

• versão de cada programa;
• plataforma;
• data ou período da avaliação;
• funcionalidades testadas;
• configurações;
• critérios de comparação.

Uma atualização durante o estudo pode alterar o objeto de pesquisa.

Exemplo 32 — Comparação entre duas versões do mesmo software

Se o objetivo é comparar versões, cada uma precisa ser claramente identificada.

Exemplo:

Foram comparadas as versões [X] e [Y] do software [NOME], avaliadas sob as mesmas condições de [DESCREVER].

Nesse cenário, a versão deixa de ser apenas um metadado e passa a integrar diretamente o desenho da pesquisa.

Exemplo 33 — Software atualizado continuamente

Ferramentas web podem mudar sem exibir números de versão.

Nesse caso:

• registre a data ou período de uso;
• descreva a função utilizada;
• preserve parâmetros relevantes;
• registre a interface quando necessário;
• não invente número de versão.

Se a ferramenta mudar depois, o leitor saberá ao menos qual estado temporal foi analisado.

Exemplo 34 — Software com plugin central

Imagine que QGIS, MATLAB, software qualitativo ou outro programa tenha utilizado um plugin para executar justamente a função principal.

Metodologia:

A etapa de [FUNÇÃO] foi executada no software [NOME], versão [X], utilizando o plugin [NOME], versão [Y].

Se o plugin possui autoria, documentação ou citação próprias, avalie-as separadamente.

Exemplo 35 — Software sem autor pessoal evidente

Não invente um autor individual.

Procure nos metadados oficiais:

• organização responsável;
• equipe formalmente indicada;
• projeto;
• instituição;
• orientação de citação.

A ausência de um nome pessoal não significa ausência automática de responsabilidade bibliográfica.

Exemplo 36 — Software descontinuado

Um programa pode ter sido utilizado em uma pesquisa mesmo depois de deixar de ser mantido.

Nesse caso, documente a versão realmente utilizada.

Se a página oficial não estiver mais disponível, procure registros confiáveis, documentação preservada ou depósitos correspondentes.

Não substitua silenciosamente o software antigo pela versão ou produto atual apenas porque é mais fácil encontrar seus metadados.

Exemplo 37 — Software utilizado apenas para gerar uma figura

Nem todo programa gráfico precisa necessariamente receber destaque metodológico.

Considere se ele:

• apenas ajustou a apresentação visual;
• transformou os dados;
• executou cálculo;
• produziu visualização analítica;
• participou da interpretação.

Uma ferramenta usada apenas para acabamento gráfico possui função diferente de um software que calcula os valores representados na figura.

Exemplo 38 — Software para processamento científico de imagens

Quando o programa mede, segmenta, classifica ou quantifica imagens, sua relevância metodológica aumenta.

Metodologia:

As imagens foram processadas no software [NOME], versão [X], utilizando [PLUGIN/MÓDULO] para [FUNÇÃO]. Foram adotados os parâmetros [DESCREVER].

Registre as configurações capazes de alterar os resultados.

Exemplo 39 — Software utilizado com banco de dados externo

Imagine um programa de bioinformática que consulta uma base científica.

O software e o banco de dados são objetos diferentes.

A metodologia pode precisar documentar:

• software;
• versão;
• banco de dados;
• versão ou data da base;
• parâmetros da busca;
• critérios adotados.

Citar o programa não atribui automaticamente crédito à base utilizada.

Exemplo 40 — Software que utiliza um algoritmo publicado anteriormente

Suponha que o programa implemente um algoritmo originalmente descrito em um artigo científico.

Dependendo da pesquisa, podem ser relevantes:

• a referência do software;
• a referência do artigo do algoritmo;
• a descrição da implementação utilizada.

Novamente, ferramenta e fundamento científico não são sinônimos.

Exemplo 41 — Software utilizado com parâmetros padrão

A expressão “parâmetros padrão” pode parecer suficiente, mas apresenta um risco: padrões podem mudar entre versões.

Quando os valores padrão influenciam significativamente o resultado, considere registrá-los explicitamente.

Isso evita que uma reprodução futura utilize defaults diferentes.

Exemplo 42 — Software com seed ou semente aleatória

Procedimentos estocásticos podem produzir resultados diferentes entre execuções.

Quando a reprodutibilidade exigir, registre a semente utilizada.

Exemplo:

Os procedimentos estocásticos foram executados com semente aleatória definida em [VALOR], utilizando [SOFTWARE/BIBLIOTECA], versão [X].

A semente pertence à documentação metodológica, não à referência bibliográfica do software.

Exemplo 43 — Software utilizado em ambiente virtual ou contêiner

Em pesquisas computacionais, o ambiente pode ser preservado por mecanismos de virtualização ou contêineres.

Quando isso for relevante, registre:

• imagem ou ambiente utilizado;
• versões;
• dependências;
• configurações necessárias;
• identificador do ambiente, quando existente.

Isso pode complementar a referência dos programas executados dentro dele.

Exemplo 44 — Software executado em servidor ou nuvem

Se o processamento foi realizado em infraestrutura remota, pergunte se essa informação influencia:

• desempenho;
• hardware;
• reprodutibilidade;
• versão do ambiente;
• configuração do experimento.

Se não influencia, não sobrecarregue a metodologia com detalhes irrelevantes.

Exemplo 45 — Software utilizado por meio de API

Quando a pesquisa interage com um serviço por API, pode ser importante registrar:

• serviço;
• versão da API, quando existente;
• data ou período;
• endpoints ou funções relevantes;
• parâmetros;
• limitações;
• biblioteca cliente, quando metodologicamente importante.

A API, a biblioteca utilizada para acessá-la e o serviço subjacente podem ser objetos distintos.

Exemplo 46 — Software modificado pelo pesquisador

Se o pesquisador alterou o código de um programa existente, registre a relação entre a versão original e a modificada.

Metodologia:

Foi utilizada uma versão modificada do software [NOME], derivada da versão [X]. As alterações realizadas consistiram em [DESCREVER] e foram empregadas para [FUNÇÃO].

Quando possível, disponibilize o código correspondente ao estado utilizado na pesquisa, respeitando licenças e restrições aplicáveis.

Exemplo 47 — Fork de projeto open source

Um fork pode se afastar significativamente do projeto original.

Documente:

• projeto de origem;
• versão ou commit de origem;
• fork utilizado;
• alterações relevantes;
• versão do fork;
• local de recuperação.

Não atribua ao projeto original resultados produzidos por modificações que ele não contém.

Exemplo 48 — Software proprietário sem acesso público

Alguns programas utilizados em empresas, laboratórios ou instituições podem não estar publicamente disponíveis.

Mesmo assim, procure registrar as informações que podem ser divulgadas:

• nome;
• versão;
• responsável;
• função;
• procedimentos;
• restrições de acesso.

Não exponha informações confidenciais para tornar a referência artificialmente completa.

Exemplo 49 — Software desenvolvido internamente por uma instituição

Se o programa pertence a uma instituição e não possui publicação formal, a metodologia pode precisar assumir papel maior na sua identificação.

Registre, quando permitido:

• nome;
• instituição responsável;
• versão;
• função;
• data ou período;
• características relevantes.

Exemplo 50 — Vários softwares em um único fluxo de pesquisa

Imagine o seguinte fluxo:

1. Excel para organização;
2. Python para limpeza;
3. R para análise;
4. QGIS para componente espacial;
5. software gráfico para apresentação final.

Uma metodologia mais clara organiza o texto por etapa:

Os dados foram inicialmente organizados em [RECURSO]. A limpeza e transformação foram realizadas em Python, versão [X], utilizando [BIBLIOTECAS]. As análises estatísticas foram conduzidas no R, versão [Y], com [PACOTES]. O processamento espacial foi realizado no [SOFTWARE GIS], versão [Z], utilizando [FERRAMENTAS].

O programa gráfico utilizado apenas para acabamento visual pode nem precisar integrar a descrição metodológica se não alterou os dados ou resultados.

Como escolher o tratamento correto sem decorar todos esses exemplos?

Utilize esta sequência:

1. Identifique a função: o que o recurso fez?
2. Identifique o objeto: software, pacote, biblioteca, plugin, app, serviço ou código próprio?
3. Confirme a versão: qual estado realmente participou da pesquisa?
4. Consulte os metadados oficiais: quem é responsável e como o projeto recomenda a atribuição?
5. Separe objetos relacionados: software, artigo, manual, documentação, dados e método.
6. Descreva o procedimento: o que foi executado e com quais parâmetros?
7. Avalie a reprodutibilidade: quais informações adicionais precisam ser preservadas?

Matriz rápida de decisão

Situação	Pergunta principal	Ação provável
Software produziu ou analisou dados	Qual versão e qual função?	Documentar com atenção na metodologia e avaliar referência.
Pacote executou método central	Qual pacote e versão?	Documentar separadamente quando pertinente.
Plugin executou operação central	O software principal identifica suficientemente o procedimento?	Registrar o plugin se ele for necessário para compreender o método.
Software foi apenas editor de texto	Participou do método?	Em geral, não transformar o uso operacional em referência metodológica.
Software é objeto da pesquisa	Qual estado do recurso foi analisado?	Identificar versão, período, plataforma e condições.
Software possui artigo recomendado	O artigo e o programa representam o mesmo objeto?	Separar e citar cada um quando cumprir função distinta.
Software possui DOI	O DOI identifica a versão utilizada?	Verificar o registro antes de utilizá-lo.
Software está no GitHub	Quem é realmente responsável?	Não usar GitHub automaticamente como autor.
Software é continuamente atualizado	É possível identificar a versão?	Registrar versão quando disponível ou período/data quando necessário.
Software foi desenvolvido pelo pesquisador	É um script interno ou produto formal?	Documentar proporcionalmente à natureza real do recurso.

Erros comuns ao citar software nas normas ABNT

Grande parte dos problemas encontrados em referências de software não começa na pontuação ou na ordem dos elementos. O erro ocorre antes: o pesquisador identifica incorretamente o objeto que está tentando citar.

Por isso, revisar uma referência de software exige verificar não apenas sua aparência, mas também se os metadados pertencem realmente ao recurso utilizado.

Erro 1 — Tratar todo software como se fosse um site

Um programa pode possuir um site oficial sem ser bibliograficamente a mesma coisa que esse site.

Se o pesquisador utilizou o software para analisar dados, citar apenas a página institucional pode não identificar adequadamente o recurso empregado.

Pergunte:

• utilizei o programa?
• consultei uma página?
• usei uma aplicação online?
• consultei documentação?

A resposta determina qual objeto precisa ser documentado.

Erro 2 — Copiar uma referência de outro TCC

Uma referência encontrada em outro trabalho pode corresponder a:

• outra versão;
• outro ano;
• outro responsável;
• outro produto;
• outro formato institucional;
• metadados incorretos.

Use fontes oficiais para reconstruir os dados do recurso que você realmente utilizou.

Erro 3 — Citar a versão atual em vez da versão utilizada

Esse erro ocorre quando o pesquisador termina a análise, volta ao site meses depois e copia as informações da versão mais recente.

O resultado é uma referência que não corresponde ao ambiente que produziu os resultados.

Erro 4 — Não registrar a versão

Quando a versão é relevante e está disponível, omiti-la pode dificultar a identificação do recurso.

Isso é especialmente importante quando atualizações alteram:

• algoritmos;
• funções;
• parâmetros padrão;
• resultados;
• módulos;
• compatibilidade.

Erro 5 — Inventar uma versão que não aparece no recurso

O problema inverso também ocorre.

Algumas aplicações online não apresentam número de versão ao usuário.

Nesse caso, não crie um número fictício apenas para preencher um modelo.

Registre os dados verificáveis e, quando relevante, a data ou o período de utilização.

Erro 6 — Confundir empresa com autoria automaticamente

Uma empresa pode:

• desenvolver;
• distribuir;
• adquirir;
• licenciar;
• manter;
• comercializar

um software.

Isso não significa que qualquer nome empresarial encontrado na página de venda deva ser colocado automaticamente como autor.

Verifique os metadados oficiais correspondentes ao recurso.

Erro 7 — Usar GitHub como autor

GitHub é uma plataforma.

O projeto hospedado nela possui responsáveis próprios.

Procure:

• CITATION.cff;
• README;
• release;
• documentação;
• registro de depósito;
• orientação oficial de citação.

Não transforme o serviço de hospedagem em autor do software.

Erro 8 — Usar o proprietário do repositório como autor sem verificar

O nome da conta ou organização que mantém um repositório pode fornecer uma pista, mas não resolve automaticamente a autoria bibliográfica.

Um repositório pode ser mantido por:

• organização;
• espelho automatizado;
• equipe técnica;
• membro do projeto;
• fork independente.

Use a atribuição recomendada pelo projeto sempre que ela estiver disponível.

Erro 9 — Copiar um DOI sem descobrir o que ele identifica

Um DOI encontrado na página de um software pode apontar para:

• artigo científico;
• versão específica do software;
• depósito geral do projeto;
• conjunto de dados;
• manual;
• outro objeto.

Abra o registro e confira os metadados antes de utilizá-lo.

Erro 10 — Colocar o DOI de um artigo como se fosse DOI do software

Esse erro produz uma referência híbrida.

O artigo pode ser recomendado pelo projeto, mas seu DOI continua identificando o artigo.

Se o software possuir identificador próprio, trate-o separadamente.

Erro 11 — Misturar software, manual, documentação e artigo na mesma referência

Uma referência deve representar um objeto identificável.

Evite reunir:

• autor do artigo;
• título do programa;
• ano do manual;
• URL da documentação;
• DOI de outra publicação.

Se várias fontes foram utilizadas, cada uma pode receber sua própria referência quando necessário.

Erro 12 — Usar o ano do artigo como ano do software

Um artigo que apresenta determinado programa pode ter sido publicado muito antes da versão utilizada na pesquisa.

As datas pertencem a objetos diferentes.

Não transfira uma para o outro sem fundamento documental.

Erro 13 — Usar o copyright do site como data da versão

Rodapés de sites frequentemente apresentam intervalos ou datas de copyright.

Isso não significa que aquela data corresponda à versão do software utilizada.

Procure informações específicas de:

• release;
• versão;
• publicação;
• atualização correspondente.

Erro 14 — Citar apenas R e ignorar o pacote central

Se um pacote implementou o método principal, citar apenas o ambiente R pode ocultar o componente metodologicamente mais relevante.

Verifique:

citation("nomeDoPacote")

e:

packageVersion("nomeDoPacote")

quando aplicável.

Erro 15 — Citar todos os pacotes carregados no R

O extremo oposto também é problemático.

Uma sessão pode carregar dependências que o pesquisador não utilizou diretamente.

Priorize os pacotes que tiveram participação científica ou metodológica relevante.

Erro 16 — Citar apenas Python e ignorar bibliotecas centrais

Em muitas pesquisas, Python funciona como ambiente para bibliotecas que executam as operações efetivamente responsáveis pelos resultados.

Se uma biblioteca implementou:

• algoritmo;
• modelo;
• estatística;
• processamento;
• classificação;

avalie a necessidade de documentá-la separadamente.

Erro 17 — Listar todas as bibliotecas instaladas no Python

Um ambiente pode conter dezenas ou centenas de dependências.

A metodologia não precisa se transformar em um inventário do ambiente inteiro.

Uma lista completa pode ser preservada separadamente quando necessária à reprodutibilidade, enquanto o texto principal destaca os componentes relevantes.

Erro 18 — Confundir R com RStudio

R e RStudio cumprem funções diferentes.

Se os cálculos foram executados pelo R, dizer apenas que a análise foi feita “no RStudio” pode esconder o ambiente estatístico responsável pelo processamento.

Documente cada recurso de acordo com sua função real.

Erro 19 — Confundir Python com Jupyter Notebook

Jupyter pode funcionar como ambiente para escrever e executar código, enquanto Python constitui a linguagem/ambiente utilizado pelo código.

Uma pesquisa pode envolver ambos, mas isso não os torna o mesmo objeto.

Erro 20 — Confundir Python com Anaconda

Python, distribuição, gerenciador de ambientes, IDE e biblioteca científica são camadas diferentes.

Não substitua automaticamente uma pela outra na metodologia ou na referência.

Erro 21 — Ignorar plugins, módulos ou extensões centrais

Em determinados programas, o recurso que realmente executa a análise é um componente adicional.

Isso pode ocorrer em:

• GIS;
• software estatístico;
• software qualitativo;
• programas de simulação;
• processamento de imagens.

Se o plugin ou módulo é essencial para compreender o procedimento, documente-o adequadamente.

Erro 22 — Listar todos os plugins instalados

Novamente, a proporcionalidade é importante.

Documente os componentes que participaram do método, não todos os recursos disponíveis no computador.

Erro 23 — Citar o software e não explicar o método

Frases como:

Os dados foram analisados no SPSS.

ou:

A análise foi realizada no R.

identificam apenas a ferramenta.

O leitor ainda precisa saber:

• qual análise;
• quais critérios;
• quais parâmetros;
• quais pressupostos;
• qual modelo;
• como os resultados foram produzidos.

Erro 24 — Tratar o software como referência metodológica do teste

O fabricante de um programa não se torna automaticamente a fonte científica para todos os métodos implementados nele.

Quando o procedimento exige fundamentação, utilize literatura metodológica adequada.

Erro 25 — Descrever o método e não identificar o software

Também pode ocorrer o problema inverso.

O estudante descreve perfeitamente o teste ou algoritmo, mas não informa qual implementação computacional foi utilizada.

Quando o software influencia o procedimento, identificar a ferramenta e sua versão melhora a rastreabilidade.

Erro 26 — Informar “parâmetros padrão” sem verificar quais eram

Valores padrão podem mudar entre versões.

Se o resultado depende desses valores, registrar apenas “foram utilizados os parâmetros padrão” pode prejudicar a reprodução.

Quando necessário, informe explicitamente os valores relevantes.

Erro 27 — Omitir hiperparâmetros em aprendizado de máquina

Informar apenas biblioteca e algoritmo pode ser insuficiente.

Dependendo do estudo, registre:

• hiperparâmetros;
• divisão dos dados;
• validação;
• métricas;
• seed;
• pré-processamento.

Esses elementos pertencem à metodologia, não à referência bibliográfica do software.

Erro 28 — Omitir a seed quando ela é importante

Em procedimentos estocásticos, a semente aleatória pode influenciar a reprodução dos resultados.

Se ela foi fixada e é metodologicamente relevante, registre-a.

Erro 29 — Colocar parâmetros dentro da referência bibliográfica

A referência identifica o software.

Ela não deve receber todos os detalhes operacionais da análise.

Parâmetros, filtros, limiares, hiperparâmetros e configurações pertencem principalmente à metodologia.

Erro 30 — Colocar toda a metodologia dentro da referência

O excesso de informação também prejudica a clareza.

Uma referência bibliográfica não precisa narrar:

• como os dados foram limpos;
• qual teste foi aplicado;
• qual parâmetro foi escolhido;
• como o corpus foi preparado;
• qual algoritmo foi treinado.

Separe identificação bibliográfica de documentação metodológica.

Erro 31 — Omitir a fonte dos dados porque o software foi citado

Isso é especialmente frequente em GIS, bioinformática e estudos com bases externas.

Citar QGIS, ArcGIS, R, Python ou outro programa não identifica:

• base cartográfica;
• imagem de satélite;
• banco genético;
• base estatística;
• dataset;
• dados censitários.

Software e dados precisam ser tratados separadamente.

Erro 32 — Citar a base de dados e esquecer o software

O inverso também pode ocorrer.

Se a implementação computacional influencia significativamente o resultado, a fonte dos dados não substitui a identificação da ferramenta.

Erro 33 — Confundir software gratuito com open source

Preço e licença são dimensões diferentes.

Um programa pode ser gratuito e proprietário.

Outro pode ser open source e fazer parte de um modelo comercial.

Não utilize esses termos como sinônimos.

Erro 34 — Confundir licença com referência

A licença define condições de uso, modificação ou distribuição.

A referência identifica e atribui o recurso.

Uma não substitui a outra.

Erro 35 — Acreditar que CITATION.cff já está automaticamente em ABNT

O arquivo CITATION.cff pode fornecer excelentes metadados estruturados.

Isso não significa que sua apresentação esteja automaticamente formatada segundo o padrão bibliográfico exigido pelo TCC.

Use-o para recuperar informações confiáveis e adapte a apresentação quando necessário.

Erro 36 — Copiar BibTeX como se fosse referência ABNT

BibTeX é uma representação estruturada utilizada em fluxos bibliográficos.

Ele pode fornecer metadados úteis, mas não deve ser colado diretamente na lista de referências como se fosse uma entrada ABNT.

Erro 37 — Usar a referência sugerida pelo projeto sem verificar o objeto

Alguns projetos recomendam citar um artigo.

Outros fornecem uma referência do software.

Outros oferecem várias opções.

Leia a orientação e descubra o que cada entrada representa.

Erro 38 — Confundir DOI geral do projeto com DOI da versão

Quando ambos existem, cada identificador pode ter finalidade diferente.

Se a pesquisa precisa documentar exatamente a versão utilizada, verifique qual DOI corresponde àquele depósito específico.

Erro 39 — Citar apenas a página inicial do repositório

Um repositório em desenvolvimento pode mudar depois da pesquisa.

Quando o estado exato do código é importante, uma release, tag, depósito ou commit pode oferecer identificação mais precisa.

Erro 40 — Usar commit sem necessidade

Precisão excessiva também pode prejudicar a legibilidade.

Se existe uma release formal que identifica adequadamente o software utilizado, um hash de commit pode ser desnecessário no corpo principal do trabalho.

Escolha o nível de detalhe proporcional à pesquisa.

Erro 41 — Não registrar quando o software foi atualizado durante o estudo

Se uma atualização ocorreu entre etapas e pode ter alterado os resultados, documente essa mudança.

Não apresente todo o procedimento como se tivesse sido executado no mesmo ambiente quando isso não aconteceu.

Erro 42 — Omitir sistema operacional quando ele afeta o procedimento

Na maioria dos trabalhos, o sistema operacional não precisa receber destaque.

Mas ele pode ser relevante quando influencia:

• compilação;
• drivers;
• bibliotecas;
• comportamento;
• compatibilidade;
• resultado.

O critério deve ser metodológico, não burocrático.

Erro 43 — Informar hardware irrelevante

Não existe benefício em escrever a configuração completa do computador se ela não influencia o procedimento.

Hardware ganha importância em situações como:

• benchmark;
• GPU;
• machine learning;
• simulação;
• alto desempenho;
• tempo de execução como variável.

Erro 44 — Omitir hardware quando ele é parte do experimento

Se o desempenho ou resultado depende do equipamento, omitir essa informação pode impedir comparação adequada.

A regra é novamente proporcionalidade.

Erro 45 — Confundir referência correta com pesquisa reproduzível

Uma referência perfeita não preserva automaticamente:

• código;
• dados;
• parâmetros;
• dependências;
• seed;
• ambiente;
• sequência das etapas.

A referência é apenas uma camada da documentação.

Erro 46 — Acreditar que reprodutibilidade elimina a necessidade de referência

O fato de o código e o ambiente estarem disponíveis não torna a identificação bibliográfica desnecessária.

As duas práticas cumprem funções complementares.

Erro 47 — Não guardar informações enquanto a pesquisa está acontecendo

Tentar reconstruir todo o ambiente meses depois pode ser difícil.

Durante a pesquisa, registre progressivamente:

• versões;
• pacotes;
• bibliotecas;
• plugins;
• parâmetros;
• links;
• DOIs;
• datas;
• scripts;
• arquivos de ambiente.

Erro 48 — Referenciar software que não teve nenhuma relevância para o trabalho

Nem toda ferramenta utilizada durante meses de pesquisa precisa entrar nas referências.

Você provavelmente utilizou:

• navegador;
• sistema operacional;
• editor de texto;
• leitor de PDF;
• compactador;
• programa de apresentação.

A pergunta não é “eu abri esse programa durante o TCC?”.

A pergunta é:

esse recurso precisa ser identificado para compreender, atribuir ou reproduzir uma parte relevante da pesquisa?

Erro 49 — Omitir software metodologicamente central porque “todo mundo conhece”

A popularidade do programa não elimina a importância da identificação.

SPSS, R, Python, MATLAB, QGIS ou qualquer outro recurso pode possuir múltiplas versões e componentes.

O fato de o leitor conhecer o nome não informa qual ambiente produziu os resultados.

Erro 50 — Seguir um modelo institucional antigo sem conferir a norma vigente

Manuais institucionais são importantes porque definem como a universidade operacionaliza a normalização de seus trabalhos.

Entretanto, um manual pode ter sido elaborado com base em uma edição anterior de determinada norma.

Verifique:

• data do manual;
• normas declaradas;
• orientações atuais da instituição;
• eventuais atualizações.

Erro 51 — Ignorar a regra específica da instituição

A existência de uma norma técnica não elimina as orientações acadêmicas locais.

A instituição pode estabelecer:

• modelo de trabalho;
• padrão de apresentação;
• procedimentos internos;
• exigências adicionais;
• orientações para casos específicos.

Quando houver manual oficial atualizado, ele deve ser consultado em conjunto com as normas aplicáveis.

Erro 52 — Tratar uma recomendação de boa prática como exigência literal da ABNT

Práticas como:

• preservar ambiente;
• registrar dependências;
• arquivar código;
• criar release;
• depositar software;
• usar identificador persistente;

podem ser excelentes para transparência e reprodutibilidade.

Isso não significa que todas sejam requisitos bibliográficos universais da ABNT.

Mantenha clara a diferença entre:

• norma bibliográfica;
• regra institucional;
• política editorial;
• boa prática científica.

Erro 53 — Transformar recomendação de um periódico em regra universal

Periódicos podem possuir políticas específicas para software, dados e código.

Essas regras devem ser seguidas quando o trabalho for submetido ao periódico correspondente, mas não devem ser apresentadas como se fossem automaticamente exigências da ABNT para todos os TCCs.

Erro 54 — Aplicar automaticamente regras de software convencional à IA generativa

Ferramentas de inteligência artificial generativa podem exigir documentação adicional relacionada a:

• modelo;
• interação;
• conteúdo gerado;
• data;
• política institucional;
• integridade acadêmica.

Consulte o guia específico Como Citar Inteligência Artificial nas Normas ABNT quando esse for o caso.

Erro 55 — Pensar que formatação correta corrige metadados errados

Uma referência pode apresentar:

• pontuação impecável;
• ordem aparentemente correta;
• tipografia consistente;

e ainda assim estar bibliograficamente errada porque:

• o autor pertence a outro objeto;
• a versão está errada;
• a data veio de outra fonte;
• o DOI identifica outro documento.

A qualidade dos metadados vem antes da formatação.

Erro 56 — Pensar que mais detalhes sempre significam uma referência melhor

Referências não são depósitos de todas as informações conhecidas sobre o software.

Detalhes metodológicos pertencem à metodologia.

Detalhes de reprodutibilidade podem pertencer a:

• apêndice;
• material suplementar;
• repositório;
• arquivo de ambiente.

O objetivo é fornecer a informação certa no lugar certo.

Erro 57 — Pensar que menos detalhes sempre tornam o texto mais elegante

A simplificação também possui limites.

Omitir versão, componente ou parâmetro crítico apenas para deixar a metodologia curta pode prejudicar a compreensão do estudo.

Escaneabilidade não significa superficialidade.

Erro 58 — Não conferir a correspondência entre texto e lista de referências

Depois de concluir o TCC, verifique se:

• os recursos citados no texto aparecem nas referências quando necessário;
• as referências correspondem aos objetos realmente mencionados;
• não existem entradas abandonadas que deixaram de ser utilizadas;
• software, artigos e manuais não foram confundidos.

Essa conferência também ajuda a detectar referências híbridas.

Erro 59 — Alterar silenciosamente o nome oficial do software

Use o nome oficial do recurso conforme os metadados correspondentes.

Não expanda siglas, traduza marcas ou modifique grafias sem verificar se essa forma representa realmente o produto.

Erro 60 — Deixar a documentação de software para o último dia

Esse talvez seja o erro operacional que causa vários dos anteriores.

No final do trabalho, o pesquisador pode já não lembrar:

• qual versão utilizou;
• quais pacotes estavam instalados;
• qual release foi baixada;
• quais parâmetros foram alterados;
• qual página continha a orientação de citação.

Documentar progressivamente é mais seguro e muito mais rápido.

Passo a passo para citar software nas normas ABNT

Depois de compreender as diferenças entre software, artigo, manual, documentação, pacote, biblioteca, plugin, repositório e serviço online, o processo pode ser reduzido a uma sequência prática.

O objetivo deste passo a passo não é criar uma fórmula universal, mas impedir que a referência seja montada antes de o objeto estar corretamente identificado.

Passo 1 — Descubra exatamente o que você utilizou

Comece pelo objeto real.

Pergunte:

• foi um programa instalado?
• uma aplicação web?
• um aplicativo?
• uma biblioteca?
• um pacote?
• um plugin?
• um módulo?
• uma API?
• um script?
• um software desenvolvido pelo próprio pesquisador?

Não avance para a formatação enquanto essa resposta não estiver clara.

Passo 2 — Determine a função do recurso na pesquisa

Identifique se ele foi utilizado para:

• coleta;
• organização;
• limpeza;
• transformação;
• análise;
• simulação;
• visualização;
• geoprocessamento;
• cálculo amostral;
• triagem;
• transcrição;
• modelagem;
• outra etapa.

Essa resposta ajuda a determinar quanto destaque o recurso deve receber na metodologia.

Passo 3 — Registre a versão utilizada

Procure a versão:

• no próprio programa;
• na tela “Sobre”;
• no terminal;
• no gerenciador de pacotes;
• na release;
• nos metadados oficiais;
• na documentação correspondente.

Registre a versão utilizada, e não necessariamente a mais recente.

Passo 4 — Identifique o responsável

Consulte fontes oficiais para verificar quem o projeto indica como responsável.

Não presuma que:

• a empresa atual é automaticamente autora;
• o GitHub é autor;
• a loja de aplicativos é autora;
• o primeiro contribuidor é necessariamente autor;
• o autor de um artigo é automaticamente o autor bibliográfico de toda versão do software.

Passo 5 — Procure orientação oficial de citação

Verifique se o projeto disponibiliza:

• “Cite this software”;
• “How to cite”;
• CITATION.cff;
• BibTeX;
• RIS;
• referência recomendada;
• artigo associado;
• DOI;
• registro em repositório.

Essas fontes podem fornecer metadados valiosos.

Entretanto, a existência de uma citação recomendada não elimina a necessidade de verificar qual objeto ela representa.

Passo 6 — Descubra se existe identificador persistente

Se houver DOI ou outro identificador, abra o registro e confirme:

• título;
• autores ou responsáveis;
• versão;
• data;
• tipo de objeto;
• relação com o software utilizado.

Não copie o identificador sem verificar o destino.

Passo 7 — Separe objetos relacionados

Crie mentalmente ou em uma anotação uma pequena tabela:

Objeto	Usei?	Por quê?
Software	[sim/não]	Identificar a ferramenta.
Pacote/biblioteca	[sim/não]	Implementou procedimento relevante.
Plugin/módulo	[sim/não]	Executou função específica.
Manual	[sim/não]	Foi consultado como fonte técnica.
Documentação	[sim/não]	Sustentou informação técnica.
Artigo	[sim/não]	Apresentou, validou ou fundamentou o recurso/método.
Dados	[sim/não]	Forneceram o material analisado.

Isso reduz drasticamente o risco de produzir uma referência híbrida.

Passo 8 — Monte a referência com os metadados do objeto correto

Somente agora organize os elementos bibliográficos conforme a natureza do recurso e as regras adotadas.

Uma estrutura didática geral pode envolver:

RESPONSABILIDADE. Título do software. Versão/edição. [Demais elementos aplicáveis]. Disponibilidade e acesso, quando pertinentes.

Essa estrutura serve como orientação de leitura dos elementos. Ela não deve ser tratada como fórmula universal aplicável sem análise a qualquer software.

Passo 9 — Escreva separadamente a metodologia

Depois de identificar bibliograficamente o recurso, responda no texto:

• para que foi utilizado;
• como foi utilizado;
• quais procedimentos foram executados;
• quais parâmetros importam;
• quais componentes adicionais foram utilizados.

Passo 10 — Verifique a correspondência entre texto e referências

Ao final, confira se:

• o software mencionado corresponde à referência;
• a versão está consistente;
• o artigo não foi confundido com o programa;
• o DOI aponta para o objeto correto;
• os componentes importantes estão documentados;
• não existem referências abandonadas.

Matriz de decisão: preciso citar este software?

Nem toda ferramenta utilizada durante a produção do TCC precisa receber o mesmo tratamento.

A matriz abaixo ajuda a avaliar a relevância do recurso.

Situação	Relevância provável	O que avaliar
Produziu resultados científicos	Alta	Versão, referência, metodologia e componentes.
Executou análise estatística	Alta	Versão, testes, módulos e parâmetros.
Executou algoritmo central	Alta	Implementação, versão, biblioteca e método.
Processou imagens ou sinais	Alta	Versão, plugins, parâmetros e etapas.
Executou simulação	Alta	Versão, modelo, condições e parâmetros.
Realizou cálculo amostral	Alta	Versão e entradas utilizadas.
Participou da coleta	Alta ou moderada	Função, versão, plataforma e procedimento.
Participou da triagem de estudos	Alta ou moderada	Etapa, versão e procedimento de seleção.
Organizou referências	Variável	Se participou formalmente do fluxo metodológico.
Apenas inseriu citações no Word	Baixa	Uso predominantemente operacional.
Apenas redigiu o trabalho	Baixa	Normalmente não integra o método científico.
Apenas criou slides da defesa	Baixa	Uso operacional.
É objeto da pesquisa	Muito alta	Versão, estado, período, plataforma e critérios de análise.
Foi desenvolvido pelo pesquisador	Variável a alta	Natureza do recurso, versão, código, depósito e função.

A coluna “relevância provável” não representa uma classificação normativa da ABNT. Ela funciona apenas como ferramenta didática para ajudar o pesquisador a decidir quanto detalhamento metodológico pode ser necessário.

Diagnóstico rápido por tipo de software

Se você utilizou R

Confira:

• versão do R;
• pacotes metodologicamente relevantes;
• versões dos pacotes;
• função de cada pacote;
• orientações obtidas por citation() e citation("pacote");
• informações de sessão quando úteis à reprodutibilidade.

Se você utilizou Python

Confira:

• versão do Python;
• bibliotecas centrais;
• versões;
• algoritmos;
• parâmetros;
• ambiente, quando relevante;
• arquivos de dependências, quando úteis.

Se você utilizou SPSS

Confira:

• nome oficial do produto;
• versão;
• procedimentos estatísticos;
• módulos relevantes;
• critérios e parâmetros.

Se você utilizou jamovi

Confira:

• versão;
• módulos adicionais;
• versões dos módulos relevantes;
• procedimentos estatísticos;
• orientação oficial de citação.

Se você utilizou IRaMuTeQ

Confira:

• versão;
• constituição do corpus;
• preparação;
• tipo de análise;
• variáveis;
• critérios de interpretação;
• componentes técnicos relevantes.

Se você utilizou NVivo, ATLAS.ti ou MAXQDA

Confira:

• versão;
• método qualitativo;
• funções utilizadas;
• procedimentos de codificação;
• eventuais módulos relevantes.

Se você utilizou MATLAB

Confira:

• release ou versão;
• toolboxes relevantes;
• modelos;
• algoritmos;
• parâmetros;
• condições de simulação, quando aplicável.

Se você utilizou QGIS ou ArcGIS

Confira:

• produto e versão;
• plugins ou extensões;
• algoritmos;
• sistema de referência, quando relevante;
• procedimentos espaciais;
• fontes dos dados geográficos.

Se você utilizou Excel

Pergunte:

• foi apenas armazenamento?
• houve transformação dos dados?
• foram usadas fórmulas?
• houve macros?
• resultados foram calculados na planilha?

Quanto maior a influência da planilha sobre os resultados, maior tende a ser a necessidade de documentar o procedimento.

Se você utilizou G*Power

Confira:

• versão;
• tipo de teste;
• tamanho de efeito;
• nível de significância;
• poder estatístico;
• demais entradas relevantes.

Se você utilizou um aplicativo

Confira:

• nome;
• responsável;
• versão;
• plataforma;
• data ou período;
• função no estudo;
• atualizações relevantes.

Se você utilizou software online ou SaaS

Confira:

• nome do serviço;
• responsável;
• versão, se houver;
• data ou período de uso;
• URL;
• configurações;
• função metodológica.

Se você utilizou software open source

Confira:

• orientação oficial de citação;
• CITATION.cff;
• release;
• versão;
• responsabilidade;
• DOI ou depósito, quando existente;
• repositório correspondente.

Se você utilizou um plugin ou extensão

Confira:

• nome;
• versão;
• responsabilidade;
• software hospedeiro;
• função desempenhada;
• orientação de citação.

Se você desenvolveu o software

Confira:

• se é apenas um script ou um produto independente;
• nome;
• versão;
• linguagem;
• bibliotecas;
• função;
• repositório;
• release;
• licença;
• identificador persistente, quando existente.

Se o software utiliza inteligência artificial

Pergunte primeiro se você está diante de:

• software convencional que incorpora algum algoritmo de IA;
• modelo de machine learning;
• serviço baseado em IA;
• IA generativa.

Se for IA generativa, consulte também Como Citar Inteligência Artificial nas Normas ABNT.

Checklist final para citar software no TCC

Antes de considerar a referência e a documentação concluídas, faça esta revisão.

Identificação do recurso

• ☐ Confirmei o nome oficial do software.
• ☐ Sei exatamente qual recurso utilizei.
• ☐ Diferenciei software, site, manual, documentação e artigo.
• ☐ Diferenciei ambiente, pacote, biblioteca, módulo e plugin quando necessário.
• ☐ Não tratei GitHub ou loja de aplicativos automaticamente como autor.

Versão e data

• ☐ Registrei a versão efetivamente utilizada.
• ☐ Não substituí minha versão pela versão atualmente disponível.
• ☐ Não inventei versão quando ela não estava disponível.
• ☐ Verifiquei a data correspondente ao objeto.
• ☐ Não usei automaticamente o ano de um artigo como ano do software.

Responsabilidade

• ☐ Consultei metadados oficiais.
• ☐ Verifiquei a orientação de citação do projeto.
• ☐ Não presumi autoria apenas pelo nome de uma empresa ou plataforma.
• ☐ Confirmei autoria ou responsabilidade quando havia múltiplos contribuidores.

Identificadores e repositórios

• ☐ Verifiquei se existe DOI ou outro identificador persistente.
• ☐ Abri o registro do DOI para saber qual objeto ele identifica.
• ☐ Diferenciei DOI do artigo e DOI do software.
• ☐ Diferenciei DOI geral do projeto e DOI da versão, quando aplicável.
• ☐ Identifiquei release, tag ou commit quando isso era necessário.

Pacotes, bibliotecas e componentes

• ☐ Identifiquei os pacotes metodologicamente relevantes.
• ☐ Registrei suas versões quando necessário.
• ☐ Não listei indiscriminadamente todas as dependências.
• ☐ Documentei plugins ou módulos centrais.
• ☐ Não confundi ambiente de desenvolvimento com linguagem ou software principal.

Metodologia

• ☐ Expliquei para que o software foi utilizado.
• ☐ Descrevi o procedimento realizado.
• ☐ Informei parâmetros relevantes.
• ☐ Registrei seed quando necessária.
• ☐ Expliquei algoritmos, modelos ou testes quando pertinente.
• ☐ Diferenciei ferramenta computacional e método científico.
• ☐ Identifiquei a fonte dos dados separadamente do software.

Reprodutibilidade

• ☐ Preservei scripts importantes.
• ☐ Registrei dependências relevantes.
• ☐ Preservei arquivos de ambiente quando necessário.
• ☐ Registrei configurações capazes de alterar os resultados.
• ☐ Considerei release ou depósito para código próprio quando apropriado.
• ☐ Não confundi essas boas práticas com exigências bibliográficas universais da ABNT.

Conferência bibliográfica

• ☐ A referência representa um único objeto real.
• ☐ Não misturei dados de software, artigo, manual e site.
• ☐ A citação no texto corresponde à entrada da lista de referências.
• ☐ Os dados foram conferidos em fontes confiáveis.
• ☐ Consultei as orientações atualizadas da minha instituição.

Conferência final do trabalho

• ☐ Não transformei as referências em inventário de todos os programas utilizados.
• ☐ Não omiti software metodologicamente central apenas por ele ser conhecido.
• ☐ Diferenciei exigência normativa, regra institucional e boa prática científica.
• ☐ Tratei IA generativa separadamente quando necessário.
• ☐ Fiz uma última conferência de versão, responsabilidade, data, DOI e URL.

Matriz final: onde colocar cada informação?

Uma das melhores maneiras de evitar excesso ou falta de detalhes é decidir onde cada informação pertence.

Informação	Referência	Metodologia	Material de reprodutibilidade
Nome do software	Sim, quando referenciado	Sim	Pode aparecer
Versão	Quando aplicável	Frequentemente relevante	Sim
Responsabilidade	Elemento bibliográfico	Normalmente não precisa ser repetida	Pode aparecer
URL/DOI	Quando aplicável	Normalmente não é o foco	Pode aparecer
Função na pesquisa	Não	Sim	Sim
Teste estatístico	Não	Sim	Pode aparecer
Parâmetros	Não	Sim, quando relevantes	Sim
Seed	Não	Quando relevante	Sim
Dependências completas	Não	Apenas as centrais	Frequentemente
Código	Não como parte da referência	Descrição resumida	Repositório/apêndice quando apropriado
Hardware	Não	Somente se relevante	Pode ser registrado
Sistema operacional	Normalmente não	Somente se relevante	Pode ser registrado

Auditoria rápida em 2 minutos

Se você já possui uma referência de software pronta, faça este teste antes de entregar o TCC.

1. Abra a fonte original dos metadados.
2. Confirme se o título pertence realmente ao software.
3. Confira a responsabilidade.
4. Confira a versão utilizada.
5. Confira a data.
6. Abra o DOI, se houver.
7. Confira se a URL aponta para o recurso correto.
8. Veja se algum dado foi copiado de artigo, manual ou página diferente.
9. Confirme se a metodologia explica a função do software.
10. Confira as regras atuais da sua instituição.

Se qualquer etapa falhar, corrija o problema antes de ajustar apenas pontuação, negrito ou itálico.

Ordem de prioridade na revisão

Ao revisar uma referência, siga esta ordem:

1. objeto correto;
2. metadados corretos;
3. versão correta;
4. correspondência com a metodologia;
5. formatação bibliográfica;
6. padronização visual final.

Essa ordem evita gastar tempo aperfeiçoando a aparência de uma referência conceitualmente errada.

Como citar software nas normas ABNT?

Identifique primeiro o software e depois organize os elementos da referência

O primeiro passo é descobrir exatamente qual recurso foi utilizado e recuperar seus metadados oficiais. Procure nome, responsabilidade, versão, data, identificadores persistentes e informações de disponibilidade quando aplicáveis.

Depois, organize esses elementos de acordo com a natureza do documento e com as normas e orientações adotadas pela instituição.

Evite começar copiando uma referência pronta de outro TCC. Ela pode corresponder a outra versão ou até a outro objeto.

Qual norma ABNT é usada para citar software?

A referência bibliográfica e a citação no texto pertencem a camadas normativas diferentes

Para referências, o eixo normativo central é a ABNT NBR 6023. Para o sistema de citações no texto, a referência normativa é a ABNT NBR 10520.

Além disso, a instituição pode possuir manual próprio de normalização.

É importante separar:

• norma de referências;
• norma de citações;
• regra institucional;
• política de periódico;
• boa prática de documentação e reprodutibilidade.

Essas camadas podem trabalhar juntas, mas não devem ser apresentadas como se fossem a mesma coisa.

Todo software usado no TCC precisa ser citado?

Não necessariamente; a relevância depende da função desempenhada

Um software utilizado diretamente para produzir, processar ou analisar resultados possui relevância diferente de um programa usado apenas para escrever o trabalho ou criar os slides da apresentação.

Pergunte se a identificação do recurso é importante para:

• compreender o método;
• atribuir corretamente o recurso;
• identificar a implementação utilizada;
• reproduzir uma etapa relevante.

Não transforme a lista de referências em um inventário de todos os programas instalados no computador.

Preciso citar o software e mencionar na metodologia?

As duas informações podem cumprir funções complementares

A referência identifica bibliograficamente o recurso. A metodologia explica como ele foi utilizado.

Por exemplo, a referência pode identificar determinado software estatístico, enquanto a metodologia informa:

• versão;
• testes realizados;
• modelos;
• parâmetros;
• critérios analíticos.

Uma referência correta não substitui uma metodologia suficientemente clara.

Como citar software no corpo do texto?

A forma depende de como o recurso é introduzido e do sistema de citação adotado

Em muitos casos, o software aparece naturalmente na descrição metodológica.

Exemplo adaptável:

As análises foram realizadas no software [NOME], versão [X].

Quando houver uma fonte bibliográfica correspondente, a citação deve manter correspondência com a entrada da lista de referências segundo o sistema adotado no trabalho.

Evite inventar paginação para o próprio software.

Preciso colocar a versão do software na referência?

A versão pode ser essencial para identificar o recurso utilizado

Versões diferentes podem apresentar mudanças em:

• algoritmos;
• funções;
• módulos;
• parâmetros padrão;
• correções;
• resultados.

Quando a versão está disponível e é relevante para identificar o recurso, registrá-la melhora a precisão da documentação.

Use a versão efetivamente utilizada, não simplesmente a versão mais recente encontrada no site.

O que fazer quando o software não mostra a versão?

Não invente um número de versão

Algumas ferramentas online são atualizadas continuamente e não apresentam versão visível ao usuário.

Nesse caso, registre os metadados realmente disponíveis e, quando metodologicamente necessário, informe a data ou o período de utilização.

Também pode ser útil documentar configurações e características do estado analisado.

Como citar software sem autor?

Primeiro confirme se realmente não existe responsabilidade identificável

Software pode possuir responsabilidade atribuída a:

• pessoa;
• equipe;
• organização;
• fundação;
• universidade;
• projeto.

Não conclua que um software “não tem autor” apenas porque não aparece um nome pessoal na página inicial.

Procure metadados oficiais, orientação de citação, documentação e registros do projeto antes de definir a entrada bibliográfica.

A empresa do software deve aparecer como autora?

Somente quando os metadados sustentarem essa responsabilidade

Uma empresa pode desenvolver, distribuir, comercializar ou adquirir um produto. Essas funções não são automaticamente equivalentes à autoria bibliográfica.

Use a responsabilidade indicada para o objeto que está sendo citado.

Como citar software com DOI?

Confirme primeiro qual objeto o DOI identifica

Abra o registro do DOI e verifique:

• título;
• autores ou responsáveis;
• tipo de objeto;
• versão;
• data.

O DOI pode apontar para uma versão do software, para o projeto em geral ou para outro objeto relacionado.

Não presuma que qualquer DOI encontrado na página do projeto pertence ao software.

Posso usar o DOI do artigo do software?

Sim para citar o artigo; não para fingir que o DOI identifica o software

Se o projeto recomenda um artigo científico, esse artigo pode ser citado quando apropriado.

Entretanto, seu DOI identifica o artigo.

Não combine o DOI do artigo com título e versão do software em uma referência híbrida.

Software e artigo científico precisam ser citados juntos?

Podem ser citados juntos quando cumprem funções diferentes

O software pode identificar a implementação utilizada, enquanto o artigo pode:

• apresentar o projeto;
• descrever o algoritmo;
• validar a ferramenta;
• fornecer fundamentação científica.

Não existe conflito em utilizar ambos quando cada fonte é pertinente ao que está sendo documentado.

Posso citar apenas o artigo recomendado pelo software?

Depende do que precisa ser documentado

O artigo pode fornecer a atribuição científica solicitada pelo projeto, mas pode não identificar exatamente a versão do programa que produziu os resultados.

Quando a versão é metodologicamente importante, considere também a identificação do software correspondente.

Software e manual são a mesma referência?

Não; o programa e o manual são objetos diferentes

O software é a ferramenta computacional. O manual é um documento que explica seu funcionamento ou uso.

Se você utilizou ambos, cada um pode ser referenciado conforme sua função.

Para o segundo caso, consulte Como Citar Manual nas Normas ABNT.

Software e documentação online são a mesma coisa?

Também não

A documentação pode explicar funções, parâmetros, APIs e procedimentos, enquanto o software corresponde ao recurso executado.

Se uma afirmação técnica foi retirada da documentação, cite a fonte que realmente sustenta aquela informação.

Como citar software hospedado no GitHub?

Identifique o projeto, e não apenas a plataforma de hospedagem

Procure:

• nome do projeto;
• autores ou responsáveis;
• versão;
• release;
• CITATION.cff;
• orientação oficial de citação;
• DOI, quando existente.

GitHub não deve ser colocado automaticamente como autor apenas porque hospeda o repositório.

GitHub é autor de software?

Não apenas por hospedar o projeto

A plataforma fornece infraestrutura de hospedagem e colaboração. A responsabilidade pelo software deve ser identificada nos metadados do próprio projeto.

Preciso citar o repositório do GitHub?

Depende de qual objeto precisa ser identificado

O repositório pode ser importante quando o estado do código, sua disponibilidade ou sua versão faz parte da documentação da pesquisa.

Quando existe uma release ou depósito persistente correspondente exatamente à versão utilizada, esse objeto pode oferecer identificação mais precisa.

Preciso informar o commit do GitHub?

Somente quando esse nível de precisão for necessário

Um commit pode ser útil quando:

• não existe release;
• o código muda rapidamente;
• a análise depende de um estado específico;
• a reprodução exige aquela revisão.

Não trate hash de commit como exigência universal da ABNT.

O que é CITATION.cff?

É um arquivo estruturado que pode fornecer informações de citação do projeto

Projetos de software podem disponibilizar um arquivo CITATION.cff contendo dados como:

• título;
• autores;
• versão;
• identificadores;
• informações recomendadas para atribuição.

Ele é uma excelente fonte de metadados quando mantido pelo projeto.

Entretanto, não significa que a apresentação dos dados já esteja automaticamente formatada conforme as exigências bibliográficas do seu TCC.

Posso copiar o BibTeX do software para as referências?

Use o BibTeX como fonte estruturada de metadados, não como referência ABNT pronta

Uma entrada BibTeX pode ajudar a recuperar:

• autores;
• título;
• ano;
• DOI;
• URL;
• versão.

Depois, organize esses dados conforme o padrão bibliográfico utilizado no trabalho.

Como citar software open source?

Verifique versão, responsabilidade e orientação oficial do projeto

Softwares open source frequentemente disponibilizam informações úteis em:

• releases;
• documentação;
• CITATION.cff;
• repositórios;
• depósitos científicos;
• DOIs.

O fato de o código ser aberto não elimina a necessidade de identificar corretamente o objeto utilizado.

Software gratuito e software open source são a mesma coisa?

Não

“Gratuito” descreve uma condição de acesso ou preço. “Open source” envolve disponibilidade do código sob condições de licenciamento específicas.

Um software pode ser gratuito e proprietário, enquanto outro pode ser open source e possuir serviços comerciais associados.

Como citar software baixado do Zenodo?

Use os metadados do depósito correspondente ao objeto utilizado

Verifique:

• autores ou responsáveis;
• título;
• versão;
• data;
• DOI;
• relação entre o depósito e o software executado.

Se existirem DOI da versão e DOI geral do projeto, confirme qual corresponde à finalidade da referência.

Como citar R nas normas ABNT?

Registre a versão utilizada e consulte a orientação de citação do próprio ambiente

No R, você pode recuperar informações úteis com:

R.version.string
citation()

Também pode preservar informações do ambiente com:

sessionInfo()

Depois, adapte os metadados do recurso ao padrão bibliográfico adotado no trabalho.

Preciso citar os pacotes do R?

Cite ou documente os pacotes que tiveram participação metodológica relevante

Se determinado pacote implementou o método central, sua identificação pode ser importante.

Utilize:

citation("nomeDoPacote")
packageVersion("nomeDoPacote")

Não é necessário transformar todas as dependências carregadas automaticamente em referências.

Preciso citar RStudio?

Depende da função que ele desempenhou no trabalho

RStudio e R não são o mesmo objeto.

Se os cálculos foram executados pelo R e RStudio serviu apenas como ambiente de desenvolvimento, o componente metodologicamente central pode ser o R e seus pacotes.

Se RStudio desempenhou alguma função específica relevante, essa situação pode ser documentada separadamente.

Como citar Python nas normas ABNT?

Identifique a versão do Python e as bibliotecas metodologicamente relevantes

Você pode verificar a versão, por exemplo, com:

python --version

ou:

import sys
print(sys.version)

Depois, documente as bibliotecas responsáveis pelos procedimentos centrais quando isso for relevante para a pesquisa.

Preciso citar NumPy, pandas, SciPy ou scikit-learn?

Depende da participação de cada biblioteca no método

Uma biblioteca que implementa o algoritmo, procedimento estatístico ou transformação central possui relevância diferente de uma dependência instalada mas nunca utilizada diretamente.

Consulte a orientação oficial de cada projeto e registre a versão efetivamente utilizada.

Como saber a versão de uma biblioteca Python?

Use o ambiente em que a pesquisa foi executada

Dependendo da instalação, comandos como:

pip show nome-do-pacote

podem fornecer informações da biblioteca.

Também pode ser útil preservar o ambiente com:

pip freeze

Essas informações ajudam na documentação e reprodutibilidade, mas uma lista completa de dependências não precisa necessariamente aparecer no corpo principal do TCC.

Preciso citar Jupyter Notebook?

Somente quando sua identificação for relevante para o fluxo da pesquisa

Jupyter pode ser o ambiente em que o código foi organizado e executado, enquanto Python e suas bibliotecas realizam as operações computacionais.

Documente cada camada de acordo com sua função.

Preciso citar Anaconda?

Depende da relevância da distribuição e do ambiente para o estudo

Anaconda não deve substituir automaticamente a identificação de Python ou das bibliotecas responsáveis pela análise.

Quando o ambiente de distribuição é importante para reproduzir a configuração, ele pode ser documentado proporcionalmente.

Como citar SPSS nas normas ABNT?

Confirme o nome oficial e a versão efetivamente utilizada

Na metodologia, informe também quais procedimentos estatísticos foram executados.

Não copie uma referência de SPSS de outro trabalho sem verificar se:

• a versão coincide;
• o produto é o mesmo;
• a responsabilidade corresponde ao recurso utilizado;
• os metadados continuam adequados.

Como citar jamovi nas normas ABNT?

Identifique a versão do programa e os módulos relevantes

Se determinado módulo executou uma análise central, registre também suas informações quando necessárias.

Além da identificação bibliográfica, descreva na metodologia quais procedimentos foram realizados.

Como citar IRaMuTeQ nas normas ABNT?

Identifique o programa e documente separadamente o procedimento de análise textual

A metodologia pode precisar informar:

• versão;
• preparação do corpus;
• variáveis;
• tipo de análise;
• critérios utilizados;
• procedimento interpretativo.

A referência do IRaMuTeQ não substitui essas informações.

Como citar NVivo nas normas ABNT?

Confirme a versão e explique a função desempenhada no processo qualitativo

Não atribua automaticamente ao software o método de análise.

Informe, quando pertinente, como o programa foi utilizado para:

• organização;
• codificação;
• recuperação;
• classificação;
• exploração do material.

A abordagem qualitativa deve ser fundamentada separadamente.

Como citar ATLAS.ti ou MAXQDA?

A lógica é semelhante: software e método precisam permanecer separados

Identifique o produto e sua versão e descreva quais funções foram utilizadas.

Se módulos ou recursos específicos forem centrais, registre-os quando necessário.

Como citar G*Power nas normas ABNT?

Além do programa, registre os parâmetros do cálculo amostral

Na metodologia, informe elementos como:

• tipo de teste;
• tamanho de efeito;
• nível de significância;
• poder;
• demais entradas relevantes.

A referência do software não substitui a justificativa dos valores adotados.

Como citar QGIS nas normas ABNT?

Registre a versão e documente plugins, algoritmos e dados quando relevantes

Em uma análise espacial, pode ser necessário separar:

• QGIS;
• plugin;
• algoritmo;
• base geográfica;
• sistema de referência;
• fonte dos dados.

Citar o programa não substitui a referência dos dados geográficos utilizados.

Como citar ArcGIS nas normas ABNT?

Identifique o produto e a versão correspondente à pesquisa

Quando extensões, módulos ou ferramentas específicas participarem do procedimento, documente-as proporcionalmente.

Também mantenha separadas as referências das bases geográficas utilizadas.

Preciso citar Excel no TCC?

Depende do que a planilha fez na pesquisa

Se Excel foi utilizado apenas para armazenar ou visualizar dados, sua relevância metodológica pode ser pequena.

Se fórmulas, macros, funções ou ferramentas analíticas produziram resultados, descreva o procedimento e avalie a necessidade de identificar o software.

A pergunta mais útil é:

o que o Excel fez com os dados?

Preciso citar Word no TCC?

O simples uso para redigir o trabalho normalmente é operacional

Escrever o TCC em um editor de texto não significa automaticamente que o programa faça parte da metodologia científica.

O mesmo princípio se aplica a outras ferramentas utilizadas apenas para edição e apresentação.

Preciso citar Zotero?

Depende de sua participação no fluxo da pesquisa

Se Zotero foi utilizado apenas para armazenar referências e inserir citações durante a escrita, seu uso pode ser predominantemente operacional.

Se participou formalmente de uma etapa metodológica — por exemplo, organização de registros em uma revisão — sua função pode ser descrita.

Preciso citar Mendeley?

A decisão também depende da função desempenhada

O simples uso do gerenciador para formatar referências não cria automaticamente necessidade de tratá-lo como software metodologicamente central.

Quando ele participa formalmente do fluxo de pesquisa, documente sua função de maneira proporcional.

Zotero e Mendeley garantem referências ABNT corretas?

Não; a saída precisa ser conferida

Gerenciadores dependem:

• dos metadados cadastrados;
• do tipo de documento;
• do estilo utilizado;
• da qualidade dos dados importados.

Uma referência gerada automaticamente deve ser revisada antes da entrega do trabalho.

Como citar aplicativo nas normas ABNT?

Identifique o aplicativo como recurso e registre sua função na pesquisa

Procure nome oficial, responsável, versão, plataforma, data e informações de acesso quando aplicáveis.

Se o aplicativo participou da coleta ou medição, explique também como foi utilizado.

Google Play ou App Store entram como autores do aplicativo?

Não automaticamente

As lojas funcionam como plataformas de distribuição.

O responsável pelo aplicativo deve ser identificado nos metadados correspondentes.

Como citar software online nas normas ABNT?

Diferencie aplicação web de página comum da internet

Se a ferramenta executa cálculos, análises ou processamento, ela pode constituir um recurso computacional utilizado na metodologia.

Registre, conforme disponível:

• nome;
• responsável;
• versão;
• data ou período;
• URL;
• função desempenhada.

Software online precisa de data de acesso?

A informação de acesso pode ser importante para recursos disponíveis na internet

Entretanto, ela não substitui a versão quando esta existe.

Também não garante que uma aplicação continuamente atualizada permanecerá igual no futuro.

Como citar SaaS no TCC?

Registre o serviço e documente o estado utilizado tanto quanto for possível

Ferramentas SaaS podem mudar sem instalação local.

Dependendo da pesquisa, registre:

• nome do serviço;
• responsável;
• versão, se disponível;
• data ou período de uso;
• configurações;
• função metodológica.

Como citar API utilizada no TCC?

Separe serviço, versão da API e biblioteca cliente quando necessário

Uma pesquisa pode utilizar simultaneamente:

• serviço remoto;
• API;
• versão da API;
• biblioteca cliente;
• código próprio.

Documente apenas as camadas relevantes, mas não as confunda.

Como citar software desenvolvido por mim?

Documente o objeto real sem inventar elementos editoriais

Se você desenvolveu um programa para a pesquisa, registre, quando aplicável:

• autoria;
• nome;
• versão;
• data;
• linguagem;
• repositório;
• DOI;
• licença.

Se for apenas um script interno, pode ser mais apropriado descrevê-lo metodologicamente e disponibilizá-lo quando pertinente, sem fingir que existe uma publicação formal.

Posso colocar meu código no apêndice do TCC?

Pode ser adequado quando o código foi produzido pelo próprio autor e possui extensão compatível

Códigos muito longos podem ser mais adequadamente disponibilizados em repositório, enquanto o texto do TCC descreve sua função e indica como recuperá-los.

Siga também as orientações da instituição para apêndices e materiais suplementares.

Preciso publicar meu software para citá-lo?

Não necessariamente, mas a recuperabilidade influencia a documentação

Um recurso interno pode ser descrito metodologicamente mesmo sem publicação formal.

Se o objetivo é torná-lo citável e reutilizável, versionamento, release, depósito e identificador persistente podem melhorar sua identificação.

Como citar software proprietário que não está disponível publicamente?

Registre as informações que podem ser divulgadas sem violar restrições

Dependendo do caso, informe:

• nome;
• versão;
• responsável;
• função;
• período de uso;
• restrição de acesso.

Não exponha informações confidenciais apenas para tornar a documentação mais detalhada.

Preciso informar sistema operacional na metodologia?

Somente quando ele influencia o procedimento

O sistema operacional pode ser relevante quando afeta:

• compatibilidade;
• compilação;
• dependências;
• drivers;
• comportamento do software.

Em muitos TCCs, essa informação não é necessária.

Preciso informar o computador utilizado?

Somente quando o hardware possui relevância científica ou técnica

Isso pode ocorrer em estudos envolvendo:

• GPU;
• benchmark;
• machine learning;
• simulações intensivas;
• alto desempenho;
• tempo de execução.

Evite preencher a metodologia com especificações sem função científica.

Preciso informar parâmetros do software?

Sim quando eles influenciam o procedimento ou os resultados

Podem ser relevantes:

• hiperparâmetros;
• limiares;
• filtros;
• tolerâncias;
• número de iterações;
• seed;
• configurações de algoritmos.

Esses detalhes pertencem principalmente à metodologia, não à referência bibliográfica.

Preciso informar a seed usada no código?

Quando a semente é importante para reproduzir um procedimento estocástico, registre-a

Isso pode ocorrer em:

• machine learning;
• simulações;
• amostragem;
• algoritmos aleatórios.

A seed não é elemento da referência do software; ela faz parte da documentação do experimento.

Referenciar software torna a pesquisa reproduzível?

Não por si só

Reprodutibilidade pode depender também de:

• dados;
• scripts;
• pacotes;
• dependências;
• parâmetros;
• seed;
• ambiente;
• sequência das etapas.

A referência identifica a ferramenta, mas não substitui a documentação do processo.

A ABNT obriga a colocar todas as dependências do software?

Não trate a preservação completa do ambiente como exigência bibliográfica universal

Registrar dependências pode ser uma excelente prática de reprodutibilidade, especialmente em pesquisa computacional.

Entretanto, isso deve ser distinguido das regras de elaboração da referência bibliográfica.

A ABNT obriga a colocar o commit do GitHub?

Não trate commit como requisito universal de referência

Um commit pode ser metodologicamente útil quando identifica o estado exato do código utilizado.

Isso é diferente de afirmar que toda referência ABNT de software hospedado em GitHub precisa obrigatoriamente conter um hash.

Preciso seguir o manual da minha faculdade mesmo usando ABNT?

Consulte as orientações institucionais atualizadas

Universidades podem estabelecer modelos e procedimentos próprios de normalização para seus trabalhos.

O ideal é verificar:

• manual institucional;
• modelo oficial;
• orientação do curso;
• eventuais atualizações;
• normas indicadas pela instituição.

Como saber se uma referência de software está correta?

Faça uma auditoria dos metadados antes de revisar apenas a formatação

Confira:

1. qual objeto está sendo citado;
2. nome oficial;
3. responsabilidade;
4. versão;
5. data;
6. DOI;
7. URL;
8. correspondência com o recurso utilizado;
9. correspondência com a citação no texto.

Uma referência visualmente perfeita pode estar errada se seus metadados pertencem a objetos diferentes.

Como citar ChatGPT como software nas normas ABNT?

IA generativa exige análise específica e não deve ser reduzida automaticamente a software convencional

O uso de ChatGPT pode envolver questões adicionais de:

• modelo;
• data da interação;
• prompt;
• conteúdo produzido;
• recuperabilidade;
• transparência;
• integridade acadêmica;
• política institucional.

Por isso, consulte o guia dedicado Como Citar Inteligência Artificial nas Normas ABNT.

Qual é a regra mais importante para citar software corretamente?

Identifique o objeto antes de tentar formatar a referência

Antes de perguntar onde colocar ponto, dois-pontos, itálico ou URL, descubra:

• qual recurso você realmente utilizou;
• qual versão;
• quem é responsável;
• qual data pertence àquele objeto;
• se existe DOI;
• se existe orientação oficial de citação;
• qual função o recurso desempenhou.

Depois disso, a normalização se torna muito mais segura.

Conclusão: citar software corretamente começa pela identificação do recurso

Citar software nas normas ABNT não deve ser tratado como um exercício de copiar um modelo pronto e substituir o nome do programa.

Softwares podem assumir formas muito diferentes: programas instalados, aplicativos, serviços online, pacotes, bibliotecas, plugins, ambientes computacionais, projetos open source, ferramentas proprietárias ou recursos desenvolvidos pelo próprio pesquisador.

Por isso, o primeiro passo é sempre identificar qual objeto realmente participou da pesquisa.

Depois, procure confirmar:

• nome oficial;
• responsabilidade;
• versão;
• data correspondente;
• orientação oficial de citação;
• DOI ou outro identificador, quando existente;
• local de recuperação;
• componentes metodologicamente relevantes.

Somente depois dessa investigação faz sentido organizar a referência bibliográfica.

A referência é apenas uma parte da documentação

Em trabalhos acadêmicos, existe ainda uma segunda questão:

como o software participou do método?

Uma referência pode identificar perfeitamente determinado programa e, ainda assim, o leitor não saber:

• qual análise foi realizada;
• quais parâmetros foram utilizados;
• qual pacote executou o procedimento;
• qual algoritmo foi aplicado;
• como os dados foram processados;
• qual versão realmente produziu os resultados.

É por isso que referência bibliográfica e descrição metodológica precisam trabalhar juntas.

Software não substitui método

Escrever que os dados foram analisados em R, Python, SPSS, jamovi, IRaMuTeQ, NVivo, MATLAB ou qualquer outro programa não explica, por si só, como a pesquisa foi realizada.

O software é uma ferramenta ou implementação.

O método científico precisa continuar sendo:

• descrito;
• justificado;
• fundamentado;
• executado de forma coerente com o desenho do estudo.

Método também não substitui software

O inverso também é verdadeiro.

Uma descrição detalhada do teste estatístico, algoritmo ou procedimento não informa automaticamente qual implementação computacional produziu os resultados.

Quando a implementação possui relevância para interpretação ou reprodução, o software e sua versão também merecem identificação adequada.

Não misture objetos bibliográficos

Ao finalizar o trabalho, confirme se você manteve separados:

• software;
• artigo científico;
• manual;
• documentação;
• site institucional;
• repositório;
• base de dados;
• pacote;
• biblioteca;
• plugin.

Esses recursos podem estar relacionados e até aparecer juntos na mesma pesquisa, mas isso não significa que seus metadados possam ser combinados em uma única referência.

Não confunda ABNT com reprodutibilidade

Práticas como preservar scripts, registrar dependências, fixar seeds, arquivar releases e depositar código podem aumentar significativamente a transparência e a reprodutibilidade de pesquisas computacionais.

Entretanto, essas práticas não devem ser apresentadas automaticamente como exigências universais de uma norma de referências.

Mantenha sempre separadas quatro camadas:

1. normalização bibliográfica;
2. exigências da instituição;
3. descrição metodológica;
4. boas práticas de transparência e reprodutibilidade.

A versão merece atenção especial

Quando disponível e metodologicamente relevante, a versão ajuda a identificar o estado do software que realmente participou da pesquisa.

Isso é especialmente importante em recursos que:

• mudam algoritmos;
• alteram valores padrão;
• recebem novos módulos;
• corrigem erros;
• modificam comportamentos entre versões.

Se o recurso não disponibiliza versão ao usuário, não invente uma. Registre os dados verificáveis e documente temporalmente o uso quando isso for necessário.

Comece pelos metadados, não pela pontuação

Antes de perguntar se determinada parte deve estar em negrito, itálico ou seguida por ponto, confirme se:

• o título pertence ao objeto correto;
• a responsabilidade está correta;
• a versão corresponde à utilizada;
• a data pertence ao software;
• o DOI aponta para o objeto citado;
• a URL corresponde ao recurso adequado.

Uma referência visualmente impecável continua errada quando seus metadados são incorretos.

Continue aprendendo sobre ABNT e pesquisa acadêmica

A referência de software faz parte de um sistema maior de normalização e documentação acadêmica. Os conteúdos abaixo ajudam a resolver situações relacionadas.

Boa prática científica na citação de software

Além das normas bibliográficas utilizadas no trabalho, pesquisadores podem consultar princípios internacionais voltados especificamente à citação de software científico.

Os Software Citation Principles da FORCE11 defendem, entre outros aspectos, que o software seja reconhecido como produto citável de pesquisa e que sua identificação favoreça crédito, persistência, acesso e especificidade da versão utilizada.

Essa distinção é importante porque algumas recomendações de ciência aberta e reprodutibilidade vão além dos elementos necessários à elaboração de uma referência bibliográfica.

Referências e documentos consultados

ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR 6023: informação e documentação — referências — elaboração. Rio de Janeiro: ABNT, 2025.

ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR 10520: informação e documentação — citações em documentos — apresentação. Rio de Janeiro: ABNT, 2023.

ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR 14724: informação e documentação — trabalhos acadêmicos — apresentação. Rio de Janeiro: ABNT, 2024.

SMITH, Arfon M.; KATZ, Daniel S.; NIEMEYER, Kyle E.; FORCE11 SOFTWARE CITATION WORKING GROUP. Software Citation Principles. PeerJ Computer Science, v. 2, e86, 2016. DOI: 10.7717/peerj-cs.86.

FORCE11. Software Citation Principles. 2016. Disponível em: https://force11.org/info/software-citation-principles-published-2016/. Acesso em: 23 set. 2026.

Nota editorial

Resumo final: como citar software no TCC

Antes de finalizar, lembre-se dos pontos essenciais:

• Identifique o objeto: software, aplicativo, pacote, biblioteca, plugin, serviço ou código próprio.
• Registre a versão: use aquela efetivamente utilizada.
• Confirme a responsabilidade: não presuma autoria pela plataforma ou empresa.
• Procure metadados oficiais: documentação, CITATION.cff, release, DOI e orientação de citação podem ajudar.
• Separe os objetos: software, artigo, manual, documentação, repositório e dados não são automaticamente a mesma fonte.
• Descreva a metodologia: informe o que o software fez e os parâmetros relevantes.
• Não exagere: não cite todo programa utilizado operacionalmente.
• Não omita: recursos computacionais centrais precisam ser suficientemente identificados.
• Confira a instituição: manuais acadêmicos podem estabelecer orientações complementares.
• Revise os metadados: uma referência bem formatada não corrige dados bibliográficos errados.