Typische Fehler-Quellen bei der Softwareentwicklung

Fehlerquellen

Die meisten Programm-Fehler lassen sich auf einige wenige Ursachen zurückführen. Diese will ich hier klassifizieren.

Codierung

Eine typische Fehlerquelle sind missverstandene, falsch interpretierte beziehungsweise nicht oder falsch dokumentierte Codierungen.

Nehmen wir eine Methode mit einem int-Parameter an. Der int-Parameter kann ein

• boolean-Schalter
• Betriebsarten-Schalter
• Wert mit ganzahligem Wertebereich
• Array-Index (Wertebereich von 0 bis Array-Größe-1)
• Index mit Basis 0 oder Basis 1
• ganze Zahl positiv oder negativ

Wertebereich

Fehler durch Nichbeachtung des möglichen Wertebereichs einer Variablen / eines Parameters gehören eigentlich mit zur Fehler-Klasse Codierung.

Seiteneffekte

Viele Programmfehler beruhen auf Seiteneffekten, die nicht dokumentiert sind, nicht überblickt werden oder gar nicht beabsichtigt sind.
Besonders bei Programmänderungen schleichen sich diese Fehler ein.
Es gibt mehrere Möglichkeiten für Seiteneffekte:

• aus Methode heraus (auf Objekt, JVM oder Kontext)
• aus Objekt heraus (auf JVM-statics, Session, Request oder Kontext)
• aus JVM heraus (Kontext, Datenbanken, Filesystem)
• aus Rechner heraus (physische Welt bei Steuerungen, Kontostände, Aktienkurse)

algorithmische Asymmetrien

Viele Abläufe in Programmen verlangen eine Vorbereitung (Initialisierung), eigentliche Ausführung und Ende-Bandlung(Rücksetzen).
Dazu gehört das Anfordern und Freigeben von Ressourcen.
Wird eines davon vergessen oder befindet sich in einem bedingt ausgeführtem Programmteil, so arbeitet das Programm fehlerhaft.

Lesen Sie hierzu auch meine Seite über algorithmische Symmetrie

redundante Speicherung/redundante Zustände

Es kann vorkommen, daß Daten oder Programm-Stati mehrfach gespeichert werden. Wird es vergessen, immer alle Änderungen auf alle Exemplare anzuwenden, kann es passieren, daß unterschiedliche Daten/Stati gelesen werden.
Deshalb sollten alle redundanten Speicherungen vermieden werden. Ist die redundante Speicherung zum Beispiel für das Performance-Tuning nötig, so sollten spezielle Maßnahmen und eine gründliche Dokumentation die Konsistenz der verschiedenen Exemplare sichern.

nicht formulierte oder nicht verstandene Anforderungs-Spezifikation

Wenn dem Entwicklerteam bestimmte Anforderungen nicht bekannt sind oder falsch verstanden wurden, entsteht falsche Software. Hier hilft die Einbindung des fachlichen Anwenders, häufige Tests und inkrementelle Vorgehensweise.

unabgestimmte Änderungen

Ich habe ein Projekt erlebt, in dem die Struktur der Backend-Datenbank häufig ohne Abstimmung oder Kommunikation zum Web-Team geändert wurde.

Dadurch traten immer wieder Fehler auf.

Dagegen helfen neben organisatorischen Maßnahmen Test-Programme gegen die Meta-Daten der Datenbank.

Mischung von Anwendungscode mit technischen Aspekten

Wenn das Framework, auf dem ein Projekt aufbaut, notwendige Features nicht unterstützt, neigt man schnell dazu, diese Features gemischt mit Anwendungscode zu implementieren.

Beispiele dafür sind Transaktions-Massnahmen (optimistisches Locking), Masken-Reset (Undo-Funktionalität) Caching (Cache-Timeout, LRU-Mechanismus, Synchronisation Cache und Persistenzspeicher) oder Thread-Synchronisation.

Dies ist prinzipiell fehleranfällig und verschlechtert den Code in der Art, dass weder die Fachlichkeit noch die technische Infrastruktur flexibel zu warten sind.

Werden die fehlenden Features später im Framework nachgearbeitet, so entsteht ein Anwendungscode, der auf unterschiedlichen API-Versionen aufbaut.

Die Folge sind Fehler und hohe Kosten. Deshalb sollte die Entwicklung eines Frameworks immer der Anwendungsprogrammierung voraus sein.