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

21

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?

Stefan Hendriks
quelle
@StefanHendriks Die Kommentare in Ihrem verlinkten Artikel von Morendil decken wirklich alles ab, was Sie fragen können. MEINER BESCHEIDENEN MEINUNG NACH. Tolle Informationen dort.
Aaron McIver
@AaronMcIver Ich möchte, dass mehr Leute davon erfahren. Als würde man das Wort verbreiten und die Chancen erhöhen, echte Daten zu erhalten. Ich suche keine wirkliche Diskussion; am artikel werden tolle veranstaltet (wie ihr auch herausgefunden habt :)).
Stefan Hendriks
2
Hallo Stefan, das ist weder ein Diskussionsforum noch eine Seifenkiste: Ich habe deinen Kommentar aus der Frage entfernt. Wir können Ihnen dabei helfen, Aspekte der Softwareentwicklung zu erläutern. Wenn Sie diese Website jedoch als Werbemittel für Ihre Ideen oder zum Teilen von Blogposts verwenden möchten, sind Sie hier falsch.
Auch wenn dies sicherlich mit der Programmierung zu tun hat, könnte die Art der Frage es auf critics.stackexchange.com tatsächlich angemessener machen.
StriplingWarrior

Antworten:

16

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.

pdr
quelle
3
+1. Ich denke, man sollte hinzufügen, dass Böhms Forschung zu einer Zeit durchgeführt wurde, in der die Kosten für das Erstellen und Bereitstellen von Bugfix-Releases viel höher waren als heute.
Doc Brown
@ DocBrown: Guter Punkt. Hinzugefügt. Zusammen mit einem weiteren Streifzug.
pdr
+1 als Referenz, +1 für die Visualisierung (schade, dass ich nur einen Punkt geben kann.) Tolle Antwort, danke!
Stefan Hendriks
15

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 = $.

Demian Brecht
quelle
1
Im Grunde geht es also um den Aufwand, der erforderlich ist, um einen Fehler später (oder früher) zu beheben. Ich kann mir andere Faktoren vorstellen, die Fehler teurer machen, wenn sie später behoben werden. Aber das hängt von Ihrer Definition des Fehlers ab. Vielleicht ist das etwas, worüber man sich zuerst einigen muss. In meinem Buch ist es auch eine "nicht übereinstimmende Erwartung in dieser Version". Wie eine fehlende Funktionalität. Dies könnte echtes Geld kosten, es ist also offensichtlicher. Einige Funktionen kosten jedoch möglicherweise nicht mehr (z. B. für Websites, CSS-Änderungen?) Als früher. Oder nicht wesentlich mehr. Ich habe noch keine Daten.
Stefan Hendriks
@StefanHendriks: Wir sprechen sowohl über den Aufwand als auch über neue Fehler, die durch beanspruchte Korrekturen entstehen. Sie müssten sich wahrscheinlich mit den Post-Mortems von Projekten befassen (die beide Methoden angewendet haben), um tatsächliche Daten zu erhalten.
Demian Brecht
2
@AaronMcIver: Meine Erkenntnis aus dem Artikel ist nicht, welche Methode besser ist, sondern, dass die Recherche und die harten Daten, die zur Sicherung der Behauptung und Fehlinterpretationen in nachfolgenden Berichten verwendet wurden. Meine Antwort basiert nicht auf öffentlichen Daten, sondern auf mehr als 10 Jahren Berufserfahrung im Umgang mit hochkomplexen Systemen.
Demian Brecht
1
Übrigens stimme ich nicht zu, dass CSS-Änderungen nicht darunter leiden. Versuchen Sie, ein Layout-Problem zu beheben, sobald Sie alle anderen Pixel perfekt haben und Sie feststellen, dass Sie möglicherweise eine Menge Dinge brechen müssen
Andrea
1
@DemianBrecht Deine Antwort ist sehr subjektiv, weshalb ich frage. Es ist Spekulation und ein Bauchgefühl. Während diese sicherlich Gewicht halten können, ist das Problem, dass es häufig eine ungenaue Darstellung der Realität sein kann, wie der Artikel hervorhebt. Es kann auch umgekehrt werden, wenn Sie den gesunden Menschenverstand als Kriterium dafür verwenden, warum es mehr kosten kann. Sie könnten argumentieren, dass die Anzahl der Personen, die an einer Fehlerbehebung beteiligt sind, der eigentliche Faktor sein kann, der mehr kostet oder nicht, unabhängig vom tatsächlichen Aufwand der Entwickler.
Aaron McIver
12

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.
tdammers
quelle
+1. Gute Antwort. Kopieren und Einfügen von Code, der Fehler enthält, führt zu mehr Fehlern, je nachdem, welche Module davon abhängig sind.
Karthik Sreenivasan
2

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.

schnell_nun
quelle
1
Angenommen, Sie liefern Ihren Benutzern jeden Monat eine neue Version einer Software (oder nur Patches, wie MS es für Windows tut). Jetzt tauchen zwei Bugs auf, einer, der vor zwei Jahren in die Software eingeführt wurde, einer, der letzten Monat eingeführt wurde. Die Kosten für die Behebung dieser beiden Fehler und die Bereitstellung der neuen Version können praktisch gleich sein. Die Kosten für die Behebung der Probleme, die durch einen dieser Fehler verursacht werden, können unterschiedlich sein, aber das hängt stark vom Fehler selbst ab.
Doc Brown
Nicht ganz dasselbe - das ist nach dem Versand. Die Kosten nach dem Versand sind in der Größenordnung ähnlich (sie müssen alle aktualisiert, getestet und bereitgestellt werden). Ich weise darauf hin, dass die Kosten nach der Veröffentlichung dramatisch ansteigen.
quick_now
1
"Post-Release" ist ein Status, der für eingebettete Software, bis zu einem gewissen Grad für Shrink-Wrap-Software und auch für Software, die in einem (fehlgeleiteten!) Wasserfallmodell entwickelt wurde, gültig ist. Andere Softwaretypen werden schrittweise entwickelt und veröffentlicht. Die Zeit nach der Veröffentlichung ist im Vergleich zur Lebensdauer des Produkts praktisch gering. Dies gilt insbesondere für Webanwendungen.
Doc Brown
Das mag für Webanwendungen der Fall sein, aber das ist nicht das gesamte Universum. Was ist mit Waschmaschinen? Autos? Raketen? PC-Betriebssysteme? Kraftwerke? SPS, die Zementwerke betreiben? Weiter und weiter und weiter geht die Liste.
quick_now
2

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.

S.Robins
quelle
1

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.

Slawek
quelle
Ja das alles macht Sinn. Ich frage mich allerdings, ob sich dies erheblich von der späteren Korrektur unterscheidet. Ja, du musst ein bisschen neu lernen. Aber vielleicht durch nicht die Freigabe früher haben Sie mehr Geld als die Kosten verloren es der Festsetzung dieses Problem wäre. Würde dies das Problem billig oder teuer machen? Auch wenn es weniger Arbeit ist, weil es am Anfang war?
Stefan Hendriks
2
Das Reparieren eines bereits freigegebenen Systems ist viel komplizierter. Sie können zum Beispiel nicht einfach Datenstrukturen umschreiben. Sie müssen den Benutzern eine Möglichkeit bieten, ihre Daten zu migrieren. Wiederum, wenn Sie zu früh veröffentlichen, werden Sie in einem Durcheinander enden, anstatt Fehler zu beheben, werden Sie Zeit damit verschwenden, Migrationscode zu schreiben. Vielleicht verlieren Sie etwas Geld, es ist besser, als Kunden zu verlieren, weil Sie ihnen miese Software verkaufen.
Slawek,
>> ... du musst ein bisschen neu lernen ... Gerade Edge-Fälle machen dies schwierig und nicht trivial. Interaktionen außerhalb der unmittelbaren Umgebung werden schnell vergessen, es sei denn, Sie verfügen über eine vollständige, korrekte und gewartete Spezifikation.
DaveE
1

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.

DaveE
quelle
1

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.

Adam f
quelle
1

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?

mattnz
quelle
Software - Fehler in der Embedded - Welt ist auf jeden Fall mehr teuer am Ende des Projektes zu beheben. Stellen Sie sich vor, Sie müssen ein Auto wegen eines Softwarefehlers im Motorsteuergerät zurückrufen.
Tehnyit
Die von Ihnen erwähnten Fehler wurden nicht früh gefunden und daher nicht früh behoben.
@ Thorbjørn Sie sind in der Tat richtig - obwohl wir die Fehler, die wir vorzeitig eingefügt haben, nicht frühzeitig gefunden haben (Bei der Ariane-Rakete wurde der Fehler bereits vor dem Start des Projekts eingefügt, da der vorhandene Code wiederverwendet wurde.). Die Kosten sind proportional zu der Zeit zwischen dem Einfügen und der Bereitstellung der Korrektur. Dies hat nichts mit dem Zeitpunkt zu tun, zu dem der Patch gefunden oder behoben wurde (die meisten Entwickler halten ihn für behoben, sobald er sich in der Codebasis befindet. Ein Fehler wird erst behoben, wenn der Endbenutzer ihn installiert hat.) ). All dies ist jedoch nur IMHO - ich habe keine Beweise, um es zu unterstützen.
Mattnz
1

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).

Rune FS
quelle
1

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.

Ahelly
quelle
0

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.

Kristian H
quelle