Lösen, welche Fehler den größten Kostenvorteil bringen [geschlossen]

Ich wollte eine Vorstellung davon bekommen, wie man Fehler kategorisiert, basierend darauf, wie einfach sie zu lösen sind und welchen Nutzen sie mir bringen. Zum Beispiel, wenn es einen Fehler gibt, dessen Behebung beispielsweise eine Stunde dauert (doppeltes Schließen der Datei usw.), während ein Fehler einen Tag dauert (Segmentierungsfehler). Aber wenn das Lösen des ersten Fehlers nicht sehr wichtig ist, werde ich wahrscheinlich am zweiten arbeiten.

Gibt es Forschungsarbeiten, die Fehler anhand des Kosten-Nutzen-Verhältnisses oder einer ähnlichen Metrik kategorisieren?

Angenommen, es ist möglich, Fehler anhand von Fehlermerkmalen zu kategorisieren, z. B. Sicherheitslücke, Speicherfehler, Logikfehler usw. In der anderen Dimension können Parameter wie Schwierigkeit (einfach, mittel, schwer) auftreten. Gibt es andere Dimensionen, nach denen ich suchen sollte? Zur Vereinfachung kann ich zwei Dinge annehmen:

1. Jeder Programmierer im Team ist gleichermaßen in der Lage, jeden Fehler zu beheben
2. Es gibt keine Frist

Das typische Fehlerverfolgungssystem verfügt über zwei, möglicherweise drei Felder, die das Kosten-Nutzen-Verhältnis von Fehlern identifizieren:

1. Priorität (vom Geschäftsinhaber vergeben)
2. Schweregrad (Klassifizierung des Fehlers - kritisch bis niedrig)
3. Geschätzte Stunden (eine Schätzung, wie lange es dauern wird)

Wie Sie bemerken, identifiziert dies, welcher Fehler der wichtigste ist, an dem gearbeitet werden muss.

Das in PEF / REV beschriebene System : Eine mehrdimensionale Fehlerverfolgungsmetrik fügt weitere Informationen zu den Geschäfts- und Entwicklerkomponenten hinzu, um den Kostenvorteil zu verbessern.

Alle Werte liegen auf einer Skala von 1 .. N (jeweils der gleiche Spitzenwert).

PEF wird vom Unternehmen identifiziert:

• P ain - Wie schmerzhaft der Fehler ist
• E ffort - Wie viel Aufwand ist erforderlich, um den Fehler zu umgehen
• F requenz - Wie oft der Fehler auftritt

REV kommt vom Entwickler:

• R isk - Wie riskant ist die Behebung des Systems?
• E ffort - Wie viel Aufwand ist erforderlich, um den Fehler zu beheben
• V erifiability - Wie einfach ist es, die Fehlerbehebung zu überprüfen?

Wenn Sie beispielsweise einen selten auftretenden Absturz haben, der leicht zu umgehen ist (automatische Speicherung aktivieren), kann dies ein PEF von 7,1,1 sein (Punktzahl 9). Während der Korrektur kann es zu einer Änderung eines Kernmoduls kommen und eine REV von 9,3,2 (Punktzahl 14) aufweisen.

Auf der anderen Seite könnten Sie einen Ärger haben, der immer da ist (3,3,9 - Punktzahl 15), der eine triviale Lösung hat (1,1,3 - Punktzahl 5).

In diesem Beispiel scheint der Ärger ein besseres Kosten-Nutzen-Verhältnis zu sein.

Das Problem, das Sie beschreiben, ist sehr häufig und die beste Antwort könnte "Verwenden Sie Ihr Bauchgefühl" sein.

Normalerweise teile ich Fehler in drei Kategorien ein: Absturz, Ärgerlich, Kosmetisch (sie können als 1, 2, 3 bezeichnet werden - das spielt keine Rolle) und dann eine Gesamtschätzung der Zeit aufstellen, die zur Behebung jedes Fehlers benötigt wird (alle Fehler müssen jederzeit eine grobe aktualisierte Schätzung haben).

Bei der Behebung von Fehlern Crashing> Ärgerlich> Kosmetik und dann mache ich einfach einen "kürzesten Job zuerst", um so viel Anfangsdurchsatz wie möglich zu erzielen.

Ich finde es SEHR schwierig, einen direkten finanziellen Nutzen aus der Lösung eines Fehlers zu berechnen - es sei denn, es handelt sich um einen sehr eng bezahlten bezahlten Job.

Eine Anmerkung, die Sie möglicherweise benötigen, ist, dass Sie dem fünften Punkt des Joel-Tests wirklich gerecht werden sollten - dies kann durch die Teamgröße und die Verteilung auf verschiedene andere "lokale" Probleme beeinflusst werden -, aber dies ist im Allgemeinen ein Zeichen für eine gute Praxis.

Eine weitere Überlegung könnte die Art des Tests oder der Testorganisation sein, die den Fehler aufdeckt, wenn versucht wird, die Auswirkungen und Kosten des Fehlers zu ermitteln und zu beheben. Einheiten- oder Funktionstests können auf etwas im Design hinweisen, das geändert werden muss, und daher wäre eine frühzeitige Korrektur einfacher und kostengünstiger als später. System- oder Integrationstests können auf etwas hinweisen, das eine größere Vielfalt von Kunden betrifft. Obwohl das Testen von Standards für eine große Anzahl von Kunden häufig unkritisch ist, kann dies zu einem Verlust der Zertifizierung führen, wenn es nicht korrigiert wird, und sich negativ auf das Geschäft auswirken.

Nur weil eine bestimmte Testorganisation einen Testfehler hat, sollte ein Fehler nicht automatisch "kritisch" werden. Beispielsweise könnte die Versuchung bestehen, etwas zu sagen wie "Alle Systemtests müssen vor dem Versand bestanden werden. Daher führt jeder Systemtest, der automatisch fehlschlägt, zu einem kritischen Fehler mit hohem Schweregrad." Hoffentlich würde keine Organisation diese Aussage treffen (gute Test-Exit-Kriterien sind eine andere Diskussion), aber der Punkt ist, dass die "Schwere" des Fehlers eher nach seiner Auswirkung auf das Kunden-, Produkt- oder Unternehmensimage beurteilt werden sollte als nach dem Ort oder wann ist aufgedeckt.

Eine Möglichkeit, dies zu beheben, besteht darin, zwischen "Schwere" und "Dringlichkeit" zu unterscheiden. Wenn sich das Veröffentlichungsdatum nähert, kann es beispielsweise zu Zeitdruck kommen, um festzustellen, ob ein Fehler mit anscheinend geringerem Schweregrad eine große Anzahl von Kunden betrifft, was dem Fehler eine größere "Dringlichkeit" verleiht und die Arbeit an diesem Fehler gegenüber (einigen) anderen bei erhöht zumindest bis diese Feststellung getroffen werden kann. Ein ausgewogenes Verhältnis zwischen beiden, zusammen mit Erfahrung und gutem Urteilsvermögen, würde dazu beitragen, festzustellen, wo Zeit und Mühe aufgewendet werden.

Zusätzlich zu dem, was andere über die Klassifizierung von Fehlern usw. gesagt haben, sollten Sie auch die afferente Kopplung (Ca) betrachten, um den Grad der Kritikalität zu bestimmen, den ein bestimmter Fehler darstellen könnte. Wenn Sie einen Fehler in einem Modul mit einer hohen Ca-Zahl haben, könnte ich versuchen, diesen zuerst zu beheben, da dies anderen Komponenten im System zugute kommen könnte. Ca hilft Ihnen dabei, den Grad der Verantwortung zu bestimmen, und verantwortliche Module mit Fehlern in der gesamten Anwendung (lesen Sie mehr über Ca hier: http://www.ibm.com/developerworks/java/library/j-cq04256/index.html) ).

In diesem Sinne neigen wir dazu, Fehler zu kategorisieren und sie basierend auf ihren Auswirkungen auf den Kunden zu priorisieren. Ihr Kunde wird unterschiedlich sein, aber wenn er in die Diskussion einbezogen wird, wird letztendlich entschieden, welche Fehler gegenüber anderen behoben werden sollten. Es ist nicht wirklich wissenschaftlich, aber als ganzes Team sind wir uns einig über die Priorität und Kategorisierung von Fehlern, jeder hat Input zu den "großen" (alle Stakeholder können Input geben) und wir stapeln und stapeln von dort aus.

Sie können die tatsächlichen Kosten aller Fehler nicht ermitteln. Einige können Sie, für viele ist es sehr schwer zu quantifizieren. Angenommen, Sie haben einen Fehler, der dazu führt, dass der gesamte Text auf den Schaltflächen leicht falsch ausgerichtet ist. Dadurch sieht Ihr 1.0-Produkt etwas schlampig aus. Dies führt nicht dazu, dass Ihr Programm abstürzt oder Ihre Benutzer Daten verlieren. Wahrscheinlich ein ziemlich billiger Fehler, oder?

Was ist nun, wenn jeder Ihrer Kunden dieses Problem bemerkt und jeder Rezensent es in Bewertungen Ihres Produkts erwähnt? Und was ist, wenn dieser Fehler von Version 1.0 auf 1.1 und 1.2 übertragen wird? Ihr Unternehmen hat jetzt möglicherweise den Ruf, bei der Qualitätskontrolle etwas schlampig zu sein. Wie teuer könnte dieser einfache Fehler in Bezug auf potenzielle Umsatzverluste für Ihr Unternehmen für zukünftige Produkte sein? Oder wie könnte sich dies auf eine Bewertung auswirken, die Ihr Produkt erhält? Ihr Produkt entspricht möglicherweise perfekt den Anforderungen Ihrer Kunden, erhält jedoch nur eine 9 von 10, da es etwas schlampig aussieht.

Sie müssen also nicht nur die Kosten eines bestimmten Fehlers im Hinblick auf die Kosten für die Behebung und die direkten Auswirkungen auf den Benutzer untersuchen, sondern auch im größeren Kontext berücksichtigen, wie sich dies auf die Wahrnehmung Ihres Produkts auswirkt auf dem Markt und wie sich diese Wahrnehmung auf zukünftige Verkäufe auswirkt.

Dies mag weit hergeholt erscheinen, ist es aber nicht. Zum Zeitpunkt, an dem ich dies schreibe, können Sie zu einer anderen Website im Web gehen, die einen Artikel darüber enthält, wie Apple die "1" in ihrem Kalendersymbol um ein oder zwei Pixel verschoben hat. Wenn Sie eine Suche durchführen, sehen Sie mehrere negative Artikel über diesen kleinen Fehler. Natürlich hat dies keinen direkten Einfluss auf das Endergebnis von Apple, aber sie bewerben sich als Höhepunkt guten Designs. Ein Designfehler wirkt sich also auf diese Wahrnehmung aus, wenn auch nur geringfügig.