Software-Entwicklungskosten Pyramide
Ein Freund erzählte mir neulich, dass es eine Pyramide für die Kosten der Behebung eines Problems in der software development life cycle. Wo finde ich diese?
Er bezog sich auf die Kosten der Fehlerbehebung problem.
Beispielsweise
Fix ein problem an der Anforderungen Stufe Kosten 1.
Fix ein problem in der Entwicklungsphase die Kosten 10.
Fix ein problem an der Testphase kostet 100
Um ein problem zu beheben in der Produktion kostet 1000.
(Diese zahlen sind nur Beispiele)
Ich wäre interessiert, mehr über dieses, wenn jemand Referenzen.
- Ich werde die Abstimmung zu schließen, ist diese Frage off-topic, weil es um die Bereitstellung Kosten
- Ich werde die Abstimmung zu schließen, ist diese Frage off-topic, weil es um die Verwaltung eines Projekts, nicht die Programmierung.
Schreibe einen Kommentar
Du musst angemeldet sein, um einen Kommentar abzugeben.
Die Unglaubliche Rate von der Abnehmenden Wirkung der Festsetzung von Software-Bugs
(Stefan Priebsh: OOP und Design Patterns: Codeworks DC im September 2009)
Dies ist ein bekanntes Ergebnis in der empirischen software-engineering, die repliziert wurden und überprüft immer und immer wieder in zahllosen Studien. Das ist sehr selten in software-engineering, leider: die meisten software-engineering "Ergebnisse" sind im Grunde vom Hörensagen, Anekdoten, Vermutungen, Meinungen, Wunschdenken oder einfach nur Lügen. In der Tat, die meisten software-engineering-wahrscheinlich nicht verdient, die "engineering" - Marke.
Leider, trotz des seins eine der solidesten, die meisten wissenschaftlich und statistisch fundierte, am intensivsten erforscht, am meisten überprüft, am häufigsten replizierten Ergebnisse des software-engineering, ist es auch falsch.
Das problem ist, dass alle diese Studien kontrollieren nicht die Variablen richtig. Wenn Sie möchten, Messen Sie die Wirkung einer Variablen, Sie werden sehr vorsichtig zu ändern nur, dass eine variable und anderen Variablen nicht ändern an alle. Nicht "ein paar "Variablen", nicht "minimieren von änderungen an anderen Variablen". "Nur eine" und der andere "gar nicht".
Oder in der genialen Zed Shaw ' s Worte: wenn Sie wollen, um zu Messen, Scheiße, nicht Messen, andere Scheiße.
In diesem besonderen Fall, Sie haben nicht nur Messen, in welcher phase (Anforderungen, Analyse, Architektur, design, Implementierung, Test, Wartung) der Fehler gefunden wurde, Sie auch gemessen, wie lange es blieb im system. Und es stellt sich heraus, dass die phase ist ziemlich unerheblich, was zählt, ist die Zeit. Es ist wichtig, dass Fehler gefunden werden schnell, nicht in der phase.
Dies hat einige interessante Konsequenzen: wenn es wichtig ist, Fehler zu finden schnell, warum dann so lange warten mit der phase, wahrscheinlich um Fehler zu finden: testen? Warum nicht den Test an der Anfang?
Das problem mit der "traditionellen" interpretation ist, dass es führt zu ineffizienten Entscheidungen. Weil Sie davon ausgehen, die Sie brauchen, um herauszufinden, alle Fehler, die während der anforderungsphase, Sie ziehen aus den Anforderungen phase unnötig lange: Sie können nicht laufen Anforderungen (oder Architekturen oder Entwürfen), so finden einen Fehler in etwas, das Sie selbst nicht ausführen ist freaking schwer! Im Grunde, während Befestigung Fehler in der anforderungsphase ist Billig, finden Sie ist teuer.
Wenn Sie jedoch erkennen, dass es nicht über die Suche nach dem Fehler in der frühestmöglichen phase, aber eher über das finden der bugs zum frühest möglichen Zeitpunkt, dann können Sie Anpassungen vornehmen, um Ihren Prozess, so dass Sie verschieben die phase, in der finden bugs billigsten ist (Prüfung) zu dem Zeitpunkt, zu dem Befestigung Sie am billigsten ist (der Anfang).
Hinweis: ich verkenne die Ironie der Beendigung einer Beschwerde über die nicht ordnungsgemäße Anwendung der Statistik eine völlig unbegründete Behauptung. Leider verlor ich den link wo ich das Lesen. Glenn Vanderburg auch erwähnt dies in seinem "Real Software Engineering" Vortrag auf der Lone Star Ruby Conference 2010, aber AFAICR er nicht zitieren irgendwelche Quellen, entweder.
Wenn das jemand kennt irgendwelche Quellen, bitte lassen Sie mich wissen, oder Bearbeiten Sie meine Antwort, oder auch nur stehlen meine Antwort. (Wenn Sie eine Quelle finden, die Sie verdienen alle das rep!)
Siehe Seiten 42 und 43 diese Präsentation (pdf).
Leider die situation so ist, wie Jörg beschreibt, in der Tat etwas schlechter: die meisten der Referenzen zitiert in diesem Dokument schlagen mich als Schein, in dem Sinne, dass das Papier zitiert entweder ist nicht ursprüngliche Forschung, oder nicht enthalten, die Worte unterstützen die Forderung gemacht wird, oder - im Fall der 1998 Papier über Hughes (p54) - enthält Messungen, die in der Tat widersprechen, was angedeutet wird durch die Kurve in p42-Präsentation: verschiedene Form der Kurve, und eine bescheidene x5 bis x10 Faktor der cost-to-fix zwischen den Anforderungen phase und der funktionale test-phase (und tatsächlich verringern-in-system, test und Wartung).
Nie gehört, dass es eine Pyramide vor, und das scheint ein wenig den Kopf, um mich! Noch ist die zentrale these ist weithin als korrekt zu sein. gerade so dick, um es, die Kosten für die Behebung des Fehlers im alpha-Stadium sind oft trivial. Durch beta-Stadium, es könnte ein bisschen mehr debugging-und user-Berichte. Nach dem Versand könnte es sehr teuer werden. eine ganz neue version erstellt werden, müssen Sie sorgen über brechen in der Produktion von code und Daten kann es auch zu entgangenen Umsätzen aufgrund der Fehler?
Versuchen, diese Artikel. Es nutzt die "Kosten Pyramide" - argument (keine Nennung), unter anderem.