• Qualitätsstandards und -richtlinien kennen: Es gibt ein haufen an Standard und richtlinien. Alle muss man nicht kennen. Viele Softwarefirmen sind z.B. ISO 9001 zertifiziert. Es wird festgelegt wie Unternehmen ihre Prozesse dokumentieren und kontinuirlich verbessern sollen.
  Um bei dem Beispiel der ISO 9001 zu bleiben ist dort festgelegt wie der Entwicklungsprozess von der Anforderungsanalyse bis zur Abnahme Dokumentiert wird. Dies wird gemacht, damit die Entwicklung transparent und Nachvollziehbar ist.
• Fehlerquellen analysieren: Systematisch wird hier gelernt Schwachstellen in IT Systemen, Prozessen oder Software zu erkennen und diese zu bewerten. Dazu sind verschiedene Schritte nötig:
  • Fehlerarten Identifizieren: Es muss unterschieden werden zwischen
    • bedienfehlern
    • Softwarefehler
    • Hardwaredefekten
  • Ursachenanalyse durchführen: Mithilfe verschiedenster Methoden wird gelernt den Fehler auf dem Grund zu gehen. Einige Methoden sind:
    • 5-Why-Methode: Eigentlich eine Einfache Methode 5 mal fragt man sich selber Warum. Ein Beispiel dazu ist weiter unten unter 5-Why-Methode zu finden.
    • Ishikawa-Diagramm: Ursache-Wirkungs-Diagramm oder auch Fischgrätendiagramm genannt.
      Das Ishikawa-Diagramm – auch bekannt als Fischgrätendiagramm oder Ursache-Wirkungs-Diagramm – dient der strukturierten Analyse möglicher Fehlerursachen. Ein Beispiel dazu ist weiter unten unter Beispiel Ishikawa-Diagramm zu finden.
• Tests und Prüfverfahren anwenden: Zunächst werden verschiedenste Testarten kennengelernt (wie z.B. Unit-Integrations-,Systemtest) sowie verschiedene Testmethoden (Z.B. Blackbox, Whitebox,etc.). Hier sollten Auszubildene mittels praktischer Übung selbst ein Programm erstellen und für dieses Programm Testfälle erstellen. Dafür eignen sich Unit Tests sehr gut. Je nach Anwendung wird hier gelernt wie Testdaten ausgewählt oder Testprotokolle erstellt werden. Dieser Punkt fördert das Qualitätsbewussten. (Siehe weiter unten das Beispiel Tests und Prüfverfahren).
• Maßnahmen zur Fehlerbehebung umsetzen: Tritt ein Fehler während eines Tests auf, sollte dieser natürlich behoben werden. Dazu muss folgendes erfolgen:
  • Lösungsstrategien entwickeln: Es wird gelernt aus Fehlerursachen konkrete Maßnahmen abzuleiten. Beispiel den Code korrigieren (anhand des Beispielen Fehler „Division durch 0“ eine automatische Prüfung das als Divisor der Benutzer ein Hinweis erhält das 0 als Divisor nicht erlaubt ist.
  • Fehlerbehebung dokumentieren: Jede Behebung nachvollziehbar in einem Fehlerprotokoll festhalten.
  • Wirksamkeit prüfen: Durch erneute Tests prüfen ob der Fehler tatsächlich behoben ist und sich durch die Behebung nicht neue Fehler eingeschlichen haben.
  • Kommunikation im Team: Der / die Auszubindende natürlich lernen Fehler und Lösungen im Team zu kommunizieren.
  • Prävention ableiten: Es ist noch kein Meister vom Himmel gefallen. Hier ist tatsächlich der Satz „Lerne aus deinem Fehlern“ Programm. Durch die Lösung und ordentlichen Dokumentation (einschweißen der Lösung) können diese oder ähnliche Fehler präventiv für die Zukunft ausgeschlossen werden.
    
• Dokumentation und Nachverfolgung: Hier geht es darum Fehler nachvollziehbar, strukturier und auch dauerhaft verfügbar zu Dokumentieren. Bei der Dokumentation ist folgendes zu beachten:
  • Vollständigkeit der Dokumentation: Alle Informationen müssen enthalten sein, z.B. die Fehlerbeschreibung, die Ursache, die Lösung des Problemes und alle Testergebnisse.
  • Nachvollziehbarkeit: Die Kollegen oder nachvolgende Programmierer müssen die Dokumentation verstehen können.
  • Struktur: Das Dokument sollte Strukturiert sein. Also Einheitliche Formate verwenden
  • Korrekte Sprache: Fachlich präzise in verständlicher Form.
  • Versionierung: Änderungen an der Dokumentation sollten Versioniert werden um so die Dokumente Nachvollziehbar zu gestalten. Einige Firmen verwenden zur Qualitätskontrolle sowie implementierung neuer Programmteile und Fehlerbehebung Tools wie Jira (externer Link).
    

Beispiele zur Fehlerquellenanalyse

Bei den Beispielen der Ursachenanalyse wird der Fehler „Division durch 0“ als Fallbeispiel für die unterschiedlichen Methoden verwendet.

5-Why-Methode

Das folgende Beispiel der 5-Why-Methode veranschaulicht die herangehensweise bei den Fehler „Division durch 0“:

• Warum wird durch 0 geteilt?
  → Weil der Divisor zur Laufzeit den Wert 0 hat.
• Warum hat der Divisor zur Laufzeit den Wert 0?
  → Weil er aus einer Benutzereingabe oder Berechnung stammt, die 0 ergibt.
• Warum wurde die Eingabe oder Berechnung nicht überprüft?
  → Weil im Code keine Validierung auf den Wert 0 vor der Division erfolgt.
• Warum fehlt die Validierung?
  → Weil sie im ursprünglichen Entwicklungsprozess nicht berücksichtigt oder getestet wurde.

Beispiel Ishikawa-Diagramm

Das folgende Diagramm veranschaulicht typische Ursachen für diesen Fehler und zeigt auf, wie er sich vermeiden lässt. Das Ishikawa-Diagramm (auch als Fischgrätendiagramm oder Ursache-Wirkung-Diagramm bekannt) hilft bei der Ursachenanalye.
Als Beispiel verwende ich ein Programmfehler „Division durch 0“ (ich denke kennt fast jeder der mit dem Programmieren anfängt).
Das folgende Diagramm zeigt ein Beispiel des Ishikawa-Diagramm zeigt Ursachen zu dem Fehler „Division durch 0“ und wie diese verhindert werden können.

FMEA (Fehlermöglichkeits- und einflussanalyse)

Die klassische Struktur der FMEA besitz 3 Kernbewertungen. Auftretenwahrscheinlichkeit (A), Bedeutung (B) sowie Entdeckungswahrscheinlichkeit(E).
Dabei werden die Kernbewertungen auf einer Skala von 1 (niedrig) bis 10(hoch) bewertet.

Beispiel Tests und Prüfverfahren

Test für Division durch 0

Durch diesen Test soll vermieden werden, dass das Programm abstürzt oder eine unbehandelte Ausnahme auswirft. Mit dem Beispiel Protokoll wird der Testfall festgehalten.

Der Beitrag Lfd 5 a Betriebliche Qualitätssicherung systematisch feststellen, beseitigen und dokumentieren erschien zuerst auf .

• Ursachen Feststellen:
  Aufbauend auf Lfd 5 a müssen erst einmal die Fehler analysiert werden. Dazu können natürlich Datenquellen verwendet werden, wie z.B. Log Files. Aus den Logs oder anderen Monitoring-Tools sowie das Verhalten des Programmes müssen Zusammenhänge erkannt werden.
• Maßnahmen zur Beseitigung umsetzten: Durch Anpassung des Codes kann Zielgerichtet eine Lösung entwickelt werden. Nach der Änderung des Codes muss des erneut geprüft werden ob der Fehler tatsächlich behoben ist (Dokumentieren nicht vergessen), bzw. keine Fehler an andere Stelle auftauchen.
• Dokumentation: Änderungen und Ergebnisse müssen klar, verständlich sowie nachvollziehbar dokumentiert oder im Team kommuniziert werden (Siehe Lfd 5 a).

Hier lernt man nicht nur reaktiv zu lernen, sondern proaktiv und Nachhaltig mit Qualitätsmängeln umzugehen.

Fallbeispiel

Bleiben wir bei den Fehler „Division durch 0“ aus den Beitrag Lfd 5 a.
Ausgangssituation: Es wurde gemeldet das ein Programm plötzlich beim Rechnen abstürzt

• Ursache Festellen:
  • Fehlerbild: Anwendungs stürzt ohne Meldung ab.
  • Analyse: Es wird das Logfile geprüft, dort fällt folgende Meldung auf „Unhandled Exception: Division by zero“
• Methode angewendet: 5-Why-Methode (Siehe Lfd 5 a)
  • Warum stürzt die App ab? → Weil sie eine Division durch 0 ausführt.
  • Warum wird durch 0 geteilt? → Weil keine erledigten Tickets vorhanden sind.
  • Warum prüft das Programm das nicht vorher? → Weil keine Validierung eingebaut ist.
  • Warum fehlt die Validierung? → Weil im ursprünglichen Konzept dieser Fall nicht bedacht wurde.
  • Warum wurde dieser Fall nicht getestet? → Es gab keinen Testfall für „keine erledigten Tickets“.
• Maßnahmen zur Fehlerbehebung anwenden:
  • Im Code wird die Eingabe durch eine Validierung der Eingaben des Benutzers geprüft.
  • Es wird ein Testfall zu dieser Rechnung erstellt
  • Es wird ein Regressionstest durchgeführt um sicher zu stellen, das der Fehler nun behoben ist und nicht an anderer Stelle der Software ein Fehler durch der Änderung auftritt.
• Dokumentation und Nachverfolgung:
  Der Fehler, die Ursache sowie Maßnahme und aktueller Status wird Dokumentiert (Siehe Lfd 5 a).

Der Beitrag Lfd 5 b Ursachen Qualitätsmängel systematisch feststellen, beseitigen und dokumentieren erschien zuerst auf .

Wie kann ich als Softwareentwickler die Qualität der Software messbar machen?

Das klingt zunächst etwas merkwürdig, nicht wahr?
Nun, so ungewöhnlich ist es auch nicht; ich nehme eines Beispiel für Quellcode, den ich hier veröffentlicht habe.

Fallbeispiel

Nehmen wir an, es wird ein Programm erstellt, welches eine mit „;“ getrennte Textdatei erstellen soll (Export von Daten), diese Textdatei hat am ende ca. 7688460 Zeichen. Da wir uns selber die Anforderung stellen das wir den Kunden nicht zu lange warten lassen möchten, setzen wir uns als Zeit direkt die höchst zeit von 1 Sekunde (welche wir auch als Qualitätsmerkmal verwenden).

Nach der Programmierung sehen wir das wir mehr als 48 Minuten nur zum einlesen benötigen. Jetzt schauen wir uns unser Gesetzes Ziel an:

Soll-Ziel: Ladezeit der Textdatei <=1 Sekunde
Ist-Zustand: ca. 48 Minuten
Etwas zu lang, 2.880 Sekunden.

Nach einem Brainstorming im Team erkennen wir, dass solche Aktionen besser mit einem String-Array anstatt mit einem normalen String durchgeführt werden sollten. Daher schreiben wir den Code um und testen ihn erneut.

Soll-Ziel: Ladezeit der Textdatei <=1 Sekunde
Ist-Zustand: ca. 0,23 Sekunden
Perfekt!

Wir haben uns übertroffen.

Mittlerweile gibt es ganz gute Frameworks, welche Daten aus einer Tabelle in einer CSV speichern können. Aber als Ausbilder war ich auch immer darauf bedacht den angehenden Programmierer die Roots zu zeigen, wenn er oder sie dann die Roots verstanden hat darf er/sie gerne Tools und Frameworks verwenden (sofern diese Lizenzrechtlich für die jeweiligen zwecke verwendbar sind).

Der Beitrag Lfd 5 c im Rahmen eines Verbesserungsprozesses die Zielerreichung kontrollieren, insbesondere einen Soll-Ist-Vergleich durchführen erschien zuerst auf .