Software-Entwicklungskosten Pyramid [geschlossen]

Question

Es wurde ein Freund mir neulich erzählt, dass es eine Pyramide für die Kosten der ein Problem in der Software-Entwicklungs-Lebenszyklus zu fixieren. Wo könnte ich diese finden?

Er bezog sich auf die Kosten ein Problem zu beheben.

Beispiel:

  

ein Problem beheben auf den Anforderungen Stufe kostet 1.

     

ein Problem in der Entwicklungsphase beheben kostet 10.

     

ein Problem in der Testphase zu beheben kostet 100

     

Um ein Problem bei der Produktion zu beheben kostet 1000.

(Diese Zahlen sind nur Beispiele)

Ich würde sieht dies mehr über interessiert sein, wenn jemand Referenzen hat.

Answer 1

Die unglaubliche Rate des abnehmenden Ertrags von Fixing Software-Bugs

(Stefan Priebsh: OOP und Design Patterns: Codeworks DC im September 2009)

Answer 2

Dies ist ein bekanntes Ergebnis des empirischen Software Engineering, die in zahlreichen Studien immer und immer wieder wiederholt und überprüft wurde. Das ist sehr selten in Software Engineering, leider: Die meisten Software-Engineering „Ergebnisse“ sind im Grunde Hörensagen, Anekdoten, Vermutungen, Meinungen, Wunschdenken oder einfach nur Lügen. In der Tat, die meisten Software-Engineering wahrscheinlich nicht verdienen die "Engineering" Marke.

Leider, trotz einen der fest ist, wissenschaftlich und statistisch gesicherte, am stärksten erforschten, am häufigsten überprüft, am häufigsten replizierten Ergebnisse des Software-Engineering, es ist auch falsch.

Das Problem ist, dass alle diese Studien nicht kontrollieren ihre Variablen richtig. Wenn Sie den Effekt einer Variablen messen wollen, müssen Sie sein sehr zu ändern vorsichtig nur , die ein Variable und dass die anderen Variablen don ‚t Änderung an alle . Nicht „ändert einige Variablen“, nicht „minimieren Änderungen zu anderen Variablen“. „Nur ein“ und die anderen „gar nicht“.

Oder in den brillanten Zed Shaw Worte:., Wenn Sie wollen Scheiße messen, nicht andere Scheiße messen

In diesem speziellen Fall, sie haben nicht misst nur in welcher Phase (Anforderungen, Analyse, Architektur, Design, Implementierung, Test, Wartung) der Fehler gefunden wurde, sie auch gemessen, wie lang im System geblieben. Und es stellt sich heraus, dass die Phase ziemlich irrelevant ist, alles, was die Zeit zählt, ist. Es ist wichtig, dass Fehler gefunden werden schnell , nicht, in welcher Phase.

Das hat einige interessante Konsequenzen: Wenn es wichtig ist, Fehler zu finden schnell , warum dann so lange warten mit der Phase, die am ehesten Fehler zu finden: Testen? Warum legen Sie die Prüfung nicht auf die Anfang

Das Problem mit der „traditionellen“ Interpretation ist, dass es zu einem ineffizienten Entscheidungen führt. Da man davon ausgehen, müssen Sie alle Fehler während der Anforderungsphase finden, ziehen Sie die Anforderungsphase unnötig lange aus: Sie können nicht run Anforderungen (oder Architekturen oder Designs), so zu finden ein Fehler in etwas, dass Sie nicht einmal ausführen ist freaking hart ! Im Grunde genommen, während Fixierung Fehler in der Anforderungsphase billig ist, Suche sie ist teuer.

Wenn Sie jedoch feststellen, dass es nicht um die Fehler zu finden in der frühestmöglichen Phase , sondern um die Fehler zu finden zum frühestmöglichen Zeitpunkt , Ihnen dann Anpassungen an Ihren Prozess machen, so dass Sie die Phase bewegen, in der Suche Bugs ist billigst (Prüfung) zu dem Zeitpunkt, zu dem Fixierung sie am billigsten (ganz am Anfang ).

---

Hinweis: Ich bin mir bewusst, die Ironie eine Tirade über nicht richtig Statistiken mit einem völlig unbegründeten Anspruch Beendigung der Anwendung. Leider verlor ich den Link, wo ich diese Zeilen lesen. Glenn Vanderburg erwähnt dies auch in seinem „ Echt Software Engineering “Vortrag auf der Lone Star Ruby-Konferenz 2010, aber AFAICR, er hat keine Quellen zitieren, auch nicht.

Wenn jemand irgendwelche Quellen kennt, Sie lassen Sie mich wissen oder zu bearbeiten meine Antwort, oder auch nur stehlen meine Antwort. (Wenn Sie eine Quelle finden, die Sie verdienen alle rep!) ??

Answer 3

Siehe Seiten 42 und 43 der diese Präsentation (pdf).

Leider ist die Situation wie Jörg zeigt in der Tat etwas schlechter: Die meisten der zitierten Referenzen in diesem Dokument Streik mich als Schein, in dem Sinne, dass das Papier entweder zitiert ist nicht originäre Forschung, oder enthält keine Worte die Forderung, gemacht werden, oder - im Fall des 1998 Papiers über Hughes (p54) - enthält Messungen, dass in der Tat contradict was durch die Kurve in p42 der Darstellung angedeutet wird: andere Form der Kurve und eine bescheidenen x5 x10 Faktor Cost-to-fix zwischen der Anforderungsphase und die Funktionstestphase (und tatsächlich in Systemtest und Wartung abnehmend).

Answer 4

hörte nie davon eine Pyramide vor genannt wird, und das scheint ein wenig upside-down zu mir! Dennoch ist die zentrale These weit als richtig angesehen. nur dick darüber nach, die Kosten einen Fehler im Alpha-Stadium der Festsetzung sind oft trivial. Durch die Beta-Phase könnte es ein bisschen mehr Debuggen und Anwenderberichte nehmen. Nach der Auslieferung könnte es sehr teuer sein. eine ganz neue Version erstellt werden muss, Sie Sorge haben etwa in der Produktion von Code und Daten zu brechen, gibt es auch Umsatzverluste aufgrund des Fehlers sein kann?

Answer 5

Versuchen Sie, diese Artikel . Es nutzt das „Kosten Pyramide“ Argument (keine Namensgebung), unter anderem.