Frais de développement Pyramid Software [fermé]

Question

Un ami me disait l'autre jour qu'il ya une pyramide pour les coûts de la fixation d'un problème dans le cycle de vie du développement logiciel. Où pourrais-je trouver?

Il faisait référence au coût de la fixation d'un problème.

Par exemple,

  

Pour résoudre un problème au stade exigences coûte 1.

     

Pour résoudre un problème au stade de développement coûte 10.

     

Pour résoudre un problème au frais phase de test 100

     

Pour résoudre un problème au stade des coûts de production 1000.

(Ces chiffres ne sont que des exemples)

Je serais intéressé à voir plus sur ce si quelqu'un a des références.

Answer 1

Le taux incroyable de Diminishing Returns de la correction de bugs logiciels

(Stefan Priebsh: POO et design patterns: Codeworks DC en Septembre 2009)

Answer 2

Ceci est un résultat bien connu en génie logiciel empirique qui a été reproduit et vérifié maintes et maintes fois dans d'innombrables études. Ce qui est très rare dans le génie logiciel, malheureusement: la plupart des logiciels d'ingénierie « résultats » sont essentiellement du ouï-dire, des anecdotes, des suppositions, des opinions, Wishful Thinking ou tout simplement de mensonges. En fait, la plupart des logiciels d'ingénierie ne méritent probablement pas la marque « d'ingénierie ».

Malheureusement, en dépit d'être l'un des plus solides, plus scientifiques et statistiques, plus fortement documenté, le plus largement vérifiées, le plus souvent répliquées résultats de l'ingénierie logicielle, il est également faux.

Le problème est que toutes ces études ne contrôlent pas leurs variables correctement. Si vous voulez mesurer l'effet d'une variable, vous devez être très attention au changement uniquement que un variable et que les autres variables don « t changement tout . Non « changer quelques variables », et non « minimiser les changements à d'autres variables ». « Un seul » et les autres « pas du tout ».

Ou, dans les mots brillants de Zed Shaw. Si vous voulez mesurer la merde, ne mesurent pas d'autres conneries

Dans ce cas particulier, ils ont fait pas juste mesure dans laquelle phase (besoins, analyse, architecture, conception, implémentation, tests, maintenance) le bug a été trouvé, ils aussi comment mesurer long il est resté dans le système. Et il se trouve que la phase est à peu près hors de propos, tout ce qui compte est le temps. Il est important que les bugs sont disponibles rapide , pas dans quelle phase.

Cela a des ramifications intéressantes: s'il est important de trouver des bugs rapide , alors pourquoi attendre si longtemps avec la phase qui est le plus susceptible de trouver des bugs: tests? Pourquoi ne pas mettre les tests à la commençant

Le problème avec l'interprétation « traditionnelle » est qu'il conduit à des décisions inefficaces. Parce que vous assumez vous avez besoin de trouver tous les bugs durant la phase d'exigences, vous faites glisser la phase d'exigences inutilement long: vous ne pouvez pas run exigences (ou des architectures ou des modèles), alors trouver un bug dans quelque chose que vous ne pouvez même pas exécuter flippe dur ! En fait, alors que fixation bugs dans la phase des exigences est pas cher, trouver eux est cher.

Si, cependant, vous vous rendez compte que ce n'est pas de trouver les bugs dans la première phase possible , mais plutôt de trouver les bugs le plus tôt possible , vous peuvent faire des ajustements à votre processus, de sorte que vous déplacez la phase dans laquelle trouver bogues est moins cher (test) au moment où fixation les moins cher est (le début ).

---

Note: Je suis bien conscient de l'ironie de mettre fin à une diatribe de ne pas appliquer correctement les statistiques d'une réclamation complètement non fondées. Malheureusement, j'ai perdu le lien où je lis cela. Glenn Vanderburg également mentionné cela dans son « A Software Engineering » parler à la conférence Ruby Lone Star 2010, mais AFAICR, il ne cite aucune source, que ce soit.

Si quelqu'un connaît des sources, s'il vous plaît faites le moi savoir ou modifier ma réponse, ou même simplement voleras ma réponse. (Si vous pouvez trouver une source, vous méritez tout le représentant!)

Answer 3

Voir pages 42 et 43 cette de présentation (pdf).

Malheureusement, la situation est que Jörg met en scène, en fait un peu moins bonne: la plupart des références citées dans cette grève du document moi comme faux, dans le sens que le document cité soit ne sont pas des recherches originales, ou ne contient pas les mots appui de la demande réalisés, ou - dans le cas de la 1998 papier à propos de Hughes (le p54) - contient des mesures que en fait en contradiction avec ce qui est impliqué par la courbe p42 de la présentation: une forme différente de la courbe, et un modeste x5 au facteur x10 du coût à fixer entre la phase des exigences et la phase de test de fonctionnement (et de diminuer effectivement dans le test du système et la maintenance).

Answer 4

Jamais entendu parler appelé une pyramide avant, et qui semble un peu à l'envers pour moi! Pourtant, la thèse centrale est largement considéré comme correct. juste épaisseur à ce sujet, les coûts de la fixation d'un bogue dans l'alpha stade sont souvent trivial. En phase bêta, il peut prendre un peu plus de débogage et des rapports utilisateurs. Après la livraison, il pourrait être très coûteux. une toute nouvelle version doit être créée, vous avez à vous soucier de casser le code et les données en production, il peut y avoir aussi des ventes perdues en raison du bug?

Answer 5

Essayer cette article . Il utilise l'argument « pyramide coût » (nom non ce), entre autres.