Bei der Bearbeitung eines Fehlers steht naturgemäß seine Behebung im Vordergrund, um die dadurch verursachte Einschränkung des Anwenders bei der Nutzung des Systems zu beseitigen. In vielen Fällen zwingen vereinbarte Reaktions- oder Fehlerbehebungszeiten zu einer schnellen Fokussierung auf eine Lösung, auch wenn es sich dabei nur um eine Umgehungslösung handelt, die das Auftreten des Fehlers nicht nachhaltig verhindert.
Blogserie: Produktivität in der Softwareentwicklung
- Produktivitätssteigerung in der Softwareentwicklung – eine Buchvorstellung
- Neues Buch: Produktivitätssteigerung in der Softwareentwicklung – Teil 2
- Drei Hebel für mehr Produktivität in der Softwareentwicklung
- Produktive Softwareentwicklung erfordert ein Managementmodell
- In der Softwareentwicklung ist jeder Fehler eine Chance
- Produktiver Durchblick: Monitoring in der Softwareentwicklung
Fehleranalysen können die Qualität nachhaltig verbessern
Jeder Fehler, bei dem nur die Auswirkungen behandelt werden, verursacht nichts als Kosten und Probleme. Demgegenüber verbessern Fehler, bei denen durch die Behandlung ihrer Ursache verhindert werden kann, dass sie erneut und mehrmals auftreten, nachhaltig die Qualität. Sie sparen – in Form nicht angefallener Korrekturkosten – bares Geld. Der Aufwand für eine Fehlerursachenanalyse ist daher kein zusätzlicher Aufwand, sondern eine Investition, die sich schnell bezahlt macht.
Die Suche nach der Ursache
Wird ein Fehler gemeldet, so beschreibt dieser Bericht zunächst nur die Auswirkungen, d.h. was der Anwender als Abweichung vom erwarteten Ergebnis oder Systemverhalten empfindet. Selbstverständlich ist dies eine wichtige Information, die dahin gehend einer genauen Überprüfung bedarf, ob es sich überhaupt um eine Abweichung handelt oder etwa um eine Fehlbedienung oder eine neue Anforderung. Für die Fehlerbehebung ist es anschließend jedoch entscheidend, – ausgehend von der Fehlerbeschreibung, die als Auswirkung am Ende der Ursache-Wirkungs-Kette steht – die genaue Ursache am Anfang der Kette herauszufinden. Hat man sie gefunden, ist zu prüfen, ob sie nicht ebenfalls durch ein anderes Problem oder eine Nachlässigkeit verursacht wurde. Diese rückwärts gerichtete Rekonstruktion der Ursache-Wirkungs-Kette, die auch als Fehlerursachenanalyse bezeichnet wird, findet ihr Ende meist bei einem Problem, das noch weitere Fehler verursachen könnte. Mit der Behebung dieses Problems sind somit alle dadurch bereits verursachten Fehler behoben und es werden zudem künftige Fehler vermieden.
Methodisch hilft es in der Praxis, sich an der 5-Why-Methode zu orientieren, bei der mehrfach (nicht zwingend fünfmal) nach dem Warum gefragt wird. Erst wenn es darauf keine sinnvolle Antwort mehr gibt, hat man mit hoher Wahrscheinlichkeit die Ursache des Fehlers gefunden, die Hinweise auf eine effektive Verbesserungsmaßnahme liefern kann. Als Beispiel mag eine Fehlermeldung dienen, die besagt, dass der Anwender den Inhalt in einem bestimmten Feld einer Maske nicht ändern kann, obwohl er aufgrund seiner Rolle dazu berechtigt sein sollte:
Selbstverständlich könnte man noch weiter hinterfragen, warum die Spezifikation unvollständig war. Nur oberflächlich und unzureichend hinterfragt würde man diesen Fehler übrigens als einen Programmierfehler oder GUI-Fehler klassifizieren. Dabei handelt es sich eher um einen Fehler in der Spezifikation, vielleicht aber auch um eine neue Anforderung (und somit um keinen Fehler). Mögliche Maßnahmen, um einen Fehler der Klasse „Fehler in der Spezifikation“ künftig zu verhindern, sind: mehr Gründlichkeit beim Anforderungsmanagement bzw. bei der Spezifikationserstellung, eine angemessene Qualitätssicherung sowie ein Freigabeprozess für die Spezifikation vor ihrer Implementierung.
Die Bedeutung einheitlicher Fehlerklassen
Für den Praxiseinsatz ist es empfehlenswert, die möglichen Klassen von Fehlerursachen unternehmensweit einheitlich festzulegen und jedem Fehler zwingend eine Klasse aus diesem Schema zuzuweisen, beispielsweise durch eine Auswahlliste im verwendeten Ticketing-System oder Error Tracking Tool. Die Standardisierung ist wichtig, um mit einfachen Mitteln Auswertungen zur Häufigkeit von Fehlern bestimmter Klassen vornehmen zu können. Diese lassen erkennen, in welchen Bereichen Verbesserungsmaßnahmen schon aufgrund der Fehleranzahl wahrscheinlich besonders effektiv sind. Um beim oben genannten Beispiel zu bleiben: Wurden 25 Prozent der auftretenden Fehler der Klasse „Fehler in der Spezifikation“ zugewiesen, sollte den Verantwortlichen klar sein, dass sie bei der Erstellung und QS der Spezifikationen ein Problem haben. Anders ausgedrückt haben sie jedoch auch die Chance, mit wahrscheinlich wenig zielgerichteten Maßnahmen ihre Fehlerrate um 25 Prozent zu verbessern und hohe Korrekturkosten zu vermeiden.
Für das in unserer Buchreihe „Produktivitätssteigerung in der Softwareentwicklung“ beschriebene Managementmodell sind die Ergebnisse von Fehlerursachenanalysen neben KPIs wichtige Eingangsgrößen der Phase Auswertung. Deren Ergebnisse bilden wiederum die Grundlage der Phase Optimierung, die innerhalb der Key Performance Areas (KPAs) nach möglichst wirksamen Verbesserungsmaßnahmen sucht. Um dies zu erleichtern, sollte das Schema der Fehlerklassen auf der obersten Ebene bereits nach den relevanten Handlungsfeldern gruppiert sein.
Bildquelle: Shutterstock
Dieser Beitrag hat 5 Kommentare
Interessant geschrieben.
Die Suche nach der Fehlerusache ist sicherlich ein guter Ansatz. Eine gute Dokumentation der Software wäre hierbei beispielsweise hilfreich, um auch die Logik hinter der Software zu verstehen. Besonders wenn neue Entwickler an das Projekt kommen.
Die 5 Why Methode klingt auch spannend.
Vielen Dank für den Beitrag.
Viele Grüsse
Sascha Thattil
Danke für den Beitrag zu Softwareentwicklung. Mein Neffe ist Softwareentwickler für ein großes Unternehmen, aber ich habe nie wichtig verstanden, was genau er macht. Er hat es immer so erklärt, dass er Programme entwickelt. Schön, darüber zu lesen.
Vielen Dank für den Beitrag. Ich arbeite bei einem Projekt für eine Kassensoftware für Gastronomie. Die Dokumentation finde ich bei einer Software sehr wichtig. Damit kann man einfacher die Software weiterentwickeln.
Interessant, dass man bei der Softwareentwicklung eine einheitliche Fehlerklassifizierung festlegen sollte. Ich und ein paar Freunde haben eine Idee für eine Software. Es wäre ganz gut, wenn wir uns schon früh auf solche Klassifizierung einigen könnten, oder? Oder ist es für kleinere Projekte weniger relevant?
Hallo Neeltje,
die Fehlerklassifizierung ist dann wichtig, wenn Du aus mehreren Fehlern “Hotspots” erkennen möchtest, um dort gezielt Verbesserungen vorzunehmen. Erkennst Du beispielsweise, dass die meisten Fehler durch Browsernavigation innerhalb Deiner Webanwendung verursacht werden, so ist das Navigationsverhalten der Anwendung die beste Stelle, um nach Verbesserungen zu suchen. Das wird auch in kleineren Projekten helfen, denn keine neue Software ist frei von Fehlern.