Experiências que correlacionam métricas de código à densidade de bugs

15

Eu estou querendo saber se alguém fez algumas experiências correlacionando métricas de código (SLOC, Complexidade Cyclomatic, etc) com densidade de bug em aplicações orientadas a objeto.

Não estou procurando experiências que apenas provem ou refutem uma correlação, mas em ambos. Eu não estou tentando encontrar uma bala de prata, pois acredito que a densidade de bug de um projeto pode se correlacionar com uma ou mais métricas para um determinado projeto ou equipe e a correlação pode mudar durante a vida útil do projeto. projeto / equipe.

Meu objetivo é

  1. Avalie todas as métricas interessantes por dois a três meses (já temos muito do sonar).
  2. Encontre uma métrica que se correlacione com o número de novos bugs.
  3. Faça uma análise de causa-raiz para verificar por que isso acontece (por exemplo, falta-nos uma certa habilidade de design?).
  4. Aprimore a habilidade e avalie a mudança para algumas iterações.
  5. Enxague e repita a partir de 2.

Se você não tem experiência com isso, mas lembre-se de ver um artigo / blog sobre esse assunto, eu agradeceria se você pudesse compartilhá-lo.

Até agora eu encontrei os seguintes links com algumas informações sobre este assunto

por Augusto 17.05.2012 / 11:55
fonte

3 respostas

10

Sempre que ouço falar de tentativas de associar algum tipo de métrica baseada em código a defeitos de software, a primeira coisa que penso é em de McCabe. complexidade ciclomática . 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, o número de linhas em um módulo e a complexidade ciclomática podem servir como bons indicadores de possíveis defeitos, ou talvez uma maior probabilidade de que defeitos sejam injetados se modificações forem feitas 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, já que o aumento de linhas significa que mais coisas estão acontecendo. Existem muitas ferramentas de análise estática que suportam a computação de linhas de código de origem contra regras especificadas e complexidade ciclomática, parece que capturá-las seria pegar os frutos mais baixos.

As medidas de complexidade do Halstead também podem ser interessantes. Infelizmente, sua validade parece ser um pouco debatida, então eu não precisaria confiar neles. Uma das medidas de Halstead é uma estimativa de defeitos baseados em esforço ou volume (uma relação entre o comprimento do programa em termos de operadores totais e operandos e o vocabulário de programa em termos de operadores e operadores distintos).

Há também um grupo de métricas conhecidas como Métricas CK. A primeira definição desse conjunto de métricas parece estar em um artigo intitulado Um conjunto de métricas para projeto orientado a objetos por Chidamber e Kemerer. Eles definem métodos ponderados por classe, profundidade da árvore 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 deles fornece os métodos computacionais, bem como uma descrição de como analisar cada um deles.

Em termos de literatura acadêmica que analisam essas métricas, você pode estar interessado em Análise Empírica de Métricas CK para Complexidade de Projeto Orientada a Objetos: Implicações para Defeitos de Software, de autoria de Ramanath Subramanyam e M.S. Krishna Eles analisaram três das seis métricas CK (métodos ponderados por classe, acoplamento entre objetos classificados e profundidade da árvore de herança). Observando o artigo, parece que eles são métricas potencialmente válidas, mas devem ser interpretadas com cautela, pois "melhorar" pode levar a outras alterações que também levam a uma maior probabilidade de defeitos.

Análise empírica de métricas de projeto orientadas a objeto para prever falhas de gravidade altas e baixas, de autoria de Yuming Zhou e Hareton Leung, também examinam 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 de 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ê é membro do IEEE, recomendo pesquisar nas IEEE Transactions on Software Engineering para obter mais informações acadêmicas. publicações e IEEE Software para alguns relatórios mais reais e aplicados. O ACM também pode ter publicações relevantes em sua biblioteca digital .

    
por 17.05.2012 / 15:33
fonte
6

Eu tenho discutido possíveis correlações em uma das postagens do meu blog :

Correllation between Cyclomatic Complexity and Bugs density: Is this the real Issue?

The answer is no. Keeping the size constant, studies show no correlation between CC and defect density. However, there are other two interesting correlations to study:

The first one is: Does CC strongly correlate with the duration of detecting and fixing defects? In other words, if CC is lower, would we spend less time debug and fix defects?

The second one is: Does CC strongly correlate with the Fault Feedback Ratio (FFR, the average number of defects which results from applying one change or fixing one defect)?

It needs more investigation to see if anyone has ever studied this correlation empirically. But, my gut feeling and the feedback I get from the teams I work with is that there is strong positive correlation between cyclomatic complexity on one side and the duration of detecting and fixing a defect or the change impact on another side.

This is a good experiment to do. Keep alert for the results!

    
por 30.07.2012 / 08:07
fonte
3

No livro Code Complete, p.457, Steve McConnell diz que "a complexidade do fluxo de controle é importante porque está correlacionada com baixa confiabilidade e erros freqüentes". Ele então menciona algumas referências que suportam essa correlação, incluindo o próprio McCabe (que é creditado por ter desenvolvido a métrica da complexidade ciclomática). A maioria deles é anterior ao uso difundido de linguagens orientadas a objetos, mas como essa métrica se aplica a métodos dentro dessas linguagens, as referências podem ser o que você está procurando.

Essas referências são:

  • McCabe, Tom. 1976. "Uma medida de complexidade". Transações do IEEE em software Engenharia, SE-2, não. 4 (dezembro): 308-20
  • Shen, Vincent Y., et al. 1985. "Identificando Software Propenso a Erros - Um Estudo Empírico." Transações IEEE em Engenharia de Software SE-11, no.4 (Abril): 317-24.
  • Ward, William T. 1989. "Prevenção de defeitos de software usando a métrica da complexidade de McCabe." Hewlett-Packard Journal, abril, 64-68.

De minha própria experiência, a métrica de McCabe, como pode ser calculada por um programa em muitas seções de código, é útil para encontrar métodos e funções que são supercomplicadas e que têm uma alta probabilidade de conter erros. Embora eu não tenha calculado, a distribuição de erros dentro de funções de alta complexidade ciclomática versus funções de baixa complexidade ciclomática, investigar essas funções me permitiu descobrir erros de programação negligenciados.

    
por 22.08.2012 / 22:38
fonte