L’analyse en Composante Principale pour la réduction de dimension

Revue de littérature

La revue de littérature s’articule autour des travaux liés à la prédiction de bogues utilisant les métriques en lien avec l’historique de versions des logiciels (git). Par la suite, elle fait le survol des grandes familles d’approches pour évaluer les métriques logicielles pour la prédiction de fautes. L’usage de l’historique git dans la prédiction de bogues logiciels n’est pas tout à fait nouveau dans la littérature. Zhang et al. (2014) ont montré qu ‘avec certains mots-clés des « commits » on pouvait inférer les types de changements qui s’effectuent sur le code source. En effet, quand l’ingénieur logiciel effectue un changement dans le code, il y laisse une ou plusieurs phrases résumant l’acte de changement : c’est le « commit ». Des études récentes ont montré qu’il existe une corrélation forte et significative entre des métadonnées comme la taille des mots des commit et l’apparition des fautes (Barnett et aL, 2016). Trois grandes familles d’approches sont fréquemment rencontrées dans la littérature de la prédiction de bogues logiciels. La plus utilisée est sans doute l’évaluation des métriques étudiées logiciel par logiciel. Cette première approche consiste à voir une par une la performance des métriques selon différents dépôts logiciels choisis par les auteurs. L’étude récente de Toure, Badri et Lamontagne (2018) met en valeur cette façon de faire.

La deuxième famille d’approche appelée « cross defect prediction » vise à sonder la capacité d’un modèle et d’une métrique à généraliser d’un dépôt logiciel à l’autre. T. Zimmermann et al. (2009) est la référence en la matière. Les auteurs ont conclu qu’il était difficile de prédire la connaissance du bogue appris depuis les données d’un logiciel dans celles d’un autre logiciel. Pour pallier à ce problème, il existe une troisième famille d’approches consistant à transformer les variables à prédire afin d’uniformiser leur distribution dans tous les logiciels. En effet, Zhang et al. (2014) ont voulu corriger la distribution statistique de la variable d’intérêt afin d’améliorer la prédiction d’un logiciel à un autre. Notre travail est lié aux travaux de S. Kim et al. (2007) qui étaient les premiers à définir les caractéristiques d’une entité logicielle susceptible de contenir des bogues dans le futur. Pour la présente étude, la pertinence de leurs travaux est liée au fait qu’ils ont pu formuler des situations typiques qui amènent le développeur à commettre des erreurs. Ces caractéristiques sont les suivantes:

Ces caractéristiques sont utilisées pour formuler des métriques capables de prendre en compte simultanément tous ces aspects. Notre métrique est dérivée d’une fonction Cobb-Douglas (Paul Douglas (1928)) qui pondère l’apport en effort de test (que l’on définira par la suite) et le temps écoulé depuis le dernier changement ou création dans la probabilité de produire des bogues. Les métriques sont construites à partir de 03 jeux de données logicielles: ActiveMQ et Apache Struts 1 et II. Le choix de ces logiciels a été motivé par la présence de données conséquentes sur le Web. Notre métrique se met à jour lorsqu’un changement ou création est réalisé au niveau d’une entité (ici, l’entité que nous nous sommes fixée est la classe). L’approche ainsi adoptée est aussi motivée par celle de Barnet et al. (2016) qui ont établi des corrélations entre la taille des phrases des « commits » et la probabilité qu’un logiciel contienne des bogues. Elle est aussi motivée par le papier précurseur de Zhang et al. (2014), qui sont les premiers à avoir émis l’hypothèse selon laquelle il y aurait un lien entre la description textuelle des « commits » et les raisons du changement : adaptive, corrective et autres. Zhou et Leung (2006) ont établi la classification basée sur la sévérité des bogues en utilisant une dichotomie binaire: « Severe» – « Not Severe ». G. Sharma, Sharma et Gujra (2015) ont élaboré un dictionnaire de termes critiques pour la prédiction de la sévérité des bogues et ont utilisé plusieurs modèles comme les k-plus proches voisins, la classification multi-classes de Bayes. Ils ont également utilisé des métriques d’information pour évaluer la qualité de leurs modèles.

Résultats de la comparaison pour l’ensemble du jeu de données

Les disparités des performances des métriques selon les logiciels nous conduit à les évaluer en utilisant une combinaison de tous les logiciels. Trois types de modèles d’apprentissage sont utilisés: Random Forest (RF), Support Vector Machine (SVM) et Perceptron multicouches (MLP). Chaque modèle est utilisé trois (03) fois:

1. Avec toutes les variables (métriques traditionnelles, Ranking Index et Bug Index) 2. Utilisant seulement les 78 métriques traditionnelles 3. Utilisant uniquement les 02 métriques : Rank Index et Bug Index.

En entrai na nt les modèles avec toutes les données, le constat est que les métriques indépendantes du code (celles que nous proposons) rivalisent avec la sélection de métriques choisies dans la Table 3 (ci-dessous). En effet, en utilisant Rank Index et Bug Index comme variables explicatives, un modèle de Random Forest peut atteindre 71% de bonne classification (tous logiciels confondus). A la lumière de ces résultats, nous pouvons raisonnablement affirmer que les métriques issues des dépôts GIT sont tout à fait capables de prédire la sévérité des bogues logiciels au même titre que les métriques usuelles de la littérature (RQ1 et RQ28 ). Dans cette section, il est constaté que les métriques proposées par l’étude peuvent atteindre des performances similaires aux métriques de code bien établies de la littérature et qui ont été choisies en guise de « benchmark ». Cependant, cette performance cache l’apport individuel de chaque métrique dans la prédiction. En effet, si parmi les métriques prises en « benchmark », il existe deux qui peuvent atteindre les performances des 02 proposées par l’étude, alors, la question de la supériorité de notre proposition ne tient plus. Dans ce qui suit, une évaluation 02 par 02 des métriques faites et ce, pour chaque catégorie de sévérité.

On effectue alors une classification binaire pour chaque catégorie de bogues et non plus une classification multi-classes comme auparavant. 4.8 Comparaison 02 par 02 des métriques Dans la section précédente, il est constaté qu’aucun ensemble de métriques ne se démarque de manière significative dans la prédiction de la sévérité des bogues logiciels. Cela ne permet pas de conclure sur l’efficacité de Rank Index et Bug Index ainsi que de répondre directement à la question de recherche RQ3 qui consiste à affirmer si les métriques issues du git sont supérieures dans la prédiction de la sévérité des bogues. D’ailleurs, il se peut que les performances des modèles utilisant les 78 métriques puissent être influencées par quelques métriques seulement (2, 3, etc.). Ainsi, il est beaucoup plus judicieux d’effectuer une comparaison 02 par 02 des métriques. Dans les résultats résumés à la Table 4 (ci-dessous), un tirage aléatoire de 02 métriques parmi les 78 fréquemment utilisées dans la littérature a été effectué, puis une comparaison des résultats de leur prédiction aux modèles qui utilisent uniquement Ranking Index et Bug Index est réalisée. Le couple de métriques proposées par l’étude (Ranking Index et Bug Index) atteignent des Aue de 0.96, 0.45, 0.52, 0.58 et 0.49 respectivement sur les catégories de bogues: bloquants, majeurs, mineurs, triviaux et Autres.

A l’inverse, pour tous les autres couples de métriques traditionnelles, les Aue tournent autour de 0.5 sans exception. A la lumière de ces expériences, la conclusion est que nos deux métriques ont la capacité de bien prédire les bogues bloquants (AUe: 0.967) et une performance plus ou moins égale à celle des autres métriques dans la prédiction des autres classes de bogues logiciels. Rappelons qu’un AUe de l’ordre de 0.5 est l’équivalent d’un classifieur qui réalise une prédiction complètement aléatoire et donc, de très faible performance. Le couple de métriques évaluées par l’étude rivalise globalement avec les métriques traditionnelles. Elles sont, par ailleurs, excellentes dans la prédiction de certains types de bogues notamment les plus importants que les études de la littérature cherchent à prédire : les bogues bloquants. Les résultats expérimentaux confirment ainsi, les deux questions de recherches RQ1 et RQ2, mais ne permettent pas d’établir la supériorité absolue des 02 métriques proposées comparativement au reste.

Discussions et Conclusions

Tout au long de cette étude, la possibilité d’utiliser des modèles et des métriques indépendantes du logiciel, pour la classification de la sévérité des bogues, a été explorée. Le Ranking Index est défini en utilisant les hypothèses de Kim S. et al. (2014), des classes à risque de bogues. Cette métrique est facile d’interprétation et est complémentée par le Bug Index qui est, quant à lui, une variable indicatrice de bogues par le passé. Le paramètre a du Ranking Index a été déterminé empiriquement en faisant en sorte que la métrique sépare au mieux les différentes classes de sévérité, une fois entrainée dans un modèle. La valeur a = 0.5 de ce paramètre indique que le faible effort de test et les modifications récentes de code source contribuent de façon égale à l’apparition de bogues. Par ailleurs, les phrases des « commits » sont largement exploitées par le traitement des langues naturelles qui s’est avéré encore plus efficace dans la classification des bogues logiciels en surpassant de 9% le taux de bonne classification du « Ranking Index ». Notre recherche s’est également attardée sur un modèle d’apprentissage profond « convnet » qui prend comme entrée les phrases des « commits ». Ce modèle, développé par Kim. Y (2014), nous a permis d’atteindre 89% de taux de bonne classification. Notre étude vient démontrer le potentiel des données issues du Git pour la classification de la sévérité des bogues. Qu’elles soient numériques ou textuelles, ces données rivalisent de pair avec les métriques traditionnelles fréquemment utilisées dans la littérature du génie logiciel empirique et dans certains cas, les dépassent en terme de performance. Cependant, les applications de notre étude sont limitées si l’on ne dispose pas d’outils pour les mettre à disposition des développeurs. Pour ce faire, il faut, au préalable, standardiser l’acquisition et la mise en forme des données issues des dépôts Git. Ainsi, toutes nos réflexions et futurs travaux s’articulent autour de l’encapsulation de nos algorithmes et métriques pour les servir en tant qu’API dans les principaux fournisseurs de dépôts Git infonuagiques.