Themen

Ausgangspunkt: Software ist (fast) nie fehlerfrei

Umgang mit Fehlern in Software

Motivation: Warum eine Bugverwaltung?

Handhabung: Fehlerberichte, Feedback, Integration

Folien

PDF

Glossar

PDF

• Software ist (fast) nie fehlerfrei.
  Je früher Fehler entdeckt (und behoben) werden, desto besser und billiger.
• Die Wahrscheinlichkeit von Fehlern sollte aktiv minimiert werden
  (Wahl der Programmiersprache, Werkzeuge, …).
• Fehler sollten in Tests verwandelt
  und auch in Entwicklungsversionen behoben werden.
• Eine Bugverwaltung hilft Anwendern und Entwicklern
  durch Strukturierung und Automatisierung.
• Eine Bugverwaltung sollte fest in die restliche Infrastruktur
  und Abläufe bei der Projektentwicklung eingebunden sein.

Diese Fragen dienen der persönlichen Beschäftigung mit der Thematik, werden aber nicht separat in der Vorlesung besprochen.

• Lässt sich Code im allgemeinen beweisen? Welcher mathematische Satz ist dafür zentral?
• Welche Strategien gibt es, um die Zahl der Fehler zu reduzieren?
• Was sind die Vorteile einer Bugverwaltungssoftware?
• Welche Verantwortung kommt dem Nutzer, welche dem Entwickler, hinsichtlich des Umgangs mit Fehlerberichten (bug reports) zu?
• Welche Fragen sollte ein brauchbarer Fehlerbericht mindestens beantworten, um für die Entwickler nützlich zu sein?
• Worauf sollte bei der Verwendung einer Bugverwaltungssoftware im wissenschaftlichen Kontext insbesondere geachtet werden?

Eine kommentierte und handverlesene Liste mit weiterführender Literatur zum Thema. Die Auswahl ist zwangsläufig subjektiv.

Eine sehr auf die Situation in den Wissenschaften fokussierte Beschreibung von Bugverwaltung bzw. genauer gesagt Issue-Tracking-Systemen findet sich in [Scopatz, 2015Scopatz, Anthony; Huff, Kathryn D. (2015): Effective Computation in Physics, O'Reilly, Sebastopol] (Kapitel 21). Eine gute Zusammenfassung ist Abb. 21-1, die in einem Flussdiagramm den Ablauf von der Fehlerentdeckung über die Programmierung eines Bugfixes bis hin zur finalen Lösung erklärt und die Beteiligung weiterer Aspekte von Infrastruktur (Tests, Versionsverwaltung) aufzeigt.

• Scopatz, Anthony; Huff, Kathryn D. (2015): Effective Computation in Physics, O'Reilly, Sebastopol

Bugs können im schlimmsten Fall Menschenleben kosten, finanziell erhebliche Wirkung haben oder „nur“ die Reputation (zer)stören. Für alle das gibt es (leider) ausreichend Beispiele.

Der missglückte Jungfernflug der Ariane 5 der ESA ist, trotz des finanziellen Verlustes von alleine ca. 370 Mio USD für die vier Satelliten, ein Beispiel nicht nur für die fatale Auswirkung einer unterbliebenen Überprüfung des Wertebereiches einer Variablen, sondern auch ein Musterbeispiel der Aufarbeitung. Für eine sehr knapp gefasste Ursachenanalyse vgl. den Artikel von Bertrand Meyer [Jézéquel, 1997Jézéquel, Jean-Marc; Meyer, Bertrand (1997): Design by contract: the lessons of Ariane, Computer 30:129-130]. Ein Artikel auf Golem.de beleuchtet weitere ähnliche Software-Probleme in der Raumfahrt der 1990er Jahre und benennt als grundlegendes Problem die gestiegene Komplexität der Software durch die viel mächtigere Rechenhardware und die mangelnde Einbindung der Software-Ingenieure in den restlichen Entwicklungsprozess. Zu ähnlichen Einschätzungen kommt ein Artikel von N. G. Leveson vom MIT. Leveson war auch an der Aufarbeitung des Therac-25-Unfalls beteiligt (s.u.).

• Jézéquel, Jean-Marc; Meyer, Bertrand (1997): Design by contract: the lessons of Ariane, Computer 30:129-130

Nichts für schwache Nerven, aber eine sehr detaillierte Beschreibung, wie es zu den Fehlern mit Todesfolge (drei Tote, drei Schwerverletzte) beim in Kanada und den USA eingesetzten medizinischen Bestrahlungsgerät Therac-25 kam: der Artikel von Leveson und Turner. Das einzig Gute: In der Folge dieser Vorfälle wurden die Bestimmungen für Software im medizinischen Kontext in den USA angepasst.

• Leveson, Nancy G.; Turner, Clark S. (1993): An investigation of the Therac-25 accidents, Computer 26:18-41

Wer sich für die eingangs erwähnte Berechenbarkeit im Detail interessiert, dem sei als Einführung in die theoretische Informatik das Buch von Uwe Schöning [Schöning, 2008Schöning, Uwe (2008): Theoretische Informatik - kurz gefasst, Spektrum Akademischer Verlag, Heidelberg] und dort insbesondere Kapitel 2 empfohlen. Es richtet sich zwar an Informatiker und ist entsprechend formal, bietet dafür aber auf sehr knappem Raum sehr viel Information. Die originale Formulierung der Gödelschen Unvollständigkeitssätze findet sich in [Gödel, 1931Gödel, Kurt (1931): Über formal unentscheidbare Sätze der Principia Mathematica und verwandter Systeme I, Monatsh. Math. Phys. 38:173-198].

• Gödel, Kurt (1931): Über formal unentscheidbare Sätze der Principia Mathematica und verwandter Systeme I, Monatsh. Math. Phys. 38:173-198
• Schöning, Uwe (2008): Theoretische Informatik - kurz gefasst, Spektrum Akademischer Verlag, Heidelberg

Ein „Klassiker“ zur Verdeutlichung, warum präzise Fehlerbeschreibungen wichtig sind, ist das „Quantas-Mem“, der fiktive schriftliche Austausch zwischen Pilot und Technikern nach jedem Flug. Eine Seite, die das beschreibt, gleichzeitig aber durchaus noch ernsthaften Kontext liefert (ein ehemaliger Luftwaffenpilot der USAF):

• http://www.rb-29.net/html/03relatedstories/03.10.funstuff/17.qantas.htm