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

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Chroniqueur Actualités

    Homme Profil pro
    Rédacteur technique
    Inscrit en
    juin 2016
    Messages
    2 084
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Bénin

    Informations professionnelles :
    Activité : Rédacteur technique
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : juin 2016
    Messages : 2 084
    Points : 45 988
    Points
    45 988
    Par défaut Tout le monde cite l'étude : « les bogues sont 100 fois plus chers à corriger en production »
    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 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.

    Nom : c0542b3e-d76a-4be4-9477-92d1ef365864.png
Affichages : 2086
Taille : 5,8 Ko

    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 ?
    Contribuez au club : corrections, suggestions, critiques, ... Contactez le service news et Rédigez des actualités

  2. #2
    Modérateur
    Avatar de grunk
    Homme Profil pro
    Architecte Web / Android
    Inscrit en
    août 2003
    Messages
    6 389
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Côte d'Or (Bourgogne)

    Informations professionnelles :
    Activité : Architecte Web / Android
    Secteur : Industrie

    Informations forums :
    Inscription : août 2003
    Messages : 6 389
    Points : 18 566
    Points
    18 566
    Par défaut
    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 ...
    Pry Framework php5 | N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  3. #3
    Expert confirmé Avatar de marsupial
    Homme Profil pro
    Retraité
    Inscrit en
    mars 2014
    Messages
    1 330
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Autre

    Informations professionnelles :
    Activité : Retraité

    Informations forums :
    Inscription : mars 2014
    Messages : 1 330
    Points : 5 039
    Points
    5 039
    Par défaut
    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.
    Repeat after me
    Le monsieur lutte pour la défense des libertés individuelles et collectives

    Repeat after me...

  4. #4
    Membre à l'essai
    Homme Profil pro
    Chef de projet en SSII
    Inscrit en
    juin 2012
    Messages
    3
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Chef de projet en SSII

    Informations forums :
    Inscription : juin 2012
    Messages : 3
    Points : 14
    Points
    14
    Par défaut on trouve des études sérieuses en 10 minutes
    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

  5. #5
    Membre extrêmement actif
    Homme Profil pro
    Inscrit en
    janvier 2014
    Messages
    1 206
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : janvier 2014
    Messages : 1 206
    Points : 4 508
    Points
    4 508
    Par défaut
    Ç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 !
    « L’humour est une forme d'esprit railleuse qui s'attache à souligner le caractère comique, ridicule, absurde ou insolite de certains aspects de la réalité »

  6. #6
    Membre expérimenté
    Profil pro
    Ingénieur système Linux N3
    Inscrit en
    juillet 2008
    Messages
    399
    Détails du profil
    Informations personnelles :
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Ingénieur système Linux N3

    Informations forums :
    Inscription : juillet 2008
    Messages : 399
    Points : 1 361
    Points
    1 361
    Par défaut Retour de terrain
    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é

  7. #7
    Membre régulier
    Profil pro
    Inscrit en
    février 2010
    Messages
    92
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : février 2010
    Messages : 92
    Points : 120
    Points
    120
    Par défaut Tests
    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.

  8. #8
    Membre expérimenté
    Profil pro
    Ingénieur système Linux N3
    Inscrit en
    juillet 2008
    Messages
    399
    Détails du profil
    Informations personnelles :
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Ingénieur système Linux N3

    Informations forums :
    Inscription : juillet 2008
    Messages : 399
    Points : 1 361
    Points
    1 361
    Par défaut de la mise en production
    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...

Discussions similaires

  1. Réponses: 13
    Dernier message: 11/09/2019, 17h06
  2. Réponses: 5
    Dernier message: 15/05/2019, 16h11
  3. Réponses: 170
    Dernier message: 12/09/2018, 11h57
  4. Réponses: 11
    Dernier message: 25/11/2016, 01h12
  5. Réponses: 6
    Dernier message: 25/09/2009, 12h03

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo