Benutzer-Werkzeuge

Webseiten-Werkzeuge


de:lehre:programmierkonzepte:ss2020:09:index

09. Bugverwaltung

Themen
Ausgangspunkt: Software ist (fast) nie fehlerfrei
Umgang mit Fehlern in Software
Motivation: Warum eine Bugverwaltung?
Handhabung: Fehlerberichte, Feedback, Integration
Folien
PDF
Glossar
PDF
Video
MP4


Webcast

Hinweis: Der Webcast wurde mit Tiny Webcasts for Lecture(r)s erstellt.

Zentrale Aspekte

  • 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 grundsätzlich 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.

Fragen zur Vertiefung und Wiederholung

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.

Bugverwaltung im wissenschaftlichen Kontext

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. Für den Kontext der allgemeinen Softwareentwicklung, insbesondere hinsichtlich Validierung und Verifizierung, vgl. Kap. 2 von [Sommerville, 2018Sommerville, Ian (2018): Software Engineering, Pearson, Hallbergmoos].

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

Folgen von Softwarefehlern

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.

Raumfahrt

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 kurzes Video von und mit Ian Sommerville (Autor des Buches „Software Engineering“ [Sommerville, 2018Sommerville, Ian (2018): Software Engineering, Pearson, Hallbergmoos]) liefert detailllierte Einblicke ebenso wie gute Tipps zum generellen Umgang mit Fehlern und dazu, wie man aus diesem konkreten Fehler lernen kann. 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

Menschenleben: Therac-25

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

Berechenbarkeit

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, Monatshefte für Mathematik und Physik 38:173-198], jene von Turing zum Halteproblem in [Turing, 1936Turing, A. M. (1936): On computable numbers, with an application to the Entscheidungsproblem, Proceedings of the London Mathematical Society 42:230-265].

  • Gödel, Kurt (1931): Über formal unentscheidbare Sätze der Principia Mathematica und verwandter Systeme I, Monatshefte für Mathematik und Physik 38:173-198
  • Schöning, Uwe (2008): Theoretische Informatik - kurz gefasst, Spektrum Akademischer Verlag, Heidelberg
  • Turing, A. M. (1936): On computable numbers, with an application to the Entscheidungsproblem, Proceedings of the London Mathematical Society 42:230-265

Zur Bedeutung guter Fehlerberichte

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):

Ein Essay, der beschreibt, wie ein guter Fehlerbericht aussehen sollte und was Entwickler, insbesondere von Open-Source-Software, erwarten, zumal sie die Software weitestgehend in ihrer Freizeit entwickeln, ist How to Report Bugs Effectively von Simon Tatham:

Herkunft von "Weinberg's Second Law"

Die Originalquelle für das Zitat von Gerald Weinberg, bekannt als „Weinberg's Second Law“, zu finden, ist gar nicht so einfach. Die Seite Quote Investigator hilft hier allerdings weiter, zumal man dort zitierfähige Quellenangaben und den Hinweis ihrer Bestätigung durch Scans der Originale findet.

Dilbert-Comicstreifen zum Thema

Ein Dilbert-Comicstreifen zum Thema Fehler und Rolle der Nutzer von Software illustriert sehr schön ein Problem und die Wahrnehmung von Softwareentwicklern: „I've detected the root cause of our problems – It's people. – They're buggy“.

de/lehre/programmierkonzepte/ss2020/09/index.txt · Zuletzt geändert: 2020/09/30 21:35 von 127.0.0.1