Est-il beaucoup plus coûteux de corriger un bogue à la fin du projet?

21

Dans un article de blog d'Andrew Hay , l'axiome suivant a été posé:

Corriger un bogue à la fin du projet coûte beaucoup plus cher que de corriger le même bogue plus tôt dans le projet.

Cependant, cela ne semble pas certain, surtout après avoir lu un article de blog sur Less Wrong , et les données que j'ai vues pour le sauvegarder sont extrêmement anciennes.

Cet axiome est-il toujours exact aujourd'hui?

Stefan Hendriks
la source
@StefanHendriks Les commentaires dans votre article lié à Morendil couvrent vraiment tout ce que vous pourriez demander; A MON HUMBLE AVIS. Grande information là-bas.
Aaron McIver
@AaronMcIver, mon intention est de faire en sorte que plus de gens le sachent. Comme passer le mot et augmenter les chances d'obtenir de vraies données. Je ne recherche pas une vraie discussion; de grandes ont lieu à l'article (comme vous l'avez également découvert :)).
Stefan Hendriks
2
Salut Stefan, ce n'est pas un forum de discussion, ni une boîte à savon: j'ai supprimé votre commentaire de la question. Nous pouvons vous aider à expliquer les aspects du développement de logiciels, mais si vous cherchez à utiliser ce site comme un moyen de promouvoir vos idées ou de partager des articles de blog que vous avez aimé, vous êtes au mauvais endroit.
Bien que cela ait certainement à voir avec la programmation, la nature de la question peut en fait la rendre plus appropriée sur critics.stackexchange.com.
StriplingWarrior

Réponses:

16

Les seules données réelles que j'ai jamais vues sont Boehm et Papaccio, Comprendre et contrôler les coûts des logiciels .

Cela remonte à 1988 et était une étude d'environ 80 projets logiciels. Ils ont conclu qu'une décision prise tôt et corrigée tardivement pourrait coûter 50 à 200 fois ce qu'elle aurait été si elle avait été corrigée tôt. Mais le type de décisions très précoces dont ils parlent sont le système d'exploitation sur lequel s'exécuter et la langue et la base de données à utiliser.

Ces chiffres peuvent donc être exagérés par rapport au développement logiciel d'aujourd'hui. Cependant, nous avons maintenant beaucoup d'expérience dans le domaine et nous savons instinctivement que cela reste vrai jusqu'à un certain point.

À l'extrême, nous savons que si une défaillance des exigences est détectée juste avant de passer à la production, cela entraîne beaucoup de retouches et retarde ou annule le projet, où s'il avait été détecté avant la fin des travaux, nous ça aurait été bien.

Edit: Doc Brown fait un bon point dans son commentaire.

Les recherches de Boehm ont été effectuées sur les projets COBOL et FORTRAN à une époque où les temps de compilation et d'exécution étaient ridiculement lents. J'ai commencé ma carrière au début des années 90 sur COBOL et le cycle de compilation et de test prenait si longtemps qu'il valait la peine de tester à sec le code avant de passer par le cycle (ou au moins pendant la phase de construction, juste au cas où vous pourriez attraper quelque chose et l'annuler tôt, vous épargnant une heure environ).

À leur tour, nos patrons se moquaient de nos plaintes car il n'y a pas si longtemps, ils devaient transporter une boîte de cartes perforées triées à la main dans la salle des serveurs et la laisser là pendant une journée.

C'était donc bien plus vrai qu'à l'époque.

Et pourtant, très récemment, j'ai vu des blogs réutiliser la visualisation de Steve McConnell de ce problème ( réf , datée de 1996) comme si ce graphique était en fait basé sur des nombres réels. Ce n'est pas le cas. C'est une visualisation, pour expliquer simplement son propos.

Je pense que la prémisse de Morendil, dans l'article cité par le PO, est bonne. La science que nous avons à ce sujet est pauvre et dépassée et pourtant traitée comme un canon. Mais je pense aussi que cela résiste bien et semble vrai parce que nous savons par expérience amère que c'est toujours vrai, au moins jusqu'à un certain point. Et je pense que son phrasé dramatique de «discipline malade» ne lui est d'aucun secours.

pdr
la source
3
+1. Je pense qu'il faut ajouter que les recherches de Boehm ont été faites à une époque où les coûts de construction et de déploiement des versions de correction de bugs étaient beaucoup plus élevés qu'aujourd'hui.
Doc Brown
@DocBrown: Bon point. Ajoutée. Avec une autre randonnée.
pdr
+1 pour référence en effet, +1 pour la visualisation (dommage que je ne puisse donner qu'un point.) Excellente réponse, merci!
Stefan Hendriks
15

Bien que je ne sois au courant d'aucune donnée solide ou autre preuve à l'appui de cette affirmation, au minimum , je pense que c'est du bon sens.

Pensez-y de cette façon. Si vous avez un système complexe avec des sous-systèmes interdépendants (comme le font la plupart des applications non triviales), pensez aux problèmes d'activation qui peuvent être le résultat de modifications apportées à l'un des systèmes. Si les sous - systèmes se sont révélés être correct (via des tests unitaires, etc.) et fixés au début, le nombre de bugs qui seront causés en raison de frapper les modules seuls sont simplement atténué par la fixation précoce.

De plus, si vous corrigez des bogues tôt, la mise en œuvre est encore fraîche dans l'esprit du développeur. Selon la durée d'un projet donné, si vous corrigez des bogues à la fin, le développeur devra passer du temps à comprendre ce qu'il a écrit et (peut-être) comment les sous-systèmes dont dépend leur code dépendent de leur fonctionnement. Temps passé à réapprendre ceci = $.

Demian Brecht
la source
1
Donc, fondamentalement, nous parlons de la quantité d'efforts nécessaires pour corriger un bogue plus tard (ou plus tôt). Je peux penser à d'autres facteurs qui rendent les bogues plus chers s'ils sont corrigés plus tard. Mais cela dépend de votre définition du bug. C'est peut-être quelque chose à convenir en premier. Dans mon livre, c'est aussi une «attente sans correspondance dans cette version». Comme, une fonctionnalité manquante. Cela pourrait coûter de l'argent réel, donc c'est plus évident alors. Certaines fonctionnalités pourraient cependant ne pas coûter plus cher (comme pour les sites Web, les modifications CSS?) Maintenant que tôt. Ou pas beaucoup plus. Pourtant, je n'ai pas de données.
Stefan Hendriks
@StefanHendriks: Nous parlons à la fois de la quantité d'effort nécessaire et des nouveaux bugs encourus par les correctifs revendiqués. Vous auriez probablement à creuser dans des projets post mortem (ceux qui ont utilisé les deux méthodes) pour obtenir des données réelles.
Demian Brecht
2
@AaronMcIver: Ce que je retiens de l'article n'est pas quelle méthode est la meilleure, mais que les recherches et les données solides utilisées pour sauvegarder la réclamation et les interprétations erronées dans les rapports ultérieurs. Bien que ma réponse ne soit pas basée sur des données publiques, elle est basée sur plus de 10 ans d'expérience professionnelle dans les systèmes très complexes.
Demian Brecht
1
BTW Je ne suis pas d'accord que les changements CSS ne souffrent pas de cela. Essayez de résoudre un problème de mise en page une fois que vous avez tous les autres éléments pixel parfait et vous constaterez que vous devrez peut-être casser beaucoup de choses
Andrea
1
@DemianBrecht Votre réponse est très subjective, c'est pourquoi je demande. C'est de la spéculation et un sentiment d'intestin. Bien que ceux-ci puissent certainement avoir du poids, le problème est qu'il peut le plus souvent être une représentation inexacte de la réalité, comme le souligne l'article. Utiliser le bon sens comme critère pour expliquer pourquoi cela peut coûter plus cher peut également être inversé. Vous pourriez faire valoir que le nombre d'individus impliqués dans une correction de bogue peut être le véritable facteur qui en coûte plus ou non, sans tenir compte des efforts réels des développeurs.
Aaron McIver
12

Je doute qu'il soit possible de trouver une manière scientifiquement rigide de mesurer cela - il y a tout simplement trop d'autres facteurs impliqués, et aucun projet n'est suffisamment comparable pour servir plus que des études de cas. La réflexion logique devrait cependant vous faire avancer. Quelques arguments:

  • La quantité totale de code dans un projet a tendance à augmenter vers la fin. Plus vous attendez la correction d'un bogue, plus la base de code que vous devez toucher est grande.
  • La qualité du nouveau code ajouté à un projet diminue vers la fin, du moins s'il y a une pression (qui est généralement une donnée): une échéance imminente oblige les gens à jeter par-dessus bord les meilleures pratiques juste pour expédier à temps. Cela signifie que plus vous corrigez un bogue tard, plus vous avez de code à filtrer.
  • Même si la duplication de code est généralement désapprouvée, cela se produit tout le temps, et comme il est facile de copier-coller, mais difficile de re-fusionner des sections de code en double, la quantité de code une fois copié augmente généralement au cours de la durée de vie d'un projet. Plus de code copié-collé signifie plus de chances que votre bogue soit dupliqué et doive être trouvé et corrigé plusieurs fois (et par conséquent, plus de chances que certaines de ses occurrences passent inaperçues).
  • La correction d'un bogue est une modification d'une base de code; vous espérez améliorer les choses, mais un changement comporte toujours un risque. Un changement qui cause de sérieux problèmes dans un projet avec des mois à parcourir devrait laisser beaucoup de marge pour la gestion des dommages, mais deux jours avant l'expédition, vous avez de sérieux problèmes.
  • Plus le bogue lui-même existe, plus il est probable que d'autres parties de l'application commencent à se fier à son mauvais comportement. Ensuite, lorsque vous le corrigez, vous déclenchez soudainement un tas de bogues secondaires dans le code qui ne s'attend pas à ce que votre fonction fournisse réellement les résultats documentés corrects.
tdammers
la source
+1. Très bonne réponse. Copier et coller du code contenant des bogues génère plus de bogues en fonction des modules qui en dépendent.
Karthik Sreenivasan le
2

Il s'agit d'ingrédients de base acceptés par l'ingénierie des systèmes - et cela s'applique à toute forme de développement technique (que ce soit la construction de ponts, de missiles, de cuirassés ou de logiciels).

Essentiellement, le coût des choses augmente d'environ un ordre de grandeur à mesure que vous progressez dans les étapes de développement.

Quelque chose qui coûte 10 $ à réparer au moment de concevoir l'idée ...

Coûtera environ 100 $ si vous avez besoin de mettre à jour les spécifications ....

Ou coûter environ 1000 $ si quelque chose a été mis en œuvre et vous devez apporter des modifications à ce stade (et mettre à jour les spécifications, obtenir les approbations, etc.), mais il n'a pas subi une sorte de test d'acceptation / de vente officiel

Ou coûter environ 10000 $ si quelque chose a été implémenté et accepté par le client, et vous devez apporter des modifications à ce stade (et mettre à jour les spécifications, obtenir les approbations, et tester à nouveau et réexécuter l'acceptation et la qualification du client, etc.)

Et le coût après déploiement / déploiement / mise en service est encore plus élevé.

Les exemples abondent et il est facile de les comprendre: un système bancaire avec un sérieux changement de périmètre effectué après que 25000 employés l'utilisent coûtera un paquet en temps de recyclage ... avant même d'envisager la portée, le codage, le test, la régression, etc etc etc.

NOTAMMENT, votre kilométrage variera: les coûts et les impacts du changement du site Web de commerce électronique de réchauffement de chaussettes de Fred Nurke sont quelque peu différents des coûts de changement de logiciel sur un ordinateur de contrôle de vol d'avion.

vite_maintenant
la source
1
Dites, vous livrez chaque mois une nouvelle version d'un logiciel à vos utilisateurs (ou simplement des correctifs, comme MS le fait pour Windows). Maintenant, deux bogues apparaissent, un qui a été introduit dans le logiciel il y a deux ans, un qui a été introduit le mois dernier. Le coût de la correction de ces deux bogues et du déploiement de la nouvelle version peut être pratiquement le même. Le coût de la résolution des problèmes causés par l'un de ces bogues peut être différent, mais cela dépend beaucoup du bogue lui-même.
Doc Brown
Pas tout à fait la même chose - c'est après l'expédition. Les coûts après expédition sont de même ampleur (ils ont tous besoin de mises à jour, de tests, de déploiement.) Ce que je souligne ci-dessus, c'est que les coûts augmentent considérablement après la sortie.
vite_maintenant
1
"post-release" est un état valable pour les logiciels embarqués, dans une certaine mesure pour les logiciels sous film rétractable, et aussi pour les logiciels développés dans un modèle en cascade (malencontreux!). D'autres types de logiciels sont développés et diffusés de manière incrémentielle, le temps "post-release" est pratiquement réduit par rapport à la durée de vie du produit. C'est particulièrement le cas pour les applications Web.
Doc Brown
Ce pourrait être le cas pour les applications Web, mais ce n'est pas tout l'univers. Et les machines à laver? Voitures? Des missiles? Systèmes d'exploitation PC? Centrales? Des automates exploitant des cimenteries? Et ainsi de suite et sur la liste continue.
quick_now
2

Je n'ai pas accès à des données ou faits concrets, je ne peux donc que vous proposer des observations anecdotiques glanées au cours de mes 20 dernières années en informatique.

Je pense qu'il y a une grande différence entre la façon dont la plupart des développeurs créent des logiciels aujourd'hui par rapport à il y a 20 ans. Avec le mouvement Agile ayant pris tellement d'élan, en particulier au cours des 5 à 6 dernières années, j'ai vu un réel changement d'attitude sur le lieu de travail. À tel point que la qualité de ce que nous faisons semble croître à pas de géant chaque année, et à chaque projet lorsque nous appliquons les leçons que nous avons apprises de projet en projet. Les processus plus légers combinés à l'accent mis sur le développement test-first sont passés de très controversés à banals. À tel point que pour entrer dans de nombreuses entreprises aujourd'hui, si vous n'êtes pas à l'aise avec Agile, vous aurez de la chance s'ils ne vous montrent pas la porte.

Quel impact cela a-t-il donc eu? Tout d'abord, j'ai remarqué que les problèmes sont souvent identifiés bien plus tôt. Il arrive souvent que si le problème ne semble pas trop important, il peut parfois être suspendu indéfiniment. Dans quelques rares cas, j'ai vu des bogues qui étaient considérés comme insignifiants devenir de sérieux problèmes lorsqu'ils sont résolus plus tard, car un problème fondamental devient évident qui n'a pas été pris en compte à l'époque. Parfois, cela peut conduire à un cycle de réparation prolongé, et cela peut être coûteux dans une certaine mesure, mais ce coût est souvent mesuré moins en termes de ressources, et plus souvent en termes d'impact sur la relation entre le client et le développeur. Les clients sont de plus en plus habitués à cette façon de penser agile, qui leur donne des résultats beaucoup plus rapidement qu'auparavant, avec des sprints de développement hautement itératifs et un délai d'exécution rapide entre les demandes et la mise en œuvre, ils attendent donc beaucoup de nous. Et en ce qui concerne les bogues réels, le temps de correction d'un bogue est le plus souvent considérablement réduit du fait de disposer d'une suite solide de tests pour prendre en charge les modifications et de la possibilité de créer de nouveaux tests à partir desquels fournir des informations et des solutions. aux problèmes signalés.

Donc, dans l'ensemble, il semble que l'effort global pour corriger les bogues ait été dans la plupart des cas réduit s'il y a une suite robuste de tests en place, et des procédures pour s'assurer que les tests restent au centre de ce que fait le développeur, mais le coût réel à certains égards, s'est déplacé en partie au moins de la mise en œuvre vers d'autres secteurs de l'entreprise, car à certains égards, l'accent est également passé de l'offre et de la demande pures à la gestion des relations.

Une autre chose qui est devenue évidente, c'est que nos instincts intestinaux d'il y a quelques années, qui suggéraient qu'être Agile réduirait nos cycles de maintenance, ont été prouvés dans une certaine mesure à la fois bien et mal. Juste en ce sens que des tests solides ont facilité le débogage et la correction de notre code dans une large mesure, et de réduire globalement le nombre de bogues publiés dans le code de production, et faux en ce sens que nous travaillons maintenant plus dur pour éviter d'avoir à maintenir le code hérité, en refactorisant constamment le code et en améliorant l'architecture de sorte qu'il devient de plus en plus rare que nous devions développer de nouveaux produits complètement à partir de zéro.

Donc au final, qu'est-ce que cela signifie par rapport à la question du PO? Eh bien, cela signifie que la réponse n'est vraiment pas aussi simple que nous l'aurions cru une fois. Il y a 15 ans, j'aurais probablement répondu à la question par Oui, mais maintenant je pense qu'il est plus réaliste de dire qu'il est vraiment trop difficile de mesurer empiriquement, car la nature de ce que nous faisons pour développer des logiciels a beaucoup changé depuis que nous avons commencé à nous poser la question du PO à l'époque. À certains égards, plus nous faisons progresser nos techniques et nos compétences en tant qu'industrie, plus la question passe d'un oui définitif à un point où je soupçonne que dans un court nombre d'années, nous dirons que cela n'a pas d'importance lorsque nous corrigeons des bogues, parce que nos tests et processus seront tellement plus robustes, que le timing des corrections de bogues sera moins motivé par les efforts pour économiser nos budgets, et plus par les priorités pour satisfaire les besoins de nos clients, et le coût relatif sera devenir pratiquement sans signification contextuellement.

Mais comme je l'ai dit, ce ne sont pas des preuves solides appuyées par des données, juste mes observations des dernières années, et mes tripes me disent qu'il y aura plus de sagesse révolutionnaire à venir qui améliorera la façon dont nous faisons les choses.

S.Robins
la source
1

Les premiers bogues se propageront à d'autres parties du système, donc lorsque vous corrigez le bogue, vous serez peut-être obligé de réécrire certaines parties du système qui dépendaient du bogue lui-même.

À côté du temps, vous comprendrez comment certaines parties du programme sont construites et vous devrez vous rappeler. C'est une forme de dette technique (si vous précipitez le projet à un stade précoce, vous aurez des problèmes pour le terminer en raison des raccourcis que vous avez pris).

C'est aussi simple que cela et il n'y a rien à prouver.

Je pense que vous essayez de précipiter le projet le plus rapidement possible pour présenter une solution de travail à votre employé. Les bonnes nouvelles sont que vous les aurez très rapidement, les mauvaises nouvelles sont que vous ne les terminerez probablement jamais sans réécriture complète si vous continuez à écrire de la merde aussi vite que possible et prévoyez de tout réparer dans quelques mois. Vous ne pourrez probablement même pas refactoriser cela.

Slawek
la source
Oui, tout cela a du sens. Cependant, je me demande si cela est très différent de la correction ultérieure. Oui, vous devez réapprendre un peu les choses. Cependant, peut-être qu'en ne publiant pas plus tôt, vous avez perdu plus d'argent que le coût de la résolution de ce problème. Est-ce que cela rendrait ce problème bon marché ou coûteux à résoudre? Même quand c'est moins de travail parce que c'était au début?
Stefan Hendriks
2
La réparation d'un système déjà sorti est beaucoup plus compliquée. Vous ne pouvez pas simplement réécrire des structures de données par exemple. Vous devrez fournir aux utilisateurs un moyen de migrer leurs données. Encore une fois, si vous publiez trop tôt, vous vous retrouverez dans un désordre, au lieu de corriger les bugs, vous perdrez du temps à écrire du code de migration. Peut-être que vous perdez de l'argent, c'est mieux que de perdre des clients à cause de la vente de logiciels moche.
Slawek
>> ... vous devez réapprendre un peu les choses ... Les cas Edge en particulier rendent cela délicat et non trivial. Les interactions en dehors de l'immédiat sont vite oubliées, sauf si vous avez une spécification exhaustive, correcte et maintenue .
DaveE
1

Eh bien, je ne peux probablement pas vous donner la preuve définitive que vous demandez, mais je peux raconter un incident assez récent de mon travail.

Nous avons ajouté une fonctionnalité qui fournissait des capacités de gestion du flux de travail à notre produit. Trucs BDUF typiques, spécifications approuvées et approuvées par le client. Implémenté selon les spécifications. Plaintes du jour 1 sur le déploiement.

Nous n'avions pas fait une véritable revue de la convivialité avec le client, nous avions simplement pris leur parole pour ce qu'ils voulaient. Résultat: des centaines d'heures de retouches - analyse, conception, implémentation et assurance qualité ont dû être refaites. Tout cela parce que la spécification a manqué des cas d'utilisation particuliers. Un bug dans la spécification, si vous voulez.

J'ai vu des choses similaires dans des emplois précédents lorsque quelqu'un dans la chaîne émet des hypothèses différentes de celles de l'utilisateur final. Les bogues de codage simples sont relativement faciles à traiter s'ils sont détectés près du moment où ils se produisent, mais les bogues de conception peuvent tuer des systèmes entiers.

DaveE
la source
1

Si vous corrigez le bogue après la publication, vous avez le coût de la recherche et de la correction du bogue - ce qui peut ou non prendre plus de temps / coût pour faire après la publication. Cependant, vous aurez une série de tests d'intégration, de tests de régression, de tests UA, d'activités de publication, etc. qui devront être pris en compte. À moins que le correctif de bogue n'aille avec un certain nombre d'autres correctifs ou une mise à jour de version, vous aurez des dépenses supplémentaires pour les activités de test et de publication qui seraient évitées en incluant le correctif dans la version initiale - car ces coûts seraient partagés sur un certain nombre de correctifs / mises à jour / fonctionnalités.

Tenez également compte du coût que le bogue entraînera lors de son utilisation, s'il n'est que cosmétique, alors cela n'a probablement pas d'importance, mais un bogue de fonction ou de performance pourrait créer un coût avec des activités de support ou une productivité réduite ou des calculs incorrects.

adam f
la source
1

Demandez à Intel combien leur a coûté le Pentium Bug, la fusée Ariane 5 en est un autre bon exemple. Ces bugs ont été corrigés à la fin du projet. J'ai travaillé sur un système où une "tentative" de sortie de logiciel a un budget de 6 chiffres. Dans ces cas extrêmes, il est facile de voir le coût. Dans d'autres cas (la plupart?), Le coût est masqué par le bruit, mais il est toujours là.

Il ne fait aucun doute que les bogues coûtent de l'argent lorsqu'ils existent. Un élément, les rapports de défauts, prend du temps à compiler, à trier et à fermer comme dup, le temps c'est de l'argent - donc un bogue ouvert crée un coût continu. par conséquent, il faut que le report des corrections de bogues coûte plus cher que leur correction plus tôt.

Si un bug s'échappe dans la nature, le coût a un saut pas à pas ...... Est-ce que "La fin du projet" est avant ou après la sortie du logiciel?

mattnz
la source
Les bogues logiciels dans le monde embarqué sont nettement plus chers à corriger à la fin du projet. Imaginez avoir à faire un rappel sur la voiture à cause d'un bug logiciel dans le module de contrôle moteur.
tehnyit
Les bogues que vous mentionnez n'ont pas été trouvés tôt et n'ont donc pas été corrigés tôt.
@ Thorbjørn Vous avez en effet raison - bien que nous n'ayons pas trouvé au début les défauts que nous avons insérés tôt (dans le cas de The Ariane Rocket, le bogue a été inséré avant même le démarrage du projet, car ils réutilisaient le code existant.). Le coût est proportionnel au temps entre l'insertion et la correction déployée, rien à voir avec le moment où il est trouvé ou corrigé (la plupart des développeurs le considèrent comme corrigé une fois le correctif dans la base de code. Un défaut n'est pas corrigé tant que les utilisateurs finaux ne l'ont pas installé ). Tout cela n'est que IMHO - je n'ai aucune preuve pour le soutenir.
mattnz
1

J'ai lu une fois un article qui avait deux points intéressants (malheureusement, les références que j'avais avaient disparu depuis longtemps, je vais donc devoir postuler ici). Le premier point qu'ils ont fait valoir est qu'environ 50% de toutes les erreurs ont été introduites dans la spécification des exigences et qu'environ 90% de toutes les erreurs ont été détectées lors des tests UAT ou système.

Le deuxième point qu'ils avaient était que pour chaque phase du modèle en V, le coût avait été multiplié par 10. Que le facteur soit correct ou non, je trouve cela peu pertinent, mais les erreurs les plus coûteuses se produisent lorsque votre conception est basée sur une hypothèse incorrecte. Cela conduit à une énorme quantité de réécriture. Tout le code qui fonctionne à cause de cette hypothèse mais échoue lorsque l'hypothèse correcte est appliquée devra être réécrit.

J'ai rencontré le modèle de domaine entier devant être réécrit en raison d'une hypothèse incorrecte dans les spécifications des exigences. Si un tel bug est détecté tôt, c'est-à-dire lors de l'examen des spécifications des exigences, le coût est très faible. Dans ce cas particulier, il aurait fallu dix lignes de texte. Dans le cas où il est trouvé pendant l'UAT (comme c'était le cas), le coût est substantiel (dans l'exemple donné, le coût du projet a été augmenté de 50%)

Rune FS
la source
1

Pas de données statistiques, mais une expérience personnelle:

Le code de commande du moteur de fusée sur lequel je travaillais avait une ligne semblable powerCutoff = someCondition && debugOptions.cutoffIsAllowed;. L'option par défaut était aucune coupure autorisée. La version «finale» était censée supprimer toutes les options de débogage, donc la ligne a été modifiée pourpowerCutoff = someCondition; .

Avez-vous attrapé le bogue lors de la révision du code? Nous ne l'avons pas fait. La première fois que la condition de déclenchement s'est produite lors du test, provoquant une coupure inattendue, c'était quelques mois seulement avant le premier vol.

Ce bug aurait coûté moins d'une heure s'il avait été détecté lors de l'examen. Cela aurait pu coûter un jour ou deux s'il avait été intercepté lors de l'intégration, provoquant une seule répétition du test. S'il a été pris lors de la qualification officielle, cela aurait pu coûter une semaine ou deux en provoquant un redémarrage complet de la série de tests avec une nouvelle version.

En l'état, le coût monta en flèche. Nous avons d'abord conçu et exécuté des tests pour déterminer si l'unité de vol pouvait même déclencher la condition. Une fois qu'il a été déterminé qu'il s'agissait d'une possibilité réelle, il y a eu des coûts pour l'ingénierie, la gestion et l'analyse des clients du meilleur correctif, la publication de la nouvelle version, la création et l'exécution d'un nouveau plan de test de régression, les tests du système dans plusieurs unités et simulateurs. Dans l'ensemble, cela a coûté des milliers, voire des dizaines de milliers d'heures de travail. Plus les 15 minutes d'origine pour effectuer le bon changement de code.

AShelly
la source
0

Malheureusement, comme beaucoup de choses, cela dépend.

Si un message de dialogue est mal orthographié, il peut être «trivial» à corriger (mise à jour de la chaîne, reconstruction / package, redéploiement). Ou si une mise en page doit être mise à jour, une modification d'un fichier .css peut être suffisante.

Si le bogue est que la sortie d'une méthode critique qui a une spécification de 100+ pages et une preuve est incorrecte, alors l'enquête elle-même peut prendre des heures ou des jours. C'est ce à quoi se réfère l'ancien «axiome» et ce que, entre autres, TDD et agile essaient d'éviter (échouer tôt et clairement, faire des progrès incrémentiels sûrs, yada).

D'après mon expérience récente avec des équipes multi-scrum sur un seul projet, les `` bugs '' sont généralement des problèmes de fusion / intégration qui n'apparaissent qu'à la fin d'une version lorsque les branches de fonctionnalités sont promues stables. Ce sont les pires, car les conflits nécessitent souvent un soutien inter-équipes alors que les équipes sont pressées de terminer leurs propres objectifs, mais je ne sais pas qu'ils sont plus chers que les autres bugs, car ils surviennent lorsqu'ils se produisent: tard dans la la libération, mais le plus tôt possible. C'est ce qui les rend les pires.

Kristian H
la source