Comment mesurer le retour sur investissement lors de la mise en place d’un outil d’analyse statique avancée ?
Les outils d’analyse statique avancée sont de plus en plus populaires de par leur efficacité à détecter rapidement et sans création de cas de tests des erreurs logicielles complexes. En permettant leur détection au plus tôt dans le cycle de développement, ils diminuent drastiquement leur coût de correction. Comment prouver à sa direction le retour sur investissement (ROI) d’un outil comme GrammaTech CodeSonar en comparant le gain apporté par son utilisation avec son coût d’achat ?
Comment mesurer l’efficacité économique d’un outil d’analyse statique avancée ?
Mesurer le ROI d’un outil d’analyse statique avancée est souvent ardu, compte tenu des nombreux facteurs à prendre en compte, souvent différents au sein de chaque société voire équipe. Cependant, les trois métriques suivantes sont toujours les plus importantes :
- Nombre de défauts détectés : lors de la comparaison entre plusieurs outils, le nombre de détections est une métrique intéressante, et celle-ci peut être dissociée par classe de détection ;
- Rappel : pourcentage de détection de véritables erreurs (les « vrais positifs »). Un rappel de 100% indique donc que l’outil a détecté tous les problèmes ;
- Précision : pourcentage indiquant la possibilité que chaque détection soit une véritable erreur. Une précision de 100% indique que l’outil n’a détecté que des véritables problèmes (aucun « faux positif »).
Quelles hypothèses prendre dans un calcul de retour sur investissement d’un outil d’analyse statique ?
Pour illustrer notre propos, nous comparerons ici plusieurs approches et outils, depuis l’absence totale d’outil, jusqu’à l’outil parfait (mais qui malheureusement n’existe pas (encore)). Lier les métriques d’efficacité à des entrées économiques permet d’estimer le ROI d’un outil comme CodeSonar, les éléments financiers utilisés ici étant basés sur des points objectifs (coûts outil ou ingénieur) ou communément admis dans l’industrie :
Coût de l’outil et de son déploiement :
Ceci est le premier coût auxquels pensent les équipes ! Dans le cadre de cette comparaison, nous l’estimerons à 20 000€ pour chaque outil (licence, maintenance, formation…).
Probabilité d’un incident et coût de correction d’une défaillance
Les erreurs logicielles et de cybersécurité post-production sont devenues monnaie courante, mais n’entraînent heureusement pas toutes de véritables incidents. La plupart sont corrigées durant la phase classique de maintenance (que nous n’incluons pas dans cette simulation, mais qui a néanmoins un coût). Nous utiliserons dans cet exemple une probabilité de 5% qu’une erreur entraîne un incident, avec un coût de correction moyen de 40 000€ (comprenant les audits d’urgence pour trouver la cause du problème, le temps ingénieur passé voire les heures supplémentaires, le coût de rappel des systèmes défectueux, …).
Temps de correction d’une erreur sans outil :
Que l’erreur entraine une défaillance du système ou non, elle a un coût de correction, dépendant principalement de l’étape du cycle de vie logiciel dans laquelle elle est corrigée. Selon le rapport NIST 2002 (p. 121), la correction d’une erreur nécessite en moyenne 4 heures avant la phase d’intégration, et plus de 13 heures après livraison, ce qui nous semble cohérent avec les informations récoltées sur le terrain.
Temps de tri des détections d’un outil :
Même avec un outil, il faut du temps pour trier les détections en vrai ou faux positif. La plupart des erreurs sont très rapides à analyser, spécialement avec un outil comme CodeSonar affichant le chemin menant à l’erreur et les hypothèses prises ; d’autres peuvent nécessiter plus de temps.
Au travers de son retour d’expérience, GrammaTech estime à 10 minutes le temps moyen de tri d’une erreur au sein de CodeSonar.
Coût horaire d’ingénierie :
Nous utiliserons un taux horaire moyen de 45€, que chaque société peut adapter à ses propres données.
Nombre d’erreurs par milliers de lignes de code :
Cette métrique est très difficile à calculer, car dépendante de nombreux facteurs : industrie, langages utilisés, maturité des équipes de développement, … Cependant, plusieurs études permettent de l’estimer.
Tout d’abord, le rapport CRASH 2017 de la société CAST (principalement destiné à l’industrie IT et aux développements Java), dans son panel, arrive à un taux de près de 100 violations de règles de codage pour 1000 lignes de code (aussi appelé KLOC), avec fort heureusement « seulement » 1,5 erreurs critiques / KLOC. C’est moins que les données utilisées par de nombreux sites internet reprenant celles de Steve McConnell dans son livre « Code Complete » : entre 10 et 50 erreurs / KLOC, mais cohérent avec ce qu’annonçait Microsoft au début des années 90 (de 10 à 20 durant le développement, et 0,5 en production).
Une étude plus récente sur un code source modélisant des données climats, montre un ratio médian de 0,28 erreurs / KLOC, ce qui, selon l’expert Steve Easterbrook, est un excellent ratio, cependant effectué sur un code mature, les résultats étant généralement compris entre 0,5 et 10 erreurs / KLOC sur des codes sources embarqués et/ou critiques.
Pour cette étude, nous avons décidé d’utiliser un ratio bas d’une erreur pour 1000 lignes, soit 100 erreurs sur un code source de 100 000 lignes, ce qui nous semble aussi cohérent avec notre expérience d’audit de code sources clients.
Coût de l’outil et de son déploiement :
Ceci est le premier coût auxquels pensent les équipes ! Dans le cadre de cette comparaison, nous l’estimerons à 20 000€ pour chaque outil (licence, maintenance, formation…).
Probabilité d’un incident et coût de correction d’une défaillance
Les erreurs logicielles et de cybersécurité post-production sont devenues monnaie courante, mais n’entraînent heureusement pas toutes de véritables incidents. La plupart sont corrigées durant la phase classique de maintenance (que nous n’incluons pas dans cette simulation, mais qui a néanmoins un coût). Nous utiliserons dans cet exemple une probabilité de 5% qu’une erreur entraîne un incident, avec un coût de correction moyen de 40 000€ (comprenant les audits d’urgence pour trouver la cause du problème, le temps ingénieur passé voire les heures supplémentaires, le coût de rappel des systèmes défectueux, …).
Temps de correction d’une erreur sans outil :
Que l’erreur entraine une défaillance du système ou non, elle a un coût de correction, dépendant principalement de l’étape du cycle de vie logiciel dans laquelle elle est corrigée. Selon le rapport NIST 2002 (p. 121), la correction d’une erreur nécessite en moyenne 4 heures avant la phase d’intégration, et plus de 13 heures après livraison, ce qui nous semble cohérent avec les informations récoltées sur le terrain.
Temps de tri des détections d’un outil :
Même avec un outil, il faut du temps pour trier les détections en vrai ou faux positif. La plupart des erreurs sont très rapides à analyser, spécialement avec un outil comme CodeSonar affichant le chemin menant à l’erreur et les hypothèses prises ; d’autres peuvent nécessiter plus de temps.
Au travers de son retour d’expérience, GrammaTech estime à 10 minutes le temps moyen de tri d’une erreur au sein de CodeSonar.
Coût horaire d’ingénierie :
Nous utiliserons un taux horaire moyen de 45€, que chaque société peut adapter à ses propres données.
Nombre d’erreurs par milliers de lignes de code :
Cette métrique est très difficile à calculer, car dépendante de nombreux facteurs : industrie, langages utilisés, maturité des équipes de développement, … Cependant, plusieurs études permettent de l’estimer.
Tout d’abord, le rapport CRASH 2017 de la société CAST (principalement destiné à l’industrie IT et aux développements Java), dans son panel, arrive à un taux de près de 100 violations de règles de codage pour 1000 lignes de code (aussi appelé KLOC), avec fort heureusement « seulement » 1,5 erreurs critiques / KLOC. C’est moins que les données utilisées par de nombreux sites internet reprenant celles de Steve McConnell dans son livre « Code Complete » : entre 10 et 50 erreurs / KLOC, mais cohérent avec ce qu’annonçait Microsoft au début des années 90 (de 10 à 20 durant le développement, et 0,5 en production).
Une étude plus récente sur un code source modélisant des données climats, montre un ratio médian de 0,28 erreurs / KLOC, ce qui, selon l’expert Steve Easterbrook, est un excellent ratio, cependant effectué sur un code mature, les résultats étant généralement compris entre 0,5 et 10 erreurs / KLOC sur des codes sources embarqués et/ou critiques.
Pour cette étude, nous avons décidé d’utiliser un ratio bas d’une erreur pour 1000 lignes, soit 100 erreurs sur un code source de 100 000 lignes, ce qui nous semble aussi cohérent avec notre expérience d’audit de code sources clients.
Exemple de comparaison du gain de la mise en place d’un outil d’analyse statique avancée
Dans cet exemple, il existe donc 100 erreurs au sein du projet, non détectées par les moyens classiques de relecture. Prenons ces cas :
L’outil B remonte très peu de faux positifs, au prix d’une diminution du nombre de détection de véritables erreurs ; l’outil A adopte un comportement plus mesuré entre détection de véritables erreurs et faux positifs (choix de Grammatech pour CodeSonar par exemple). Enfin, nous ajoutons une comparaison avec un outil gratuit, basé sur notre retour d’expérience.
Cet exemple montre que la mise en place d’un outil d’analyse statique avancée est toujours bénéfique, et permet la diminution des coûts de développement et d’exploitation (bien entendu si les erreurs détectées sont corrigées !). De plus, il met en lumière le fait que malgré le coût d’achat d’un outil commercial, l’utilisation d’un outil gratuit revient bien plus cher en coûts de correction des incidents, à cause de leurs détections limitées.
Enfin, de nombreux clients ont pour principal critère le fait que l’outil ait « peu de faux positifs ». Or, alors que le coût lié au tri des détections est peu onéreux, celui de rater un véritable problème l’est particulièrement ! Aussi, force est de constater qu’à l’instar de l’outil A de cet exemple, un outil d’analyse statique avancée comme CodeSonar, recherchant le meilleur ratio rappel/précision, est celui qui permet le meilleur retour sur investissement, contrairement à d’autres outils privilégiant justement le ratio « faux positifs » le plus bas possible.
Enfin, de nombreux clients ont pour principal critère le fait que l’outil ait « peu de faux positifs ». Or, alors que le coût lié au tri des détections est peu onéreux, celui de rater un véritable problème l’est particulièrement ! Aussi, force est de constater qu’à l’instar de l’outil A de cet exemple, un outil d’analyse statique avancée comme CodeSonar, recherchant le meilleur ratio rappel/précision, est celui qui permet le meilleur retour sur investissement, contrairement à d’autres outils privilégiant justement le ratio « faux positifs » le plus bas possible.
Sources :
- Temps de correction d’une erreur sans outil : Rapport NIST 2002
- Nombre moyen d’erreurs par milliers de lignes de code : Rapport CRASH 2017 de la société CAST
-Nombre d’erreurs p21 ;
-Nombre de lignes de code p9. - Extrait du livre « Code Complete » de Steve McConnell paru en 1993, expert en Ingénierie Logiciel et de Projets, cité sur de nombreux sites web, notamment :
-https://www.mayerdan.com/ruby/2012/11/11/bugs-per-line-of-code-ratio
-http://amartester.blogspot.fr/2007/04/bugs-per-lines-of-code.html - Thèse « Assessing climate model software quality: a defect density analysis of three models » parue en 2012, accessible à cette adresse : https://www.geosci-model-dev.net/5/1009/2012/gmd-5-1009-2012.pdf
- Sites web :
-http://planete.gaia.free.fr/sciences/divers/info.code.html (Données provenant de Microsoft, de 1 à 10 bugs / 1000 LOC) ;
-https://www.wired.com/2004/12/linux-fewer-bugs-than-rivals/ (Nombre d’erreurs dans Linux inférieur à 1 par millier de lignes) ;
-http://www.easterbrook.ca/steve/2014/05/tedx-talk-should-we-trust-climate-models (Discussion de Steve Easterbrook suite à son étude sur le code source de modélisation du climat).