Metodologia Pericial Computacional · v. 3.01 — 2026
Métricas tradicionais contam linhas. A Auditoria de Densidade Funcional mede o que importa em contexto pericial — a distância entre o que foi declarado e o que está operacional — expressando o resultado em Score de Prontidão auditável.
Ferramentas tradicionais de análise estática foram desenhadas para um propósito específico: melhorar código existente em produção. Elas medem manutenibilidade, complexidade ciclomática, dívida técnica e cobertura de testes.
No contexto pericial, a pergunta é outra. Não se trata de avaliar a saúde do código que opera num sistema em uso — trata-se de aferir se o que foi entregue está, de fato, apto a operar. Essa pergunta exige instrumental próprio.
A Auditoria de Densidade Funcional foi desenvolvida para responder a essa pergunta forense: quantificar, com critério objetivo e reproduzível, a Densidade Funcional de cada camada tecnológica de um sistema, distinguindo o motor funcional da casca arquitetural.
A mera contagem bruta de linhas de código mostra-se cientificamente ineficaz para mensurar a completude negocial de um software — incapaz de distinguir código autoral funcional de código gerado automaticamente, de bibliotecas de terceiros ou de declarações arquiteturais desprovidas de lógica operativa.
— Princípio fundamental da ADF
O método. Framework estruturado de análise estática de código-fonte aplicado em contexto pericial.
A métrica. Relação entre estrutura arquitetural declarada e lógica de domínio efetivamente implementada.
O resultado. Valor numérico apurado por camada tecnológica, expresso em escala de 0 a 100.
A ADF distingue duas dimensões que ferramentas convencionais não separam: a Linha de Base Arquitetural — infraestrutura estrutural, mapeamentos, classes declaradas, rotas configuradas — e a Lógica de Domínio, que compreende as regras de negócio efetivamente implementadas, a inteligência operativa que faz o sistema funcionar.
Um sistema pode ter chassi arquitetural íntegro e, ainda assim, ser inoperante em produção. Pode ter mil componentes declarados e zero integração entre eles. A densidade funcional mede precisamente essa relação — quanto da estrutura está preenchida com lógica viva, quanto está vazia ou desativada.
O Score de Prontidão resultante não é avaliação subjetiva. Decorre de processamento algorítmico determinístico, classe a classe, sobre os arquivos-fonte autorais — reproduzível por qualquer perito que execute o mesmo método sobre o mesmo material.
Existe coerência entre a arquitetura declarada e os achados quantitativos. O motor funcional pode estar substancialmente codificado nas camadas internas e, no entanto, permanecer ilhado por um painel de controle inoperante — o sistema possui o chassi, mas não a fiação que o coloca em movimento.
— Diagnóstico típico em laudos baseados em ADF
A densidade funcional do projeto é mensurada a partir de cinco chaves aplicadas concorrentemente sobre cada classe e arquivo-fonte. Quatro identificam lacunas; uma estabelece o piso mínimo de fundação arquitetural.
Skeleton Code / Stub Implementation
Implementação Esquelética
Classes e métodos declarados em conformidade com o padrão arquitetural, porém com corpos vazios ou desprovidos de lógica operativa. Method stubs declaratórios sem implementação efetiva.
Correspondência normativa: ISO/IEC 25010 — subcaracterística Completeness (Functional Suitability); IEEE 1028 — critério de incompletude de implementação.
Commented-Out Code / Dead Code
Lógica Suprimida
Lógica de negócio efetivamente codificada, mas desativada por marcações de comentário. Configura dívida técnica e inoperância de fato em funcionalidades aparentemente concluídas.
Correspondência normativa: ISO/IEC 25010 — subcaracterística Functional Correctness; conceito de Technical Debt conforme Cunningham (1992); code smell documentado em Fowler, Refactoring (1999).
Anemic Domain Model
Modelos Anêmicos
Objetos de dados que funcionam como meros receptáculos, desprovidos de comportamentos ou regras de negócio. Antipadrão clássico de design orientado a objetos.
Correspondência normativa: ISO/IEC 25010 — subcaracterística Maintainability / Modularity; antipadrão documentado em Fowler (2003) e Evans, Domain-Driven Design (2003).
Incomplete Implementation / Requirement Gap
Lacuna de Implementação
Pendências críticas sinalizadas por anotações de desenvolvimento (TODO, FIXME), retornos estáticos hardcoded ou funções desprovidas de tratamento de erro. Caracteriza incompletude de requisitos em nível de código.
Correspondência normativa: ISO/IEC 25010 — subcaracterísticas Completeness e Functional Correctness; IEEE 1028 — não-conformidade detectável por inspeção estática de código.
Minimum Operational Baseline
Fundação Estrutural
Mecanismos arquiteturais estruturais necessários para sustentar a execução das regras de negócio — rotas mapeadas, esquema relacional íntegro, controllers, DAOs. Estabelece piso mínimo de pontuação.
Correspondência normativa: ISO/IEC 25010 — subcaracterística Maintainability; IEEE 42010 — elementos de descrição arquitetural obrigatórios para conformidade estrutural.
A apuração do Score de Prontidão decorre de processamento lógico e determinístico aplicado mediante varredura programática classe a classe sobre o universo de arquivos autorais — não de inferência subjetiva.
Filtragem de Código de Terceiros
Identificação e expurgo de todo código que não seja de autoria original. Componentes de terceiros, utilitários de mercado e boilerplate gerado por IDEs são excluídos da base de cálculo, evitando contaminação estatística da amostra.
Validação da Base Positiva
Avaliação da maturidade da infraestrutura técnica de fundação. A presença de classes estruturais funcionais, mapeamentos operacionais e esquema relacional íntegro garante pontuação mínima de partida.
Auditoria de Densidade
Cruzamento entre camadas verificando integração efetiva entre interface, lógica e dados. O Score de Prontidão é proporcionalmente reduzido conforme magnitude e criticidade da incompletude.
A Auditoria de Densidade Funcional restringe-se às camadas de lógica de negócio entregável, excluindo do cômputo do Score de Prontidão tecnologias de configuração, apresentação e estilização. Essa delimitação decorre da finalidade do método — medir a Densidade Funcional, não usabilidade ou volumetria.
HTML, CSS e arquivos de configuração compõem infraestrutura de build e camada de apresentação visual. Sua presença ou ausência não altera o diagnóstico de operabilidade do motor lógico, conforme distinção consagrada pela norma ISO/IEC 25010 entre Adequação Funcional e Usabilidade.
A metodologia, embora customizada quanto ao seu arranjo final, ampara-se integralmente em conceitos consagrados pela literatura técnica de Engenharia de Software e em normas técnicas internacionais reconhecidas.
ISO/IEC 25010
Systems and Software Quality Requirements and Evaluation — subcaracterísticas Functional Completeness, Functional Correctness, Functional Appropriateness e Maintainability/Modularity.
IEEE 1028
Standard for Software Reviews and Audits — define critérios para inspeção estática de código e detecção de não-conformidades em incompletude de implementação.
IEEE 42010
Systems and Software Engineering — Architecture Description — elementos arquiteturais obrigatórios para conformidade estrutural, base da Chave 05 (Minimum Operational Baseline).
Martin Fowler
Refactoring: Improving the Design of Existing Code (1999) e Anemic Domain Model (2003) — fundamentação dos conceitos de Dead Code, Code Smells e antipadrão de modelos sem comportamento.
Eric Evans
Domain-Driven Design: Tackling Complexity in the Heart of Software (2003) — princípios de modelagem de domínio que sustentam a distinção entre Anemic Domain Model e Rich Domain Model.
Ward Cunningham
Conceito de Technical Debt (1992) — formalização do custo acumulado por dívida técnica, base teórica para a Chave 02 (Commented-Out Code / Dead Code).