Beruht die Softwaretestmethode auf fehlerhaften Daten?

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?

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?

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.

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.

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.

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)

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 .

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.