Die Spezifikation

Als ich in den letzten 80er Jahren des vergangenen Jahrtausends (uff!) begann, mich mit Informatik zu befassen, entdeckte ich schnell die phantastische Welt der Spezifikation. Um das nachempfinden zu können, muss man sich zunächst klar machen, dass auch der schnellste Computer letztlich eine dumme Maschine ist, der man Alles haargenau und klitzeklein erklären muss …

Der eine Teil der Informatik beschäftigt sich mit den Sprachen, die man dazu braucht, um ihm überhaupt irgendetwas erklären zu können, die andere Hälfte damit, was man ihm denn erklären will, nämlich der “Spezifikation”.

Kluge Menschen haben schon viele brauchbare Erklärungen aufgeschrieben, und diese werden in den jungfräulichen Computer in Form eines Betriebssystems hineingeladen. Ich muss ihm dann nicht mehr wirklich Alles selber sagen, vielleicht gibt es sogar GPS, eine Rechtschreib-Korrektur und einen kontext-sensitiven Editor für Programmiersprachen, rechnen kann er auch sehr gut. Also kann ich hier schon mal Vieles voraussetzen, doch was ist nun meine Spezifikation? Was soll das Ding für mich tun?.

Während einige Hard-Core-Informatiker euphorisch drauf los programmierten, erdachten andere die bizarrsten Formen und Rituale der Spezifikation, wie z.B. das berühmte “Vorgehensmodell”. Allen solchen Modellen war zunächst gemeinsam, dass sie die Spezifikation zuerst abschließen wollten, bevor das Programmieren begann. In der Regel hatten deren Verfechter auch vom Programmieren selbst wenig Ahnung, daher haben sie sich über die Umsetzbarkeit in Programmiersprachen und -prozessen wenig Gedanken gemacht..

Die Programmierer wiederum fanden die Spezifikation ähnlich lästig wie jede Gebrauchsanweisung (ab und zu muss man doch mal hineinschauen, knirsch), aber sie erstellten ein lauffähiges Programm. Nun stellt man fest, dass dieses Programm seine gedachten Aufgaben nicht erfüllt. Zum einen, weil es von der Spezifikation abweicht, zum anderen, weil die Spezifikation Vieles vergessen hat, das erst jetzt zutage tritt. Die Fachanwender erklären, dass man damit nicht arbeiten kann, und das Ganze geht in eine neue Revision.

Dies ist noch der glückliche Fall. Häufig wird der Gebrauch solcher Programme dennoch erzwungen, was die Mitarbeiter frustriert und die Fehlerhäufigkeit steigert.

Anwender können eine erstaunliche Kreativität in der unvorhergesehenen Nutzung unzulänglicher Programme entwickeln. So haben z.B. die Mitarbeiter eines großen deutschen Autovermieters das Attribut “Flugnummer” verwendet, um die Reservierung eines ganz bestimmten Autos (und nicht nur einer Fahrzeugklasse) zu hinterlegen – was ihnen eigentlich untersagt war und daher auch nicht vom Programm unterstützt werden sollte. Vor der Einführung dieses Programms und neuer Verfahren hatten sie sich damit beholfen, die Papiere des reservierten Fahrzeugs unterm Tresen verschwinden zu lassen, aber dies funktionierte nun nicht mehr.

Den Trick mit der “Flugnummer” konnten natürlich nur die Rental Stations nutzen, die nicht an einem Flugplatz stationiert waren. Allen anderen kann zugute, dass die Programmierer (oder schon die Spezifikation) vergessen hatte, das Flugnummer-Feld für sie zu sperren, welch ein Glück!

Sehr viel Freude hatten wir auch mit der fachlichen Befragung zur Spezifikation des Porsche-Verleihs. Alle waren sich einig, dass dabei besondere Regeln gelten, aber keine Regel wurde von allen akzeptiert, und viele schlossen sich gegenseitig aus. Nichts davon wurde spezifiziert oder programmiert. Wir hoffen nur, dass die spätere Programmversion noch weitere solche Lücken wie die “Flugnummer” enthält, um jedem sein eigenes Ritual des Porsche-Verleihs zu ermöglichen.

Nach und nach sah man in der Welt der Informatik auch ein, dass die Spezifikation und das Programmieren einen wechselseitigen Prozess bilden, weil durch das programmierte Ergebnis erst sichtbar wird, wie unklar die Spezifikation an vielen Stellen noch ist. Diese Iteration widerholt sich, und durch die “agile” Bewegung versucht man heute, solche Prozesse planbar zu machen.

König im Spiel bleibt aber letztlich der Anwender, der ein Programm durch beharrliche Besserwisserei vernichten oder aber kreativ nutzen kann. Lassen wir ihm diesen geheimnisvollen,  individuellen Spielraum, den man einer Maschine noch auf lange Zeit nicht wird erklären können.

Print Friendly, PDF & Email

Du magst vielleicht auch

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.