IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Tout le monde cite l'étude : « les bogues sont 100 fois plus chers à corriger en production »,
Mais il se peut que l'étude n'existe même pas

Le , par Bill Fassinou

218PARTAGES

13  0 
Le terme "génie logiciel" est généralement défini comme un processus d'analyse des besoins des utilisateurs, puis de conception, de construction et de test d'une application logicielle qui répondra à ces besoins. C'est un domaine important de l'IT qui cherche à résoudre certains problèmes de la vie à l'aide de logiciels et à innover. Mais les experts pensent qu'il souffre de plusieurs problèmes, dont l'un des plus importants est : le manque d'études sur le coût de la maintenance d'un logiciel, en particulier de la détection et de la correction des bogues en production. Voici ci-dessous une analyse de Hillel Wayne, consultant en logiciels basé à Chicago et spécialisé dans les méthodes formelles.

Une recherche rapide sur Internet sur le thème "Software Crisis" (la crise du logiciel) affiche des résultats qui montrent que les problèmes du génie logiciel ne datent pas d'aujourd'hui. Ils remonteraient à la fin des années 1960, alors que de nombreux projets logiciels ont échoué. L'on peut noter les problèmes suivants : plusieurs logiciels ont dépassé leur budget (le résultat était un logiciel peu fiable et coûteux à entretenir) ; les logiciels de grande taille étaient difficiles et assez coûteux à maintenir ; de nombreux logiciels ne sont pas en mesure de satisfaire les exigences croissantes des clients ; etc.



D'autres exemples de problèmes intéressants sont : la complexité des projets logiciels augmentait chaque fois que la capacité du matériel augmentait ; la demande de nouveaux logiciels augmentait plus rapidement que la capacité à générer de nouveaux logiciels. Tous ces problèmes auraient conduit à la "crise du logiciel". Mais alors que le génie logiciel a parcouru un long chemin depuis les années 1960, les experts estiment qu'il reste encore difficile de savoir si la crise s'est complètement apaisée. Hillel Wayne s'est penché sur la question dernièrement et estime que les choses n'ont pas vraiment changé depuis.

Il a concentré sa recherche sur le coût de la maintenance des logiciels. Dans un billet de blogue qu'il a publié la semaine dernière, il a déclaré que les ingénieurs n'ont aucun repère lorsqu'il faut évaluer le coût de la correction des bogues présents dans un logiciel déjà en production. « La recherche sur les logiciels est une catastrophe. Si vous cherchez sur Google "coût d'un bogue logiciel", vous trouverez des tonnes d'articles affirmant que les bogues trouvés dans les exigences sont 100 fois moins chers à éliminer que les bogues trouvés dans les implémentations. Selon Wayne, ils s'appuient tous sur le tableau ci-dessus de l'IBM Systems Sciences Institute.

« Cependant, il y a un petit problème avec l'étude de l'IBM Systems Sciences Institute : elle n'existe pas », a ajouté Wayne. En effet, Wayne a cité dans son billet Laurent Bossavit, expert en méthodologie Agile et conseiller technique au sein de la société de conseil en logiciels CodeWorks à Paris. Bossavit a également consacré du temps à cette question, et a publié sur GitHub un billet intitulé "Degrees of intellectual dishonesty". À son tour, Bossavit fait référence à un livre à succès de Roger S. Pressman, publié en 1987 et intitulé "Software Engineering : a Practitioner's Approach". Le livre stipule ce qui suit :

« Pour illustrer l'impact sur les coûts de la détection précoce des erreurs, nous considérons une série de coûts relatifs qui sont basés sur des données de coûts réels collectées pour de grands projets logiciels [IBM81] ». Selon le billet de blogue de Wayne, la référence à [IBM81] indique que les informations proviennent de "notes de cours" de l'IBM Systems Sciences Institute. Bossavit a découvert, cependant, que de nombreuses autres publications ont fait référence au livre de Pressman comme étant la source faisant autorité pour cette recherche, dissimulant ainsi sa nature provisoire.

En outre, Bossavit a pris le temps d'enquêter sur l'existence de l'IBM Systems Science Institute. Il a conclu qu'il s'agissait simplement d'un programme de formation interne pour les employés de l'entreprise. Mieux, il a ajouté qu'aucune donnée n'était disponible pour étayer les chiffres du graphique, qui montre un coût net 100 fois plus élevé pour corriger un bogue une fois que le logiciel est en maintenance. « Les données originales du projet, s'il en existe, ne sont pas plus récentes que 1981, et probablement plus anciennes ; et pourraient remonter à 1967 », a déclaré Bossavit. En gros, ces données pourraient être aussi vieilles que "la crise du logiciel" et provenir d'une estimation sans fondement.

Alors, les défauts logiciels coûtent-ils réellement plus cher à corriger lorsqu'ils sont découverts tardivement ? « Je pense que l'ensemble des recherches menées jusqu'à présent pointe provisoirement dans cette direction, selon la façon dont vous interprétez 'stade avancé', 'bogues' et 'plus cher' », a répondu Wayne. « Certains bogues prennent plus de temps à corriger (et causent plus de dommages) que d'autres, et ces bogues ont tendance à être des problèmes de conception », a-t-il ajouté. En plus, Wayne a cité une étude qui a révélé que les délais de résolution des problèmes à différents moments n'étaient généralement pas significativement différents.

L'étude a examiné 171 projets logiciels menés entre 2006 et 2014, qui ont tous utilisé une méthodologie appelée Team Software Process. Wayne a déclaré qu'il était tout autant préoccupé par l'état de la recherche sur les logiciels que par la question des défauts elle-même. Il a observé que des articles tels que celui cité ci-dessous "utilisent différentes définitions des défauts". Selon lui, cela ne permet pas de tirer des conclusions. De même, Wayne a expliqué que les structures d'incitation universitaires ne sont pas alignées de manière à fournir à l'industrie des informations exploitables.

Wayne a déclaré qu'il est un partisan de l'ingénierie logicielle empirique (ESE – Empirical Software Engineering), qui consiste à utiliser des preuves pour apprendre ce qui fonctionne dans le développement de logiciels. Alors, comment résoudre le problème du manque de données fiables sur les logiciels ? « Il y a beaucoup plus d'incitation à créer de nouveaux modèles et à introduire des innovations qu'à faire le "travail de fond" nécessaire qui serait le plus utile », a déclaré Wayne. Selon lui, se concentrer sur ce que la recherche empirique montre de manière écrasante, à savoir la révision du code, est un bon moyen de trouver les bogues logiciels et de diffuser les connaissances sur les logiciels.

« Elle montre également que des cycles d'itération et des boucles de rétroaction plus courts conduisent à des logiciels de meilleure qualité que des délais plus longs », a-t-il ajouté. Selon Wayne, le rôle de l'IBM Systems Sciences Institute dans la consolidation de l'autorité d'une recherche qui pourrait ne pas exister est un rappel de l'importance des sources primaires, qui peuvent être difficiles à découvrir dans la chambre d'écho d'Internet. En somme, Wayne ne réfute pas l'idée selon laquelle "les bogues sont 100 fois plus chers à corriger en production", il indique simplement que l'étude n'existe peut-être pas et pointe du doigt le manque d'études dans le domaine du génie logiciel.

Source : Hillel Wayne

Et vous ?

Quel est votre avis sur le sujet ?
Que pensez-vous de l'état médiocre de la recherche dans le domaine des logiciels ?
Quelles approches de solution proposez-vous pour remédier à ce problème persistant ?
Connaissez-vous des ressources (études ou livres) traitant de la maintenance des logiciels ? Si oui, partagez-les ?

Voir aussi

Que vaut le mythe du mois-homme de la Bible du génie logiciel suggérant qu'un dev écrit en moyenne 10 lignes de code logique par jour face à des statistiques de 14 ans de dev à temps plein ?

Cours, articles et tutoriels sur les outils de génie logiciel, d'architecture, de modélisation, pratiques de conception et méthodes de développement : outils

Sondage : quels sont les conseils pour débuter en tant que développeur de logiciels ? Partagez votre expérience

Agile pourrait-il conduire les organisations vers une dette technique plus importante ? Oui, selon Don Clos, développeur logiciel, qui propose une analyse détaillée de la situation

Étude : 50 % des projets de développement d'applications se soldent par un échec. Cela est-il dû à la lenteur des codeurs et la dette technique ?

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de grunk
Modérateur https://www.developpez.com
Le 23/07/2021 à 15:50
Ce qui est certains c'est qu'il ne coutera jamais moins cher de corriger un bug en prod. Par contre il y'a des risque qu'il coutent beaucoup plus cher :
- Si il se produit uniquement en prod il va être très dur à reproduire et debugger => donc temps +++ = $$$
- Si on le reproduit facilement il y'a de forte chance qu'on ai des contraintes supplémentaires (rétro compatibilité entre autre) qui n'auraient pas existée si il avait été vu avant.

il a déclaré que les ingénieurs n'ont aucun repère lorsqu'il faut évaluer le coût de la correction
Pour estimer un coût il faut estimer un temps. Déjà que c'est pas évident d'estimer comme il faut sur une feature , alors sur un bug ...
8  0 
Avatar de Earered
Membre à l'essai https://www.developpez.com
Le 23/07/2021 à 16:40
Ce type est un fumiste et vend sa came, une recherche documentaire rapide permet de trouver des études sérieuses de la NASA sur le sujet https://ntrs.nasa.gov/api/citations/...0100036670.pdf
8  0 
Avatar de Mingolito
Membre extrêmement actif https://www.developpez.com
Le 23/07/2021 à 16:55
Ça c'est sur que pour la NASA, corriger des "bogues en production", ça doit être plus difficile, comme corriger des bogues dans une tenue de cosmonaute dans un Lem en train d'alunir

Ceci dit il est courant que pour ce qui est des applications web c'est mis en prod puis débogué sur le tas, je ne dis pas que c'est bien mais c'est courant

Et pas que pour le web, Elon Musk il met bien en prod son application de "conduite autonome" avec un gros tas de bugs à chaque fois, il y a quelques dizaines de morts mais c'est pas grave c'est pour le progrès
Faire tester ses applis par les utilisateurs ça coute quand même moins cher que de payer un service de tests, il n'y a qu'a voir sur Steam tous les jeux qui sont maintenant vendus en "accès anticipé" c'est à dire que qu'au lieu d'être payé pour un job de testeur, tu dois toi payer pour devenir testeur de l'appli, c'est quand même beau !
3  0 
Avatar de marsupial
Expert éminent https://www.developpez.com
Le 23/07/2021 à 16:05
Connaissez-vous des ressources (études ou livres) traitant de la maintenance des logiciels ? Si oui, partagez-les ?
A partir du moment où un bogue devient une source de faille de sécurité, je conseille de lire "Software Security Engineering: A Guide for Project Managers". Je l'ai juste parcouru comme ça maintenant que la question se pose. Il me semble approprié. Le chapitre II de ce bouquin Professional_Software_Development_Shorter_Schedules_Higher_Quality_Products_More_Successful_Projects_Enhanced_Careers me paraît pas mal aussi.

Que pensez-vous de l'état médiocre de la recherche dans le domaine des logiciels ?
Déjà, obtenir des ressources pour déboguer,... alors pour faire une étude sur le déboguage

Quelles approches de solution proposez-vous pour remédier à ce problème persistant ?
Lire l'art du test : The_Art_of_Software_Testing_Second_Edition

Quel est votre avis sur le sujet ?
Le jour où un OS sort sans le besoin de mises à jour de sécurité, je crois qu'on aura gagné. Mais ce n'est pas pour tout de suite.
1  0 
Avatar de CaptainDangeax
Membre expérimenté https://www.developpez.com
Le 27/07/2021 à 10:00
Il a été dit en commentaires que des études existent, et évidemment la Nasa est une bonne source parce qu'on ne peut pas débugguer dans l'espace (quoique, la lentille du téléscope Hubble a été débugguée en production = en orbite)... Retour d'expérience sur mon projet précédent, une évolution d'un système mail--> fax, mail-->sms et fax-->mail. Le fax-->mail c'est facile, on convertit l'image de réception en TIFF et on la colle dans le mail qui correspond au n° de fax. Dans l'autre sens c'est beaucoup plus compliqué d'autant plus qu'il y a une foultitude de logiciels mails et encore plus de pinpins dans les entreprises pour trifouiller les paramètres de base. On a beau prendre un échantillon de données sur le système précédent et faire tous les tests avec, on se retrouve toujours avec un cas particulier quelques jours ou quelques semaines après la mise en production et qui oblige à effectuer la correction. Parfois, c'est tellement tordu comme erreur qu'on préfère ne pas corriger et descendre l'information au N1 que le bug vient du coté client (bah oui un mail vide, on n'envoie pas un fax page blanche...). Mais une correction en production c'est minimum 2 semaines à 5 ingénieurs entre l'extraction des données de prod, la simul en lab, la reproduction du bug, l'étude du correctif, test et validation de la correction en lab, rejouer les scénarios de test précédent pour vérifier qu'il n'y a pas d'effet de bord indésirable, mettre en production (en HO si pas d'interruption de service, en HNO sinon), et ensuite surveiller si tout fonctionne bien en production et parfois faire un rollback, et dans ce cas faire une étude sur les pourquois et comments du rollback et justifier la décision aux supérieurs. Même si l'étude n'existe prétendument pas, dire que c'est 100X plus cher c'est limite sous-estimé
0  0 
Avatar de mach1974
Membre averti https://www.developpez.com
Le 27/07/2021 à 10:04
C'est pourquoi en avant projet il faut bien voir les types de tests à faire . Entre les tests unitaires et avant de faire des tests fonctionnels, il faudrait des bouts en bouts en environnement utilisateur avant.
0  0 
Avatar de CaptainDangeax
Membre expérimenté https://www.developpez.com
Le 27/07/2021 à 10:18
Citation Envoyé par mach1974 Voir le message
C'est pourquoi en avant projet il faut bien voir les types de tests à faire . Entre les tests unitaires et avant de faire des tests fonctionnels, il faudrait des bouts en bouts en environnement utilisateur avant.
On a beau faire tous les tests possibles, on n'arrive jamais à reproduire totalement les conditions de production, notamment en terme de charge. Non seulement on n'arrive jamais à simuler la charge réelle du système en production et encore moins ses surcharges, mais en plus les ressources techniques sont toujours limitées et il faut arriver à une saturation pour que les grands yakas délient les cordons de leur bourse. Genre (expérience personnelle) c'est seulement quand le projet est passé de 200 GB à 650 GB de logs par jour (remplacement de la messagerie par du MS Exchange) et un arrêt de la production que le SAN de collecte est passé de 500 GB à 1 TB ; bien évidemment l'équipe en charge de la migration vers Exchange était bien incapable de dire la volumétrie de logs de leur nouvelle plateforme, finalement ce sont eux qui ont pris le coup de règle sur les doigts mais bon...
0  0