Wie viel Zeit sollte für Fehler im Vergleich zur ursprünglichen Entwicklung aufgewendet werden? [geschlossen]

Diese Frage ist ein wenig abstrakt, aber ich hoffe, dass mich jemand in die richtige Richtung weisen kann.

Meine Frage ist, wie viel Zeit man den Fehlern eines Softwareprojekts im Verhältnis zur ursprünglichen Entwicklungszeit widmen kann. Mir ist klar, dass es eine Vielzahl entscheidender Faktoren gibt, aber ich hatte auf eine typische oder durchschnittliche Panne gehofft.

Wenn Projekt A beispielsweise 40 Stunden in Anspruch nimmt und weitere 10 Fehler behoben werden, hat dieses Projekt ein Verhältnis von 4: 1.

Wenn ein anderes Projekt (B) 10 Stunden, aber weitere 8 Stunden dauert, hat es ein Verhältnis von 5: 4.

Ist das ein dokumentiertes / recherchiertes Konzept?

AKTUALISIEREN

Vielen Dank für alle informativen Antworten. Ich verstehe, dass es unmöglich ist, einen Standard für diese Art von Metrik festzulegen, da alle Variablen und Umgebungsfaktoren beteiligt sind. Bevor ich eine Antwort zuweisen möchte, möchte ich wissen, ob diese Metrik einen vereinbarten Namen hat, damit ich weitere Nachforschungen anstellen kann. Ich möchte an einen Punkt gelangen, an dem ich die Messungen verstehen kann, die zur Erstellung der Metriken selbst erforderlich sind, und schließlich einen Basisstandard für mein Projekt entwickeln kann.

Der Gleichgewichtsprozentsatz der Gesamtkapazität, die der Fehlerbehebung zugewiesen ist, entspricht der Fehlerinjektionsrate .

Viele Faktoren können diese Rate beeinflussen, unter anderem natürlich: Welche Art von Produkt entwickelt das Team, welche Technologien und technischen Praktiken werden verwendet, wie gut das Team ist, welche Unternehmenskultur wird verwendet usw.

Wenn Team B durchschnittlich 8 Überarbeitungseinheiten für jeweils 10 abgeschlossene Arbeitseinheiten erstellt, werden durch die Bearbeitung dieser 8 Einheiten neue 6,4 Überarbeitungseinheiten erstellt. Wir können den Gesamtaufwand, den sie eventuell aufwenden müssen, als Summe eines geometrischen Verlaufs abschätzen:

10 + 8 + 6,4 + 5,12 + ...

Die Anzahl der Bugs nimmt mit der Zeit exponentiell ab, aber Team B hat einen solchen Koeffizienten in seinem Exponenten, dass er sehr langsam auf Null geht. Tatsächlich beträgt die Summe der ersten drei Terme in der obigen Reihe nur 24,4; von den ersten fünf 33,6; von den ersten 10 45; der gesamten Serie, 50. Also, Team B Zusammenfassung: Defektinjektionsrate, 0,8; Merkmalsentwicklung, 10/50 = 20%; Fehlerbehebung, 80%. 20/80 ist ihre nachhaltige Kapazitätsallokation.

Im Gegensatz dazu ist Team A in einer viel besseren Verfassung. Ihr Fortschritt sieht folgendermaßen aus:

40 + 10 + 2,5 + 0,625 + ...

Die Summe dieser Serie beträgt 53 1/3, daher beträgt die Zuweisung für die Funktionsentwicklung von Team A 40 / (53 1/3) = 75% und die Zuweisung für die Fehlerbehebung 25%, was ihrer Fehlerinjektionsrate von 10/40 = 0,25 entspricht .

Tatsächlich sind alle Begriffe in der Serie von Team A nach den ersten drei zu vernachlässigen. In der Praxis bedeutet dies, dass Team A wahrscheinlich alle Fehler mit ein paar Wartungsversionen beseitigen kann, wobei die zweite Version einen recht kleinen Umfang hat. Dies schafft auch die Illusion, dass jedes Team das kann. Aber nicht team b

Ich habe über diese Entsprechung nachgedacht, als ich David Andersons neues Buch "Kanban" gelesen habe . (Das Buch befasst sich mit einem anderen Thema, geht aber auch auf Qualitätsprobleme ein.) Bei der Erörterung der Softwarequalität zitiert Anderson dieses Buch von Capers Jones mit den Worten "Software Assessments, Benchmarks und Best Practices" :

"... im Jahr 2000 ... die gemessene Softwarequalität für nordamerikanische Teams ... reichte von 6 Fehlern pro Funktionspunkt bis zu weniger als 3 pro 100 Funktionspunkten, einem Bereich von 200 bis 1. Der Mittelpunkt liegt bei ungefähr 1 Fehler pro 0,6 bis 1,0 Funktionspunkte. Dies bedeutet, dass Teams häufig mehr als 90 Prozent ihres Aufwands für die Behebung von Fehlern aufwenden. "Er nennt ein Beispiel eines Kollegen eines Unternehmens, das 90% der Zeit damit verbringt, ihre Fehler zu beheben .

Die Geläufigkeit , mit denen geht Anderson aus der Defekt Injektionsrate zur DEFEXT Festsetzungskapazitätszuweisung ( Ausfall Forderung ist der Begriff dafür) schlägt vor , dass die Gleichwertigkeit der beiden Dinge gut zu Software - Qualität Forschern bekannt und wird wahrscheinlich seit einiger Zeit bekannt .

Die Schlüsselwörter in der Argumentationslinie, die ich hier präsentieren möchte, sind "Gleichgewicht" und "nachhaltig". Wenn wir Nachhaltigkeit aufheben, gibt es einen offensichtlichen Weg, diese Zahlen zu betrügen: Sie machen die anfängliche Kodierung, fahren dann fort, um woanders zu kodieren, und überlassen die Wartung anderen. Oder Sie führen die technischen Schulden aus und laden sie bei einem neuen Eigentümer ab.

Offensichtlich wird keine bestimmte Zuordnung für alle Teams passen. Wenn wir entschieden haben, dass 20% für Bugs ausgegeben werden müssen, dann haben ein Team mit einer extrem niedrigen Fehlerinjektionsrate einfach nicht genug Bugs, um die Zeit auszufüllen, und wenn ein Team eine sehr hohe Rate hat, dann sind es die Bugs wird sich weiter ansammeln.

Die Mathematik, die ich hier verwendet habe, ist sehr vereinfacht. Ich habe Dinge wie Transaktionskosten (Planungs- und Schätzungsbesprechungen, Post-Mortems usw.) vernachlässigt, die die Prozentsätze etwas beeinflussen würden. Ich habe auch Gleichungen weggelassen, die simulieren, dass ein Produkt erhalten bleibt und gleichzeitig ein anderes entwickelt wird. Aber die Schlussfolgerung bleibt bestehen. Tun Sie, was Sie im Hinblick auf technische Verfahren tun können, wie z. B. Komponententests, kontinuierliche Integration, Codeüberprüfungen usw., um Ihre Fehlerinjektionsrate und folglich Ihre Fehleranforderung zu reduzieren. Wenn Sie nur einen Fehler für jeweils 10 Funktionen erstellen können, haben Sie viel Zeit, um neue Funktionen zu entwickeln und Ihre Kunden zufriedenzustellen.

Leider glaube ich, dass dieses Verhältnis in einem bestimmten Projekt sehr unterschiedlich ist. Es wird drastisch von Ihrer Umgebung, Sprache, Tools, Teamgröße und Erfahrung beeinflusst.

Sie sollten sich nur dann mit einem Fehler befassen, wenn das, was Sie durch die Korrektur erhalten, durch Ihre Investition größer ist.

Verwenden Sie eine Matrix wie die folgende (horizontale Zeit zur Behebung des Fehlers, vertikale Art des Fehlers - Auswirkungen auf Benutzer)

              | Few hours | Many hours
--------------+-----------+-------------------------
Minor problem | Might fix | Fix only if time permits
--------------+-----------+-------------------------
Major problem | Fix       | Fix

Beispiel für Probleme:

              | Few hours                            | Many hours
--------------+--------------------------------------+---------------------------------
              | Window moves 1px every 10            | Windows is painted incorrectly 
Minor problem | times when you open the application. | every 100th time the app is open.
              | Fix is: handle window resize event   | Fix: Change the graphical engine.
--------------+--------------------------------------+---------------------------------
Major problem | Application crashes when opening     | Poor performance when >100 users 
              | SQL connection.                      | are connected (unusable app)
              | Fix: Fix invalid query + add nice    | Fix: change architecture + DB
              | message                              |

Die Matrix kann komplexer sein und unterschiedliche Schweregrade, Aufwände, Risiken usw. Aufweisen

Sie können sogar einen Rang für jeden Fehler erstellen und ihn basierend auf dem Rang korrigieren. So etwas wie:

Bug priority = Risk x Severity x Effort

* Kann für einige Operanden (1-x) sein, je nachdem, welchen Maßstab Sie wählen :)

Zur Beantwortung Ihrer Frage: abhängig von der Art der Fehler, der verfügbaren Zeit / dem verfügbaren Budget usw.

Dies hängt nicht nur (natürlich) von der Erfahrung und Qualität des Teams sowie von der Schwierigkeit des Projekts ab (es ist nicht dasselbe, das eine andere Standard-Webanwendung als ein neuer Betriebssystemkern erstellt), sondern auch von Ihrem Managementansatz werde verwenden.

Beispielsweise können Sie bei einem Wasserfallmodell den ersten Fehler in der ersten Testphase genau festlegen. In einer agilen Umgebung kann es jedoch schwierig sein, eine Zeile mit der Aufschrift "Ab jetzt korrigieren wir Fehler" zu erstellen, da sich die Funktionen ändern können. ( und für mich ist es nicht fair, eine Funktionsänderung als Fehler zu betrachten)

Aus Erfahrung sage ich, dass es etwas ist, das IMMER unterschätzt wird und sehr leicht die gleiche Anzahl von Stunden verbringen kann wie das "ursprüngliche Projekt".

Die wirklich richtige Antwort wäre null Stunden für Fehlerbehebungen, da Ihr Code perfekt ist. :-)

Realistisch kann ich nicht sagen, dass ich jemals jemanden gefragt oder diese Art von Verhältnis angeboten habe. Das heißt nicht, dass einige Unternehmen die Zeit für Entwicklung und Wartung nicht erfassen. Die Entwicklung einer Anwendung ist jedoch im Vergleich zur Wartung so kurz, dass die meisten Unternehmen diese Quote nicht berechnen. Sie sind wahrscheinlich mehr besorgt darüber, warum eine App gewartet werden muss, und wenden diese Erkenntnisse auf neue Anwendungen an.

Wenn Sie ein zu breites Kriterium für einen Fehler haben, können Sie Ihre Zeit fast verdoppeln. Ein eifriger Manager, der denkt, dass ein Kunde eine Schaltfläche vergrößern möchte (er hat Mausprobleme), ist eine großartige Möglichkeit, die Anzahl der von uns behobenen Fehler zu erhöhen. Die Reparatur dauert nur wenige Sekunden, da das Überlegen, Testen, Neukompilieren und Verteilen eines Patches nicht erforderlich ist. Oh, und es wird als neues Feature doppelt gezählt.

Der wichtigste Faktor dafür ist, ob Sie mit einer neuen oder einer vorhandenen Technologie arbeiten. Wenn Sie mit etwas Neuem arbeiten und etwas entwickeln, das noch nicht oder einige Male unter verschiedenen Umständen durchgeführt wurde, werden Sie viel Zeit für Bugfixes aufwenden und Ihr Projekt so gestalten, wie Sie es möchten . Häufig treten Fehler auf, wenn Sie sich in eine Ecke begeben, und Sie müssen einen erheblichen Arbeitsaufwand leisten, um das, was Sie getan haben, neu zu strukturieren. Darüber hinaus resultieren viele Fehler aus einem unvollständigen Verständnis der Benutzererwartungen und dem Unwissen des Entwicklers über Randfälle.

Wenn Sie an einer etablierten Technologie arbeiten, wurden die meisten Probleme von den Bibliotheken oder von den Praktiken in der Community gelöst, und Sie sollten in der Lage sein, Fehler zu googeln, zu kaufen oder nachzufragen.

Bei kritischer Software ist ein Verhältnis von 1: 1 nicht ungewöhnlich. Alleine für Unit-Tests habe ich gesehen, dass Indikatoren 1 Tag Unit-Test für jeweils 10 Codezeilen erwähnen.

Ich denke, dass diese Frage voreingenommen ist: Es geht von der Voraussetzung aus, dass das Korrigieren von Fehlern eine Phase ist, die der Entwicklung neuer Funktionalitäten ähnelt . Das ist nicht der Fall.

Ein guter Entwickler wird nicht viel Zeit mit dem Debuggen von Code verbringen, da sein Code von Anfang an fehlerfrei ist. Ein schlechter Entwickler wird viel Zeit damit verbringen, seinen Code zu debuggen, da er keine geeigneten Abstraktionen erstellen kann, um echte Probleme zu lösen.

Beachten Sie, dass Entwickler ihren eigenen Code selbst testen sollten. Es liegt in ihrer Verantwortung, fehlerfreien Code zu liefern. Daher ist es schwierig, Codierung und Debugging voneinander zu trennen.

Es ist auch eine Frage der Priorität. Bei der Entwicklung hängt die zur Korrektur eines Fehlers erforderliche Zeit exponentiell von der Zeit ab, die seit dem Einfügen des Fehlers in den Code vergangen ist. Die Behebung von Fehlern sollte daher Vorrang vor der Entwicklung neuer Funktionen haben.

Anstatt von "Zeit für Bugs" zu sprechen, sollten Sie von "Zeit für Tests" sprechen (Integrationstests, Benutzerakzeptanztests ...)

Ich denke, Sie haben Recht - Sie werden aufgrund der Vielzahl von Einflussfaktoren keine aussagekräftige Messgröße erhalten.

Wenn es hilft, kann ich Ihnen sagen, dass Projekte, an denen ich arbeite (Unternehmensbereich, große komplexe Systeme, viele Integrationen in andere Systeme), ein Verhältnis von etwa 3: 2 haben. Die meisten davon sind keine Fehler mit dem Code - in der Regel Fehler mit den Schnittstellen. Zum Beispiel sprechen System A und B über die Schnittstelle X miteinander. Die Entwickler von System A interpretieren die Schnittstelle X geringfügig anders als die Entwickler von System B. Es folgt eine Komödie.

Eine Bemerkung, die gemacht werden sollte, ist, dass die Entwicklung von Code und das Testen / Beheben von Fehlern von Code nicht zwei getrennte Phasen sein sollten. Wenn Sie während der Entwicklung testen, sind die "Kosten" für die Fehlerbehebung geringer.

Ich nehme einen rein praktischen Standpunkt ein: Was behindert den praktischen Nutzen des Projekts mehr? Wenn es sich um Fehler in vorhandenen Funktionen handelt, sollten Sie diese beheben. Wenn es sich um fehlende Funktionen handelt, sollten Sie die ursprüngliche Entwicklung durchführen und die Fehler beheben, sobald die schwerwiegendsten fehlenden Funktionen implementiert sind. Dies setzt voraus, dass Sie mit Ihren Anwendungsfällen vertraut sind. Ein Fehler, der das Programm in einigen ungewöhnlichen Fällen zum Absturz bringt, hat möglicherweise eine geringere Priorität als geringfügige Verbesserungen der Benutzerfreundlichkeit, die alle betreffen. Ein kleiner Fehler in den am häufigsten verwendeten Funktionen ist möglicherweise wichtiger als eine Funktion, die nur Personen zugute kommt, die Ihre Software auf die Spitze treiben.