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 ? 
Envoyé par mach1974
