Beruht die Softwaretestmethode auf fehlerhaften Daten?

45

Es ist eine bekannte Tatsache in der Softwareentwicklung, dass die Kosten für die Behebung eines Fehlers exponentiell ansteigen, je später in der Entwicklung dieser Fehler entdeckt wird. Dies wird durch Daten gestützt, die in Code Complete veröffentlicht und in zahlreichen anderen Veröffentlichungen angepasst wurden.

Es stellt sich jedoch heraus, dass diese Daten nie existierten . Die von Code Complete angeführten Daten weisen offenbar keine solche Korrelation zwischen Kosten und Entwicklungszeit auf, und ähnliche veröffentlichte Tabellen zeigten nur die Korrelation in einigen Sonderfällen und eine flache Kurve in anderen (dh keine Erhöhung der Kosten).

Gibt es unabhängige Daten, die dies bestätigen oder widerlegen?

Und wenn dies zutrifft (dh wenn es einfach keine Daten gibt, um diese exponentiell höheren Kosten für spät entdeckte Fehler zu decken), wie wirkt sich dies auf die Softwareentwicklungsmethode aus?

Konrad Rudolph
quelle
Dies klingt logisch, da ein später entdeckter Fehler in den meisten Fällen auch zu einer Beschädigung der Daten führt. Darüber hinaus kostet die Beschädigung von Daten Unternehmen viel, wenn dies später beim Beheben des Fehlers festgestellt wird.
EL Yusubov,
8
@ ElYusubov Es tut in der Tat. Der gesunde Menschenverstand kann jedoch sehr trügerisch sein. Unsere Gedanken lassen sich leicht durch offensichtliche Logik täuschen, wenn es tatsächlich umgekehrt ist. Deshalb ist evidenzbasiertes Software-Engineering so wichtig.
Konrad Rudolph
2
Siehe auch
2
Für die Aufzeichnung (und in meiner Antwort erwähnt) ist die früheste Erwähnung davon, die ich finden konnte, weit vor Code Complete. Die Arbeit von Fagan und Stephenson (unabhängig) im Jahr 1976 ist der früheste Hinweis darauf, den ich finden kann. Die erste Ausgabe von Code Complete erschien erst 1993, fast 20 Jahre später. Ich würde erwarten, dass die Arbeit von Barry Boehm in den 1980er Jahren zu einer Zunahme der Popularität dieser Idee führte - Böhms Arbeit hatte großen Einfluss auf den Software-Engineering-Prozess in den 1980er Jahren und sogar in den späten 2000er Jahren.
Thomas Owens
1
Es ist selbstverständlich, dass alle Aussagen zur Statistik der Softwareentwicklung, einschließlich dieser, falsch sind. (Die Bugs, die Sie später finden, sind in der Regel die komplexeren Bugs. Und die Behebung dieser Bugs wird durch die "Kontrollen", die für spätere Korrekturen eingerichtet wurden, noch komplizierter.)
Daniel R Hicks

Antworten:

25

Beruht die Softwaretestmethode auf fehlerhaften Daten?

Ja, nachweislich. Die Untersuchung der Agile Cost of Change-Kurve zeigt, dass ein Teil von Kent Becks Arbeit an XP (ich bin nicht sicher, ob es Teil seiner Motivation oder seiner Rechtfertigung war) darin bestand, die Kurve der Fehlerkosten auf der Grundlage der Kenntnis der exponentielle "Kurve, die hinter der Tabelle Code Complete liegt. Also ja, arbeiten Sie an mindestens einer Methode - derjenigen, die am meisten zur Popularisierung der Test-First-Entwicklung beigetragen hat -, die zumindest teilweise auf fehlerhaften Daten basiert.

Gibt es unabhängige Daten, die dies bestätigen oder widerlegen?

Ja, es gibt sicherlich andere Daten, auf die Sie zurückgreifen können - die größte mir bekannte Studie ist die Analyse von Fehlern, die bei Hughes Aircraft im Rahmen des CMM-Evaluierungsprogramms durchgeführt wurden . Der Bericht von dort zeigt, wie die Fehlerkosten mit der Phase für sie abhingen : Obwohl die Daten in diesem Bericht keine Abweichungen enthalten, müssen Sie vorsichtig sein, zu viele Schlussfolgerungen zu ziehen, dass "dieses Ding mehr kostet als dieses Ding". Sie sollten auch beachten, dass es zwischen den 1980er Jahren und heute methodenunabhängige Änderungen bei Werkzeugen und Techniken gegeben hat, die die Relevanz dieser Daten in Frage stellen.

Unter der Annahme, dass wir immer noch ein Problem haben, das diese Zahlen rechtfertigt:

Wie wirkt sich dies auf die Softwareentwicklungsmethodik aus?

Die Tatsache, dass wir uns auf Zahlen verlassen, die nicht verifiziert werden können, hat die Menschen nicht davon abgehalten, Fortschritte auf der Grundlage von Anekdoten und Erfahrungen zu erzielen. So werden viele Meisterberufe erlernt. Ich glaube nicht, dass es im Mittelalter ein Journal of Evidence-Based Masonry gab , aber eine ganze Reihe von großen, beeindruckenden und langlebigen Gebäuden wurden dennoch mit beachtlichem Erfolg errichtet. Was es bedeutet ist, dass wir unsere Praxis hauptsächlich auf "das, was für mich oder die Menschen, die ich getroffen habe, funktioniert hat", stützen; Keine schlechte Sache, aber vielleicht nicht der effizienteste Weg, um ein Feld von Millionen von Menschen zu verbessern, die den Eckpfeiler des gegenwärtigen technologischen Zeitalters bilden.

Ich finde es enttäuschend, dass in einer so genannten technischen Disziplin keine bessere empirische Grundlage vorhanden ist, und ich vermute, dass wir bessere, klarere Fortschritte bei der Verbesserung unserer Techniken und Methoden erzielen können (obwohl dies eindeutig nicht zu beweisen ist) Diese Grundlage ist vorhanden - so wie die klinische Medizin durch evidenzbasierte Praxis verändert worden zu sein scheint. Dies basiert jedoch auf einigen großen Annahmen:

  • dass der proprietäre Charakter der meisten Softwareentwicklungspraktiken nicht verhindert, dass genügend nützliche und relevante Daten gesammelt werden;
  • dass die aus diesen Daten gezogenen Schlussfolgerungen allgemein zutreffend sind (da das Software-Engineering ein qualifizierter Beruf ist, können persönliche Abweichungen in Bezug auf Erfahrung, Fähigkeiten und Geschmack die Anwendbarkeit beeinträchtigen);
  • dass Software-Ingenieure "vor Ort" in der Lage und motiviert sind, die so erzielten Ergebnisse zu nutzen; und
  • dass wir tatsächlich wissen, welche Fragen wir eigentlich stellen sollen. Dies ist offensichtlich der größte Punkt hier: Wenn wir über die Verbesserung des Software-Engineerings sprechen , was möchten wir verbessern? Was ist das Maß? Verbessert die Verbesserung dieser Messung tatsächlich das Ergebnis oder spielt sie das System aus? Nehmen wir beispielsweise an, das Management in meinem Unternehmen hat beschlossen, das Verhältnis zwischen den tatsächlichen Projektkosten und den prognostizierten Projektkosten zu verringern. Ich könnte einfach anfangen, alle meine Kostenschätzungen mit einem Fudge-Faktor zu multiplizieren, und ich würde dieses "Ziel" erreichen. Sollte es dann zur branchenüblichen Praxis werden, alle Schätzungen zu verfälschen?

quelle
Tolle Meta-Antwort zu evidenzbasiertem Engineering. Vielen Dank.
Konrad Rudolph
4
Verdammt, ich habe gerade gemerkt, dass dies direkt aus dem Maul des Pferdes kommt. Hehe Genial.
Konrad Rudolph
1
Ich habe das Gefühl, dass jeder die Verwendung von "fehlerhaften Daten" als "völlig unwahr, das Gegenteil ist der Fall" interpretiert, aber ich habe das Gefühl, dass Ihre Position einfach darin besteht, darauf hinzuweisen, dass sie möglicherweise nicht wahr ist . Ist das richtig?
Daniel B
3
@ DanielB Richtig. Zeig mir Beweise, dass es tatsächlich falsch ist und ich meine Meinung ändern könnte; bis dahin weiß ich nur, dass es nachweislich nicht stimmt.
1
@ AbrahamLee Ich verstehe deinen Standpunkt (denke nur, dass die Formulierung ein bisschen unnötig aggressiv gewesen sein könnte). Aus Neugier habe ich hier das Fagan-Papier gefunden , auf dem steht: "... ermöglicht Nacharbeiten ... in der Nähe ihres Ursprungs ... 10- bis 100-mal günstiger als in der letzten Hälfte des Prozesses". Ich sehe jedoch keine Zitate in der Nähe dieses Textes.
Daniel B
8

Die Antwort auf die Frage, wie sich dies auf die Softwareentwicklungsmethodik auswirkt, lautet für mich "nicht viel".

Ob vom Entwickler oder vom Endbenutzer abgefangen, ob es mehr Geld kostet, es zu reparieren, nachdem es vom Benutzer abgefangen wurde oder nicht, es bleibt die Tatsache, dass ein Fehler im System gefunden wurde. Wenn es vom Entwickler erwischt wird, ist es hoffentlich eine schnelle Lösung. Die gleiche Hoffnung gilt für Fehler, die vom Benutzer entdeckt wurden.

Unabhängig von den tatsächlichen Entwicklerstundenkosten für die Behebung eines Fehlers, der von einem Endbenutzer entdeckt wurde, entstehen immaterielle Kosten für die Beibehaltung des Stereotyps, das Programmierer bei der Behebung der von ihnen ausgeführten Aktionen verursachen. Wenn ein Benutzer einen Fehler findet, ist dies die Schuld des Entwicklers. Daher verringert jeder Fehler, den der Endbenutzer findet, das Vertrauen des Benutzers in das System. Es ist, als würde man ein Haus besichtigen, das man kaufen möchte, und einen Wasserfleck durch die Decke in einer Ecke des Hauses sehen. Das ist an sich eine einfache Lösung, aber Sie fragen sich, was sie verursacht hat und was die Grundursache sonst noch beeinflusst hat. Was ist dein Seelenfrieden wert? Möglicherweise müssen Sie die Wände bis zu den Stehbolzen abreißen und alles visuell untersuchen, um sicherzustellen, dass der Fleck von einem isolierten Vorfall stammt, der behoben wurde. Zu wissen, dass dies eine Möglichkeit sein könnte, macht Sie nicht sehr zuversichtlich in Ihrem Zuhause. Ähnlich,

Diese immateriellen Kosten werden umso schneller vermieden, je schneller der Fehler auftritt. Dies ist der erklärte Zweck von TDD-ähnlichen Methoden. Ein Fehler, der während der Eingabe durch den Entwickler oder Partner in einem Paar, ein Fehler beim Kompilieren oder ein Fehler beim Unit- / Integrationstest (die von TDD hinzugefügte Ebene) festgestellt wurde, ist ein Fehler, über den der Benutzer nie Bescheid wissen muss Der Projektmanager muss sich nie entschuldigen, und dass Sie in dieser Sekunde nicht von allem abgezogen werden müssen, was Sie gerade tun, um auf einem Teil des Systems, von dem Sie dachten, Sie hätten Wochen hinter sich gelassen, in den Fehlerbehebungsmodus zu schalten vor.

KeithS
quelle
3
Interessante Antwort. Ich versuche, meine Benutzer zu verstehen, dass Entwicklung ein iterativer Prozess ist oder sowohl Verfeinerung als auch Verbesserung. Ich kann ihnen sehr schnell etwas geben, und wenn sie Probleme finden oder Verbesserungen wünschen, kann ich diese Änderungen auch sehr schnell umdrehen (Minuten oder Stunden, nicht Tage oder Wochen). Das System wird im Laufe der Zeit stabiler, aber sie verlassen sich eher auf den Entwicklungsprozess und das Endergebnis als auf den Spezifikationsprozess und den ersten Build. (Das hängt natürlich von der Umgebung ab, in der Sie arbeiten. Ich schreibe eine Reihe von Business-Apps. Wenn diese kaputt gehen, werden sie repariert.)
Kirk Broadhurst
Leider impliziert der ursprüngliche Beweis, dass Anforderungsfehler, die beim Einsatz des Produkts festgestellt wurden, umso kostspieliger sind als Implementierungsfehler, die beim Einsatz des Produkts festgestellt wurden, die Notwendigkeit einer besseren Validierung und nicht einer besseren Verifizierung. TDD - das Testen des Produkts anhand der Anforderungen - ist für das Auffinden dieser Fehler einfach nicht relevant.
Pete Kirkham
6

Ich gehe davon aus, dass das meiste, was ich finde, aus den 1970er und frühen 1980er Jahren stammt. In dieser Zeit waren sequentielle Prozessmodelle weitaus häufiger als die iterativen und / oder inkrementellen Ansätze (das Spiralmodell oder die agilen Methoden). Ein Großteil dieser Arbeit basiert auf diesen sequentiellen Modellen. Ich denke jedoch nicht, dass dies die Beziehung zerstört, aber einer der Vorteile von iterativen / inkrementellen Ansätzen besteht darin, Features (ein ganzes vertikales Segment einer Anwendung) schnell freizugeben und Probleme darin zu beheben, bevor Abhängigkeiten und die Komplexität jeder Phase hinzugefügt werden ist hoch.


Ich habe gerade mein Exemplar von Software Engineering Economics herausgezogen und einen Verweis auf die Daten hinter dieser Tabelle in Kapitel 4 gefunden. Er zitiert "Design- und Code-Inspektionen zur Reduzierung von Fehlern in der Programmentwicklung" von ME Fagan ( IEEE , PDF von UMD ), EB Daly's "Management of Software Engineering", WE Stephenson's "Eine Analyse der in der Safeguard System Software Development ( ACM ) verwendeten Ressourcen" und "mehrere TRW-Projekte".

... die relativen Kosten für die Korrektur von Softwarefehlern (oder andere Softwareänderungen) in Abhängigkeit von der Phase, in der die Korrekturen oder Änderungen vorgenommen werden. Wenn ein Softwareanforderungsfehler während der Planungs- und Anforderungsphase erkannt und korrigiert wird, ist seine Korrektur eine relativ einfache Sache der Aktualisierung der Anforderungsspezifikation. Wenn derselbe Fehler erst in der Wartungsphase behoben wird, umfasst die Korrektur einen viel größeren Bestand an Spezifikationen, Code, Benutzer- und Wartungshandbüchern sowie Schulungsmaterial.

Darüber hinaus erfordern späte Korrekturen einen viel formelleren Genehmigungs- und Kontrollprozess für Änderungen und eine viel umfangreichere Aktivität zum erneuten Validieren der Korrektur. Diese Faktoren machen den Fehler in der Wartungsphase bei großen Projekten in der Regel 100-mal teurer als in der Anforderungsphase.

Bohem untersuchte auch zwei kleinere, weniger formelle Projekte und stellte einen Anstieg der Kosten fest, der jedoch weitaus weniger bedeutsam war als der 100-fache Wert, der in den größeren Projekten ermittelt wurde. In Anbetracht des Diagramms scheinen die Unterschiede viermal größer zu sein, um einen Anforderungsfehler zu beheben, nachdem das System betriebsbereit ist, als in der Anforderungsphase. Er führte dies auf den geringeren Bestand an Artikeln zurück, aus denen das Projekt bestand, und auf die verringerte Formalität, die dazu führte, dass einfacher und schneller repariert werden konnte.

Basierend auf Boehm in Software Engineering Economics ist die Tabelle in Code Complete ziemlich aufgebläht (das untere Ende der Bereiche ist oft zu hoch). Die Kosten für Änderungen innerhalb der Phase betragen in der Tat 1. Ausgehend von Abbildung 4-2 in Software Engineering Economics sollte eine Anforderungsänderung das 1,5- bis 2,5-fache der Architektur, 2,5 bis 10-fache der Codierung, 4 bis 20-fache der Testphase und 4 bis 5-fache der Testphase betragen. 100 in Wartung. Die Höhe hängt von der Größe und Komplexität des Projekts sowie der Formalität des verwendeten Prozesses ab.


In Anhang E von Barry Boehm und Richard Turner enthält das Buch Balancing Agility and Discipline einen kleinen Abschnitt zu den empirischen Ergebnissen in Bezug auf die Kosten von Veränderungen.

Die ersten Absätze zitieren Kent Becks Extreme Programming Explained und zitieren Beck. Wenn die Kosten für Änderungen im Laufe der Zeit langsam steigen würden, würden Entscheidungen so spät wie möglich getroffen und nur das umgesetzt, was benötigt würde. Dies ist als "flache Kurve" bekannt und treibt Extreme Programming an. Bisherige Literatur fand jedoch die "steile Kurve" mit kleinen Systemen (<5 KSLOC) mit einer Änderung von 5: 1 und großen Systemen mit einer Änderung von 100: 1.

Die Sektion zitiert das von der National Science Foundation gesponserte Center for Empirically Based Software Engineering der University of Maryland. Sie führten eine Suche in der verfügbaren Literatur durch und stellten fest, dass die Ergebnisse tendenziell ein Verhältnis von 100: 1 bestätigten, wobei einige Ergebnisse einen Bereich von 70: 1 bis 125: 1 anzeigten. Leider handelte es sich in der Regel um "große Design-Up-Front" -Projekte, die sequentiell verwaltet wurden.

Es gibt Beispiele für "kleine kommerzielle Java-Projekte", die mit Extreme Programming ausgeführt werden. Für jede Story wurde der Aufwand für die Fehlerbehebung, das neue Design und das Refactoring nachverfolgt. Die Daten zeigen, dass mit der Entwicklung des Systems (mehr User Stories werden implementiert) der durchschnittliche Aufwand in der Regel nicht unbedeutend zunimmt. Der Aufwand für das Refactoring steigt um ca. 5% und der Aufwand für die Aufwandsbehebung um ca. 4%.

Was ich lerne, ist, dass die Komplexität des Systems eine große Rolle für den Aufwand spielt. Indem Sie vertikale Schnitte durch das System erstellen, verlangsamen Sie die Kurvengeschwindigkeit, indem Sie die Komplexität langsam erhöhen, anstatt sie stapelweise hinzuzufügen. Anstatt sich mit der Komplexität der Anforderungen zu befassen, die von einer äußerst komplexen Architektur gefolgt wird, gefolgt von einer äußerst komplexen Implementierung usw., starten Sie ganz einfach und fügen weitere hinzu.

Welche Auswirkungen hat dies auf die Kosten für die Reparatur? Am Ende vielleicht nicht viel. Es bietet jedoch den Vorteil, dass die Komplexität besser kontrolliert werden kann (durch die Verwaltung der technischen Schulden). Darüber hinaus führen die mit Agile oft verbundenen häufigen Ergebnisse dazu, dass das Projekt möglicherweise früher endet - anstatt "das System" zu liefern, werden Teile geliefert, bis die Geschäftsanforderungen erfüllt sind oder sich ein neues System (und daher ein neues Projekt) drastisch geändert hat. wird gebraucht.


Stephen Kans Metriken und Modelle in Software Quality Engineering enthalten in Kapitel 6 einen Abschnitt über die Kostenwirksamkeit der Beseitigung von Phasendefekten.

Zunächst zitiert er Fagans 1976 erschienenen Aufsatz (ebenfalls in Software Engineering Economics zitiert), in dem er feststellt, dass Nacharbeiten im High-Level-Design (Systemarchitektur), im Low-Level-Design (Detail-Design) und in der Implementierung zehn- bis hundertmal billiger sein können als die Arbeit, die beim Testen auf Komponenten- und Systemebene geleistet wurde.

Er zitiert auch zwei Veröffentlichungen von Freedman und Weinberg aus den Jahren 1982 und 1984, die sich mit großen Systemen befassen. Das erste ist "Handbuch für exemplarische Vorgehensweisen, Inspektionen und technische Überprüfungen" und das zweite "Überprüfungen, exemplarische Vorgehensweisen und Inspektionen". Die Anwendung von Überprüfungen zu Beginn des Entwicklungszyklus kann die Anzahl der Fehler, die die Testphasen erreichen, um den Faktor 10 verringern. Diese Verringerung der Anzahl der Fehler führt zu einer Reduzierung der Testkosten um 50% bis 80%. Ich müsste die Studien genauer lesen, aber es scheint, dass die Kosten auch das Auffinden und Beheben der Mängel beinhalten.

In einer 1983 von Remus durchgeführten Studie mit dem Titel "Integrierte Softwarevalidierung im Hinblick auf Inspektionen / Überprüfungen" wurden die Kosten für die Beseitigung von Fehlern in verschiedenen Phasen untersucht, insbesondere für Inspektionen, Tests und Wartungen von Konstruktionen / Codes anhand von Daten aus dem Santa Teresa Laboratory von IBM in Kalifornien. Die genannten Ergebnisse geben ein Kostenverhältnis von 1:20:82 an. Das heißt, ein Fehler, der bei Konstruktions- oder Codeprüfungen festgestellt wurde, hat Änderungskosten von 1. Wenn derselbe Fehler beim Testen auftritt, sind die Kosten 20-mal höher. Wenn es einem Benutzer vollständig entgeht, werden die Korrekturkosten um bis zu 82 multipliziert. Unter Verwendung von Beispieldaten aus dem IBM-Werk in Rochester, Minnessota, stellte Kan fest, dass die Kosten für die Fehlerbehebung für das AS / 400-Projekt ähnlich sind um 1:13:92. Er weist jedoch darauf hin, dass die Erhöhung der Kosten auf die erhöhte Schwierigkeit zurückzuführen sein könnte, einen Defekt zu finden.

Die Veröffentlichungen von Gilb aus den Jahren 1993 ( "Software Inspection" ) und 1999 ("Optimizing Software Engineering Specification and Quality Control Processes") zur Softwareinspektion bestätigen die anderen Studien.


Weitere Informationen finden Sie möglicherweise auf der Seite von Construx zur Erhöhung der Fehlerkosten , die eine Reihe von Hinweisen zur Erhöhung der Fehlerkosten für die Reparatur enthält. Es sei darauf hingewiesen, dass Steve McConnell, Autor von Code Complete, Construx gründete und für diese arbeitet.


Ich habe kürzlich einen Vortrag, Real Software Engineering , von Glenn Vanderburg auf der Lone Star Ruby Conference im Jahr 2010 gehört. Er hat den gleichen Vortrag auf der Scottish Ruby Conference und Erubycon im Jahr 2011, der QCon San Francisco im Jahr 2012 und der O'Reilly Software Architecture Conference gehalten im Jahr 2015 . Ich habe nur die Lone Star Ruby Conference gehört, aber die Diskussion hat sich im Laufe der Zeit weiterentwickelt, als seine Ideen verfeinert wurden.

Venderburg schlägt vor, dass all diese historischen Daten tatsächlich die Kosten für die Behebung von Fehlern im Laufe der Zeit aufzeigen, nicht unbedingt, wenn ein Projekt mehrere Phasen durchläuft. Viele der Projekte, die in den zuvor erwähnten Artikeln und Büchern untersucht wurden, waren sequentielle "Wasserfall" -Projekte, bei denen Phase und Zeit zusammen verschoben wurden. Ein ähnliches Muster würde sich jedoch bei iterativen und inkrementellen Projekten einstellen - wenn ein Fehler in einer Iteration injiziert würde, wäre es relativ kostengünstig, ihn in dieser Iteration zu beheben. Während die Iterationen fortschreiten, passieren viele Dinge - die Software wird komplexer, die Leute vergessen einige der kleinen Details über die Arbeit in bestimmten Modulen oder Teilen des Codes, die Anforderungen ändern sich. All dies erhöht die Kosten für die Behebung des Fehlers.

Ich denke, dass dies wahrscheinlich näher an der Realität ist. In einem Wasserfallprojekt steigen die Kosten aufgrund der Anzahl der Artefakte, die aufgrund eines vorgelagerten Problems korrigiert werden müssen. Bei iterativen und inkrementellen Projekten steigen die Kosten aufgrund der zunehmenden Komplexität der Software.

Thomas Owens
quelle
@AndresF. Eines der Probleme, die ich beim Aufspüren dieser Zitate festgestellt habe, ist das, was Bossavit in dem von Ihnen verlinkten Buch als "Nadel im Heuhaufen" -Problem bezeichnet hat. Das Zitieren eines Buches ist eine große Verschleierung - selbst wenn es noch gedruckt ist, wenn Sie das Zitat lesen, müssen Sie ein paar hundert Seiten lesen, um nach dem kleinen Nugget zu suchen, das die Behauptung des zitierenden Autors stützt.
3

Es ist nur eine einfache Logik.

Fehler in Spezifikation festgestellt.

Case : Error found while reviewing UseCase/Function spec.
Actions:
        Rewrite paragraph in error.

Case : Error found during unit test.
Actions:
        Fix code.
        (Possibly) rewrite paragraph in spec.
        rerun unit test.

Case : Error found in integration test.
        Fix code.
        (possibly) rewrite paragraph in spec.
        rerun unit test.
        build new release.
        rerun integration test for whole system.

Case : Error found in UAT
        Fix code.
        (possibly) rewrite paragraph in spec.
        rerun unit test.
        build new release.
        rerun integration test for whole system.
        deploy release to UAT.
        rerun UAT tests.


Case : Error found in production
        Fix code.
        (possibly) rewrite paragraph in spec.
        rerun unit test.
        Build release.
        rerun integration test for whole system.
        deploy release to UAT.
        rerun UAT tests.
        deploy release to production.

Wie Sie sehen können, ist der Papierkram und die Bürokratie umso größer, je später der Fehler erkannt wird, je mehr Personen involviert sind.

Dies alles ohne Berücksichtigung der Kosten, die einem Unternehmen aufgrund eines Fehlers in der Produktionssoftware entstehen könnten (Umsatzverluste, Überbestellungen, Hackerangriffe auf Kunden usw. usw.).

Ich glaube nicht, dass es jemals jemandem gelungen ist, ein nicht triviales System zu schreiben, das niemals Fehler in der Produktion aufwies. Aber alles, was Sie tun können, um Fehler frühzeitig zu erkennen, spart Ihnen auf lange Sicht Zeit und Mühe. Spezifikationsüberprüfungen, Codeüberprüfungen, umfangreiche Komponententests, das Schreiben der Tests mit verschiedenen Codierern usw. usw. sind bewährte Methoden, um Fehler frühzeitig zu erkennen.

James Anderson
quelle
2
Dies gilt nur für einen Fall: Fehler, der in der Spezifikation erkannt wurde, dh ein Fehler, der ganz am Anfang auftritt. Fehler können jedoch in allen Phasen der Entwicklung (einschließlich der Fehlerbehebung nach der Bereitstellung) auftreten, und die Behebung dieser Fehler wird erheblich einfacher, da sie wahrscheinlich einen kleineren Teil des Systems beeinflussen.
Konrad Rudolph
2
Das Problem ist jedoch, dass Fehlerkorrekturen unerwartete Nebenwirkungen haben können. Wenn Sie also nicht garantieren können, dass die Korrektur nur einen bestimmten Teil der Komponenten betrifft, müssen Sie SIT UAT usw. erneut ausführen Veränderung.
James Anderson
2
Ich bin immer noch nicht davon überzeugt, dass dies zeigt, dass die Behebung von Fehlern immer teurer sein wird, wenn sie zu spät entdeckt werden. Ich würde behaupten, dass die Behebung eines Fehlers mit der Zeit, die nach seiner Einführung vergeht, teurer wird . Das heißt, ein Fehler, der spät eingeführt, kurz danach entdeckt und behoben wurde, ist billiger als ein Fehler, der sehr früh eingeführt und früh entdeckt wurde (jedoch mit einer längeren Verzögerung als im ersten Fall). Zumindest konnte ich mir vorstellen, dass es so funktioniert.
Konrad Rudolph
@KonradRudolph Könnten Sie das näher erläutern? Dieser Beitrag ist so ziemlich auch mein Verständnis, und ich verstehe nicht, warum Zeit wichtig ist, aber Phase nicht. Für mich ist das Maß für die Zeit in einem Projekt Ihre aktuelle Phase (und manchmal Ihre zeitliche Iteration, um alle Phasen zu durchlaufen). Ich sehe keinen Unterschied zwischen der Arbeit an Tag 3 des Detailentwurfs und der Arbeit an Tag 300 - das Detailentwurfsprodukt wurde nicht für die Herstellung anderer Arbeitsprodukte verwendet, sodass ein im Detailentwurf eingespritzter Fehler nur an einer Stelle und nur vorhanden ist erfordert dort eine Änderung. Ich verstehe nicht, wie wichtig der Lauf der Tage ist.
Thomas Owens
3
@Thomas Ich mache nur Hypothesen. Aber Zeit ist wichtig, da die meisten eingeführten Code- oder Spezifikationsmerkmale im Laufe der Zeit mehr Komponenten beeinflussen, es sei denn, sie sind hochspezialisiert und nichts anderes wird direkt oder indirekt von ihnen abhängen. Ein Fehler, der lange anhält, unabhängig davon, in welcher Phase er aufgetreten ist, kann sich auf viele Teile des Systems auswirken. Daher muss beim Entfernen sichergestellt werden, dass keine andere Komponente durch diesen Prozess beschädigt wird.
Konrad Rudolph
2

Ich glaube, das war und ist Risikomanagement und Ökonomie. Wie hoch sind die Kosten für die Reduzierung der Anzahl der Mängel gegenüber dem Barwert der Auswirkungen künftiger Mängel? Die Flugbahn des gelben Vogels, der in Angry Birds leicht abweicht, entspricht nicht der Flugbahn eines Tomahawk-Marschflugkörpers, der abweicht. Softwareentwickler in beiden Projekten können anhand dieser Tabelle keine Entscheidungen treffen. Daran ändert sich nichts.

Meiner Meinung nach funktioniert dies in der Regel über Feedback. Teure Fehler im Außendienst führen dazu, dass Unternehmen ihre Qualitätsprozesse verschärfen, während keine Beschwerden vom Außendienst die Unternehmen dazu veranlassen, sich zu entspannen. Daher tendieren Softwareentwicklungsunternehmen im Laufe der Zeit dazu, sich auf etwas zu konzentrieren oder zu oszillieren, das für sie funktioniert (+/-). Code Complete kann einige anfängliche Werte beeinflussen oder Unternehmen leicht in die eine oder andere Richtung ziehen. Ein Unternehmen, das sich zu viel Mühe gibt, um Fehler zu beseitigen, die niemand bemerken würde, wird wahrscheinlich das Geschäft an einen Konkurrenten verlieren, der einen optimierten Ansatz verfolgt. Andererseits wird auch ein Unternehmen, das Buggy-Produkte auf den Markt bringt, seine Geschäftstätigkeit einstellen.

Einige relevante Artikel aus einer Schnellsuche (lesen Sie die vollständigen Artikel, recherchieren Sie mehr und bilden Sie sich Ihre eigene Meinung):

Eine systematische Literaturrecherche zur Softwarequalitätskostenforschung (2011)

"Während die Community ein solides Verständnis für die Struktur des Forschungsbereichs entwickelt hat, fehlt es häufig an empirischer Validierung. Nur etwa ein Drittel der analysierten Artikel enthält eine Fallstudie oder umfangreichere empirische Ergebnisse. Dies scheint für die Softwarequalitätskostenforschung unzureichend zu sein Es besteht daher ein Bedarf an neuen Ansätzen für die Erfassung hochwertiger Kostendaten sowie an einer engeren Zusammenarbeit zwischen Industrie und Forschung, um diese Daten verfügbar zu machen. "

Bewertung der Kosten der Softwarequalität (1998)

"Schließlich haben wir festgestellt, dass es wichtig ist, die Software-Konformitäts- und Nichtkonformitätskosten zu überwachen, damit die Konformitätsrichtlinien angepasst werden können, um die Gesamtkosten der Softwarequalität zu senken."

Das Kostenverhalten von Softwarefehlern (2004)

Abstract ... "Die aktuelle Forschung versucht, unser Wissen über die Art und Weise zu aktualisieren, in der Fehler und die Kosten für deren Behebung (oder alternativ für deren Nichtbehebung) die endgültigen Softwarekosten beeinflussen." ... "Nichtbehebbare Fehler werden exponentiell teurer mit jeder Phase, in der sie ungelöst sind "

Testabdeckung und Nachprüfungsfehler: Eine multiple Fallstudie (2009)

"Wir stellen auch fest, dass der Testaufwand mit der Testabdeckung exponentiell zunimmt, die Reduzierung der Feldprobleme jedoch linear mit der Testabdeckung zunimmt. Dies legt nahe, dass für die meisten Projekte die optimale Abdeckung wahrscheinlich weit unter 100% liegt."

Brücke zwischen Softwaretestprozess und Geschäftswert: Eine Fallstudie (2009)

Guy Sirton
quelle
0

Ich kann Ihren ersten Teil der Frage nicht beantworten, da ich einfach nicht geprüft habe. Aber ich kann eine Antwort auf Ihre zweite Frage formulieren und vielleicht auf eine mögliche Antwort auf die erste hinweisen.

Es versteht sich von selbst, dass einige der wichtigsten Faktoren für die Behebung eines Fehlers, die von Haus aus nur schwer zu verwendende Entwicklungstools betreffen, die eigentliche Komplexität des Produkts sind und wie gut der Benutzer dieses Produkt verstehen kann.

Ich konzentriere mich für eine Sekunde auf Code und gehe davon aus, dass Code in der Regel von Entwicklern geschrieben und gepflegt wird, die in der Lage sind, mit der inhärenten Komplexität ihres Codes umzugehen (was möglicherweise nicht ganz stimmt und eine eigene Debatte verdient) Die Fähigkeit des Betreuers, diesen Code zu verstehen , ist für die Wartung und damit für die Behebung von Fehlern von entscheidender Bedeutung .

Die Fähigkeit, Code zu verstehen, wird durch die Verwendung bewährter Software-Engineering-Tools, die leider meistens nicht oder nur unzureichend verwendet werden, erheblich verbessert. Unter Verwendung der richtigen Abstraktionsebene sind Modularität, Verbesserung der Modulkohäsion und Reduzierung der Modulkopplung entscheidende Werkzeuge für die Bewältigung der Komplexität, die ordnungsgemäß eingesetzt werden muss. Das Codieren an Schnittstellen oder, in OOP, das Vermeiden der Überbeanspruchung der Vererbung gegenüber der Komposition, das Packen nach Merkmalen, sind einige der Techniken, denen beim Codieren häufig nicht genügend Aufmerksamkeit geschenkt wird.

Ich glaube, dass die Realitäten des Wettbewerbs in der Branche den Einsatz qualitätssteigernder Methoden zur Entwicklung von Software negativ beeinflussen und die Qualität von Software als Maß für den anhaltenden Erfolg niedrig halten.

Aus diesem Grund glaube ich, dass in der Industrie die Kosten für die Fehlerbehebung in der Regel umso höher sind, je größer sie werden. In solchen Produkten wird es mit der Zeit schwieriger, Fehler zu beheben, da das System mit zunehmendem Wachstum schwerer zu verstehen ist. Die Bedenken, die durch die einzelnen Funktionen hervorgerufen werden, sind zu stark mit anderen Bedenken verknüpft, was die Verständlichkeit erschwert. Oder es wurde nicht die richtige Abstraktionsebene verwendet, was es für den Betreuer schwierig machte, ein geeignetes Modell des Systems und eine Begründung dafür zu formulieren. Fehlende Dokumentation hilft sicherlich nicht.

Es gibt Ausnahmen. Ich bin mir sicher, dass Google nicht in seinem Tempo funktioniert, ohne dass einige solide Praktiken von herausragenden Entwicklern eingehalten werden. Und andere sind wahrscheinlich in der gleichen Situation. Aber für einen Großteil der Software, würde ich nicht überrascht sein , wenn die Daten haben in der Tat bestätigt die Behauptung in Code Complete .

Mihai Danila
quelle
Ich stehe zu meiner Antwort auch mit der negativen Bewertung. Ich habe kürzlich einen Kandidaten interviewt, der das Online-Banking-Tool einer der Top-Banken betreut. Während eines ungezwungenen Chats schlug er vor, es nicht zu verwenden, da es sich um eine häufige Wiederverwendung durch Kopieren und Einfügen und eine ansonsten miese Struktur handelte. Bei einem früheren Job war ich Entwickler bei einem Unternehmen, das Analyse-Tools für Banken wie Lehman, MS, UBS schrieb. Wir mussten als Domain-Experten fungieren und aus höchstens spärlichen Unterlagen herausfinden, was als nächstes in der else-Branche zu tun ist. Auch wenn die spezifischen Praktiken nicht übereinstimmen, ist die allgemeine Botschaft bezüglich der Branche wahr.
Mihai Danila
-1

Noch eine Antwort! Diesmal zur Beantwortung der Titelfrage "Verlässt sich Software-Morhtodoligy auf fehlerhafte Daten?".

Die eigentliche Antwort lautet "Es gibt keine Daten". Da es dort keine großen zuverlässigen Datenmengen zu Softwareprojekten gibt, gibt es Mängel, erfolgreiche Time-to-Market usw.

Alle Versuche, solche Daten zu erheben, waren unterfinanziert, statistisch fehlerhaft oder so projektspezifisch, dass keine allgemeinen Schlussfolgerungen gezogen werden können.

Außerdem glaube ich nicht, dass es jemals einen geben wird, der Softwareentwicklungsprozess ist zu subjektiv und rutschig für eine strenge Messung. Die am besten geeigneten Organisationen (die großen Softwarehäuser und Systemintegratoren) wissen in ihrem Herzen, dass es äußerst peinlich wäre, Zahlen zu ihrer Leistung zu sammeln.

Die einzigen Organisationen, die Zahlen über Kosten und Erfolg von Softwareprojekten veröffentlichen,
sind Regierungsabteilungen, und nur dann, weil sie es müssen, und ja, diese Zahlen sind zutiefst peinlich, egal wie sehr sie die Zahlen massieren.

Folglich sind alle Softwarestudien notwendigerweise rein subjektiv, da es keine realen Daten gibt, auf denen eine objektive Schlussfolgerung beruhen könnte.

James Anderson
quelle
1
Nein, das kaufe ich nicht. Zunächst einmal gibt es Daten, obwohl Sie vielleicht Recht haben, dass sie fehlerhaft sind. Dies erfordert jedoch eine individuelle Kritik jedes Datensatzes und keine generelle Entlassung. Und ich bin zutiefst misstrauisch gegenüber der Behauptung, dass es niemals Daten geben wird, und solchen Gründen wie „es ist zu subjektiv“. Das ist im Wesentlichen ein Argument aus Mangel an Vorstellungskraft . Ich behaupte nicht, dass das Sammeln zuverlässiger Statistiken hier einfach ist, aber ich behaupte, dass es durchaus machbar ist. Auf anderen Gebieten werden viel kompliziertere Systeme erfolgreich analysiert.
Konrad Rudolph
@Konrad - Nehmen Sie etwas Grundlegendes und Einfaches wie "Fehleranzahl", einige Shops zählen Testfehler, einige Shops beginnen erst mit UAT mit der Verfolgung von Fehlern, einige Shops verfolgen nur Fehler im Code, einige Shops enthalten Dokumentation, Konfiguration und Bereitstellungsskripte in ihrem Fehlerverfolgungsprozess. Zählt die falsche Hintergrundfarbe als Fehler? Einige Projekte werden es als einen Defekt verfolgen, andere werden es ignorieren.
James Anderson
Das sind alles parochiale - also lösbare - Probleme. Sie schränken das Mögliche nicht grundlegend ein, sondern fügen nur Probleme hinzu, die gelöst werden müssen.
Konrad Rudolph