Bugs und Schule

2018-08-08 · 1372 Wörter

software · bugs

Ich habe kürzlich auf einem sozialen Netzwerk geschrieben:

Falls Ihr Schülerinnen/Schülern zeigen wollt, wie und was sich aus Fehlern lernen lässt und das diese Teil des Lernprozesses sind, ladet Euch einen erfahrenen Softwareentwickler ein, der gut erzählen kann.

Tatsächlich bieten Softwarefehler (und ihre Behebung) eine gute Gelegenheit, um Fehlerkultur und das Lernen aus Fehlern auf interessante Art und Weise zu zeigen. Gleichzeitig kann die Geschichte des “Debugging” spannend sein wie eine gute Detektivgeschichte. Es gibt Bücher und sogar einen Roman über Software-Bugs. Gleichzeitig leisten Stories über Bugs, wenn die entsprechend aufbereitet werden, auch einen Beitrag zur informatischen Grundbildung und dem kritischen Denken. Schließlich sollte Software nicht ohne sie zu hinterfragen eingesetzt bzw. den Ergebnissen einfach geglaubt werden. Nicht nur Softwarefehler werden als “Bug” bezeichnet und der Begriff ist wahrscheinlich viel älter die berühmt-berüchtigte Motte, deren Dokumentation im Logbuch gerne Flotillenadmiral Grace Hopper zugeschrieben wird, der Grande Dame des frühen Computerzeitalters. Auch Grace Hopper wusste wohl, was mit der Software auf die Welt zukommen würde, wie eines ihrer Zitate zeigt.

“Life was simple before World War II. After that, we had systems.”
– Grace Hopper

Wie kann ich nun mit Hilfe von Berichten über Bugs, ihre Auswirkungen und die Suche nach ihrer Ursache für Schülerinnen und Schüler Erkenntnisse erhalten? Nicht überraschend werden dazu Berichte über Bugs benötigt. ;-) Allerdings schrieb ich in meinem Tweet noch von “einen erfahrenen Softwareentwickler, der gut erzählen kann”. Fangen wir mit “gut erzählen” an. Ich meine damit vor allem die Fähigkeit, komplizierte Themen auch für Nicht-Entwickler verständlich zu vermitteln. Dazu gehört aber auch, das Publikum nicht für dumm zu halten oder Dinge zu weit zu vereinfachen. Gerade Kinder und Jugendliche haben hier ein untrügliches Gespür dafür, ob Sie ernst genommen werden oder nicht. “Erfahren” sollte ein Entwickler sein, da sich mit zunehmender Erfahrung ein gesundes Verhältnis zu den eigenen Fähigkeiten und dem Umgang mit Bugs einstellt. Es gibt unter Entwicklern eine Liste mit den “Sechs Stufen des Debugging”, den meinen Punkt verdeutlichen.

Six Stages of Debugging

That can’t happen.
That doesn’t happen on my machine.
That shouldn’t happen.
Why does that happen?
Oh, I see.
How did that ever work?

Ich schreibe hier aus Erfahrung. Ich bin ein ausgewiesener Experte im Bugs schreiben, wie die meisten Softwareentwickler. Ich habe jede Menge Bugs produziert, die meisten davon (hoffe ich) glücklicherweise wieder gefunden und entfernt. Ich habe Bugs von anderen Leute gesehen und Dinge erlebt, die eine Mischung aus Bug, Hardwareproblemen und Esoterik waren. Natürlich gibt es auch die gefährlichen Bugs. Die, die tatsächlich Menschenleben gekostet haben oder hunderte Millionen Euro in die Luft gejagt haben. Umso wichtiger ist es, Bugs eben nicht nur als nervende Rundungsfehler in Excel zu sehen. Was dann auch nicht mehr so unwichtig erscheint, wenn man weiß, dass es Ärzte gab, die angeblich vor Jahren ihre Anästhesieberechnungen in Excel gemacht haben sollen …

Eine gute Bug-Story erlaubt es, ohne vorhandene Hardware interessante Ergebnisse zu produzieren, Strategien zur Fehlersuche (nicht nur für Software) zu vermitteln und bietet Ausgangspunkte für Projekte im Unterricht. Ein Bespiel, mit dem sich die Bereich Wandeln von Zahlensystemen, Darstellung von Gleitkommazahlen in Computern sowie ballistischer Flug und Geschwindigkeits/Weg-Rechnungen darstellen lässt, ist im folgenden Abschnitt ausgeführt.

Rundungsfehler + Raketen = Probleme!

Diesen “Bug” kann jeder Schüler auf seinem Smartphone oder einem Taschenrechner nachvollziehen. Sie geben die Zahl 1,0000001 ein und drücken dann 27x hintereinander auf die Quadratfunktion-Taste (x^2). Nach den ersten paar Tastendrücken zeigen sich bereits die ersten Rundungsfehler, weil die App oder der Taschenrechner nur mit einer begrenzten Anzahl von Stellen rechnet und ab einem bestimmten Punkt runden muss. Diese Rundungsfehler summieren sich. Das erwartete Ergebnis nach 27-Quadrierungen wäre übrigens 674530,4707. Bei billigen Taschenrechner kann man froh, wenn man auch nur in die Nähe dieser Zahl kommt. In diese Kategorie fallen auch die oben genannten Rundungsfehler bei Excel.

Rundungsfehler können allerdings auch wesentlich drastischere Auswirkungen haben. Am 25. Februar 1991 traf eine irakische Scud-Rakete eine Militärbasis in Dharan in Saudi-Arabien. Die als Schutz eingesetzte Patriot-Abwehrraketen-Batterie konnte dies nicht verhindern. 28 Soldaten starben und mehr als 100 wurden verletzt. Wie konnte so etwas passieren?

Die Patriot-Raketen fliegen im Idealfall einer ankommenden feindlichen Rakete entgegen und spielen dann die moderne Version einer guten alten Schrotflinte. In einem kurzen Abstand von idealerweise wenigen Metern spuckt die Rakete dem feindlichen Geschoss 1000 Metallpellets entgegen, die den Sprengkopf zum Auslösen bringen und die Rakete zerstören. Natürlich ist bei der Geschwindigkeit, mit der Raketen unterwegs sind, ein exaktes Timing alles. Die Patriot-Software berechnet daher ein Radarfenster, in dem eine anfliegende Rakete bei der nächsten Messung erwartet wird. Die interne Uhr der Patriot ticket mit einer Basis von 1/10 Sekunde. Um die Zeit in Sekunden umzurechnen, muss diese Takteinheit also mit 10 multipliziert werden. Der Computer der Patriot arbeitet mit einer fest eingestellten Nachkomma-Genauigkeit von 24 Bits. Und jetzt fängt die Sache an, interessant zu werden. Computer rechnen binär. Daher müssen wir aus dem Dezimalwert 1/10 eine binäre Dezimalbruchdarstellung machen.

In Binärdarstellung ist das dann 0.0001100110011001100110011001100…. – also ein periodischer binärer Dezimalbruch! Da die CPU der Patriot aber nur 24 Bits zur Verfügung hat, muss ab dieser Stelle abgehackt und gerundet werden. Mit jeder Zehntelsekunde, die die interne Uhr der Patriot seit dem Einschalten weitertickt, entsteht also ein minimaler Fehler (0.000000095 decimal, also etwa eine Millionstel Sekunde). Irgendwann “schielt” das Radargerät bzw. das Beobachtungsfenster also an die falsche Stelle am Himmel.

Das hatte das US-Militär auch bedacht. Das Bedienpersonal hatte daher die Anweisung, das System alle 24 Stunden neu zu starten (kommt das jemand von Windows bekannt vor?). Allerdings war die zweite Patriot gerade aufgrund Wartungsarbeiten abgeschaltet. Um “sicher zu sein”, ließ die Bedienmannschaft also die erste Reketeneinheit weiterlaufen. Etwa 100 Stunden lang. Das ergibt einen aufgelaufenen Rundungsfehler von:

0.000000095×100×60×60×10 => 0.34 Sekunden

Eine irakische Scud hat eine Geschwindigkeit von etwas über 1670 m/s, schafft in den 0.34 Sekunden also mehr als einen halben Kilometer. Und genau um diesen halben Kilometer hat die Patriot vorbei geschossen …

Es gibt noch einige technische Details, die an dieser Stelle zu weit führen würden. Wer aber Interesse hat, kann u.a. hier nachlesen.

Zusätzlich lässt sich an dieser Stelle noch diskutieren, ob der Bug sich wirklich so auswirken musste. Denn wäre der Hinweis auf das mögliche Problem der Bedienmannschaft bewusst gewesen, hätten Sie die Patriot wahrscheinlich nicht 100 Stunden durchlaufen lassen.

Debugging als Computerspiel?

Ein weiteres Beispiel ist der Fehler, der bei der Entwicklung des Computerspiels “Crash Bandikoot” auftrat. Der Entwickler beschreibt hier detailliert die Symptome und die Suche nach dem Bug.

Interessant hier ist Vorgehen bei der Fehlersuche. “Teile und herrsche” ist eine der Standard-Methoden bei der Suche nach Softwarefehlern. Infrage kommender Code wird zerteilt bzw. durch “Mocks” (Simulationscode) ersetzt, solange bis sich die Fehlerquelle eingrenzen lässt. Interessant ist an diesem Beispiel auch die interkulturelle Zusammenarbeit. Der Autor kennt das aus seiner IT-Tätigkeit als Systemadministrator für einen japanischen Konzern aus eigener Erfahrung. Hier ist entsprechende interkulturelle Sensibilität gefragt.

Fehlerkultur

Es gibt dieses schöne Zitat, das Edsger W. Dijkstra zugeschrieben wird (sogar Wikiquote sagt “Citation Needed”):

Wenn Debugging der Prozess ist, bei dem Fehler aus Programmcode entfernt werden, dann muss Programmieren der Prozess der Fehler-Produktion sein.

Jeder, der Software schreibt, auch wenn es “nur” Scripts zur Automatisierung von Aufgaben sind (Sie würden sich wundern, wie schnell man mehrere Tausend Produkte in einer Datenbank per Script mit der Farbe “bordeauxrot” versehen kann :-) ), hat sicher bereits Softwarefehler produziert. Auch wenn die glücklicherweise fast nie so dramatische Auswirkungen haben wie im ersten Beispiel. Eine entsprechende Fehlerkultur, die das Auftreten solcher Fehler einbezieht, ist daher unvermeidlich. Fehler sind nicht das Problem, solange aus ihnen gelernt wird. Abhängig vom Einsatzgebiet der Software sind Tests bzw. ein test-basierter Ansatz unerlässlich. Im schulischen Bereich wäre ein test-basierter Ansatz beim Lernen beispielsweise die Definition eines Erfolgskriteriums (der Test wäre dann “Ich kann den folgenden Textabschnitt fehlerfrei übersetzen”). Tritt dennoch ein Fehler auf, sind bestimmte Strategien hilfreich, die unter anderem hier beschrieben werden.

Im Unterricht lassen sich Fehler simulieren (in Software oder Hardware) und anhand hier entlehnter Fehlersuchtechniken ein logisches Vorgehen vermitteln. Auch bei einer Autopanne kann dieses Wissen hilfreich sein, ein systematisches Vorgehen hilft sicher mehr als Rütteln als irgendwelchen Teilen. :-)

Weitere Beispiele

Die nachfolgende Linkliste ist eine Ausgangsbasis für Recherchen zum Thema Softwarebugs mit ernsten möglichen Folgen: