Buginfo est un outil open source permettant de faire de la fouille de données sur les bogues dans les répertoires logiciels (SVN et CYS). Il permet d’identifier les classes ayant été affectées par des bogues. Il fonctionne de façon relativement simple. L’idée est de se connecter à un VCS et d’analyser la description des commits pour identifier les corrections de bogues et d’extraire les informations sur les modifications du code (patchs) associées à ces dernières. On peut distinguer deux étapes pour chaque commit examiné :

1. Reconnaissance du bogue: Cela est fait par analyse textuelle dans les descriptifs des soumissions (commits) en utilisant une expression régulière (E) donnée en paramètre. Ce motif couvre des termes particuliers fréquemment utilisés pour décrire la correction d’un bogue. Ces termes dépendent du nom du projet et/ou du ITS qu’il utilise. Par exemple, pour le projet apache ANT qui utilise Bugzilla, les commits correspondant à des corrections de bogues vont contenir le mot « bugfix }) ou « bugzilla }) (sans respect de la casse). Dans ce cas, notre expression régulière ressemblera
à:  E = . * (([bB][ u U][gG][ fF][iI][xX]) 1 ([bB][ uU][gG][zZ][iI][IL][IL][ aA])). *

2. Extraction d’information: Une fois qu’ un commit a été identifié comme étant la correction d’un bogue, les informations additionnelles du patch vont être utilisées pour connaître les classes concernées par le bogue. Pour ce faire, trois paramètres permettant d’identifier le nom complet d’un fichier source vont être utilisés.

• L’extension du fichier qui permet d’identifier les fichiers correspondants aux classes, par exemple .java pour le code écrit en JAVA
• La racine du dossier principal
• Le séparateur de dossier (/ par défaut).

Ces trois paramètres vont servir à identifier, parmi tous les fichiers ayant subi des modifications pour la correction du bogue, ceux qui correspondent à des fichiers de code source. Les fichiers ainsi retenus vont être considérés comme contenant des classes défectueuses et leur compteur de bogues sera incrémenté de 1. Cela suppose qu’une classe est considérée comme étant fautive si elle a subi des modifications dans le cadre de la correction d’un bogue.

L’outil prend tous ses paramètres via un fichier de configuration . Les paramètres vont permettre, entre autres, de : limiter la fouille sur une version spécifique (en utilisant un intervalle de numéro de révision), définir le motif des chemins d’accès aux fichiers de code source (dossier racine, chemin, extension), ou choisir l’option de stockage des résultats dans un fichier ou une base de données. Buginfo présente des limitations. En regard de nos objectifs, nous avons énuméré celles qui nous concernent:

• L’identification des bogues lors de la phase 1 est un peu approximative. L’expression régulière ne permet pas à coup sûr d’identifier les bogues.

• Le risque de duplication dans le décompte des bogues. L’outil ne prend pas en considération, pour compter les fautes d’une classe, le fait qu’on peut avoir un bogue dont la résolution s’est faite sur plusieurs commits. Chaque commit retenu à la phase 1 est considéré comme un nouveau bogue (diffèrent), ce qui n’est pas forcément le cas.

• La non-intégration des ITS. Aucune information concernant la nature des bogues. Il est impossible, par exemple, de connaître la sévérité des bogues.

BuginfoV2 

En partant de Buginfo, nous allons apporter des améliorations, en effectuant des modifications dans le code source du logiciel, pour produire Buginfo V2. L’outil sera connecté aux ITS JIRA et BUGZILLA. Nous allons ainsi pouvoir:

• Augmenter la précision de l’identification des commits correspondants à des corrections de bogue (phase 1). Nous utiliserons l’identifiant unique des bogues contenu dans l’ITS pour réduire le champ de couverture de l’expression régulière (E), qui était assez vaste sur Buginfo.
• Réduire le risque de duplication dans le décompte des fautes pour une classe. En effet, chaque classe fautive est associée à une liste contenant les identifiants des bogues trouvés. Avant l’ ajout d’un nouveau bogue, nous vérifions sa présence préalable dans la liste. Cette approche nous permet d’éviter la duplication (phase 2).
• Obtenir toutes les informations sur la nature des bogues plus particulièrement la sévérité. Nous allons utiliser un compteur de bogues par niveau de sévérité. À chaque nouvelle faute identifiée et associée à une classe, nous incrémentons uniquement le compteur correspondant à la sévérité de la faute.

D’autres modifications ont aussi été apportées à l’outil pour améliorer la flexibilité de Buginfo. Nous pourrons, par exemple, choisir au niveau des paramètres d’utiliser un fichier local comme ITS en lieu et place d’une connexion distante. En effet, il se trouve que les interfaces utilisateurs (web) de JIRA et Bugzilla permettent de faire des recherches exhaustives sur les bogues, et d’exporter les résultats de la recherche sous différents formats de fichier. Nous avons mis à profit cette fonctionnalité dans la nouvelle version Buginfo V2. Ainsi, une partie de la recherche pourra être effectuée manuellement par l’utilisateur et les résultats seront soumis en entrée à BuginfoV2. Cela offre, par ailleurs, la possibilité d’exploiter les informations d’un ITS même si celui-ci n’offre pas ou restreint l’accès via des appels distants RPC. Pour la génération du rapport final, la seule modification apportée est la possibilité d’ intégrer les métriques des classes qui sont données en entrée dans un fichier CSV. Cette amélioration a aussi permis d’ augmenter la précision de l’ association entre classe et nom de fichier (phase 2), en ne retenant que les noms de fichiers correspondants à des noms de classe contenus dans le fichier des métriques de classe (dans le cas où celui-ci est donné en entrée). Il faudra noter que ces modifications ont été volontairement limitées au module de recherche pour les répertoires SVN, car étant celui qui concerne notre étude. Elles seront probablement élargies à l’outil CVS au besoin.