Softwareentwicklung: Der Weg von mündlicher zu formaler Sprache

Am Anfang steht das Wort. Jemand beschreibt, was er von der Software erwartet. Dies geschieht in deutsch, englisch oder sonst einer menschlichen Sprache. Daher ist es unvollständig, in sich widersprüchlich und mißverständlich. Am Ende steht ein Softwareprogramm, daß sich nach präzisen Regeln verhält.

Man kann den Entwicklungsprozeß also als zunehmende Präzisierung und Formalisierung der Anforderung begreifen.

Jeder Schritt auf diesem Weg führt zu einer Einengung der Auslegungsmöglichkeiten der Formulierung der Anforderung. In jedem Schritt sind somit auch fachliche Entscheidungen zu treffen.

Damit werden viele klassische Ansätze fragwürdig, die vorsehen, daß das fachliche Verständnis in einer Analysephase festgehalten wird und anschließend in einer Designphase nur die technische Umsetzung behandelt wird. Diese Vorgänge verschwimmen alle zusammen mit der Programmierung.

Eine vollständige, überprüfbare Darstellung der Software kann nur in einer formalen Sprache erfolgen. Dies war z.B. auch der Ansatz von UML/MDA. Jedoch kann es auch eine DSL oder ein hinreichend gut strukturiertes Programm sein. Wenn die Interfaces der Komponenten so gestaltet sind, daß sie die fachliche Intention offenbaren, werden Analyse, Design und Codierung eins.

Wenn eine vollständige, widerspruchsfreie Beschreibung vorliegt, so läßt sie sich zumindest prinzipiell Compilieren. Es gibt heute genügend Werkzeuge, um dies auch wirklich zu tun. Menschliche Arbeit ist hier meist Verschwendung von Ressourcen, so billig sie auch zu bekommen ist.

Lob des Wasserfallmodells

Das Wasserfallmodell der Softwareerstellung ist einfach nicht totzukriegen. Zwar scheitern immer wieder Projekte, die dieses Modell verwenden spektakulär, aber das liegt sicher nur an dem Unvermögen der Beteiligten.

Es lebt sich halt so schön mit dem Wasserfallmodell. Da schreibt man erst in aller Ruhe seine Lasten- und Pflichtenhefte, macht großartige Projektpläne und verteilt Aufgaben (heute möglichst international). Dann haben alle erst mal monatelang ihre Ruhe. Es gibt nichts, was die Theorie eines stetigen Projektfortschritts stört.

Wenn dann der vorgesehene Ablieferungstermin naht, werden alle etwas nervös. Das ist dann die Gelegenheit Karriere zu machen. Das Projekt hat jetzt die volle Aufmerksamkeit des Managements. Man kann in den Krisensitzungen wunderschön Kontakte mit wichtigen Leuten knüpfen.

Wenn es dann schief geht, müssen bei Auftraggeber und -nehmer geeignete Sündenböcke gesucht werden. Alle anderen haben doch alles richtig gemacht.

Nicht selten geht es im letzten Moment dann doch noch gut. Dann nämlich, wenn das Management in seinen Krisensitzungen das Entwicklungsteam ganz vergessen hat. Dieses organisiert sich nun selbst, da keiner mehr Zeit für die alten Regeln hat. Wenn man nachträglich das jetzt verwendete Vorgehen betrachtet, erkennt man meist große Ähnlichkeiten mit Vorgehensweisen, die in agilen Projekten geplant benutzt werden. Aber psst, nicht weitersagen.

Sprache, menschliche

Bei der Erstellung von Software hat man es nicht nur mit Computersprachen zu tun sondern auch mit der menschlichen Sprache. Dabei stellt sich häufig heraus, daß die menschliche Sprache das größere Problem ist. So ist die menschliche Sprache nicht konstant, sondern wird ständig erweitert und geändert. Im Prinzip benutzt jede Gruppe von Menschen eine unterschiedliche Sprachen. Dies merkt man zum Beispiel daran, daß man sehr schnell in der Kantine erkennt, in welchem Projekt ein Kollege arbeitet, allein an der Sprache die er in seiner Unterhaltung mit Kollegen verwendet.

Zudem ist die menschliche Sprache nicht kontextfrei. So hat das Wort "Decke" z. B. für einen Anstreicher eine andere Bedeutung als für einen Bettenverkäufer.

Wenn man sich in ein neues Thema einarbeitet, ist der erste Schritt, die Sprache zu verstehen, mit der die Fachleute über dieses Thema reden. Damit hat man dann auch die gedankliche Struktur verstanden, da wir in der Regel sprachlich denken.

Es ist daher enorm wichtig, daß in einem Softwareprojekt alle Beteiligten eine gemeinsame Sprache finden. Daher sollte auch eines der ersten Dokumente, das in der neuen Projekten angelegt wird, das Glossar sein. Darin wird jedes Projekt spezifische Wort definiert.

Ohne ein solches Glossar ist es z. B. auch fast unmöglich, Projektdokumentation in eine andere Sprache zu übersetzen, da dem Übersetzer in der Regel der Kontext fehlt. Hierbei muß dann das Glossar zuerst von Fachleuten übersetzt werden, ehe die restliche Dokumentation auch allgemeinen Übersetzern übergeben werden kann.

Daß die Kontextinformation enorm wichtig ist, sieht man sehr leicht an den Grenzen der automatischen Übersetzung. Genau das ist nämlich der Grund, weshalb die Übersetzungen zum Beispiel in Babelfish häufig eher spaßig als nützlich sind.

Softwareentwicklung als kreativer Prozeß

Ziel der Softwareentwicklung sollte es immer sein, etwas Neues zu schaffen. Dies muß nicht eine noch nie dagewesene Idee sein, sondern kann auch die Variation von etwas bekannten sein. Wenn aber etwas zum zweiten Mal gemacht wird, ohne neue Aspekte hinzuzufügen, so gibt es prinzipiell keinen Grund, nicht das Original zu benutzen und alle weitere Arbeit ist nur Zeit- (und Geld-)verschwendung.

Gleichzeitig ist die Softwareentwicklung auch eine sehr strikte Anwendung von Logik. In dieser Dualität zwischen Kunst und Mathematik ist die Softwareentwicklung der Architektur sehr ähnlich. Es ist daher kein Zufall, daß die für die Softwareentwicklung sehr fruchtbare Diskussion über Entwurfsmuster ihren Ausgang in einem Buch über Architekturmuster nahm.

Im Unterschied zur Architektur ist aber ein komplett aufgearbeiteter Entwurf bereits praktisch identisch mit dem Ergebnis. Wenn jedes Detail einer Software ausgearbeitet ist, muß ich nur noch kompilieren. Es werden nicht mehr große Mengen von Handwerkern bebraucht, die die Umsetzung von der Pläne in ein physisch existentes Gebäude durchführen.

In den Frühzeiten der Informatik war das mal anders. Damals war es recht mühselig, Lochkarten anzufertigen, diese zum Operator zu bringen, den Ausdruck des Ergebnisses abzuholen und dann die Lochkarten zu korrigieren. Damals wurden die Programme häufig von Experten auf Papier entworfen und dann von sogenannten Kodierern in verarbeitbare Lockkartenstapel umgesetzt. Bei den heutigen Entwicklungsumgebungen aber ist dieser Zwischenschritt überflüssig.

Wenn doch noch bei der Entwicklung langweilige Routineaufgaben anfallen, die man Hilfskräften übertragen könnte, machen wir etwas falsch. Dann ist entweder der Entwurf redundant oder wir benutzen die uns zur Verfügung stehenden Werkzeuge nicht richtig.