Expériences corrélant les mesures de code à la densité de bogues

Je me demande si quelqu'un a fait des expériences corrélant les métriques de code (SLOC, complexité cyclomatique, etc.) avec la densité de bogues dans les applications orientées objet.

Je ne recherche pas d'expériences qui ne font que prouver ou infirmer une corrélation, mais les deux. Je n'essaie pas de trouver une solution miracle car je pense que la densité de bogues d'un projet peut être corrélée à une ou plusieurs mesures pour un projet ou une équipe donnés et la corrélation peut changer pendant la durée de vie du projet / de l'équipe.

Mon objectif est de

1. Mesurez toutes les métriques intéressantes pendant 2 à 3 mois (nous en avons déjà pas mal du sonar).
2. Trouvez une métrique qui correspond au nombre de nouveaux bogues.
3. Faites une analyse des causes profondes pour vérifier pourquoi cela se produit (par exemple, manquons-nous d'une certaine compétence en conception?).
4. Améliorez les compétences et mesurez le changement pour quelques répétitions.
5. Rincer et répéter à partir de 2.

Si vous n'avez aucune expérience à ce sujet, mais souvenez-vous d'avoir vu un article / blog sur ce sujet, j'apprécierais que vous puissiez le partager.

Jusqu'à présent, j'ai trouvé les liens suivants avec des informations sur ce sujet

• Les bogues résident-ils dans du code complexe? - juste les diapositives d'une présentation.
• Changements et bogues: Exploration et prédiction des activités de développement - Faites simplement glisser une présentation. En bout de ligne, plus il y a de dépendances, plus les risques de bugs sont élevés (je pense que c'est une règle assez générale).
• L'échec est un mot de quatre lettres - un paradis sur la corrélation entre les bogues et les métriques.

Chaque fois que j'entends parler de tentatives d'associer un certain type de métrique basée sur le code à des défauts logiciels, la première chose à laquelle je pense est la complexité cyclomatique de McCabe . Diverses études ont montré qu'il existe une corrélation entre une complexité cyclomatique élevée et le nombre de défauts. Cependant, d'autres études qui ont examiné des modules de taille similaire (en termes de lignes de code) ont constaté qu'il pourrait ne pas y avoir de corrélation.

Pour moi, le nombre de lignes dans un module et la complexité cyclomatique pourraient servir de bons indicateurs de défauts possibles, ou peut-être une plus grande probabilité que des défauts soient injectés si des modifications sont apportées à un module. Un module (en particulier au niveau de la classe ou de la méthode) avec une complexité cyclomatique élevée est plus difficile à comprendre car il existe un grand nombre de chemins indépendants dans le code. Un module (encore une fois, en particulier au niveau de la classe ou de la méthode) avec un grand nombre de lignes est également difficile à comprendre car l'augmentation du nombre de lignes signifie que plus de choses se produisent. Il existe de nombreux outils d'analyse statique qui prennent en charge le calcul à la fois des lignes de code source par rapport aux règles spécifiées et à la complexité cyclomatique, il semble que les capturer serait saisir les fruits bas.

Les mesures de complexité de Halstead pourraient également être intéressantes. Malheureusement, leur validité semble être quelque peu débattue, donc je ne m'appuierais pas nécessairement sur eux. L'une des mesures de Halstead est une estimation des défauts basée sur l'effort ou le volume (une relation entre la durée du programme en termes d'opérateurs et d'opérandes totaux et le vocabulaire du programme en termes d'opérateurs et d'opérateurs distincts).

Il existe également un groupe de métriques connues sous le nom de métriques CK. La première définition de cette suite de métriques semble se trouver dans un article intitulé A Metrics Suite for Object Oriented Design par Chidamber et Kemerer. Ils définissent les méthodes pondérées par classe, la profondeur de l'arbre d'héritage, le nombre d'enfants, le couplage entre les classes d'objets, la réponse pour une classe et le manque de cohésion dans les méthodes. Leur article fournit les méthodes de calcul ainsi qu'une description de la façon d'analyser chacune.

En termes de littérature académique qui analyse ces métriques, vous pourriez être intéressé par l'analyse empirique des métriques CK pour la complexité de conception orientée objet: implications pour les défauts logiciels, rédigée par Ramanath Subramanyam et MS Krishna. Ils ont analysé trois des six métriques CK (méthodes pondérées par classe, couplage entre les classes d'objets et la profondeur de l'arbre d'héritage). En parcourant le document, il apparaît qu'ils ont trouvé que ce sont des mesures potentiellement valides, mais doivent être interprétées avec prudence car "l'amélioration" pourrait conduire à d'autres changements qui conduisent également à une plus grande probabilité de défauts.

L'analyse empirique des métriques de conception orientée objet pour prédire les défauts de gravité élevée et faible, rédigée par Yuming Zhou et Hareton Leung, examine également les métriques CK. Leur approche consistait à déterminer s'ils pouvaient prédire les défauts en fonction de ces mesures. Ils ont constaté que de nombreuses mesures CK, à l'exception de la profondeur de l'arbre d'héritage et du nombre d'enfants) avaient un certain niveau de signification statistique pour prédire les zones où des défauts pouvaient être localisés.

Si vous êtes membre de l'IEEE, je recommanderais de rechercher dans les transactions IEEE sur l'ingénierie logicielle pour plus de publications académiques et IEEE Software pour des rapports plus réels et appliqués. L'ACM peut également avoir des publications pertinentes dans sa bibliothèque numérique .

J'ai discuté des corrélations possibles dans l' un de mes articles de blog :

Corrélation entre la complexité cyclomatique et la densité des bugs: est-ce là le vrai problème?

La réponse est non. En gardant la taille constante, les études ne montrent aucune corrélation entre CC et la densité des défauts. Cependant, il existe deux autres corrélations intéressantes à étudier:

La première est la suivante: le CC est-il fortement corrélé à la durée de détection et de correction des défauts? En d'autres termes, si CC est inférieur, passerions-nous moins de temps à déboguer et à corriger les défauts?

La seconde est la suivante: CC est-il fortement corrélé avec le rapport de rétroaction de défaut (FFR, le nombre moyen de défauts qui résulte de l'application d'un changement ou de la correction d'un défaut)?

Il faut plus d'investigation pour voir si quelqu'un a déjà étudié empiriquement cette corrélation. Mais, mon intuition et les commentaires que je reçois des équipes avec lesquelles je travaille est qu'il existe une forte corrélation positive entre la complexité cyclomatique d'un côté et la durée de détection et de correction d'un défaut ou l'impact du changement d'un autre côté.

C'est une bonne expérience à faire. Restez attentif aux résultats!

Dans le livre Code Complete, p.457, Steve McConnell dit que "la complexité du flux de contrôle est importante car elle a été corrélée avec une faible fiabilité et des erreurs fréquentes". Il mentionne ensuite quelques références qui soutiennent cette corrélation, y compris McCabe lui-même (qui est crédité d'avoir développé la métrique de complexité cyclomatique). La plupart d'entre elles sont antérieures à l'utilisation généralisée des langages orientés objet, mais comme cette mesure s'applique aux méthodes de ces langages, les références peuvent être ce que vous recherchez.

Ces références sont:

• McCabe, Tom. 1976. «A Complexity Measure». Transactions IEEE sur le génie logiciel, SE-2, no. 4 (décembre): 308-20
• Shen, Vincent Y., et al. 1985. «Identifier les logiciels sujets aux erreurs - une étude empirique». Transactions IEEE sur le génie logiciel SE-11, n ° 4 (avril): 317-24.
• Ward, William T. 1989. «Prévention des défauts logiciels à l'aide de la métrique de complexité de McCabe». Hewlett-Packard Journal, avril 64-68.

D'après ma propre expérience, la métrique de McCabe, telle qu'elle peut être calculée par un programme sur de nombreuses sections de code, est utile pour trouver des méthodes et des fonctions qui sont trop compliquées et qui ont une forte probabilité de contenir des erreurs. Bien que je n'aie pas calculé la distribution des erreurs dans les fonctions à complexité cyclomatique élevée par rapport aux fonctions à complexité cyclomatique faible, l'étude de ces fonctions m'a permis de découvrir des erreurs de programmation négligées.