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

16

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

Augusto
la source
1
Si vous voulez éviter la fermeture, vous devez reformuler votre question. Les sites Stack Exchange ne sont pas des moteurs de recherche et les utilisateurs ne sont pas des assistants de recherche personnels . Au lieu de demander des liens vers des articles, l'accent devrait être mis sur la question de savoir quels types de mesures ont été corrélés avec les défauts et la densité des défauts.
Thomas Owens
1
Je suis désolé que la question soit apparue comme une demande pour devenir mon assistant de recherche personnel , ce n'est certainement pas ce que je voulais faire, mais trouver ce type de documents n'est pas quelque chose de très courant. J'ai changé de titre pour que les autres personnes n'aient pas la même impression.
Augusto

Réponses:

11

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 .

Thomas Owens
la source
Les métriques Halstead se sont toutes révélées fortement corrélées avec le SLOC brut (nombre de lignes de code source). À ce stade, tout ce qui est en corrélation avec une métrique Halstead est devenu connu comme étant en corrélation avec le SLOC brut, et il est plus facile de mesurer le SLOC que n'importe quelle métrique Halstead.
John R. Strohm
@ JohnR.Strohm Je ne suis pas d'accord pour dire qu'il est plus facile de compter SLOC que de calculer les métriques Halstead, lorsque vous utilisez des outils pour effectuer le calcul. En supposant que les métriques Halstead sont valides (ce qui est en fait débattu, mais rien n'a d'importance pour une métrique non valide), connaître le temps nécessaire pour développer le code ou le nombre prévu de défauts dans le système est une valeur plus utile que de connaître le montant de lignes. Je peux créer des plannings avec des données de temps, des plans qualité avec des données de défauts ou allouer assez de temps à une révision de code avec difficulté. Il est plus difficile d'utiliser SLOC brut pour ces choses.
Thomas Owens
@ JohnR.Strohm Je suis sûr qu'un programme de calcul de métrique Halstead prend un peu plus de temps à exécuter qu'un programme de comptage SLOC. Mais en supposant qu'une sortie valide devient une entrée valide dans une prise de décision, je préfère avoir des données significatives sur le temps, l'effort et les défauts plutôt qu'un compte SLOC brut. La valeur ajoutée de la métrique plus complexe vaut souvent le temps de calcul supplémentaire, en supposant là encore des entrées et des sorties de calcul valides.
Thomas Owens
@ThomasOwens, la question de savoir si l'effort logiciel, et donc le coût et le calendrier, peuvent être estimés directement à partir des estimations du SLOC brut a été faite à mort. Après de nombreuses recherches sur les données réelles du projet, la question a été résolue par l'affirmative. Voir "Software Engineering Economics", par Barry Boehm, 1981.
John R. Strohm
@ThomasOwens: De plus, il faut reconnaître que les métriques Halstead sont intrinsèquement rétrospectives. Vous ne pouvez pas mesurer les métriques Halstead d'un logiciel que vous n'avez pas encore écrit. D'un autre côté, il est possible d'estimer le SLOC brut pour une tâche donnée et, étant donné des spécifications suffisamment détaillées et un peu d'expérience, il est relativement facile de s'approcher assez près de l'estimation. De plus, il est TRÈS facile de comparer les estimations aux chiffres réels, d'affiner ses heuristiques d'estimation et de calibrer son estimateur de coûts. General Dynamics / Fort Worth a fait beaucoup de travail à ce sujet au début des années 1980.
John R. Strohm
7

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!

Amr Noaman
la source
Pas digne d'un downvote, mais cela devrait être "certaines études ne montrent aucune corrélation", car d'autres études montrent une corrélation.
David Hammen
3

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.

QuantumOmega
la source