Ist es wesentlich kostenintensiver, einen Fehler am Ende des Projekts zu beheben?

In einem Blogbeitrag von Andrew Hay wurde das folgende Axiom aufgestellt:

Das Beheben eines Fehlers am Ende des Projekts kostet erheblich mehr als das Beheben desselben Fehlers zu einem früheren Zeitpunkt im Projekt.

Dies scheint jedoch nicht sicher zu sein, insbesondere nach dem Lesen eines Blogposts über Less Wrong , und die Daten, die ich gesehen habe, um sie zu sichern, sind extrem alt.

Ist dieses Axiom heute noch richtig?

Die einzigen harten Daten, die ich je gesehen habe, sind Boehm und Papaccio, Verstehen und Kontrollieren der Softwarekosten .

Dies geht auf das Jahr 1988 zurück und war eine Studie von rund 80 Softwareprojekten. Sie kamen zu dem Schluss, dass eine früh getroffene und spät korrigierte Entscheidung das 50- bis 200-fache des Preises kosten könnte, den sie hätte, wenn sie früh korrigiert worden wäre. Die Art der sehr frühen Entscheidungen, über die sie sprechen, ist jedoch, auf welchem ​​Betriebssystem und in welcher Sprache und Datenbank sie ausgeführt werden sollen.

Diese Zahlen könnten im Hinblick auf die heutige Softwareentwicklung überzeichnet sein. Jetzt haben wir jedoch viel Erfahrung auf diesem Gebiet und wir wissen instinktiv, dass dies immer noch bis zu einem gewissen Punkt zutrifft.

Im Extremfall wissen wir, dass ein Ausfall der Anforderungen kurz vor Produktionsbeginn eine Menge Nacharbeit zur Folge hat und das Projekt verzögert oder sogar abgebrochen wird wäre gut gewesen

Edit: Doc Brown macht einen guten Punkt in seinem Kommentar.

Boehms Recherchen betrafen COBOL- und FORTRAN-Projekte in einer Zeit, in der die Kompilierungs- und Ausführungszeiten lächerlich lang waren. Ich habe meine Karriere in den frühen 90er Jahren mit COBOL begonnen und der Kompilierungs- und Testzyklus dauerte so lange, dass es sich gelohnt hat, den Code vor dem Durchlaufen des Zyklus (oder zumindest während der Erstellungsphase, nur für den Fall) einem Trockentest zu unterziehen Sie könnten etwas fangen und es frühzeitig stornieren, um sich eine Stunde zu sparen oder so).

Im Gegenzug haben unsere Chefs über unsere Beschwerden gelacht, weil sie vor nicht allzu langer Zeit eine Schachtel mit handsortierten Lochkarten in den Serverraum gebracht und dort für einen Tag gelassen haben.

So war es auf jeden Fall mehr wahr ist, dann , als es jetzt ist.

Und doch habe ich vor kurzem Blogs gesehen, die Steve McConnells Visualisierung dieses Problems wiederverwendeten ( Ref . 1996), als ob dieses Diagramm tatsächlich auf harten Zahlen basiert. Ist es nicht. Es ist eine Visualisierung, um seinen Standpunkt einfach zu erklären.

Ich denke, dass Morendils Prämisse in dem Artikel, den das OP zitiert, gut ist. Die Wissenschaft, die wir zu diesem Thema haben, ist arm und veraltet und wird dennoch als Kanon behandelt. Aber ich denke auch, dass es gut hält und wahr klingt, weil wir aus bitterer Erfahrung wissen, dass es immer noch wahr ist, zumindest bis zu einem gewissen Punkt. Und ich denke, seine dramatische Formulierung "Disease Disziplin" tut ihm keinen Gefallen.

Während ich keine Kenntnis von harten Daten oder anderen Beweisen bin um diese Behauptung zu unterstützen, bei einem Minimum , würde ich kapier gesunder Menschenverstand ist.

Denken Sie so darüber nach. Wenn Sie ein komplexes System mit voneinander abhängigen Subsystemen haben (wie die meisten nicht-trivialen Anwendungen), denken Sie an Probleme, die durch Änderungen an einem der Systeme auftreten können. Wenn Subsysteme nachweislich korrekt sein (über Unit - Tests und dergleichen) und früh festgelegt, die Anzahl der Fehler , die verursacht werden , werden aufgrund Knock-ons allein wird einfach durch die Festsetzung früh gemildert.

Wenn Sie Fehler frühzeitig beheben, ist die Implementierung für den Entwickler noch nicht abgeschlossen. Abhängig von der Länge eines Projekts muss der Entwickler einige Zeit damit verbringen, herauszufinden, was er geschrieben hat und (vielleicht) wie die Subsysteme, von denen sein Code abhängt, funktionieren, wenn er am Ende Fehler behebt. Zeitaufwand für das erneute Lernen = $.

Ich bezweifle, dass es überhaupt möglich ist, eine wissenschaftlich starre Methode zu finden, um dies zu messen - es sind einfach zu viele andere Faktoren beteiligt, und keine zwei Projekte sind vergleichbar genug, um als mehr als Fallstudien zu dienen. Logisches Denken sollte Sie jedoch weit bringen. Ein paar Argumente:

• Die Gesamtmenge an Code in einem Projekt wächst tendenziell gegen Ende. Je länger Sie auf die Behebung eines Fehlers warten, desto größer ist die Codebasis, die Sie berühren müssen.
• Die Qualität des zu einem Projekt hinzugefügten neuen Codes nimmt gegen Ende ab, zumindest wenn Druck besteht (was normalerweise gegeben ist): Eine bevorstehende Frist zwingt die Leute, bewährte Verfahren über Bord zu werfen, um sie pünktlich zu versenden. Dies bedeutet, je später Sie einen Fehler beheben, desto mehr fehlerhaften Code müssen Sie durchsehen.
• Obwohl das Kopieren von Code im Allgemeinen verpönt ist, geschieht dies immer wieder. Da das Kopieren und Einfügen von Code-Abschnitten einfach ist, das erneute Zusammenführen von Code-Abschnitten jedoch schwierig ist, erhöht sich die Menge des einmal kopierten Codes in der Regel über die Lebensdauer von a Projekt. Mehr kopierter Code bedeutet eine höhere Wahrscheinlichkeit, dass Ihr Fehler dupliziert wird und mehrmals gefunden und behoben werden muss (und folglich eine höhere Wahrscheinlichkeit, dass einige seiner Vorkommen unbemerkt bleiben).
• Das Beheben eines Fehlers ist eine Änderung einer Codebasis. Sie hoffen, die Dinge zu verbessern, aber eine Änderung birgt immer ein Risiko. Eine Änderung, die in den kommenden Monaten zu ernsthaften Problemen in einem Projekt führt, sollte genügend Spielraum für das Schadensmanagement lassen. Zwei Tage vor dem Versand treten jedoch ernsthafte Probleme auf.
• Je länger der Fehler selbst besteht, desto wahrscheinlicher wird es, dass sich andere Teile der Anwendung auf sein Fehlverhalten verlassen. Wenn Sie das Problem beheben, lösen Sie plötzlich eine Reihe von sekundären Fehlern im Code aus, von denen nicht erwartet wird, dass Ihre Funktion tatsächlich die richtigen dokumentierten Ergebnisse liefert.

Dies ist ein grundlegend akzeptiertes Material aus der Systemtechnik - und es gilt für jede Form der technischen Entwicklung (sei es der Bau von Brücken, Raketen, Schlachtschiffen oder Software).

Im Wesentlichen steigen die Kosten der Dinge ungefähr um eine Größenordnung, wenn Sie sich durch Entwicklungsstadien bewegen.

Etwas, das 10 US-Dollar kostet, um die Idee zu verwirklichen ...

Kostet ca. 100 US-Dollar, wenn Sie ein Update der Spezifikation benötigen ....

Oder es kostet ungefähr 1000 US-Dollar, wenn etwas implementiert wurde und Sie zu diesem Zeitpunkt Änderungen vornehmen müssen (und die Spezifikation aktualisieren und die Genehmigungen usw. erhalten müssen), aber es hat keinen formellen Abnahme- / Abverkaufstest durchlaufen

Oder es kostet ungefähr 10000 USD, wenn etwas implementiert und vom Kunden akzeptiert wurde, und Sie müssen zu diesem Zeitpunkt Änderungen vornehmen (und die Spezifikation aktualisieren und die Genehmigungen einholen sowie die Kundenakzeptanz und -qualifikation erneut testen und erneut ausführen usw.).

Und die Kosten nach Bereitstellung / Einführung / Inbetriebnahme sind noch höher.

Beispiele gibt es zuhauf und es ist leicht zu verstehen: Ein Bankensystem mit einer gravierenden Änderung des Umfangs, die durchgeführt wird, nachdem Sie 25.000 Mitarbeiter damit beschäftigt haben, kostet ein Paket in der Umschulungszeit ... bevor Sie überhaupt über Umfang, Codierung, Test, Regression nachdenken, etc etc etc

Ihre Laufleistung ist natürlich unterschiedlich: Die Kosten und Auswirkungen der Änderung der E-Commerce-Website von Fred Nurke für die Erwärmung elektronischer Socken unterscheiden sich etwas von den Kosten für die Änderung von Software auf einem Flugsteuerungscomputer für Flugzeuge.

Ich habe keinen Zugang zu harten Daten oder Fakten, daher kann ich Ihnen nur vereinzelte Beobachtungen anbieten, die ich aus meinen letzten 20 Jahren in der IT gewonnen habe.

Ich glaube, es gibt einen großen Unterschied zwischen der Art und Weise, wie die meisten Entwickler heute Software erstellen, und der vor 20 Jahren. Nachdem die Agile-Bewegung vor allem in den letzten fünf bis sechs Jahren so viel Fahrt aufgenommen hat, habe ich eine echte Veränderung der Einstellungen am Arbeitsplatz erlebt. So sehr, dass die Qualität unserer Arbeit jedes Jahr sprunghaft zuzunehmen scheint und wir mit jedem Projekt die Lehren ziehen, die wir von Projekt zu Projekt gezogen haben. Schlankere Prozesse in Verbindung mit der Konzentration auf die Test-First-Entwicklung haben sich von einer sehr kontroversen zu einer alltäglichen Entwicklung entwickelt. So sehr, dass Sie sich glücklich schätzen, wenn Sie heute in viele Unternehmen eintreten, und wenn Sie sich mit Agile nicht auskennen, haben Sie das Glück, dass sie Ihnen nicht die Tür zeigen.

Wie hat sich das ausgewirkt? Zunächst ist mir aufgefallen, dass Probleme häufig viel früher erkannt werden. Oft ist es der Fall, dass das Problem, wenn es nicht zu groß erscheint, manchmal auf unbestimmte Zeit zurückgestellt werden kann. In seltenen Fällen habe ich gesehen, dass Bugs, von denen angenommen wurde, dass sie trivial sind, zu ernsthaften Problemen werden, wenn sie später behoben werden, da ein grundlegendes Problem offensichtlich wird, das zu diesem Zeitpunkt nicht berücksichtigt wurde. Manchmal kann dies zu einem langwierigen Fixzyklus führen, der bis zu einem gewissen Grad kostspielig sein kann. Diese Kosten werden jedoch häufig weniger in Bezug auf die Beschaffung als vielmehr in Bezug auf die Auswirkungen auf die Beziehung zwischen Kunde und Entwickler gemessen. Kunden gewöhnen sich zunehmend an diese agile Denkweise, die viel schneller Ergebnisse liefert als früher. Mit hochgradig iterativen Entwicklungs-Sprints und einem schnellen Turnaround zwischen Anfragen und Implementierung haben sie es verstanden, viel von uns zu erwarten. In Bezug auf die eigentlichen Fehler wird die Zeit für die Behebung eines Fehlers häufiger verkürzt, da eine solide Reihe von Tests zur Unterstützung von Änderungen zur Verfügung steht und neue Tests erstellt werden können, anhand derer Erkenntnisse und Lösungen bereitgestellt werden können zu den gemeldeten Problemen.

Im Großen und Ganzen scheint sich der Gesamtaufwand für die Behebung von Fehlern in den meisten Fällen verringert zu haben, wenn eine solide Reihe von Tests vorhanden ist, und Verfahren, mit denen sichergestellt wird, dass das Testen im Mittelpunkt des Handelns des Entwicklers bleibt, jedoch die tatsächlichen Kosten hat sich teilweise zumindest von der Implementierung auf andere Geschäftsbereiche verlagert, da sich der Fokus in gewisser Weise auch von Angebot und Nachfrage auf Beziehungsmanagement verlagert hat.

Eine andere Sache, die offensichtlich geworden ist, ist, dass unser Bauchgefühl vor ein paar Jahren, das darauf hindeutet, dass Agilität unsere Wartungszyklen verkürzt, in gewissem Maße sowohl richtig als auch falsch erwiesen ist. Genau in dem Sinne, dass solide Tests das Debuggen und Korrigieren unseres Codes zu einem großen Teil erleichtert und die Anzahl der im Produktionscode veröffentlichten Fehler insgesamt verringert haben Beibehaltung von altem Code durch ständige Überarbeitung des Codes und Verbesserung der Architektur, sodass es immer seltener wird, dass wir neue Produkte komplett von Grund auf neu entwickeln müssen.

Was bedeutet dies letztendlich für die Frage des OP? Nun, es bedeutet, dass die Antwort wirklich nicht so trocken ist, wie wir es uns einmal vorgestellt haben. Vor 15 Jahren hätte ich die Frage wahrscheinlich als beantwortet JaAber jetzt finde ich es realistischer zu sagen, dass es wirklich zu schwierig ist, empirisch zu messen, da sich die Art und Weise, in der wir Software entwickeln, stark verändert hat, seit wir uns damals das erste Mal die Frage des OP gestellt haben. In mancher Hinsicht wächst die Frage von einem definitiven Ja zu einem Punkt, an dem ich vermute, dass wir in wenigen Jahren sagen werden, dass es keine Rolle spielt, je mehr wir unsere Techniken und Fähigkeiten als Branche weiterentwickeln Wenn wir Fehler beheben, weil unsere Tests und Prozesse so viel robuster sind, dass der Zeitpunkt für die Fehlerbehebung weniger durch Anstrengungen zur Einsparung unserer Budgets bestimmt wird, als vielmehr durch Prioritäten zur Befriedigung der Bedürfnisse unserer Kunden und die relativen Kosten werden praktisch sinnlos kontextuell.

Aber wie gesagt, dies sind keine stichhaltigen datengestützten Beweise, nur meine Beobachtungen der letzten Jahre, und mein Bauch sagt mir, dass es weitere bodenschüttelnde Weisheiten geben wird, die die Art und Weise, wie wir Dinge tun, verbessern werden.

Frühe Fehler breiten sich auf andere Teile des Systems aus. Wenn Sie den Fehler beheben, müssen Sie möglicherweise einige Teile des Systems neu schreiben, die auf dem Fehler selbst beruhten.

Im Laufe der Zeit werden Sie nicht nur wissen, wie einige Teile des Programms aufgebaut sind, sondern Sie müssen sich auch daran erinnern. Es ist eine Form von technischer Verschuldung (wenn Sie das Projekt in einem frühen Stadium beschleunigen, haben Sie Probleme, es zu beenden, weil Sie Verknüpfungen verwendet haben).

So einfach ist das und es gibt nichts zu beweisen.

Ich denke, Sie versuchen, das Projekt so schnell wie möglich voranzutreiben, um Ihrem Mitarbeiter eine funktionierende Lösung zu präsentieren. Die gute Nachricht ist, dass Sie es sehr schnell haben werden, und die schlechte Nachricht ist, dass Sie es wahrscheinlich nie ohne ein vollständiges Umschreiben beenden werden, wenn Sie einfach so schnell wie möglich Mist schreiben und vorhaben, alles in ein paar Monaten zu reparieren. Sie werden wahrscheinlich nicht einmal in der Lage sein, dies umzugestalten.

Nun, ich kann Ihnen wahrscheinlich nicht den endgültigen Beweis liefern, den Sie verlangen, aber ich kann einen relativ neuen Vorfall aus meiner Arbeit berichten.

Wir haben unserem Produkt eine Funktion hinzugefügt, die Workflow-Management-Funktionen bietet. Typisches BDUF-Material, vom Kunden freigegebene und genehmigte Spezifikationen. Implementiert nach Spezifikation. Beschwerden ab Tag 1 bei der Bereitstellung.

Wir hatten mit dem Kunden keinen echten Usability-Durchlauf durchgeführt, sondern nur ihr Wort für das genommen, was sie wollten. Ergebnis: Hunderte Stunden Nacharbeit - Analyse, Design, Implementierung und Qualitätssicherung mussten überarbeitet werden. Alles nur, weil die Spezifikation bestimmte Anwendungsfälle übersehen hat. Ein Fehler in der Spezifikation, wenn Sie so wollen.

Ich habe ähnliche Dinge in früheren Jobs gesehen, als jemand in der Kette Annahmen machte, die sich von den Annahmen des Endbenutzers unterscheiden. Straight-up-Coding-Bugs sind relativ einfach zu behandeln, wenn sie kurz vor ihrem Auftreten entdeckt werden. Design-Bugs können jedoch ganze Systeme töten.

Wenn Sie den Fehler nach der Veröffentlichung beheben, entstehen Ihnen die Kosten für das Auffinden und Beheben des Fehlers - was möglicherweise mehr Zeit / Kosten nach der Veröffentlichung erfordert oder auch nicht. Es gibt jedoch eine Reihe von Integrationstests, Regressionstests, UA-Tests, Release-Aktivitäten usw., die berücksichtigt werden müssen. Wenn die Fehlerbehebung nicht zusammen mit einer Reihe anderer Fehlerbehebungen oder einem Versionsupdate durchgeführt wird, entstehen zusätzliche Kosten für die Test- und Freigabeaktivitäten, die durch die Aufnahme der Fehlerbehebung in die Erstveröffentlichung vermieden würden, da diese Kosten auf mehrere verteilt würden Korrekturen / Updates / Funktionen.

Berücksichtigen Sie auch die Kosten, die der Fehler bei der Verwendung verursachen wird. Wenn es sich nur um kosmetische Probleme handelt, spielt dies wahrscheinlich keine Rolle. Ein Funktions- oder Leistungsfehler kann jedoch zu Kosten führen, die durch Support-Aktivitäten oder verminderte Produktivität oder falsche Berechnungen entstehen.

Fragen Sie Intel, wie viel der Pentium Bug sie gekostet hat. Die Ariane 5-Rakete ist ein weiteres gutes Beispiel. Diese Fehler wurden am Ende des Projekts behoben. Ich habe an einem System gearbeitet, bei dem ein "Versuch" einer Softwareversion ein Budget von 6 Ziffern hat. In diesen extremen Fällen ist es einfach, die Kosten zu sehen. In anderen (den meisten?) Fällen werden die Kosten durch den Lärm verborgen, aber es ist immer noch da.

Es besteht kein Zweifel, dass Fehler Geld kosten, solange sie existieren. Ein Punkt, Fehlerberichte, braucht Zeit zum Kompilieren, Durchsuchen und Schließen, Zeit ist Geld - daher verursacht ein offener Fehler laufende Kosten. Daher muss es sein, dass das Zurückstellen von Fehlerkorrekturen mehr kostet als das frühere Korrigieren.

Wenn ein Fehler ins Leere geht, sind die Kosten sprunghaft ...... Ist "Das Ende des Projekts" vor oder nach der Veröffentlichung der Software?

Ich habe einmal einen Artikel gelesen, der zwei interessante Punkte hatte (leider sind die Referenzen, die ich hatte, schon lange nicht mehr da, also muss ich hier nur noch postulieren). Der erste Punkt, den sie anführten, war, dass rund 50% aller Fehler in die Anforderungsspezifikation aufgenommen wurden und dass rund 90% aller Fehler bei UAT- oder Systemtests festgestellt wurden.

Der zweite Punkt, den sie hatten, war, dass für jede Phase im V-Modell die Kosten 10-fach erhöht wurden. Ob der Faktor richtig ist oder nicht, finde ich irrelevant, aber die teuersten Fehler sind, wenn Ihr Design auf einer falschen Annahme basiert. Dies führt zu einer massiven Umschreibung. Der gesamte Code, der aufgrund dieser Annahme funktioniert, aber fehlschlägt, wenn die richtige Annahme angewendet wird, muss neu geschrieben werden.

Ich habe festgestellt, dass das gesamte Domänenmodell aufgrund einer falschen Annahme in den Anforderungsspezifikationen umgeschrieben werden muss. Wenn ein solcher Fehler frühzeitig erkannt wird, sind die Kosten bei der Überprüfung der Anforderungsspezifikationen sehr niedrig. In diesem speziellen Fall hätte es zehn Textzeilen gedauert. In dem Fall, in dem es während der UAT gefunden wurde (wie dies war), sind die Kosten erheblich (in dem gegebenen Beispiel wurden die Projektkosten um 50% erhöht).

Keine statistischen Daten, aber persönliche Erfahrung:

Der Code für die Steuerung des Raketenmotors, an dem ich arbeitete, hatte eine Zeile wie powerCutoff = someCondition && debugOptions.cutoffIsAllowed;. Die Standardoption war kein Cutoff erlaubt. Der "endgültige" Build sollte alle Debug-Optionen entfernen, daher wurde die Zeile in geändert powerCutoff = someCondition;.

Haben Sie den Fehler während der Codeüberprüfung entdeckt? Haben wir nicht. Das erste Mal, dass die Auslösebedingung im Test auftrat und eine unerwartete Abschaltung verursachte, war nur wenige Monate vor dem ersten Flug.

Dieser Fehler hätte weniger als eine Stunde gekostet, wenn er während der Überprüfung entdeckt worden wäre. Es könnte ein oder zwei Tage gekostet haben, wenn es während der Integration abgefangen wurde, was zu einer einzelnen Testwiederholung führte. Wenn es während der formalen Qualifikation abgefangen wurde, hätte es ein oder zwei Wochen kosten können, weil ein vollständiger Neustart der Testreihe mit einem neuen Build durchgeführt wurde.

So wie es war, waren die Kosten ausgeglichen. Zuerst haben wir Tests entworfen und durchgeführt, um festzustellen, ob die Flugeinheit den Zustand überhaupt auslösen kann. Nachdem festgestellt wurde, dass es sich um eine echte Möglichkeit handelt, fielen Kosten für das Engineering, die Verwaltung und die Kundenanalyse des besten Fixes, die Freigabe des neuen Builds, die Erstellung und Ausführung eines neuen Regressionstestplans, Systemtests in mehreren Einheiten und Simulatoren an. Alles in allem kostete es Tausende, wenn nicht Zehntausende von Arbeitsstunden. Plus die ursprünglichen 15 Minuten, um tatsächlich den richtigen Code zu ändern.

Wie bei vielen Dingen kommt es leider darauf an.

Wenn eine Dialogmeldung falsch geschrieben ist, kann es 'trivial' sein, sie zu korrigieren (Zeichenfolge aktualisieren, neu erstellen / packen, erneut bereitstellen). Wenn ein Layout aktualisiert werden muss, kann eine Änderung an einer CSS-Datei ausreichend sein.

Wenn der Fehler darin besteht, dass die Ausgabe einer kritischen Methode mit einer Spezifikation von mehr als 100 Seiten und einem Beweis falsch ist, kann die Untersuchung selbst Stunden oder Tage dauern. Darauf bezieht sich das alte „Axiom“, und darauf, was TDD und Agile unter anderem zu vermeiden versuchen (frühzeitig scheitern und eindeutig inkrementelle Fortschritte erzielen, yada).

Aufgrund meiner jüngsten Erfahrungen mit Multi-Scrum-Teams für ein einzelnes Projekt handelt es sich bei den "Fehlern" in der Regel um Zusammenführungs- / Integrationsprobleme, die erst am Ende einer Veröffentlichung auftreten, wenn Feature-Zweige auf "Stabil" hochgestuft werden. Dies sind die schlimmsten, da die Konflikte häufig teamübergreifende Unterstützung erfordern, während die Teams in Eile sind, um ihre eigenen Ziele zu erreichen, aber ich weiß nicht, dass sie teurer sind als andere Bugs, wie sie auftreten, wenn sie auftreten: spät die Freilassung, aber zum frühesten Zeitpunkt können sie. Das macht sie zum schlimmsten.