Utilisateur:Ozzerz/Brouillon

Une page de Wikipédia, l'encyclopédie libre.

La prédiction de bugs est un domaine important de la recherche en ingénierie logicielle. Elle consiste à prédire les bugs en utilisant un programme externe qui analyse le code source d'un logiciel. Cette analyse se base sur plusieurs métriques pour déterminer le nombre et le type d'erreurs présentes dans le code source.

Introduction[modifier | modifier le code]

La prédiction de bugs a pour but d'améliorer la qualité d'un logiciel. Ainsi le développeur n'a plus à se soucier de la localisation et de la cause d'un bug. Cela permet de gagner du temps lors du développement afin de le consacrer à la construction d'un logiciel plutôt qu'à sa correction. Cette réduction du temps de développement apporte également une baisse du coût de développement.

Historique[modifier | modifier le code]

La toute première étude évaluant le nombre de bugs a été réalisée en 1971 par Akiyama[1]. Basé sur l'hypothèse qu'un code source complexe a la propension d'engendrer plus facilement des bugs, Akiyama construit un modèle simple en utilisant les Lignes de codes (LOC) qui représentent la complexité de ce code. Cependant, LOC est une métrique trop simpliste pour montrer la complexité globale d'un logiciel. Pour cette raison, McCabe et Halstead proposent un peu plus tard la complexité cyclomatique[2] représentant la complexité d'un logiciel par l'utilisation des graphes et les métriques Halstead[3] respectivement en 1976 et 1977. Ces nouvelles métriques ont été très utilisées pour la prédiction entre les années 70 et le début des années 80. Mais il est important de souligner que celles-ci ne sont pas à proprement parler des modèles pour prédire les erreurs mais plutôt pour évaluer le nombre d'erreurs apparentes[4]. Pour résoudre cette limitation des études antérieures, une étude propose un nouveau modèle de régression linéaire qui est testé sur les nouveaux modules de programme[5]. Cependant, l'état ​​de l'art des techniques de régression à l'époque n'était pas précis et il est proposé un modèle de classification catégorisant les modules en deux groupes : ceux considérés à haut risque et ceux considérés à faible risque[6]. Ce modèle de classification atteint 92 % de précision sur le système de réserve. Cependant, l'étude a encore plusieurs limites comme l'absence de métrique pour mesurer les systèmes orientés objet (OO) et peu de ressources pour extraire les données du processus de développement. En termes de systèmes OO, Chidamber et Kemerer ont proposé plusieurs métriques (dénommées CK) orientées objet en 1994[7].

Dans les années 90 avec l'apparition des systèmes de contrôle de versions de plus en plus populaires, l'historique du développement d'un logiciel est accumulé dans des dépôts logiciels. Ainsi, de nombreux travaux scientifiques émergent avec de nouvelles métriques[8][9][10][11][12][13][14].

Dans les années 2000, il existait encore plusieurs limitations pour la prédiction de bugs. La première limite était que le modèle de prédiction pourrait être utilisable juste avant la sortie du produit. Or, il est plus utile de prédire les bugs à chaque changement du code source. Pour rendre cela possible, Mockus et al. ont proposé un modèle de prédiction pour les modifications[15]. Récemment, ce type de modèle est appelé modèle de prédiction de bugs juste à temps (JIT). On trouve aujourd'hui de nombreux articles de la littérature scientifique qui étudient ces modèles[16][17][18].

La seconde limitation est qu'il n'est soit pas possible soit difficile de construire un modèle de prédiction de nouveaux projets ou des projets ayant un historique très peu fourni. Comme l'utilisation du data mining pour cette méthodologie est nécessaire afin d'explorer et d'extraire l'historique d'un logiciel de gestion de versions, cette limitation est devenue un des problèmes les plus difficiles à résoudre[19]. Les chercheurs ont alors proposé différents modèles de prédiction de bugs entre projets [20][21][22][23].

La troisième limitation repose sur la question "Comment les modèles de prédiction des défauts peuvent être utiles dans l'industrie ?". En ce sens, plusieurs études ont été menées pour proposer des applications pratiques[24][25][26].

Mesure pour l’évaluation[modifier | modifier le code]

Pour mesurer les résultats de prédiction de bugs, la plupart des algorithmes utilisent ce qu'on appelle des métriques. Ce sont des mesures qui définissent un ou plusieurs aspects des résultats d'une prédiction.

Mesure pour la classification[modifier | modifier le code]

Métriques utilisées[modifier | modifier le code]

Pour prédire les bugs en utilisant un modèle de classification, il faut considérer les métriques suivantes :

• Vrai positif (VP): Instances boguées détectées comme boguées

• Faux positif (FP): Instances non boguées détectées comme boguées

• Vrai négatif (VN): Instances non boguées détectées comme non boguées

• Faux négatif (FN): Instances boguées détectées comme non boguées

Avec ces métriques, il est possible de calculer les points suivants.

Ratio de faux positifs[modifier | modifier le code]

Le taux de faux positifs (TFP) est aussi connu comme la probabilité de fausse alarme (FA)[27]. La mesure FA indique combien de cas non bogués sont prédits comme bogués parmi tous les cas non bogués.

Exactitude[modifier | modifier le code]

L’exactitude considère les vrais positifs et vrais négatifs sur toutes les instances. En d'autres termes, l’exactitude montre le ratio de tous les cas classés correctement. Cependant, l’utilisation de l'exactitude n'a pas été recommandée pour la prédiction de bugs[28]. En effet l'exactitude n'est pas une mesure particulière dans la prédiction des bugs à cause notamment du déséquilibre de la classe d'ensembles de données de prédiction. Par exemple, le taux moyen d’exactitude des ensembles de données PROMISE évalué par Peters et al. est de 18%[29]. Si nous supposons un modèle de prédiction de données qui prédit toutes les instances comme non boguées, l’exactitude sera de 82% alors qu’aucune instance non boguée n'aura été correctement trouvée. Cela n'a pas de sens en terme de performance de prédiction de bugs.

Précision[modifier | modifier le code]

La précision exprime le taux d'instances non-boguées par rapport au nombre total d'instances non-boguées trouvées. Plus clairement, elle indique le taux d'instances non boguées correctement trouvées.

Rappel[modifier | modifier le code]

Le rappel est aussi connu comme la probabilité de détection (PD) ou taux de vrais positifs (TVP)[27]. Cette mesure prédit correctement les cas bogués entre toutes les instances boguées. C'est la mesure miroir à la précision, donc le rappel donne le taux d'instance boguées correctement trouvées.

F-Mesure[modifier | modifier le code]

La F-Mesure, ou F1 Score, combine la précision et le rappel afin d'obtenir une pondération. Plus simplement, la F-Mesure donne la moyenne d'instances correctement déterminées, c'est-à-dire d'instances effectivement boguées et non boguées. C'est une mesure très populaire dans le domaine de la prédiction de bugs[30][31][32][11][21].

AUC[modifier | modifier le code]

AUC mesure l'aire sous la courbe caractéristique d’efficacité du récepteur (ROC). Elle permet de déterminer l'efficacité du modèle de prédiction. Deux courbes sont tracées en utilisant le ratio de faux positifs en abscisse et le rappel en ordonnée. Ces deux valeurs varient en fonction du seuil de probabilité de prédiction de chaque instance classifiée. En changeant le seuil, nous pouvons tracer une courbe qui, lorsque le modèle s'améliore, tend à être proche du point rappel = 1 et ratio de faux positifs = 0[28].

AUCEC[modifier | modifier le code]

L'aire sous la courbe de coût-efficacité (AUCEC) est une mesure de prédiction de bugs considérant les lignes de code (LOC). L'idée du coût-efficacité pour les modèles de prédiction est proposé par Arisholm et al.[33]. Le coût-efficacité représente le nombre de bugs qui peuvent être trouvés parmi les de code inspecté ou testé avec LOC. En somme, si un certain modèle de prédiction peut trouver plus de bugs avec moins d'inspections et de tests comparativement à d'autres modèles, nous pourrions dire que le rapport coût-efficacité du modèle est plus élevé car il demande moins de calcul pour plus de résultats.


L'axe des abscisses représente le pourcentage de lignes de code tandis que l'axe des ordonnées représente le pourcentage de bugs constatés[14]. Dans la partie gauche de la figure, trois courbes d'exemple sont tracées. Les courbes O, P et R représentent respectivement les modèles optimaux, les modèles pratiques (modèles connaissant une implémentation) et les modèles aléatoires. Si nous considérons l'aire sous la courbe, le modèle optimal aura le plus haut AUCEC. Dans le cas du modèle aléatoire, l'AUCEC sera de 0,5[14].

Mesures pour la régression[modifier | modifier le code]

Pour mesurer les résultats de prédiction de bugs à partir de modèles de régression, des mesures fondées sur la corrélation entre le nombre de bugs réels et le nombre prévu de bugs ont été utilisés dans de nombreux articles du domaine de la prédiction de bugs[8][34][35][36]. Mais les trois mesures représentatives utilisées sont la corrélation de Spearman, la corrélation de Pearson, R² et leurs dérivées[8][34][35][36]. Par ailleurs, ces mesures ont été utilisées pour analyser la corrélation entre la valeur des métriques et le nombre de bugs détectés[36].

Métriques de prédiction de bugs[modifier | modifier le code]

Les métriques jouent le rôle le plus important pour construire un modèle de prédiction. La plupart des métriques de prédiction de bugs peuvent être classées en deux types :

  • les métriques de code sont directement collectées depuis le code source
  • les métriques de processus sont collectées à partir des informations archivées dans divers référentiels de logiciel tels que les gestionnaires de versions et les systèmes de suivi des problèmes (bugtrackers).

Métriques liées au code[modifier | modifier le code]

Les métriques de code sont aussi connues comme les métriques de produits mesurant la complexité du code source. L'hypothèse est que plus les codes sources sont complexes, plus ils sont sujets à produire des bugs.

Principales métriques de code
Métriques de code Size[1] Halstead[3] McCabe[2][37] CK [38][7] OO[39]
Lieu IFIPSC ’71 (Book) ’77 TSE ’76, ’96 TSE ’94,’96 JSS ’94

Les mesures concernant les métriques relatives à la taille du code sont "le volume, la longueur, la quantité et l'ampleur globale de produits logiciels"[40]. La représentation des métriques de taille est en lignes de code (LOC). C'est d'ailleurs le modèle d'Akiyama qui était la toute première étude à prédire les bugs en utilisant les lignes de code[1]. Ensuite, les lignes de code furent utilisées dans la plupart des documents traitant de la prédiction de bugs pour construire un modèle[41][42][11][27][43][44].

Puis Halstead a proposé plusieurs mesures de taille sur la base du nombre d'opérateurs et d'opérandes[3]. Ces mesures proposées sont le vocabulaire du programme, c'est-à-dire qu'elles symbolisent la longueur, le volume, la difficulté, l'effort et le temps d'exécution[3]. La plupart des métriques sont liées à la taille ou à la quantité. On retrouve de nombreuses utilisations des métriques d'Halstead dans la littérature. [27][44][38].

Dans le même temps, McCabe a proposé la métrique cyclomatique pour représenter la complexité des logiciels[2]. La métrique cyclomatique est calculée par le nombre de nœuds, d'arcs et des composantes connexes dans les graphes de flux d'exécution du logiciel à partir du code source. Cette métrique représente la façon dont les exécutions possibles sont complexes.

Depuis que la programmation orientée objet est devenu populaire, les métriques de code pour les langages orientés objet ont proposé d'améliorer le processus de développement. Les métriques représentatives des programmes orientés objet sont celles de Chidamber et Kemerer (appelées aussi dans la littérature les métriques CK)[45]. Les métriques CK ont été conçues à partir des caractéristiques des langages orientés objet tels que l'héritage, l'inter-dépendance des classes (ou coupling) et la cohésion[45].Basili et al.[7] ont déterminé s'il était possible de construire un modèle de prédiction de bugs en utilisant les métriques CK. Après cela, de nombreuses études ont inclus les métriques CK pour construire des modèles de prédiction [46] [41] [47] [48] [11] [39] [32].

Métriques OO[39]
Nom Description
WMC Méthodes "Wighted" par classe
DIT Profondeur de l'arborescence d'héritage
NOC Nombre d'enfants
CBO Couplage entre classes d'objets
RFC Réponse pour une classe
LCOM Le manque de cohésion dans les méthodes

Outre les métriques de CK, d'autres métriques orientées objet basées sur le volume et la quantité de code source ont été proposées[49]. Tout comme les métriques de taille, les métriques OO comptent simplement le nombre de variables d'instance, de méthodes, etc. comme indiqué dans le tableau ci-dessus. De nombreuses études de prédiction de bugs pour les programmes orientés objet ont utilisé différentes métriques OO pour construire des modèles de prédiction [41][48][11][39][32][50][36] .

Métriques de processus[modifier | modifier le code]

Le tableau "métriques de processus représentatifs" présente les sept métriques de processus les plus représentatives.

Métriques de processus représentatifs
Métriques de processus Nombre de métrique Source des métrique Lieu
Changement d'attrition du code[13] 8 Contrôle de version ICSE’05
Changement[51] 17 Contrôle de version ICSE’08
Changement d'entropie[10] 1 Contrôle de version ICSE’09
Métrique de code de désabonnement, entropie de code[52][41] 2 Contrôle de version MSR’09
Popularité[46] 5 Archives d'E-mail FASE’10
Propriété[53] 4 Contrôle de version FSE’11
Métriques d'interaction Micro[11] 56 Mylyn FSE’11

Attrition du code[modifier | modifier le code]

Nagappan et Ball[13] ont proposé huit métriques basées sur l'attrition entre les différentes versions du code (M1 - M8). Plus simplement, ces métriques mesurent la quantité de modifications (dans le sens de transformations c'est à dire qu'il n'y a ni ajout ni suppression) du code source[13]. Par exemple, la métrique M1 calcule le nombre cumulé de lignes supprimées et ajoutées entre une version de base et une nouvelle version d'un fichier source divisé par les lignes de code totales[13] .

Les autres métriques (M2 - M8) tiennent compte des divers changements tels que les lignes de codes supprimées divisé par le nombre total de lignes de codes, du nombre de fichiers modifiés dans un composant divisé par le nombre de fichiers le composant, et ainsi de suite[13]. Il a été prouvé que cette métrique est un bon indicateur pour expliquer la propension du code à provoquer des bugs selon sa densité[13] .

Changements[modifier | modifier le code]

Les métriques de changement servent à mesurer l'ampleur des changements dans l'historique enregistré dans les systèmes de contrôle de versions. Par exemple, nous pouvons compter le nombre de révisions, de bugs-fixs ou le refractoring ou le nombre d'auteurs qui ont participé à l'édition d'un fichier. Par exemple Moser et al.[51] dans leurs papiers extraient 18 métriques de changement dans les dépôts d'Eclipse afin de procéder à une analyse comparative entre le code et la variation des valeurs de ces métriques.

Toutefois, les métriques de changement ne considèrent pas la relation entre les lignes de code totales et le nombre de fichiers, mais tiennent compte des valeurs moyennes et maximales des métriques changement. Ces mesures prennent en compte également la valeur maximale et la valeur moyenne du nombre de changements de l'ensemble, c'est à dire le nombre de fichiers commités ensemble. Par ailleurs, ils prennent en compte les mesures d'âge d'un fichier au cours des semaines et l'âge pondéré par les lignes de code ajoutées[51]. Ils conclurent que les métriques de changement font partie des meilleurs prédicateurs que les métriques de code[51].

Changement d'entropie[modifier | modifier le code]

Le changement d'entropie dans le domaine de la prédiction de bugs consistent à comprendre comment la complexité de l'historique logiciel évolue. Pour cela on applique l'entropie de Shannon en proposant des métriques d'histoire complexes (HCM)[10].

Pour valider le HCM, deux modèles ont été construits afin de réaliser une étude comparative. Le première modèle est un modèle de régression linéaire statistique fondé sur HCM le second est un modèle se basant sur deux métriques de changement étant respectivement le nombre de modifications précédentes et le nombre de bugs trouvés précédemment. Il utilise comme dataset un ensemble de données composé de six projets open-source[10]. L'évaluation sur ces six projets open-source a démontré que les modèles de prédiction construits à l'aide de HCM surpassent ceux qui utilisent les deux métriques de changement[10].

Attrition du code généralisée et entropie de code[modifier | modifier le code]

Une étude approfondie des comparaisons de mesures de prédiction de bugs[52] a proposé des métriques du code généralisées (CHU) et l'entropie de code (HH). À la différence des métriques de changement de code qui se basent sur LOC, CHU mesure la variation de métriques de code telles que les métriques CK et les métriques OO sur plusieurs périodes de deux semaines. Pour être plus clair, CHU calcule la quantité de changements toutes les deux semaines. Il existe aussi quatre variantes de CHU qui appliquent pour chacune d'elle une fonction de décroissance différentes (WCHU , LDCHU , EDCHU et LGDCHU).

Tandis que le changement d'entropie est calculé sur la base du nombre de changements de fichiers, l'entropie de code (HH) est calculée sur la base du nombre de fichiers concernés quand la valeur d'une métrique de code est changée. Tout comme le CHU, il existe également quatre variantes de HH en appliquant des fonctions de décroissance (HWH, LDHH, EDHH et LGDHH). Pour l'évaluation des métriques WCHU et LDHH ont conduit à de bons résultats de prédiction sur tous les sujets utilisés dans leurs expériences. Cependant, ces nouvelles métriques demandent des ressources de calcul et d'espace de données importantes car pour les déterminer il faut suivre l'évolution du logiciel à n'importe quel moment pour évaluer les variations toutes les deux semaines.

Popularité[modifier | modifier le code]

Bacchelli et al. ont proposé des métriques de popularité en analysant les archives e-mail des développeurs dans une liste de diffusion du groupe[46]. Le tableau "Métriques de popularité" énumère les métriques de popularité. La plupart d'entre elles quantifient combien de fois une certaine classe est discutée dans les e-mails.

Métriques de popularité[44]
Nom Description
POP-NOM Le nombre de mails discutant d'une classe
POP-NOCM Le nombre de caractères dans tous les courriers discutant d'une classe
POP-NOT Le nombre de fils de discussion traitant de sujets différents pour une classe
POP-NOMT Le nombre de mails dans un fil de discussion discutant d'une classe contenant au moins un mail
POP-NOA Le nombre d'auteurs mentionnant la même classe

Propriété et droit d'auteur[modifier | modifier le code]

Bird et al. ont proposé quatre métriques basées sur la propriété du droit d'auteur d'un composant logiciel[53]. Cette étude s'est lancée à partir de la question : Comment la propriété affecte la qualité ? Quatre paramètres de propriété sont définis :

  1. MINEUR : le nombre de contributeurs mineurs
  2. MAJEUR : le nombre de principaux contributeurs
  3. TOTAL : le nombre total de contributeurs
  4. PROPRIÉTÉ : partie de la propriété du donateur sur la plus grande partie de la propriété (équivalent au LOC du contributeur sur LOC du plus gros contributeur)

Ils ont conclu qu'une propriété plus élevée conduit à moins de bugs. Une enquête menée sur la relation entre les bugs et les facteurs humains tels que la propriété et l'expérience du développeur[54] démontre que la qualité du code devrait être axée sur les fichiers de code source écrits par les développeurs les moins expérimentés.

Interaction Micro[modifier | modifier le code]

La métrique d'interaction Micro (MIM) extraite de Mylyn capture les interactions de développement d'Eclipse[11]. L'idée principale de MIM est le fait que les bugs peuvent être introduits par une erreur des développeurs. Par exemple, plus le temps passé à éditer un certain fichier de code source est long, plus celui-ci peut contenir de bugs[11].

Dans leurs expériences, MIM a surpassé les métriques de code à la fois pour la classification et la régression[11]. Cependant, MIM est fortement tributaire de Mylyn qui est un plug-in d'Eclipse. C'est pour cette raison que MIM pourrait être difficile à appliquer sur d'autres environnements de développement qui ne prennent pas forcément en charge d'outils comme Mylyn.

Autres métriques[modifier | modifier le code]

En dehors des métriques de code et de processus, des chercheurs ont proposé de nouveaux types de mesures basées sur les connaissances existantes telles que les métriques de réseau[55][56][36] et anti-modèles[57].

Les métriques de réseau sont extraites à partir d'un réseau social de développeurs en récupérant le code source stocké dans des dépôts pour extraire une structure caractérisant la collaboration entre plusieurs développeurs[55]. Sur cette base, l'étude a révélé que l'échec d'un logiciel est fortement corrélé avec le réseau d'un développeur[55].

Une autre façon de procéder est d'utiliser un réseau de développeurs pour le relier à des modules logiciels[56]. Ce réseau représente la façon dont chaque développeur contribue à chaque module et est appelé « réseau de contribution ». Il a été constaté que ces mesures permettent de prédire de façon significative les bugs post-release.

Pour les métriques d'anti-modèles, Taba et al. proposent quatre métriques[57] car cette façon de concevoir un logiciel a plus de chances d'introduire des bugs dans les fichiers de code source[57]. Dans leur évaluation avec deux projets open source, les mesures anti-modèles pourraient améliorer les performances de prédiction en termes de F-mesure[57].

Comparaison entre les métriques de code et de processus[modifier | modifier le code]

La figure 4 montre la fréquence d'utilisation des métriques dans les documents représentatifs de la prédiction de bugs. Les métriques de code telles que les métriques taille, d'Hastead, de McCabe, CK et métriques OO ont été utilisées à partir des années 1970 jusque fin des années 90. De ce fait la fréquence d'utilisation des métriques de code est supérieure à celle des métriques de processus qui ne sont apparues qu'au début des années 2000.

Il y a beaucoup de débats pour savoir si les métriques de code sont de bons prédicteurs de bugs comparés aux métriques de processus et vice versa. Menzies et al. ont confirmé que les métriques de code sont toujours utiles pour construire un modèle de prédiction de bugs[27]. Toutefois, selon de récentes études comparatives réalisées par Rahman et al., les métriques de code sont moins utiles que les métriques de processus du fait de la stagnation des valeurs à partir d'un moment donné[30].

Modèles de prédiction de bugs[modifier | modifier le code]

La figure 5 montre la fréquence d'utilisation de modèles de prédiction de bugs dans les documents représentatifs de prédiction de bugs. Comme les modèles statistiques basés sur les machines d'apprentissage ont été étudiés pendant une longue période, les modèles de classification et de régression sont les modèles dominants. Kim et al. ont proposé le BugCache[58] et il existe un nombre d'études enquêtant sur le modèles BugCache ainsi que des études de cas[24][25][14].

La différence entre les modèles de classification et de régression est ce qu'ils doivent prévoir. Les modèles de classification identifient généralement les prédispositions aux bugs[27][12][19] tandis que les modèles de régression prédisent le nombre de bugs[13][59][36]. La réponse à la question « Quel modèle devrait être utilisé pour assurer la qualité d'un logiciel ? » est dépendant du but du logiciel.

La figure 6 montre la fréquence d'utilisation des machines d'apprentissage dans la littérature scientifique. Les réseaux bayésiens naïfs et les arbres de décision sont aussi fréquemment utilisés dans la littérature scientifique. En termes de machines d'apprentissage, les modèles de régression, les modèles de régression linéaire et le modèle binomial négatif ont été principalement utilisés dans la littérature [53][41][47][11][60][35][61].

Comme de nouvelles approches de machines d'apprentissage telles que l'apprentissage actif ou semi-supervisé ont été proposées afin d'adopter ces approches pour la prédiction de bugs. Lu et Cukic[62] ont proposé des modèles de prédiction de bugs fondés sur l'apprentissage actif où un ensemble d'instances échantillon est sélectionné et un oracle (qui est un homme et non un programme) décide si les instances pourraient être une bonne série pour entrainer le système. Li et al. ont proposé CoFest et ACoFest [62]. CoFest est une approche d'échantillonnage basée sur l'apprentissage semi-supervisé pour la prédiction évaluant à plusieurs reprises un échantillon aléatoire à travers une forêt d'arbres décisionnels pour trouver le meilleur échantillon. ACoFest est une version étendue de CoFest en appliquant l'apprentissage actif[62].

Kim et al. ont proposé BugCache qui maintient la priorité des entités sujettes aux bugs dans un cache[58]. L'évaluation sur sept projets open source indique que 10% des dossiers possèdent 73% à 95% du nombre total de bugs. Le BugCache facilite la détermination des informations de localisation des bugs tels que la localité spatiale ou temporelle.

Granularité[modifier | modifier le code]

Dans la littérature, les modèles de prédiction de bugs ont été construits selon différents niveaux de granularité tels que :

Une étude récente[42] propose une prédiction des bugs au niveau de la méthode. Cette recherche démontre que la prédiction au niveau de la méthode est plus intéressante en terme de coût-efficacité que d'autres niveaux de granularité supérieurs comme celui au niveau package ou de fichier.

Kim et al. proposent un modèle de prédiction basé sur les changements logiciels[18]. À la différence des autres modèles de prédiction, ce type modèle est particulièrement utile pour les développeurs car celui-ci peut retourner une prédiction instantanément à chaque fois qu'un développeur commite un changement sur le code source dans le dépôt logiciel[18]. Dans la pratique, ce type de modèles n'est pas très efficace car il doit reconstruire à chaque commit le logiciel qui peut parfois comporter plusieurs milliers de fonctionnalités[18].

En somme, pour utiliser des modèles de prédiction, l'aspect coût-efficacité doit être considéré[28][14]. Une des façons d'améliorer la rentabilité des modèles est d'effectuer les prédictions dans les niveaux les plus fins[42].

Prétraitement pour les jeux de données de bugs[modifier | modifier le code]

Le prétraitement est une étape largement utilisée dans le domaine de l'apprentissage automatique. Il existe plusieurs études utilisant des techniques de prétraitement[48][27][21][67][32]. Selon chaque étude, les techniques de prétraitement sont utilisées de manière sélective ou non. Ce choix dépend grandement des mesures, modèles et sujets considérés.

Normalisation[modifier | modifier le code]

La normalisation est une technique courante pour donner un même poids aux valeurs des métriques dans le but améliorer les performances des modèles de prédiction[68][69]. Il est recommandé d'utiliser le filtre logarithmique (log-filtre) pour normaliser les valeurs métriques[27] pour les mesures possédant une distribution exponentielle. D'autres études utilisant les mêmes sujets expérimentaux appliquent le filtre logarithmique[27][22][70].

Il a été observé que la performance de prédiction varie selon les différentes techniques de normalisation[21]. Des règles ont d'ailleurs été définies pour la sélection appropriée de techniques de normalisation telles que la normalisation min-max, z-score et les variations de z-score afin d'améliorer la performance des prédictions[21].

Fonctionnalités de sélection et d'extraction[modifier | modifier le code]

Certains chercheurs ont souligné que la mauvaise performance des modèles de prédiction est due à un certain nombre de mesures utilisées pour construire les modèles[67]. Pour cette raison, il est utile d'utiliser une technique de sélection qui peut améliorer la classification lors de l'apprentissage[67]. Par exemple, il est possible d'appliquer une sélection de sous-ensembles en utilisant des informations obtenues avant toute prédiction de bugs[22]. Puisque les ensembles de données de prédiction des bugs peuvent avoir le problème de multicolinéarité, les chercheurs appliquent une analyse en composantes principales (ACP) afin d'extraire de nouvelles fonctionnalités pour les modèles de prédiction[52][13][36].

Réduction du bruit[modifier | modifier le code]

Les données de bugs sont généralement recueillies au sein d'un logiciel de gestion de contrôle de versions ou de bugtrackers en utilisant des outils ou des algorithmes[71][72]. Ces données peuvent être biaisées comme le montre l'étude de Bird et al.[73]. Pour réduire le bruit, une équipe de chercheurs a mis en place RELINK, un logiciel capable de récupérer automatiquement les liens corrects entre les journaux des commits et les identifiants des problèmes (ou issues en anglais)[32]. Par ailleurs, il existe un algorithme de détection de bruit et d'élimination appelé Closest List Noise Identification (CLNI)[48].

Prédiction cross-projet[modifier | modifier le code]

Sur des nouveaux projets de logiciels, il n'est pas rare que ceux-ci ne possèdent pas assez d'échantillons d'entrainement pour construire un bon modèle de prédiction. Pour cela, il est possible de croiser certaines données entre des projets logiciels similaires. Pour améliorer les performances de prédictions croisées, des chercheurs se sont concentrés sur des études basées sur l'apprentissage de transfert.

Apprentissage par transfert[modifier | modifier le code]

L'apprentissage automatique traditionnel suppose que la distribution des échantillons d'entrainement sont les mêmes. Ainsi, dans le cas où la distribution a changé, il est nécessaire de reconstituer le modèle avec des données nouvellement collectées. Toutefois, la collecte de nouvelles données et leurs étiquetages est coûteux[74]. Pour cette raison, les chercheurs ont mis l'accent sur l'apprentissage de transfert où nous pouvons transférer les connaissances d'un domaine avec beaucoup d'échantillons d'entrainements à un autre domaine qui en comporte peu.

Métrique de compensation[modifier | modifier le code]

L'idée principale est de normaliser chaque valeur métrique des données de cible en utilisant la valeur moyenne des autres métriques qui trouve une correspondance[23].

Filtre NN[modifier | modifier le code]

L'idée fondamentale du filtre NN (nommé aussi filtre du plus proche voisin) est de recueillir des instances de sources similaires pour former un modèle de détection. En d'autres termes, il construit un modèle utilisant des instances de sources possédant des caractéristiques similaires. Ainsi le modèle peut effectuer de meilleures prédictions par rapport à un autre modèle utilisant toutes les instances de sources à sa disposition dans le référentiel logiciel d'origine[22].

Transfert Bayésien naïf[modifier | modifier le code]

Le transfert bayésien naïf (TNB) a pour but de calculer une valeur de poids d'une instance source. Le poids de l'instance source est calculée en fonction de la similitude entre l'instance source et les instances de cibles[20].

La première étape consiste à calculer la similarité entre l'instance source et chaque instance cible. La similitude est calculée via le nombre de caractéristiques d'une instance source en fonction du nombre de caractéristiques de la cible correspondante. Ensuite, l'ensemble des valeurs de similitude est regroupé pour calculer une valeur de poids en utilisant la loi universelle de la gravitation de Newton[20]. Enfin, le modèle TNB est recalculé avec de nouvelles probabilités qui utilisent les poids pour les instances de sources.

TCA +[modifier | modifier le code]

TCA+ [21] est une version étendue de l'analyse des composants de transfert (TCA) qui est un algorithme d'apprentissage de transfert proposé par Pan et al.[74]. TCA essaie de trouver un espace où la distribution des ensembles de données source et cible sont semblables en utilisant la projection. La projection est une technique d'extraction de caractéristiques pour réduire l'espace d'apprentissage.

Faisabilité[modifier | modifier le code]

Il existe peu d'études sur la faisabilité sur ce sujet[19][75]. Des tentatives pour valider cette approche ont mené plusieurs chercheurs à construire un arbre de décision en utilisant les caractéristiques d'un projet telles que les langages de programmation utilisés ou le nombre de développeurs[19].

Notes et références[modifier | modifier le code]

  1. ↑ a b et c F. Akiyama, « An Example of Software System Debugging », Proceedings of the International Federation of Information Processing Societies Congress,‎ , p. 353–359
  2. ↑ a b et c T. McCabe, « A complexity measure », IEEE Transactions on Software Engineering, no 2,‎ , p. 308-320 (lire en ligne)
  3. ↑ a b c et d M. H. Halstead, « Elements of Software Science (Operating and Programming Systems Series) », Elsevier Science Inc., New York, NY, USA,‎
  4. ↑ N. Fenton and M. Neil, « A critique of software defect prediction models », EEE Transactions on Software Engineering, no 3,‎ , p. 675-689 (lire en ligne)
  5. ↑ V. Y. Shen, T.-J. Yu, S. M. Thebaut, and L. R. Paulsen, « Identifying error-prone software an empirical study », IEEE Transactions on Software Engineering,‎ , p. 317-324
  6. ↑ J. C. Munson and T. M. Khoshgoftaar, « The detection of fault-prone programs », IEEE Transactions on Software Engineering,‎ , p. 423-433 (ISSN 0098-5589)
  7. ↑ a b et c V. R. Basili, L. C. Briand, and W. L. Melo, « A validation of object-oriented design metrics as quality indicators », IEEE Transactions on Software Engineering, no 22,‎ , p. 751-761
  8. ↑ a b et c A. Bacchelli, M. D’Ambros, and M. Lanza, « Are popular classes more defect prone ? », Proceedings of the 13th International Conference on Fundamental Approaches to Software Engineering, no 10,‎ , p. 59-73
  9. ↑ C. Bird, N. Nagappan, B. Murphy, H. Gall, and P. Devanbu, « Don’t touch my code ! : Examining the effects of ownership on software quality. », Proceedings of the 19th ACM SIGSOFT Symposium and the 13th European Conference on Foundations of Software Engineering, no 11,‎ , p. 4-14
  10. ↑ a b c d e et f A. E. Hassan, « Predicting faults using the complexity of code changes », Proceedings of the 31st International Conference on Software Engineering,‎ , p. 78-88 (ISSN 0270-5257)
  11. ↑ a b c d e f g h i et j T. Lee, J. Nam, D. Han, S. Kim, and I. P. Hoh, « Micro interaction metrics for defect prediction », SIGSOFT ’11/FSE-19: Proceedings of the 16th ACM SIGSOFT International Symposium on Foundations of software engineering,‎ , p. 311-321
  12. ↑ a et b R. Moser, W. Pedrycz, and G. Succi, « A comparative analysis of the efficiency of change metrics and static code attributes for defect prediction », Proceedings of the 30th international conference on Software engineering,‎ , p. 181-190
  13. ↑ a b c d e f g h i et j N. Nagappan and T. Ball, « Use of relative code churn measures to predict system defect density », Proceedings of the 27th international conference on Software engineering, no ICSE ’05,‎ , p. 284-292 (lire en ligne)
  14. ↑ a b c d et e F. Rahman, D. Posnett, A. Hindle, E. Barr, and P. Devanbu, « Bugcache for inspections : Hit or miss ? », Proceedings of the 19th ACM SIGSOFT Symposium and the 13th European Conference on Foundations of Software Engineering, no ESEC/FSE’11,‎ , p. 322-331
  15. ↑ A. Mockus and L. G. Votta, « Identifying reasons for software changes using historic databases », Proceedings of the International Conference on Software Maintenance,‎ , p. 120-130 (ISSN 1063-6773, lire en ligne)
  16. ↑ T. Fukushima, Y. Kamei, S. McIntosh, K. Yamashita, and N. Ubayashi, « An empirical study of just-in-time defect prediction using cross-project models », Proceedings of the 11th Working Conference on Mining Software Repositories, no MSR 2014,‎ , p. 172-181 (lire en ligne)
  17. ↑ Y. Kamei, E. Shihab, B. Adams, A. E. Hassan, A. Mockus, A. Sinha, and N. Ubayashi, « A large-scale empirical study of just-in-time quality assurance », IEEE Transactions on Software Engineering,‎ , p. 757-773 (ISSN 0098-5589)
  18. ↑ a b c d et e S. Kim, E. J. Whitehead, Jr., and Y. Zhang, « Classifying software changes : Clean or buggy ? », IEEE Transactions on Software Engineering,‎ , p. 181-196 (ISSN 0098-5589)
  19. ↑ a b c d et e T. Zimmermann, N. Nagappan, H. Gall, E. Giger, and B. Murphy, « Cross-project defect prediction: a large scale experiment on data vs. domain vs. process », Proceedings of the the 7th joint meeting of the European software engineering conference and the ACM SIGSOFT symposium on The foundations of software engineering, no ESEC/FSE ’09,‎ , p. 91-100
  20. ↑ a b c et d Y. Ma, G. Luo, X. Zeng, and A. Chen, « Transfer learning for cross-company software defect prediction », Information and Software Technology,‎ , p. 248-256
  21. ↑ a b c d e f et g J. Nam, S. J. Pan, and S. Kim, « Transfer defect learning », Proceedings of the 2013 International Conference on Software Engineering, no ICSE ’13,‎ , p. 382-391 (lire en ligne)
  22. ↑ a b c et d B. Turhan, T. Menzies, A. B. Bener, and J. Di Stefano, « On the relative value of cross-company and within-company data for defect prediction », Empirical Software Engineering,‎ , p. 540-578 (lire en ligne)
  23. ↑ a et b S. Watanabe, H. Kaiya, and K. Kaijiri, « Adapting a fault prediction model to allow inter language reuse », Proceedings of the 4th international workshop on Predictor models in software engineering, no PROMISE ’08,‎ , p. 19-24 (lire en ligne)
  24. ↑ a et b E. Engström, P. Runeson, G. Wikstrand, « An Empirical Evaluation of Regression Testing Based on Fix-Cache Recommendations », Software Testing, Verification and Validation (ICST),‎ , p. 75-78 (lire en ligne)
  25. ↑ a et b C. Lewis, Z. Lin, C. Sadowski, X. Zhu, R. Ou, and E. J. W. Jr, « Does bug prediction support human developers ? Findings from a Google case study », Proceedings of the 2013 International Conference on Software Engineering, no ICSE '13,‎ , p. 372-381 (lire en ligne)
  26. ↑ F. Rahman and P. Devanbu, « Comparing static bug finders and statistical prediction », Proceedings of the 2014 International Conference on Software Engineering, no ICSE ’14,‎ , p. 424-434 (lire en ligne)
  27. ↑ a b c d e f g h i et j T. Menzies, J. Greenwald, and A. Frank, « Data mining static code attributes to learn defect predictors », IEEE Transactions on Software Engineering,‎ , p. 2-13 (ISSN 0098-5589)
  28. ↑ a b et c F. Rahman, D. Posnett, and P. Devanbu, « Recalling the ”imprecision” of cross-project defect prediction », Proceedings of the ACM SIGSOFT 20th International Symposium on the Foundations of Software Engineering, no FSE '12,‎ (lire en ligne)
  29. ↑ F. Peters and T. Menzies, « Privacy and utility for defect prediction: Experiments with morph », Proceedings of the 34th International Conference on Software Engineering, no ICSE ’12,‎ , p. 189-199 (ISSN 0270-5257, lire en ligne)
  30. ↑ a et b S. Kim, H. Zhang, R. Wu, and L. Gong, « Dealing with noise in defect prediction », Proceeding of the 33rd international conference on Software engineering, no ICSE ’11,‎ , p. 481-490 (lire en ligne)
  31. ↑ F. Rahman and P. Devanbu, « How, and why, process metrics are better », Proceedings of the 2013 International Conference on Software Engineering, no ICSE ’13,‎ , p. 432-441 (lire en ligne)
  32. ↑ E. Arisholm, L. C. Briand, and M. Fuglerud, « Data mining techniques for building fault-proneness models in telecom java software », Proceedings of the The 18th IEEE International Symposium on Software Reliability, no ISSRE ’07,‎ , p. 215-224 (ISSN 1071-9458, lire en ligne)
  33. ↑ a et b N. Nagappan, T. Ball, and A. Zeller, « Mining metrics to predict component failures », Proceedings of the 28th international conference on Software engineering, no ICSE ’06,‎ , p. 452-461 (lire en ligne)
  34. ↑ a b et c Y. Shin, A. Meneely, L. Williams, and J. Osborne, « Evaluating complexity, code churn, and developer activity metrics as indicators of software vulnerabilities », IEEE Transactions on Software Engineering,‎ , p. 772-787 (ISSN 0098-5589, lire en ligne)
  35. ↑ a b c d e f g et h T. Zimmermann and N. Nagappan, « Predicting defects using network analysis on dependency graphs », Proceedings of the 30th international conference on Software engineering, no ICSE ’08,‎ , p. 531-540 (ISSN 0270-5257)
  36. ↑ N. Ohlsson and H. Alberg, « Predicting fault-prone software modules in telephone switches », IEEE Transactions on Software Engineering,‎ , p. 886-894 (ISSN 0098-5589)
  37. ↑ a et b (en) B. Turhan, T. Menzies, A. B. Bener, and J. Di Stefano., « On the relative value of cross-company and within-company data for defect prediction. », Empirical Softw. Eng.,‎ (lire en ligne)
  38. ↑ a b c et d (en) YG. Pai and J. Bechta Dugan., « Empirical Analysis of Software Fault Content and Fault Proneness Using Bayesian Methods », Software Engineering, IEEE Transactions on, 33(10):675–686,‎ (lire en ligne)
  39. ↑ (en) S. D. Conte, H. E. Dunsmore, and V. Y. Shen., « Software engineering metrics and models », Benjamin-Cummings Publishing Co., Inc., Redwood City, CA, USA,,‎ (lire en ligne)
  40. ↑ a b c d et e (en) M. D’Ambros, M. Lanza, and R. Robbes., « Evaluating defect prediction approaches: a benchmark and an extensive comparison », Empirical Softw. Engg.,‎ (lire en ligne)
  41. ↑ a b c et d (en) H. Hata, O. Mizuno, and T. Kikuno., « Bug prediction based on fine-grained module histories », Software Engineering(ICSE), 2012 34th International Conference,‎ (lire en ligne)
  42. ↑ (en) E. Shihab, A. Mockus, Y. Kamei, B. Adams, and A. E. Hassan., « High-impact defects: a study of breakage and surprise defects », Proceedings of the 19th ACM SIGSOFT symposium and the 13th European conference on Foundations of software engineering,,‎ (lire en ligne)
  43. ↑ a b et c (en) Q. Song, Z. Jia, M. Shepperd, S. Ying, and J. Liu., « A general software defect-proneness prediction framework », Software Engineering, IEEE Transactions,‎ (lire en ligne)
  44. ↑ a et b (en) BS. R. Chidamber and C. F. Kemerer., « A metrics suite for object oriented design. », IEEE Trans. Softw. Eng., 20:476–493,‎ (lire en ligne)
  45. ↑ a et b (en) Y. Kamei, S. Matsumoto, A. Monden, K.-i. Matsumoto, B. Adams, and A. E. Hassan., « Revisiting common bug prediction findings using effort-aware models », In Proceedings of the 2010 IEEE International Conference on Software Maintenance,‎ (lire en ligne)
  46. ↑ a b c et d Dealing with noise in defect prediction. In Proceeding of the 33rd international conference on Software engineering
  47. ↑ (en) F. B. e Abreu et R. Carapua., « Candidate metrics for object-oriented software within a taxonomy framework », Journal of Systems and Software, 26(1):87 – 96,,‎ (lire en ligne)
  48. ↑ (en) H. Zhang and R. Wu., « Sampling program quality », In Software Maintenance (ICSM), 2010 IEEE International Conference,‎ (lire en ligne)
  49. ↑ a b c et d (en) R. Moser, W. Pedrycz, and G. Succi., « A comparative analysis of the efficiency of change metrics and static code attributes for defect prediction », In Proceedings of the 30th international conference on Software engineering, ICSE ’08,,‎ (lire en ligne)
  50. ↑ a b et c (en) M. D’Ambros, M. Lanza, and R. Robbes., « An Extensive Comparison of Bug Prediction Approaches », In Mining Software Repositories (MSR), 7th IEEE Working Conference,‎ (lire en ligne)
  51. ↑ a b et c (en) C. Bird, N. Nagappan, B. Murphy, H. Gall, et P. Devanbu., « Don't touch my code!: examining the effects of ownership on software quality », In Proceedings of the 19th ACM SIGSOFT Symposium and the 13th European Conference on Foundations of Software Engineering, ESEC/FSE,‎ (lire en ligne)
  52. ↑ (en) F. Rahman and P. Devanbu., « Ownership, experience and defects: a fine-grained study of authorship », Proceedings of the 33rd International Conference on Software Engineering, ICSE,‎ (lire en ligne)
  53. ↑ a b et c (en) A. Meneely, L. Williams, W. Snipes, and J. Osborne., « Predicting Failures with Developer Networks and Social Network Analysis », In SIGSOFT ’08/FSE-16: Proceedings of the 16th ACM SIGSOFT International Symposium on Foundations of software engineering,,‎ (lire en ligne)
  54. ↑ a et b (en) M. Pinzger, N. Nagappan, and B. Murphy., « Can developer-module networks predict failures? », In Proceedings of the 16th ACM SIGSOFT International Symposium on Foundations of software engineering,,‎ (lire en ligne)
  55. ↑ a b c et d (en) S. E. S. Taba, F. Khomh, Y. Zou, A. E. Hassan, and M. Nagappan., « Predicting Bugs Using Antipatterns », In ICSM,,‎ (lire en ligne)
  56. ↑ a et b (en) S. Kim, T. Zimmermann, E. J. Whitehead Jr., et A. Zeller.., « Predicting Faults from Cached History », In Proceedings of the 29th international conference on Software Engineering, ICSE ’07,‎ (lire en ligne)
  57. ↑ (en) N. Nagappan and T. Ball., « Static analysis tools as early indicators of pre-release defect density. », In Proceedings of the 27th international conference on Software engineering, ICSE ’05,,‎ (lire en ligne)
  58. ↑ a et b (en) T. J. Ostrand, E. J. Weyuker, and R. M. Bell., « Predicting the location and number of faults in large software systems », IEEE Trans. Softw. Eng., 31:340–355,‎ (lire en ligne)
  59. ↑ (en) E. Weyuker, T. Ostrand, and R. Bell., « Does Measuring Code Change Improve Fault Prediction? », Empirical Software Engineering, 15(3):277–295,,‎ (lire en ligne)
  60. ↑ a b et c (en) H. Lu et B. Cukic., « An adaptive approach with active learning in software fault prediction », In Proceedings of the 8th International Conference on Predictive Models in Software Engineering, PROMISE ’12,,,‎ (lire en ligne)
  61. ↑ N. Fenton, M. Neil, W. Marsh, P. Hearty, . Radliski, and P. Krause, « On the effectiveness of early life cycle defect prediction with bayesian nets », Empirical Software Engineering,‎ , p. 499-537
  62. ↑ « Transparent combination of expert and measurement data for defect prediction : an industrial case study », Proceedings of the 32nd ACM/IEEE International Conference on Software Engineering - Volume 2, no ICSE ’10,‎ , p. 119-128 (ISSN 0270-5257, lire en ligne)
  63. ↑ « Benchmarking classification models for software defect prediction : A proposed framework and novel findings », IEEE Transactions on Software Engineering,‎ , p. 485-496 (ISSN 0098-5589)
  64. ↑ « Method-level bug prediction », Proceedings of the ACM-IEEE International Symposium on Empirical Software Engineering and Measurement, no ESEM ’12,‎ , p. 171-180
  65. ↑ a b et c S. Shivaji, E. Whitehead, R. Akella, and S. Kim, « Reducing features to improve code change-based bug prediction », IEEE Transactions on Software Engineering,‎ , p. 552-569 (ISSN 0098-5589, lire en ligne)
  66. ↑ J. Han, M. Kamber, and J. Pei, Data mining : concepts and techniques
  67. ↑ A. B. A. Graf and S. Borer, « Normalization in support vector machines », in Proc. DAGM 2001 Pattern Recognition,‎ , p. 277-282 (lire en ligne)
  68. ↑ B. Turhan, A. T. Msrl, and A. Bener, « Empirical evaluation of the effects of mixed project data on learning defect predictors », Information and Software Technology,‎ , p. 1101-1118
  69. ↑ S. Kim, T. Zimmermann, K. Pan, and E. J. J. Whitehead, « Automatic identification of bug-introducing changes », Proceedings of the 21st IEEE/ACM International Conference on Automated Software Engineering, no ASE '06,‎ , p. 81-90 (lire en ligne)
  70. ↑ « When do changes induce fixes ? », Proceedings of the 2005 international workshop on Mining software repositories, no MSR '05,‎ , p. 1-5 (lire en ligne)
  71. ↑ C. Bird, A. Bachmann, E. Aune, J. Duffy, A. Bernstein, V. Filkov, and P. Devanbu. Fair and Balanced, « Fair and Balanced ? Bias in Bug-Fix Datasets », ESEC, no FSE '09,‎ , p. 121-130 (lire en ligne)
  72. ↑ a et b S. J. Pan and Q. Yang, « A survey on transfer learning », IEEE Transactions on Knowledge and Data Engineering,‎ , p. 1345-1359 (ISSN 1041-4347, lire en ligne)
  73. ↑ Z. He, F. Shu, Y. Yang, M. Li, and Q. Wang, « An investigation on the feasibility of cross-project defect prediction », Automated Software Engineering,‎ , p. 167-199


Annexes[modifier | modifier le code]

Articles connexes[modifier | modifier le code]

Liens externes[modifier | modifier le code]

Ce document provient de « https://fr.wikipedia.org/w/index.php?title=Utilisateur:Ozzerz/Brouillon&oldid=162724839 ».