Prédiction de défauts : pourquoi et comment analyser les pratiques de développement logiciel?

Transcription

1 Prédiction de défauts : pourquoi et comment analyser les pratiques de développement logiciel? Introduction Les techniques de prédiction de défauts ont pour objectif de réduire le coût de maintenance des applications en détectant, au plus tôt, les défauts risquant d'apparaître après la livraison du produit. Si les analyses qualimétriques sont de plus en plus démocratisées dans les environnements de développement agiles, les approches s'intéressant aux pratiques de développement sont aujourd'hui très peu répandues. L'objectif de cet article est de montrer l'intérêt de l'analyse des pratiques de développement dans la prédiction de défaut et de synthétiser les moyens de les mettre en œuvre automatiquement. La correction des défauts coûte plus cher que le développement du produit Le coût des défauts d'une application est un sujet critique de l'ingénierie logicielle. Ainsi, une étude publiée en 2002 par le NIST [1] a évalué qu'à cette époque le coût annuel des défauts logiciels était de 60 billions de dollars par an pour les États- Unis. Cette étude révèle également que 80% des dépenses de l'ingénierie logicielle étaient consacrées à la correction des défauts. "Finding and fixing a software problem after delivery is often 100 times more expensive than finding and fixing it during the requirements and design phase." Barry Boehm - Software Defect Reduction Top 10 List, Computer Vol. 34, January 2001 Barry Boehm a proposé une courbe modélisant la variation du coût de correction [8] d'un défaut en fonction du moment ou le défaut est corrigé (pour un processus de développement en cascade). Si les chiffres (x100 pour un défaut corrigé en production) peuvent être contestés [2], il existe un consensus sur le fait qu'un défaut corrigé en production coûte plus cher qu'une correction lors de la phase de développement. Ainsi, l'étude du NIST [1] évalue que le coût d'une correction en production est multiplié par 3. Améliorer la qualité logicielle pour prévenir l'apparition de défauts Le surcoût de correction tardive a favorisé la démocratisation d'outils et de méthodes pour identifier et corriger au plus tôt les défauts (intégration continue, revue de code, analyse qualité, TDD, BDD, etc.). Aujourd'hui, le développement agile d'une application s'intègre dans un environnement constitué de multiples outils : SCM (git, svn, mercurial, etc.) Gestion de tâches/projets (Jira, Redmine, Mylyn, etc.) Bugtracker (Jira, Redmine, Bugzilla, Mantis, etc.) Serveur intégration continue (Jenkins, Travis, etc.) Tableaux de bord qualimétrique (SonarQube, Kiuwan, SQuORE, etc.) 2015 Copyright Tocea Page 1 / 6

2 Revues de code manuelles (Gerrit, Crucible, etc.) ou automatisées (FindBugs, PMD, etc.). Médias de communication (mails, forums, chatroom, réseaux sociaux, etc.) En pratique, la prévention des défauts s'appuie principalement sur la revue de code et les outils de qualimétrie. Dans les deux cas, on considère que plus la qualité d une application est faible, plus le risque d apparition de défauts est élevé. La revue de code consiste à identifier manuellement ou automatiquement (via des analyses statiques) dans le code source des anomalies qui nuisent à la qualité de l'application. Les tableaux de bord qualimétriques synthétisent les informations provenant de la revue de code en y associant des métriques statiques (couplage, volumétrie, etc.) et dynamiques (taux de couverture des tests, durée des tests, etc.). L'objectif est d'évaluer la qualité des éléments de l'application sur la base des indicateurs collectés. Cette notion de qualité est ensuite utilisée pour identifier rapidement les zones ou doit se porter l'effort de correction. Cependant, les analyses automatisées de qualité ne permettent pas de détecter tous les types de défauts. En effets, certains sont issus de phénomènes ne pouvant être appréhendés par des analyses généralistes du code : interactions complexes entre les composantes de l'application, erreurs algorithmiques, mauvaises spécifications, incompréhension du métier, etc. Prédiction des défauts : l'analyse des pratiques plus efficace que celle du code? Prédiction de défauts La prédiction des défauts consiste à recourir à un modèle statistique pour identifier les composantes de l'application qui risquent de présenter un défaut lors de la prochaine livraison du produit. Elles se différencient des analyses statiques du fait qu'elles sont liées à une base de connaissances intra ou inter applications et qu'elles calculent une probabilité de présence de défaut. Les approches de prédiction permettent de prendre du recul par rapport au code de l'application. Il est possible de tenir compte de paramètres non traités par les analyses du code: pratiques de développement, facteurs humains, etc. Il semble en effet naturel d'associer l'apparition de défauts à des périodes de forte pression sur les développeurs (avant la livraison d'un produit par exemple) ou encore à un manque d'expertise métier issu d'une externalisation du développement. Métriques utilisées dans la prédiction de défauts Il existe un nombre important de travaux sur la prédiction des défauts. L'article de Radjenovica et al. [6] étudie 106 publications portant sur les métriques utilisées dans la prédiction de défauts. La classification obtenue fait notamment apparaître que les travaux sont basés sur : 49% de métriques orientées objet (couplage, cohésion, héritage, etc.) 27% de métriques traditionnelles (nombre de lignes, complexité cyclomatique, etc.) 24% de métriques sur les pratiques de développement. Cette étude montre donc qu'un quart des techniques de prédiction analysées utilisent des métriques portant sur les pratiques de développement. Celles- ci ne seront pas détaillées dans cet article, mais peuvent être classées en plusieurs catégories (toutes ne sont pas couvertes par l'étude de Radjenovica) : 2015 Copyright Tocea Page 2 / 6

3 Métriques portant sur l'évolution du code (e.g., lignes ajoutées/effacées dans la livraison candidate, éparpillement des modifications, date de création ou de modification d'un fichier, etc.) Métriques sur l'historique (e.g., nombre de révisions, nombre de défaut dans les versions précédentes, échecs de construction, etc.) Métriques humaines et sociales (e.g., nombre de développeurs ayant modifié un fichier, communications en lien avec des parties de l'application, distraction des développeurs, etc.) Au vu de la variété des métriques, il est légitime de se poser la question de leur efficacité dans le processus de prédiction. Radjenovica estime que, dans le spectre des métriques des 106 articles étudiés, les métriques les plus efficaces sont celles portant sur l'évolution du code. Les récents travaux de Madeyski [7] analysent l'efficacité de quatre métriques portant également sur les pratiques de développement. L'étude est faite sur 43 releases de projets Open Source ainsi que 23 de projets industriels. Si le nombre de métriques considéré est trop faible pour être généralisé à l'ensemble des autres métriques il est intéressant de noter les divergences constatées en fonction du contexte applicatif (communauté Open Source ou projet industriel). En effet il a été observé que le nombre de développeurs n'a pas d'impact sur l'apparition de défauts dans les projets Open Source: les développeurs ne contribuent que s'ils ont une expertise de l'application. À l'inverse, cette métrique a un impact important dans les projets industriels ou l'externalisation du développement est souvent associée à une perte d'expertise. De manière générale, les auteurs concluent que les métriques sur les pratiques de développement ont un impact plus important en milieu industriel. D'autres expérimentations [4-5] ont montré que les métriques analysant le processus de développement prédisent de manière plus efficace l apparition de défauts que les métriques de code usuelles. Le graphique de la figure 1 synthétise les performances obtenues en utilisant différents types de métriques [5]: P : pratiques de développement ou process C : métriques de code usuelles S : métriques de taille + pratiques de développement À : toutes les métriques 2015 Copyright Tocea Page 3 / 6

4 Figure 1 : Comparaison des performances des métriques dans les approches prédictives de défauts [5]. La mesure utilisée (F- Measure) pour quantifier la performance de la prédiction se base sur les taux de vrai et faux positifs et sur les taux de vrai et faux négatifs (i.e, un vrai positif correspond à une occurrence avérée de défaut dans un fichier et réciproquement un faux positif est une occurrence détectée, mais qui n'est pas un défaut). Il s'agit de la mesure la plus utilisée pour comparer les performances de classifications statistiques [9]. Les résultats montrent que, quelle que soit la méthode statistique utilisée, les métriques sur les pratiques de développement sont plus performantes que celles de code. Compléter les analyses du code La prédiction ne s'oppose pas aux outils d'analyses statiques, au contraire, elles les complètent. En effet, Rhaman et al.[3] ont récemment comparé la précision des deux approches sur des applications Open Source conséquentes (Lucene, Wicket, OpenJPA, etc.). Les résultats obtenus montrent que les approches ont des bénéfices comparables. De plus, la pertinence des outils d'analyses statiques (PMD, FindBugs JLint) peut être améliorée en ordonnant les alertes détectées selon les probabilités obtenues par prédiction pour chaque fichier. Analyse des pratiques logicielles : un manque d'outils Paradoxalement, la fertilité des travaux sur la prédiction de défauts n'a été que très peu concrétisée par des outils industriels. En effet, les tableaux de bord qualimétrique (SonarQube, Kiuwan, etc.) existants se contentent généralement d'agréger les résultats produits par les outils d'analyses du code et quelques informations provenant du gestionnaire de version et éventuellement du bugtracker. À notre connaissance, il n'existe malheureusement pas de corrélation des différentes informations collectées Copyright Tocea Page 4 / 6

5 Puisque les approches de prédiction basées sur l'analyse des pratiques donnent de bons résultats, on peut s'interroger sur les raisons de leur absence du spectre des outils de qualimétrie existants. Nous proposons quelques pistes pouvant expliquer ce constat : l'industrialisation de l'analyse qualité est encore relativement jeune et n'est pas assimilée dans toutes les entreprises. L'analyse des pratiques de développement peut sembler encore trop «exotique». le coût pour s'interfacer avec une multitude d'outils et s'adapter aux contexte de chaque entreprise. problèmes humains : certaines métriques reposent sur des jugements de compétences qui peuvent être critiqués ou même poser des problèmes éthiques et juridiques (e.g., analyse des s). les développeurs ne sont pas convaincus par l'approche ou par l'outillage [10]. Des approches prédictives ont été expérimentées dans une équipe de développement de Google [10]. Les résultats de cette expérience montrent que l'outil expérimental n'est pas prêt à être adopté par les développeurs. Les principales raisons évoquées sont: la détection est opaque. L'algorithme de prédiction se contente d'indiquer un défaut potentiel sans en indiquer les raisons. Ceci est particulièrement frustrant pour le développeur qui ne sait pas comment diagnostiquer et résoudre le problème. il n'est pas possible d'infirmer un faux positif. La méthode utilisée dans l'expérience ne permet pas au développeur d'interagir avec l'algorithme de prédiction. La conséquence est donc d'observer des faux positifs dans les rapports sans pouvoir faire autre chose que d'attendre que l'algorithme s'ajuste au cours des prochaines semaines. Les auteurs ne remettent cependant pas en cause la qualité de la méthode de détection, ils concluent sur le fait que les développeurs ne sont peut- être pas la cible de ces outils dans un premier temps. Les résultats de prédiction sont plus aisément exploitables par des personnes supervisant la qualité d'un parc applicatif. Conclusion La multiplicité des outils gravitant autour du processus de développement d'une application offre aujourd'hui une base de connaissance conséquente et exploitable par des méthodes de prédiction de défauts. Dans ce contexte, les métriques concernant les pratiques de développement qui peuvent en être extraites donnent de meilleurs résultats que celles provenant de l'analyse du code. Les techniques de prédiction de défauts ne sont pas à opposer aux outils usuels de qualimétrie, elles devraient être vues comme un complément permettant de prendre en compte le processus de développement dans son ensemble. L'outillage constitue à notre avis le principal axe de travail. En effet, si les techniques peuvent dès à présent être intégrées dans un tableau de bord s'adressant à la supervision macro de parcs applicatifs, la création d'outils adaptés aux développeurs reste un problème ouvert Copyright Tocea Page 5 / 6

6 Références [1] The Economic Impacts of Inadequate Infrastructure for Software Testing. National Institure of Standards & Technology. Program Office Strategic Planning and Economic Analysis Group. May [2] Bonnie Bayley. What Does It Really Cost to Fix a Software Defect? does- it- really- cost- fix- software- defect. October [3] Rahman, F., Khatri, S., Barr, E. T., & Devanbu, P. T. Comparing static bug finders and statistical prediction. In ICSE (pp ) (2014, May). [4] Moser, R., Pedrycz, W., & Succi, G. (2008, May). A comparative analysis of the efficiency of change metrics and static code attributes for defect prediction. ICSE 08. ACM/IEEE 30th International Conference on (pp ). IEEE. InSoftware Engineering, [5] Rahman, Foyzur, and Premkumar Devanbu. «How, and why, process metrics are better.» Proceedings of the 2013 International Conference on Software Engineering. IEEE Press, [6] Radjenovica, D., Herickob, M., & Torkarc, R. Software Fault Prediction Metrics: A Systematic Literature Review. Information and Software Technology, 55(8), [7] Madeyski, Lech, and Marian Jureczko. «Which Process Metrics Can Significantly Improve Defect Prediction Models? An Empirical Study.» Software Quality Journal [8] Boehm, Barry W. «Software engineering economics.» [9] Nam, Jaechang. «Survey on Software Defect Prediction.». Master's Thesis, [10] Lewis, Chris, et al. «Does bug prediction support human developers? findings from a Google case study.» Software Engineering (ICSE), th International Conference on. IEEE, Copyright Tocea Page 6 / 6