Download Full Text - Mathematical Journals

2 Entwicklung, Design, Gestaltung
Man spricht von der Entwicklung von Software und meint damit einen Prozess, der Beschreibungen ineinander überführt6. An seinem Anfang steht eine Beschreibung, die man oft „Anforderungsdefinition” nennt. Gern wird diese erste Vorgabe als Szenario formuliert. Am Ende
des Prozesses steht eine Beschreibung, die „Programm”, „Implementierung”, „ausführbarer
Code” o.ä. genannt wird. Hat die erste Beschreibung reine Textgestalt (mit Skizzen, Diagrammen, Tabellen etc.), so ist die letzte Text in der Form maschineller Lesbarkeit.
Wie jeder und jede weiß, sind die beiden Pole der Kette vom Menschen wie vom Computer lesbar, jedoch ergeben sie für diese zwei Interpreten – wenn solch gemeinsame Benennung gestattet ist – unterschiedlichen, wenngleich verwandten Sinn. Ich beeile mich zu versichern, dass es Sinn für den Computer gar nicht geben kann, dass er „Sinn”7 aber durchaus
feststellen mag – ja, dazu gezwungen ist, dies zu tun, damit die erwähnte Beschreibung tatsächlich zu dem führen kann, zu dem sie führen soll – nämlich zu einer Operationenfolge.
Die Entwicklung von Software ist also die Entwickelung einer Beschreibung, die zu Beginn höchsten Grad an Lesbarkeit für den Menschen, jedoch niedrigsten für die Maschine
besitzt. Am Ende dieser Entwickelung verhält es sich gerade umgekehrt. Der Mensch, durchaus in der Lage, das Programm zu lesen, tut dies nicht allzu gern und ist häufig noch nicht
einmal geschult, es zu tun. Die Maschine hingegen fühlt sich nun – ich anthropomorphisiere
aufs Schamloseste – geradezu in ihrem eigentlichen Element. Denn wenn sie die anfänglichen
Beschreibungen zu kaum etwas anderem nutzen konnte als festzustellen, dass es sich um eine
Kette von Zeichen handelte, so gewinnt sie nun aus dem Programmtext Anlässe dafür, effektiv etwas zu tun, so richtig als Maschine also in Erscheinung zu treten8.
„Lesbarkeit” bedeutet hierbei die Möglichkeit einer Sinnzuschreibung. Zeichentheoretisch betrachtet, ist solch eine Zuschreibung von Sinn aus Anlass einer Beschreibung nichts
anderes als jener Vorgang, durch den einem Repräsentamen (einem Signalangebot), das
(sichtbar) wahrgenommen wird, ein Objekt und diesen beiden zusammen ein Interpretant
zugeordnet wird.9 Die gegebene Beschreibung führt zur Erzeugung einer neuen, die den enthaltenen Sinn (Objekt) und seine Bedeutung (Interpretant) expliziert.
Kurz gesagt, ist das Objekt bei Peirce das, was bezeichnet wird. Der Interpretant ist das,
was bedeutet wird. So jedenfalls will ich es mit Max Bense halten. Über die Wirkungsweise
jedes Zeichens – eines steht für ein anderes – hinaus eröffnet diese dreistellige Begrifflichkeit
eine Differenzierung, die die Einbettung in eine Kultur von den individuellen Besonderheiten
des lebendigen Handelnden zu trennen erlaubt. Die Bezeichnung nämlich besitzt relative Allgemeingültigkeit für eine Gruppe oder Gemeinschaft oder Kultur. Die Bedeutung dagegen
kann nur vom anwesenden Interpreten, von demjenigen also hergestellt werden, der jetzt und
hier einem Signalangebot (bei Peirce: Repräsentamen) ausgesetzt ist, es wahrnimmt und
durch eine Bedeutungszumessung das Zeichen erst zum vollen Zeichen macht.
6
Aus der reichhaltigen Literatur zur Software-Entwicklung sei nur an zwei wichtige Äußerungen vom Rande her
erinnert: [Brooks 75, DeMarco & Lister 91].
7
Sinn und „Sinn“ (mit Anführungszeichen) markieren verschiedene Begriffe.
8
Ob das effektive maschinelle Operieren nach menschlichem Maße auch effizient ist, ist eine andere Frage.
9
Ich verwende die semiotische Terminologie von Charles Sanders Peirce [Peirce 93].
Die drei Begriffe der Überschrift dieses Abschnitts machen darauf aufmerksam, dass
die Arbeit des Spezifizierens, Entwerfens, Implementierens, Testens von Software nicht immer „Entwicklung“, sondern oft „Design“ genannt wird10. Im Deutschen auch: „Gestaltung“.
Klingt im Wort „Design“ im Englischen eine sehr breite Bedeutung an, die nicht mit
dem deutschen „Gestaltung“ gleichzusetzen ist, so ist doch die Nähe zum Entwerfen als einem kontext- und situationsbasierten, in Alternativen denkenden und nicht auf beste Lösungen zielenden Prozess unverkennbar (vgl. [Floyd 94]). Design zielt auf Artefakte, die eher zu
bewerten, zu deuten, dem Geschmacksurteil auf Erfahrungsgrundlage zu unterwerfen sind.
Entwicklung dagegen zielt auf Artefakte, die zu bemessen, zu begreifen, dem Korrektheitsurteil auf formaler Grundlage zu unterwerfen sind. Design geht von der Dialektik der Situation
aus, die durch Design verändert wird, Entwicklung von ihrer Optimierung.
Design bettet die Artefakte, die erst entstehen, in Sinnzusammenhänge ein, sieht Software-Entwicklung als einen situierten Prozess wechselseitigen Lernens in veränderlichen,
offenen Kontexten. Systeme sind bestenfalls Approximationen, während sie dem entwickelnden Ingenieur als Objekte ständiger Vervollkommnung erscheinen.
Für Gestaltung, die der ästhetischen Dimension, der Schönheit, dem Schein und der
Kunst einen Schritt näher kommt, gilt alles Gesagte um so entschiedener. Die Gestalt ist die
aktuale, in einer Art von Balance befindliche äußere Form einer inneren Vorstellung. Sie ist
die schwebende Dialektik von Vorstellung und Herstellung. Gestaltung zielt auf sie.11
3 Partizipative Software-Entwicklung
Zu Beginn der 80er Jahre griffen Anwendungen des Computers über die industrielle Arbeit
und die Großverwaltung hinaus; die Informationstechnik tauchte im Alltag des Büros auf.
Bald war deutlich, dass die informellen Kontexte nicht abstrakt am Programmiertisch in
Software verwandelt werden konnten.
Die Maschinisierung von Kopfarbeit verlangte plötzlich danach, die sog. Betroffenen
einzubeziehen. Das sind mögliche spätere Benutzende eines erst in Entwicklung befindlichen
Software-Systems. In Pilotprojekten, angesteckt von Beispielen wie dem skandinavischen
UTOPIA Projekt, wurde Software partizipativ entwickelt. Kommende Benutzende wurden
vor allem in frühen Phasen der Entwicklung sowie vor Inbetriebnahme gehört. In Teams wurden neuartige Entwurfsmethoden erprobt. Formales, auf sicher scheinendem Boden stehendes
Vorgehen wich einem interpretierenden und konfliktreichen Aushandeln und Probieren. Für
das traditionelle Konstruieren technischer Systeme ein Affront, der oft mit Kopfschütteln und
Unverstand abgetan wurde (und noch immer wird?).
Die Skandinavier öffneten einen Weg, der vermutlich größere Nachhaltigkeit aufweist
als der Streit um die richtige Abfolge der Phasen der Software-Entwicklung erzielen konnte.12
Denn das Prinzip der partizipativen Entwicklung von Systemen für Büro oder Arztpraxis
führte im Grunde die ästhetische Dimension in die Gestaltung von Software ein. Sie wurde
zum nur gering kontrollierbaren, dennoch aber technisch bestimmten Artefakt, das zwar zu-
10
Hierzu gibt es im englischen Sprachraum eine Explosion an Literatur, auch an reflektierender. Ich verweise
aus zufälliger Vorliebe auf [Dasgupta 91, Floyd et al. 92, Winograd 96]. Eine Brücke zur skandinavischen Tradition schlagen [Ehn & Malmborg 98]
11
Arno Rolf wird nicht müde, die Informatik als eine Gestaltungswissenschaft zu begreifen. Unrecht hat er nicht.
12
S. zusammenfassend knapp etwa [Newman & Lamming 95] und breiter [Greenbaum & Kyng 91], kritisch
[Whitaker et al. 91].