Wie wirklich ist die Softwaretechnologie?

1996, Von Peter Schnupp, InterFace GmbH, München

Einführung

Der Titel dieses Aufsatzes ist ein bewußtes Plagiat: er variiert den­jenigen eines der bekanntesten Bücher über den Konflikt zwischen "Realität" und "Wirklichkeit"
Die neuere kognitive Psychologie behauptet, daß viele bisher zur Problemlösung benützten Techniken – vor allem die ausführliche Diskussion in Gruppen – leicht zum genauen Gegenteil des gewünschten Effekts führen. Ihr Ergebnis kann unter Umständen eine "Realitätsablösung" sein; die "Wirklichkeit" aller Beteiligten, d.h. die Menge der von ihnen für zutreffend gehaltenen Aussagen entfernt sich von der "Realität", d.h. den objektiv wahren Sachverhalten. Zahlreiche Experimente belegen dies inzwischen.
Eine Reihe von Annahmen und empfohlenen Verhaltensweisen der modernen Softwaretechnologie erscheinen im Lichte dieser Untersuchungen bedenklich. Im folgenden werden einige dieser Problem­punkte zusammengestellt und Möglichkeiten zu ihrer Behebung diskutiert.

Zum Anfang

Realität und Wirklichkeit

Die neuere Wissenschafts-Theorie und die moderne Psychologie stellen zwei früher als Synonyme betrachtete Begriffe als ein Gegen­satz­paar heraus:

Diese Begriffsunterscheidung wirft neues Licht auf einige Begriffe, die für jede Wissenschaft ebenso wie für die praktische Arbeit wesentlich sind.

So ist eine Theorie grundsätzlich nicht Teil der Realität, sondern immer ein (formalisierter) Teil der Wirklichkeit. Wie für jeden Teil einer Wirklichkeit kann es deshalb auch bei der Entwicklung von Theorien zur Realitätsablösung kommen: die von der Theorie beschriebenen Sachverhalte mögen zwar logisch konsistent und anschaulich einsichtig sein, haben aber unter Umständen mit der Realität nichts mehr zu tun oder stehen mit ihr sogar in direktem Widerspruch.

Zumindest im Bereich der westlichen Zivilisation gilt es als Axiom, daß derartige Reali­täts­ablösungen von Übel sind. Jeder einzelne soll ebenso wie eine Gruppe um die Vermeidung von Realitäts­ablösungen bemüht sein. Als eine der wichtigsten Aufgaben des Menschen wird die "Erkenntnis" angesehen, d.h. das Aufspüren von Konflikten zwischen Wirklichkeit und Realität sowie deren Behebung durch Anpassen der – subjektiven – Wirklichkeit. Das entgegengesetzte Verhalten, ein ignorieren der Realität im Interesse einer Wirklichkeit, z.B. einer bestimmten Theorie, wird gemeinhin sogar als Zeichen psychischer Störungen betrachtet: es ist etwa ein wesentliches Symptom der Paranoia.

Nur beiläufig sei gesagt, daß derartige Anpassungen der Wirklich­keit an die Realität, die in der Regel durch "Reali­täts­begeg­nun­gen", d.h. ungewollte Erlebnisse oder bewußte Experimente notwendig werden, für die Psyche eines Einzelnen als auch für eine Gruppe zu sehr ernsten, teilweise fast unüberwindlichen Konflikten führen. Die Wissenschaftsgeschichte ist voll von Beispielen für derartige Schwierigkeiten des Erkenntnisprozesses, und Thomas Kuhn baut auf dem Begriff des "Paradigmenwechsels" d.h. dem mühsamen Prozeß des Ersetzens eines alten Theorie­gebäudes durch ein der Realität besser angepaßtes neues, sogar eine theoretische Grundlage der Wissenschaftshistorie auf.

Bevor nun die Anwendung dieser Theorien auf unsere Wissen­schaft, die Informatik, und ihre praktische Anwendung in der Software-Technologie eingegangen werden soll, empfiehlt es sich, durch die Beschreibung einiger einschlägiger Experimente ihren Reali­täts­bezug herzustellen.

Zum Anfang

Experimentelle Ergebnisse

Neben den zahlreichen Beispielen aus dem Gebiet der Wissen­schaft, welche etwa in den bereits zitierten Büchern von Thomas Kuhn nachgelesen werden können, wurden von Psychologen eine große Zahl von Versuchen durchgeführt, die insbesondere den Prozeß der Theoriebildung und den Erkenntniswert von Diskussionen zwischen Einzelnen und in Gruppen betreffen. Material hierzu ist z.B. in den Büchern von Watzlawik zu finden. Wegen der Relevanz für unser Thema sollen hier jedoch zwei derartige Experimente ausführlicher beschrieben werden.

Im ersten derartigen Experiment (vgl. Abb. 1) wurden zwei Menschen, die keine medizinischen oder biologischen Vorkennt­nis­se hatten, Dias mit Blutbildern vorgeführt. Ihre Aufgabe war, durch Drücken jeweils eines Knopfs mit ja oder nein zu entscheiden, ob das gerade vorgeführte Dia krankes oder gesundes Blut zeigte. Der einen Versuchsperson wurde durch Aufleuchten von Lampen, die über den Schaltern angebracht waren, anschließend jeweils mitgeteilt, ob sie korrekt oder falsch geraten hatte. Auch die andere Versuchsperson erhielt entsprechende Lampensignale. Bei ihr erfolgten die Rück­meldun­gen jedoch statistisch, ohne Bezug auf die Richtigkeit ihrer Aussage.

Bild 1

Nach etwa 50 Dias lernt nun diejenige Versuchsperson, der korrekte Rückmeldungen über ihr Urteil gegeben werden, "instinktiv" gesundes von krankem Blut zu unterscheiden, und sie macht kaum noch Fehler. Bei der anderen kann ein derartiger Lerneffekt nicht eintreten, und ihre tatsächliche Fehlerrate ändert sich nicht.

Allerdings bildet sie sich eine "Theorie", zumindest wenn sie aus dem wissenschaftlich-akademischen Bereich stammt, aus dem in der­artigen Experimenten Versuchspersonen üblicherweise ausge­wählt werden. Dies zeigt sich, wenn man anschließend die beiden Ver­suchs­personen über das Problem der Erkennung von gesundem und krankem Blut auf Blutbildern diskutieren läßt. In der Regel bestreitet die zweite, über die "Realität" im unklaren gehaltene Versuchsperson hier den wesentlichen Teil der Diskussion, da die andere allenfalls über eine sehr einfache und meist noch nicht einmal in Gedanken ausformulierte Theorie verfügt. Dementsprechend beeindruckt bis beschämt ist sie dann auch über die komplexen und schwierigen Erkenntnisinhalte, die ihr Partner über eine Aufgabe zu sammeln vermochte, über die sie selbst kaum ernstlich nachgedacht hat. Folglich ist sie gefühlsmäßig bereit, zumindest Teile der Theorie des Diskussionspartners zu übernehmen.

Die Folgen zeigen sich, wenn anschließend wiederum Blutbilder auf die gleiche Weise beurteilt werden sollen. Die erste Versuchsperson ist dann durch die gehörten Theorien derart verunsichert, daß ihre Ergebnisse signifikant schlechter sind als am Ende der ersten Dia-Serie.

Zum Anfang

Das zweite Experiment über das hier berichtet werden soll, demonstriert das gleiche Phänomen in einer Gruppe (vgl. Abb. 2).

Einem Oberseminar von Psychologie-Studenten wurde die Aufgabe gestellt, von zwei Freiwilligen aus ihrem Kreise eine möglichst genaue Personenbeschreibung –  vom äußeren Aussehen bis zur Persönlichkeitsstruktur – anzufertigen. Während der ersten Seminarveranstaltungen wurden die beiden Versuchspersonen eingehenden Interviews unterzogen über alles das, was den Übrigen Seminarteilnehmern zur Lösung ihrer Aufgabe signifikant erschien. Dann fehlten die beiden Beschreibungsobjekte plötzlich, und der Seminarleiter teilte den Studenten mit, sie seien bedauerlicherweise durch andere Verpflichtungen am weiteren Besuch des Seminars verhindert. Er meine jedoch, daß in den vorhergehenden Sitzungen genügend Tatsachen über die beiden Personen ermittelt worden seien, so daß man wohl den Rest des Semesters der gründlichen Diskussion und Aufbereitung dieses Materials widmen könne. Dies geschah denn auch, und die Seminarteilnehmer erarbeiteten zur letzten Veranstaltung des Semesters gemeinsam ein Persön­lich­keits­profil ihrer Versuchs­objekte.

Die große Überraschung kam nun in dieser letzten Sitzung. Die beiden Versuchspersonen – mit denen dies natürlich abgesprochen war – erschienen zu dieser Veranstaltung wieder. Es stellte sich heraus, daß von den gemeinsam erarbeiteten Personen­beschrei­bun­gen nicht viel mehr als das Geschlecht der Personen noch stimmte. Mangels laufender Korrektur durch "Realitäts­begeg­nun­gen" mit dem Gegen­stand ihrer Arbeit hatte sich während und durch die Diskussionen im Seminar die durchaus als objektiv empfundene Wirklichkeit der immerhin wissenschaftlich geschulten Gruppenmitglieder völlig von der Realität entfernt. Sie war durch ein "Kommunikationsphantom" ersetzt worden.

Bild 2

Wichtig in beiden Experimenten ist, daß sie in einer weitgehend angst- und autoritätsfreien Umgebung abliefen. Die häufige Erklärung für eine realitätsablösende Wirkung von Diskussionen auf einzelne Menschen, nämlich psychologischen Druck durch eine Gruppe, ein "System" oder eine irgendwie mit "Macht" ausgestat­te­te Instanz, war hier nicht gegeben. Auch eine Manipulation des Einzelnen lag – abgesehen von der bewußten Verschleierung des eigentlichen Zwecks der Experimente – nicht vor.

Wir müssen also als Resultat akzeptieren, daß auch disziplinierte Diskussionen bei völligem Willen zur Objektivität aller Beteiligten eher eine Realitätsablösung als eine echte "Erkenntnis" der wah­ren Gegebenheiten fördern, zumindest wenn sie nicht laufenden Experimenten oder bewußter Überprüfung an den realen Ereig­nis­sen und Erfahrungen unterworfen werden. Andernfalls scheinen Selbst­ver­stär­kungs­mecha­nismen innerhalb einer diskutierenden Gruppe die ohnehin in fast jedem Menschen latent vorhandene Neigung zur Realitätsverleugnung im Interesse einer ihn und seine Vorurteils­struk­turen optimal befriedigenden Wirklichkeit eher noch zu fördern.

Zum Anfang

Konsequenzen für die Softwaretechnologie

Könnte es nun sein, daß auch die Softwaretechnologie, wie wir sie heute praktizieren und lehren, nicht in allen Punkten mit der Realität erfolgreicher Software-Entwicklung (die es ja durchaus gibt) übereinstimmt? Ist auch hier zumindest in Teilbereichen ein Para­dig­men­wechsel zu befürchten oder auch zu wünschen?

Wenn sich die oben kurz beschriebenen Theorien und Experimente auf unsere Disziplin Übertragen lassen, dann könnten wir sogar besonders gefährdet sein. Denn im Gegensatz etwa zu den Natur­wissen­schaften, bei denen wir ja immerhin die Existenz einer Realität als Axiom voraussetzen können, ist dies hier in der Regel nicht der Fall. Sieht man einmal von Aufgaben wie der Nachdoku­men­ta­tion oder der Wartung existierender Softwareprodukte ab, so ist es für den Softwareentwickler geradezu charakteristisch, daß er die Realität, das (hoffentlich funktionierende) Programmprodukt, erst schafft. Zuerst einmal, in den Spezifikations- und Planungs­phasen üblicher Phasenmodelle, beschäftigt er sich allenfalls mit Wirklichkeiten, nämlich Vorstellungen, die er und andere Leute wie Benutzer, Auftraggeber und Mitarbeiter haben. "Realitäts­begeg­nun­gen" erlebt er allenfalls erst dann, wenn er beginnt, das Programmprodukt zu realisieren und vielleicht feststellt, daß dies unter den Bedingungen der Realität, d.h. der ihm verfügbaren Basis-Hardware und -Software, überhaupt nicht möglich ist.

Unter Umständen kommt die erste Realitätsbegegnung sogar erst wesentlich später, während der Inbetriebnahme: Wohl jeder kennt Softwaresysteme aller Größenordnungen, die zwar realisiert, aber von ihren Benutzern nicht akzeptiert wurden, weil sie der Realität der Anwendungsumgebung nicht entsprachen.

Leider fehlen uns für das Gebiet der Softwaretechnologie Unter­su­chungs­ergeb­nisse, mit denen sich der hier geäußerte Verdacht belegen oder entkräften läßt. Auf was wir zurückgreifen können, sind eher Meinungsäußerungen, darunter freilich auch solche von anerkannten Experten im Grenzbereich zwischen Theorie und Praxis, die ihre Bedenken artikulieren – Bedenken, die meist auf das gegenwärtig übliche Phasenmodell einer Softwareentwicklung zielen. Die Kritik zielt dabei vor allem auf eben diese Spezifi­ka­tions- und Planungsphase, wobei natürlich keiner der Autoren gegen eine Spezifikation oder Planung ist. Realitätsfremd scheint ihnen nur das im größten Teil der gegenwärtigen Veröffent­li­chun­gen über das Thema als nahezu selbstverständlich postulierte Axiom, man müsse ein Softwareprodukt erst vollständig spezifi­zie­ren und planen, ehe man die erste Programmzeile schreiben dürfe. Besonders bedenklich wird dies, wenn man in den gleichen Arbeiten Schätzungen für den relativen Aufwand dieser Spezifi­ka­tions- und Planungsphasen liest: sie bewegen sich etwa zwischen 30 und 50% der gesamten Projektarbeit. Dies bedeutet doch nichts anderes als daß während eines Drittel bis hin zur Hälfte der gesamten verfügbaren Zeit ausschließlich diskutiert wird und dies, auf Grund des strikten "Kodierverbots" ohne jeden unmittelbaren Realitätsbezug.

Das Unwohlsein der oben zitierten Autoren ist angesichts dessen, was die kognitive Psychologie inzwischen über den Erkenntniswert von Diskussionen weiß, nicht weiter erstaunlich. Und es wird offenbar auch von vielen Praktikern geteilt, sowohl von Program­mie­rern, die zum Unmut aller Vertreter der reinen Lehre immer noch "sofort zu pro­gram­mieren beginnen, sobald sie glauben, die Aufgabe ver­stan­den zu haben", als auch von den erfahrenen Managern, die sich unbehaglich fühlen, wenn ein Drittel eines Projektbudgets verbraucht ist "und immer noch nicht das kleinste Programm läuft".

Beide wünschen sich nichts anderes als möglichst baldige Reali­täts­be­geg­nun­gen: aus dem gesunden Mißtrauen des Praktikers gegenüber Diskussionen, in denen "alles zerredet wird" und "leeres Stroh gedroschen wird", umgangssprachliche Formulie­run­gen des von der Wissenschaft als Realitätsablösung bezeichneten Phäno­mens.

Leider gibt es kaum Fallstudien über erfolglose oder gar katastro­pha­le Softwareprojekte. Die einzige dem Autor bekannte Sammlung ist stark anonymisiert und teilweise humorisiert. Sie ist aber trotzdem lesenswert: nur wenige der dort beschriebenen Projekte scheiterten an schlechter Programmierung, die meisten jedoch an schlechter oder gar absurder Spezifikation und Planung.

Auch der Autor kennt bisher aus eigener Anschauung kein größeres erfolgreiches Softwareprojekt, welches entsprechend den Lehren der Softwaretechnologie über ein Drittel der vorgesehenen Projekt­laufzeit oder mehr ausschließlich diskutiert, spezifiziert und geplant wurde, ohne jede Programmierung von kritischen System­teilen, Modellimplementierungen oder ähnlichem. Dagegen kennt er eine Reihe nach diesen Regeln begonnener Projekte – vom Daten­bank­system über ein bundesweites Kommunika­tions­netz­werk bis zum Flughafen-Informationssystem – die erfolglos waren: immer auf Grund einer Ablösung der Projektwirklichkeit von irgendwelchen Realitäten, seien es die der Anforderungen von Auftraggeber und Einsatz­umge­bung, des möglichen zeitlichen und finanziellen Aufwands, oder auch der Leistungsfähigkeit der Ziel­maschine. Freilich, über diese Projekte gibt es keine Fallstudien, und sie sollen auch weiterhin anonym bleiben.

Dagegen gibt es keinerlei Grund, ein erfolgreiches Projekt zu verheimlichen, bei welchem die klassische Regel der ausführlichen Spezi­fi­ka­tion vor der Codierung in geradezu groteskem Maße mißachtet wurde.

Bei diesem Projekt handelt es sich ausgerechnet auch noch um das derzeit in Deutschland und vielleicht sogar weltweit erfolgreichste Softwaretechnologiewerkzeug PET. Die erste Version dieses Systems wurde etwa vier Monate bevor es auf der Hannover-Messe vorgestellt wurde, begonnen. Und zwar, indem die gewünschten Systemdienste in das damalige Philips-Datenerfassungssystem XIISD "hinein­ge­bastelt" wurden. Zu einem großen Teil noch nicht einmal als ad hoc geschriebene Programme, sondern als "Rucksäcke" zu existierenden Komponenten des Basissystems. Dieses Verfahren hatte den Vorteil, daß das zu entwickelnde System vom ersten Tage an Realität war und sich die Entwickler von dieser Realität nie lösen konnten: schließlich entwickelten sie ihr System mit dem System, und sie wurden bei dieser Entwicklung immer wieder auf die realen Bedingungen der Systemumgebung hingewiesen. So etwa bei der Entwicklung ihrer Implementierungssprache, der PET-Prozedursprache, die extrem kompakt gehalten werden mußte, weil im Basissystem nicht mehr als drei kByte für ihren Übersetzer und Interpreter zur Verfügung gestellt werden konnten.

Selbstverständlich sind inzwischen all diese provisorischen Programmteile durch "solide geplante" Systemkomponenten ersetzt. Aber dies geschah erst, als PET-Systeme nicht nur bei den Entwicklern selbst sondern auch bei einer Reihe von Pilot-Kunden im Routineeinsatz waren und auf diese Weise ihre Realität, d.h. ihre Benutzerschnittstellen, die möglichen Konfigurationen und die grund­legende Systemarchitektur so fest in einer Benutzer­gemein­schaft verankert waren, daß auch die ausführlichsten Diskussionen keine Ablösung von ihr mehr verursachen konnten.

Zum Anfang

Alternativen und Möglichkeiten

Freilich ist PET aus vielen Gründen ein Sonderfall, der nicht für jede Softwareentwicklung verallgemeinert werden kann. Das Team war eine kleine Gruppe sehr erfahrener Entwickler, die zudem das Glück hatten, ihr System selbst für seine eigene Entwicklung verwenden zu können. Auch stand ihnen in dem vorhandenen Daten­erfassungs­system eine Basis zur Verfügung, auf der sich sehr schnell ein arbeitsfähiger Prototyp ihres Systems realisieren ließ. Sicher wäre es deshalb absurd, aus seinem Erfolg etwa nun für normale, größere Basis oder Anwendungssystementwicklungen die Lehre ziehen zu wollen, auch hier im Phasenmodell die Spezifikation und Planung "hinter die Codierungsphase" setzen zu wollen. Selbstverständlich müssen diese Arbeiten vorausgehen oder körnen die Realisierung allenfalls überlappen. Wie es Frau Floyd in ihrem bereits zitierten Prozeßmodell einer Software­ent­wick­lung vorschlägt. Was vielmehr geschehen muß, ist die Entwicklung von Methoden und Werkzeugen, welche möglichst schon in der Analysephase, auf jeden Fall aber während Spezifikation und Planung einen möglichst engen Realitäts­bezug schaffen und als Basis für die in diesen Phasen zwangsläufig nötigen Diskussionen immer wieder zu "Realititätsbegegnungen", auf die verschiedenen, zu wahrenden Realitätsbezüge des Projekts hinzwingen.

Leider gehört wohl der Bereich, auf dem derzeit die meiste Arbeit über Spezifikation und Planungsmethoden geleistet wird, nicht hierzu: die formale Spezifikation mit Hilfe der Prädikatenlogik oder ähnlicher Systeme mit anschließender Programmkonstruktion, -transformation oder auch Programmbeweis aus diesen formalen Spezifikationen. Der Grund für diese Meinung ist, daß auch formale Logik nichts anderes ist als eine Sprache, in der man diskutiert, wenn auch vielleicht auf einer solideren, weil formalisierteren Basis. Realitätsbezüge ent­ste­hen erst durch die Interpretation dieser Logik. Die aber bleibt bei den meisten derzeitigen Ansätzen für eine formale Spezifikationssprache mindestens genauso offen und vage wie bei natürlichen Sprachen oder graphischen Dar­stel­lungen, die sie ersetzen soll.

Im Gegenteil: zumindest eine Klasse graphischer Darstellungen, die Familie der Petri-Netze, der Netze aus Instanzen und Kanälen sowie eine Reihe weiterer Mitglieder dieser Methodenfamilie bemühen sich genau um eine Erarbeitung derartiger Interpreta­tions­regeln, und zwar sowohl auf der für die praktische Anwendung wichtigen Seite der Anschauung als auch in ihrer theoretischen Begründung, etwa durch Anschluß an Modelle endlicher Automaten und an die Prädi­ka­ten­logik.

Hier, wie in einigen anderen Ansätzen für Spezifikationsverfahren und Werkzeuge, ist es wesentlich, daß die verwendeten Sprachen und Darstellungsmittel auf eine abstrakte Maschine abgestellt werden. Eine abstrakte Maschine ist als Realitätsbezug immerhin besser als gar keine. Sie eröffnet nämlich die Möglichkeit, Spezifikationen nicht nur hinzuschreiben und allenfalls rein formal auf Konsistenz und Widerspruchsfreiheit zu testen, sondern sie auch "auszuführen", indem ein Modell dieser abstrakten Maschine auf dem Entwicklungs- oder Zielsystem implementiert wird.

Diese Ausführbarkeit von Spezifikationen ist im Grunde nichts anderes als das, was von Seiten der Praxis immer wieder als "rapid prototyping" gefordert wird, wozu jedoch leider von Seiten der Software-Technologie bis jetzt kaum verwendbare Ansätze geliefert wurden. Eine bemerkenswerte Ausnahme ist hier die GMD.

Im Gegenteil, es werden sogar durchaus praktikable Lösungen, die in der Praxis oder in anderen Bereichen der Informatik hierfür erarbeitet wurden, weitgehend ignoriert. Dazu zählen vor allem die Format- oder Formularsprachen von denen inzwischen von Herstellern, Softwarehäusern und großen Anwendern unzählige Varianten erarbeitet wurden. Derartige Systeme werden auch zuneh­mend eingesetzt, da sie es erlauben, rasch den gewünsch­ten Satz von Bild­schirm­dialog­masken für eine Anwendung zu generieren und mit ihnen zumindest nennenswerte Teile der Benutzerschnittstelle zu simu­lie­ren. Dem Verfasser ist jedoch keine einzige wissenschaftliche Arbeit bekannt, die sich bemüht, für diese ständig wachsende Familie von Sprachen ähnliche Grundlagen zu schaffen wie sie heute für Pro­gram­mier­sprachen, Kommandosprachen, Sprachen für graphische Anwendungen oder auch für Spezifikationssprachen selbst­ver­ständ­lich sind.

Ebenso unbekannt war bis vor kurzem in der Softwaretechnologie die auf dem Gebiet der künstlichen Intelligenz entwickelte Sprache Prolog; inzwischen wird sie – unseres Wissens erstmalig – in entspre­chen­den Lehrveranstaltungen der Universität Karlsruhe verwendet. Prolog erfüllt zumindest einige Anforderungen, die an eine für ein "rapid prototyping" verwendbare Spezifikationssprache zu stellen sind, in einer nirgendwo sonst bisher realisierten Weise. Sie inter­pre­tiert nämlich eine wesentliche Untermenge des Prädikatenkalküls erster Ordnung, die Horn-Klauseln, durch eine abstrakte Maschine. Obgleich Prolog-Interpreter inzwischen bereits dem Versuchsstadium entwachsen sind und als vollgültige Imple­men­tie­run­gen einer "logischen" Programmiersprache ange­sehen werden können, sind dem Verfasser Anwendungen für das Prototyping oder gar für Pilotimplementierungen im Bereich des Software-Engineering kaum und in publizierter Form überhaupt nicht bekannt.

Freilich hat Prolog als Spezifikations- und "Prototyping"-Sprache für übliche Anwendungen, vor allem im kommerziellen Bereich, noch einige Mängel. Es besitzt zwar ein eingebautes, sehr leistungsfähiges, relationales Datenmodell, nicht aber ein befriedigendes Konzept zur Spezifikation virtueller Terminals. Das Ein-Ausgabe-Modell beschränkt sich auf sequentielle Zeichenströ­me und kann damit im wesentlichen nur schreib­maschi­nen­arti­ge Benutzerperipherie simulieren. Für seinen Einsatz als Prototyping-Werkzeug wäre jedoch zumindest der Anschluß oder die Einbindung einer Formularsprache, wie oben bereits angeführt, notwendig. Der Aufwand hierfür betrüge jedoch nur einen Bruchteil dessen, was derzeit für die formale Programm-Transformation oder -Konstruktion erbracht wird.

Zum Anfang

Zusammenfassung

Es gibt wenig Axiome der modernen Softwaretechnologie, die so wenig angezweifelt und mit so universellem Gültigkeitsanspruch geäußert werden, wie die strikte Trennung der Spezifikations-, Planungs- und Codierungs-Phasen und die Kritik an den altmodi­schen Programmierern, die bereits vor Abschluß der Spezifikation "auf die Maschine gehen".

Auf diesem Axiom beruhende Phasen- oder Projektmodelle sind Grundlagen fast jeder softwaretechnologischen Methodik. Erst in jüngster Zeit wird auch aus der Informatik zuweilen Unbehagen über diese Grundannahme laut.

Andererseits äußern Praktiker, sowohl Entwickler als auch Mana­ger, bereits seit langem Zweifel an der Möglichkeit einer strengen Trennung von Spezifikation, Planung und Program­mie­rung. Zudem fehlen überzeugende Fallstudien und erfolgreiche Projekte, welche ihre Realisierbarkeit, zumindest in strenger Form, nachweisen. Umgekehrt gibt es erfolgreiche Softwareent­wick­lun­gen, bei denen von einer Trennung zwischen Spezifikation, Planung und Reali­sie­rung keine Rede sein konnte.

Theoretische und experimentelle Ergebnisse der modernen Wissenschaftstheorie und der kognitiven Psychologie legen nun den Verdacht nahe, daß diese Bedenken keineswegs unbegründet sind. Theoretische Diskussionen ohne ständigen Rückgriff auf experi­men­tel­le Verifikation ihrer Ergebnisse führen nämlich nicht –  wie früher angenommen – zu besserer Erkenntnis der Realität, sondern im Gegenteil zu einer "Realitätsablösung" der Beteiligten. Dies erscheint besonders gefährlich, wenn, wie im Falle der Softwareentwicklung, die Realität gar nicht existiert sondern erst geschaffen werden soll.

Die softwaretechnologische Forschung sollte deshalb überprüfen, ob diese Ergebnisse auch für ihr Gebiet gültig sind, welche Auswir­kun­gen sie auf die ihr zugrundeliegenden Paradigmen haben, und welche Forschungs- und Entwicklungsarbeiten dies für die nächsten Jahre eröffnet. Dem Verfasser scheint dies vor allem für den Bereich der Spezifikation und der Projektplanung der Fall zu sein. Hier sollte weniger die rein formale Spezifikation mit darauffolgender, ebenso formaler Transformation in ein Programm bearbeitet werden. Lohnender scheint das Problem einer sofor­ti­gen Interpretation der, etwa prädikatenlogisch, formalisierten Spezifikationen zu sein. Die praktischen Ergebnisse derartiger Arbeiten wären Methoden und Werkzeuge für das von Praktikern schon lange geforderte "rapid prototyping".

In Form von Prozessoren für die Sprache Prolog steht ein zumin­dest in Teilbereichen befriedigendes Hilfsmittel für Forschungen, und auch für praktische Pilotanwendungen zur Verfügung. Es bleibt abzu­warten, ob mit ihm oder auf anderer Grundlage die bisher als Axiom formulierte, strenge Trennung der Projektphasen aufgelöst werden kann und welche Folgen dies für die Wirklichkeit unserer Software­techno­logie in realen Produktionsumgebungen hat.

Zum Anfang