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 .