In der Softwareentwicklung ist jeder Fehler eine Chance

In der Softwareentwicklung ist jeder Fehler eine Chance

Durch die zyklische Wiederholung von Messungen, Auswertungen und Optimierungen kann in der Softwareentwicklung eine zielgerichtete Verbesserung der Produktivität und Qualität erreicht werden. Die Fehleranalyse ist dabei ein wesentlicher Bestandteil.

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.

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:

Beispiel einer Fehlerursachenanalyse nach der 5-Why-Methode
Beispiel einer Fehlerursachenanalyse nach der 5-Why-Methode

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.

Schema zur Klassifizierung von Fehlerursachen
Schema zur Klassifizierung von Fehlerursachen (Auszug, Beispiel)

 

Bildquelle: Shutterstock

Hinterlassen Sie eine Antwort

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.