Sempre que ouço tentativas de associar algum tipo de métrica baseada em código a defeitos de software, a primeira coisa que penso é na complexidade ciclomática de McCabe . Vários estudos descobriram que existe uma correlação entre alta complexidade ciclomática e número de defeitos. No entanto, outros estudos que analisaram módulos com um tamanho semelhante (em termos de linhas de código) descobriram que pode não haver uma correlação.
Para mim, tanto o número de linhas em um módulo quanto a complexidade ciclomática podem servir como bons indicadores de possíveis defeitos, ou talvez uma maior probabilidade de que os defeitos sejam injetados se forem feitas modificações em um módulo. Um módulo (especialmente no nível de classe ou método) com alta complexidade ciclomática é mais difícil de entender, pois há um grande número de caminhos independentes através do código. Um módulo (novamente, especialmente no nível de classe ou método) com um grande número de linhas também é difícil de entender, pois o aumento de linhas significa que mais coisas estão acontecendo. Existem muitas ferramentas de análise estática que suportam o cálculo das linhas de código-fonte de acordo com as regras especificadas e a complexidade ciclomática; parece que capturá-las seria uma tarefa difícil.
As medidas de complexidade de Halstead também podem ser interessantes. Infelizmente, a validade deles parece ser um pouco debatida, então eu não precisaria confiar neles. Uma das medidas de Halstead é uma estimativa de defeitos com base no esforço ou no volume (uma relação entre a duração do programa em termos de operadores e operandos totais e o vocabulário do programa em termos de operadores e operadores distintos).
Há também um grupo de métricas conhecido como CK Metrics. A primeira definição desse conjunto de métricas parece estar em um artigo intitulado A Metrics Suite for Object Oriented Design, de Chidamber e Kemerer. Eles definem Métodos Ponderados por Classe, Árvore de Profundidade de Herança, Número de Filhos, Acoplamento entre Classes de Objetos, Resposta para uma Classe e Falta de Coesão nos Métodos. O artigo fornece os métodos computacionais, bem como uma descrição de como analisar cada um.
Em termos de literatura acadêmica que analisa essas métricas, você pode estar interessado em Análise Empírica de Métricas CK para Complexidade de Design Orientada a Objetos: Implicações para Defeitos de Software, de autoria de Ramanath Subramanyam e MS Krishna. Eles analisaram três das seis métricas de CK (métodos ponderados por classe, acoplamento entre objetos classificados e profundidade da árvore de herança). Olhando através do artigo, parece que eles descobriram que essas são métricas potencialmente válidas, mas devem ser interpretadas com cautela, pois "melhorar" uma pode levar a outras mudanças que também levam a uma maior probabilidade de defeitos.
A análise empírica das métricas de projeto orientadas a objetos para prever falhas de severidade alta e baixa, de autoria de Yuming Zhou e Hareton Leung, também examina as métricas de CK. Sua abordagem foi determinar se eles podem prever defeitos com base nessas métricas. Eles descobriram que muitas das métricas da CK, exceto a profundidade da árvore de herança e o número de filhos) tinham algum nível de significância estatística na previsão de áreas onde os defeitos poderiam ser localizados.
Se você for membro do IEEE, recomendo procurar nas publicações IEEE Transactions on Software Engineering mais publicações acadêmicas e no IEEE Software mais relatórios do mundo real e aplicados. O ACM também pode ter publicações relevantes em sua biblioteca digital .