Analyse des processus de résolution de bugs dans les logiciels de réseau

Les Bugs, c'est un problème courant dans le développement logiciel. Quand ces bugs sont signalés dans des dépôts publics, ça aide à améliorer la transparence et la confiance dans les logiciels. Cet article se penche sur comment récolter des infos du système de suivi des problèmes Jira. Il introduit aussi une méthode pour prédire combien de temps ça va prendre pour corriger de nouveaux bugs. La recherche se concentre sur un projet réseau appelé ONAP, qui s'occupe des besoins des opérateurs de réseau et des fabricants. Grâce à cette étude, on veut éclairer combien de temps il faut pour résoudre les bugs et d'autres facteurs importants dans les projets logiciels réseau.

#C'est quoi la softwarisation des réseaux ?

La softwarisation des réseaux, c'est remplacer le matériel spécialisé utilisé pour des tâches précises par du logiciel programmable. Ce changement apporte plusieurs avantages, comme une maintenance plus facile, une plus grande flexibilité, et des coûts réduits en développement et en exploitation. Des exemples de cette tendance incluent le Réseau Défini par Logiciel (SDN) et la Virtualisation des Fonctionnalités Réseau (NFV). Les fabricants utilisent souvent des solutions open-source pour ajouter des fonctionnalités tout en s'assurant qu'ils respectent les normes établies.

Malgré ces avantages, les opérateurs de réseau sont souvent réticents à adopter ces solutions logicielles. C'est surtout parce que le logiciel peut être complexe et sujet à des bugs. De plus, la fiabilité du code peut être douteuse puisqu'il est ouvert à différents développeurs avec des compétences et expériences variées.

Pour améliorer la transparence sur la fiabilité des logiciels, tous les bugs trouvés pendant l'utilisation du logiciel sont signalés dans des dépôts publics. Ces dépôts fournissent des infos précieuses sur les bugs signalés, leurs statuts, et plus, ce qui peut être crucial pour évaluer la fiabilité du logiciel. Chaque projet logiciel a un processus défini pour résoudre les bugs, que tous les développeurs sont censés suivre.

#Objectifs de l'étude

Les principaux objectifs de cette étude sont au nombre de deux. D'abord, on veut donner un aperçu des types d'infos qui peuvent être extraites des dépôts de signalement des bugs. Alors que certaines données peuvent être collectées directement, d'autres nécessiteront un traitement. Ensuite, on propose une méthode pour estimer le temps qu'il faut pour résoudre de nouveaux bugs. Notre méthodologie a été appliquée à plusieurs projets liés aux réseaux, y compris ONOS et ONAP. On reconnaît que les opérateurs de réseau et les fabricants utilisant des projets open-source s'inquiètent de la durée des résolutions de bugs.

#Contributions clés

1. Une stratégie pour collecter les bugs signalés et les processus de filtrage nécessaires.
2. Analyse de données de base pour identifier les modèles de workflow communs, les transitions entre différents états, et la distribution du temps de résolution des bugs.
3. Analyse de données avancée incluant l'impact de facteurs comme la priorité et le rapporteur sur le temps de débogage.
4. Investigation sur les probabilités de différents états de bugs au fil du temps.
5. Une comparaison du temps de résolution des bugs en utilisant diverses stratégies.
6. Prédiction du temps exact de résolution des bugs en utilisant des modèles de réseaux de neurones.

#Contexte sur l'analyse des données des bugs

Dans cette section, on va discuter des travaux précédents liés à l'analyse des bugs et à la compréhension des processus de résolution des bugs.

Les chercheurs ont exploité des systèmes de suivi des problèmes et créé des ensembles de données à partir de divers projets. Dans une étude notable, les données de 55 projets Apache ont été analysées. Ces projets ont été classés en neuf groupes tels que Big Data et sécurité. Les chercheurs ont observé comment les champs liés au signalement des bugs peuvent changer au fil du temps et ont défini le temps nécessaire pour résoudre un bug comme la période entre sa création et sa fermeture. Ils ont également étudié comment les priorités et les personnes assignées affectent ces temps.

Une autre étude a examiné comment des attributs de bugs comme le rapporteur et la priorité influencent le temps pris pour corriger les bugs. Les chercheurs ont utilisé un algorithme de K-plus proches voisins pour prédire combien de temps il faudrait pour résoudre les bugs en fonction de ces attributs. Bien que leurs résultats indiquent que l'identité du rapporteur ou de la personne assignée était importante, leur approche se concentrait sur des résultats binaires (rapide ou lent) plutôt que sur des prédictions numériques précises.

Des recherches supplémentaires ont utilisé une approche basée sur Markov pour estimer combien de bugs pourraient être résolus dans un laps de temps donné et une méthode de Monte Carlo pour prédire le temps global nécessaire pour corriger un certain nombre de bugs. Cependant, cette méthode ne considérait pas les bugs individuels comme des entités séparées.

#Comprendre les systèmes de suivi des problèmes

Les systèmes de suivi des problèmes sont des outils utilisés pour gérer le développement, la maintenance et les processus de débogage des logiciels. Ces systèmes utilisent des "problèmes" pour décrire des bugs, des demandes de fonctionnalités, des délais, et d'autres tâches en fonction des besoins du projet. Ils servent aussi de dépôts pour l'historique des problèmes signalés et traités, ce qui les rend précieux pour comprendre l'évolution des projets logiciels.

Jira est l'un des systèmes de suivi des problèmes les plus utilisés, présent dans de nombreux projets open-source. Dans Jira, les types de problèmes vont au-delà de juste "Bug" et incluent "Tâche", "Histoire", et plus. Chaque problème est stocké dans le dépôt Jira pour son projet respectif. Ça fait de Jira une source riche d'infos sur l'historique de développement du projet.

Jira a un workflow défini qui décrit les étapes qu'un problème peut traverser, depuis sa création (étiquetée "Ouverte") jusqu'à sa résolution (étiquetée "Fermée"). Bien que Jira fournisse ce workflow initial, il peut être personnalisé selon les exigences spécifiques de chaque projet.

#Projets exemples

Cette étude considère deux projets open-source : Open Network Operating System (ONOS) et Open Network Automation Platform (ONAP). ONOS, créé par la Open Network Foundation, est conçu pour le réseau défini par logiciel (SDN) et suit un workflow standard. ONAP, développé par la Linux Network Foundation, est un cadre de gestion et d'orchestration pour la virtualisation des fonctionnalités réseau (NFV). La communauté ONAP a personnalisé le workflow de Jira pour s'aligner sur leur stratégie de résolution des bugs, ajoutant un état "Soumis".

#Données de bugs dans Jira

Dans ce travail, on se concentre sur le temps de résolution des bugs, en filtrant les problèmes qui ne sont pas classés comme des bugs. Jira collecte des données sur les bugs signalés, y compris des détails sur chaque bug et le processus de résolution. Les infos pertinentes incluent :

• Niveau de priorité : Indique à quel point le bug est important, avec différents niveaux utilisés par différents projets.
• Rapporteur : La personne qui signale le bug.
• Assigné : L'individu responsable de la correction du bug.
• Date de rapport : La date et l'heure à laquelle le bug a été signalé.
• État : L'étape actuelle du bug dans le workflow.
• Progression de la résolution : Indique si le bug est toujours non résolu ou a été traité.

D'autres attributs collectés peuvent inclure des descriptions de bugs, des sous-projets liés, des commentaires pendant la résolution, et des infos sur la version.

#Processus de résolution des bugs

Les bugs dans Jira suivent un workflow spécifique. Lorsqu'un bug est d'abord signalé, il entre dans l'état "Ouvert". Quand un développeur commence à travailler dessus, le statut change en "En cours". Une fois résolu, il passe à l'état "Résolu", en attente d'approbation d'un autre membre de l'équipe. Après approbation, le bug est marqué comme "Fermé". Parfois, les bugs peuvent être rouverts pour un travail supplémentaire, revenant à l'état "Rouvrir".

#Collecte et analyse des bugs

Un script Python a été développé pour collecter et analyser les bugs. Les bugs pour ONAP et ONOS ont été recueillis directement à partir de Jira, tandis que les bugs pour Apache ont été obtenus d'un ensemble de données externe. La recherche s'est principalement concentrée sur les bugs de haute priorité (priorité 1 et 2).

#Filtrage des données collectées

Les données collectées incluent tous les bugs signalés depuis le début de chaque projet jusqu'à la date de collecte. Cependant, tous les bugs ne sont pas résolus ; certains peuvent être étiquetés comme fermés pour d'autres raisons. Seuls les statuts "Fait" et "Corrigé" ont été inclus pour ONAP et ONOS, qui sont les résolutions les plus communément signalées.

Il y a aussi eu des cas où les bugs ont passé très peu de temps dans un état spécifique, qui ont été filtrés pour améliorer l'exactitude.

#Analyse des temps de résolution des bugs

On a analysé les temps de résolution pour les bugs de priorité 1 dans le projet ONAP, où 906 de ces bugs ont été identifiés. En observant les chemins communs empruntés pour résoudre ces bugs, on a noté des tendances : beaucoup de bugs suivaient des séquences similaires dans le workflow.

#Impact des propriétés des bugs

Différentes propriétés des bugs, comme la priorité, l'assigné et le rapporteur, peuvent grandement affecter les temps de résolution. On s'est spécifiquement penché sur comment ces attributs influençaient le temps pris pour résoudre les bugs dans nos projets choisis.

#Rôle du rapporteur

La personne qui signale un bug peut avoir un impact significatif sur le temps de résolution. Une description claire et précise aide l'assigné à traiter le problème plus efficacement. Nos recherches indiquent que les différences dans les temps de résolution peuvent être énormes selon l'expérience du rapporteur.

#Rôle de l'assigné

L'individu assigné à corriger le bug joue également un rôle crucial. Chaque assigné apporte des compétences et disponibilités uniques, ce qui affecte la rapidité avec laquelle un bug peut être résolu. On a constaté que certains assignés résolvaient constamment les bugs de haute priorité plus rapidement que d'autres.

#Effets de l'auto-assignment

Parfois, un rapporteur peut aussi assumer le rôle de l'assigné pour son propre bug. Ce double rôle peut accélérer le processus de résolution car le rapporteur mène la correction sans avoir besoin de communiquer les détails séparément. Nos résultats suggèrent que résoudre un bug est beaucoup plus rapide quand les rôles s'alignent.

#Distribution des états des bugs au fil du temps

On a ensuite examiné comment les états des bugs changent au fil du temps. Lorsqu'un bug est d'abord signalé, il commence dans l'état "Ouvert". Avec le temps, il passe par divers états, atteignant finalement "Fermé". Notre analyse de trois projets-ONAP, ONOS, et Apache-montrait différentes tendances sur la rapidité avec laquelle les bugs étaient fermés.

#Prédire le temps de résolution des bugs

Malgré une analyse minutieuse, certains bugs peuvent toujours être filtrés. Parmi les raisons de filtrage, il y a les bugs montrant des durées extrêmes. On a exploré les options pour retirer ces valeurs aberrantes et examiné comment différentes stratégies de filtrage affectaient nos prédictions.

On a utilisé des réseaux de neurones pour prédire le temps de résolution des bugs. Les résultats ont été comparés avec d'autres algorithmes comme Naive Bayesian et K-plus proches voisins. Même si les réseaux de neurones n'étaient pas conçus pour des prédictions binaires, ils ont mieux performé dans de nombreux cas. L'exactitude de ces prédictions variait en fonction de la méthode de filtrage choisie.

#Conclusion

Cette étude souligne l'importance de comprendre divers facteurs qui affectent la rapidité de la résolution des bugs. On a remarqué que le fait d'assigner le rapporteur au bug avait un impact significatif sur la résolution du problème. On a aussi discuté de comment différents workflows affectent le processus de résolution des bugs. La recherche a démontré le potentiel d'utiliser des réseaux de neurones pour prédire les temps de résolution des bugs, ce qui peut aider les équipes de développement à allouer leurs ressources plus efficacement. Les travaux futurs pourraient impliquer l'utilisation de techniques d'apprentissage automatique supplémentaires pour améliorer la précision des prévisions pour des projets petits et nouveaux.