Noch vor wenigen Jahren wurde über Methoden und Werkzeuge zur Erstellung von Anwendungssoftware mehr theoretisch in der Fachpresse diskutiert. Mittlerweile haben sich zumindest bestimmte Werkzeugtypen in der Praxis durchgesetzt. Einzweckwerkzeuge wie Report- oder Maskengeneratoren werden in der Praxis breit eingesetzt. Daneben sind Universal-Werkzeuge wie Generatoren oder Sprachen der vierten Generation allgemein anerkannt und immer häufiger im Einsatz.

Aber je mehr Erfahrung im Umgang mit Methoden und Werkzeugen gesammelt wird und um so größer das Angebot von derartigen Tools wird, um so klarer wird auch, daß die meisten heute offerierten und ernsthaft verbreiteten Produkte nur Teilaspekte des SW-Entwicklungsprozesses abdecken. Die Mehrzahl zielt auf eine Optimierung der Programmiertätigkeit ab.

Damit ist natürlich auch klar, daß die Einsparungen an Zeit und Geld durch diese Tools nur jeweils einen Teil des Gesamt-Entwicklungsaufwandes betreffen. Glaubt man den Lehrern des Phasenmodells, daß die Programmierung eigentlich den geringsten Teil des SW-Erstellungsprozesses ausmacht, so ist zum Beispiel der Einsatz einer Sprache der vierten Generation nur ein Tropfen auf den heißen Stein.

Die Folgerung liegt auf der Hand:

Will man den Entwicklungsaufwand wirklich minimieren, so braucht man das integrierte Tool das alle Tätigkeiten im Entwicklungsprozeß optimal unterstützt. Die Frage ist, wie ein solches Super-Tool zweckmäßigerweise aussehen sollte.

Die hier zu diesem Thema geäußerten Überlegungen sind auf dem Erfahrungshintergrund der Durchführung verschiedener kommerzieller DV-Anwendungsentwicklungsprojekte gewachsen.

Will man eine wie oben angesprochene integrierte, maschinell unterstützte Entwicklungsumgebung implementieren, so muß man auf einem theoretischen Modell des Entwicklungsprozesses aufbauen. Deshalb heißen maschinell unterstützte integrierte Entwicklungsumgebungen häufig auch Vorgehensmodelle. Diesem Sprachgebrauch soll hier entsprochen werden.

Allen heute bekannten Ausprägungen dieser Vorgehensmodelle ist gemeinsam, daß sie auf dem Phasenkonzept aufbauen. Dies ist weiter nicht verwunderlich, da das Phasenkonzept am weitesten verbreitet ist. Solche Modelle zwingen dem Entwickler das Vorgehen gemäß dem Phasenkonzept auf. Deshalb ist vorab die Tauglichkeit des Konzepts zu prüfen.

Die wesentliche Idee ist, den SW-Entwicklungsprozeß als Folge von Detaillierungsstufen zu sehen. Für jede dieser Stufen sind bestimmte zu erreichende Arbeitsergebnisse festgelegt. Die Resultate sind Dokumente, die für verschiedene Benutzergruppen gedacht sind. Ein Teil hiervon soll zum Beispiel für die Fachabteilung lesbar sein, ein Teil für DV-Fachleute und ein spezieller Teil, nämlich das Programm selbst, soll für die DV-Anlage ausführbar sein.

Entsprechend dem Arbeitsfortschritt im Phasenmodell nimmt der Detaillierungs- und Formalisierungsgrad der Dokumente zu. Die Wunschvorstellung ist, daß die Phasen streng sequentiell - also ohne Überlappung - abgearbeitet werden und die dabei entstehende, stufenweise detaillierte Dokumentation zum Schluß von der Grobbeschreibung für das Management bis zum Programmcode konsistent ist.

Geht man so vor, das heißt, investiert man in die Konzeption und deren Dokumentationen und die Abstimmung entsprechend viel Zeit, so verspricht das Phasenmodell eine weit abgekürzte Programmierphase und insgesamt eine Minimierung des Aufwands. Die Standardbegründung dazu lautet: Je früher man den Fehler entdeckt, desto billiger ist die Behebung, je sorgfältiger man konzipiert, strukturiert und dokumentiert, desto billiger ist die Programmierung und Wartung (siehe Kasten).

Die bekannten Probleme führen in der Praxis dazu, daß sich trotz Phasenkonzept die Programmierung, der Test und die Einführung meist unerwartet in die Länge ziehen. Im Ergebnis sind mit Beendigung der Programmierung, spätestens nach seiner Einführung, die mit viel Mühe erarbeiteten Feinkonzepte wegen Überalterung bereits entwertet.

Die maschinell gestützten Vorgehensmodelle auf Basis des Phasenkonzepts sollen hier Abhilfe schaffen, bringen aber in Wahrheit keinen Schritt weiter.

Um die dem Phasenkonzept immanenten Konsistenzprobleme zu lösen, wäre eine maschinelle, inhaltliche Prüfung erforderlich. Vorgehensmodelle können aber höchstens formale Prüfungen vornehmen, häufig nur die Prüfung auf die Existenz eines bestimmten Dokuments. Darüber kann auch keine noch so detailliert im Vorgehensmodell implementierte Dokumentationsanforderung hinwegtäuschen. Auch der Einsatz von Spezifikationssprachen wie SADT von Plasma bringt zwar eine tiefere formale Prüfbarkeit, aber eben auch keine maschinelle, inhaltlich logische Prüfung oder gar eine Konsistenzprüfung zum Programmcode.

Hierzu ein einfaches Beispiel:

Für das Fein-Design zu einem Programm kann nur formal festgelegt werden, daß es mit einer Programmkurzbeschreibung in Prosa beginnen muß.

Ob der Inhalt dieser Kurzbeschreibung zum Programm paßt, kann heute kein System der Welt prüfen. Das gleiche gilt natürlich auch für eine inhaltliche Querprüfung von Fein-Design und Fachinhaltsbeschreibung.

Dabei muß hervorgehoben werden, daß prinzipiell in den der Programmierung vorgelagerten Phasen für die Dokumente keine so starke Formalisierung wie zum Beispiel die einer Programmiersprache erwünscht ist. Denn diese Dokumente sollen gerade für jedermann lesbar und verständlich sein, nicht nur mit Spezialisten.

Es wird also der Widerspruch deutlich, daß eine "gute" Dokumentation einerseits verständlich sein muß, andererseits aber nur eine formale und abstrakte Dokumentation maschinell formal prüfbar ist.

Wenn ein Vorgehensmodelle die vergleichsweise einfachen Konsistenzprobleme nicht lösen kam, ist es um so einleuchtender, daß ein Vorgehensmodell die Lerneffekte im Laufe der Beschäftigung mit einem Problem nicht vorwegnehmen kann.

Deshalb können auch de leidigen Rückpflege-Probleme und der Wunsch nach nachträglicher Änderung von Konzepten, die im Kasten genannten Probleme 3 und 4, vom Vorgehensmodell nicht gelöst werden.

Sie können nur durch maschine, gestützte Test-Pflegesysteme gemodert werden. Deshalb sind in Vorgehensmodellen hauptsächlich Dokumentations-Editierungs- und Aufbereitungswerkzeuge implementiert. Aufgrund des prinzipiellen Ansatzes des Phasenmodells liegt die Betonung weniger auf der Programmierung, nur seltener sind Programmgeneratorsysteme oder ähnliche Werkzeuge integriert.

Letztere Art von Werkzeugen ist aber heute vergleichsweise am höchsten entwickelt und am Markt in großen Zahlen im Angebot.

Dies zeigt, daß die Praxis der starren Theorie des Phasenmodells einen Schritt voraus ist. Es ist natürlich einfacher und machbar, Programmiersprachen immer höher zu entwickeln als die prinzipiellen Probleme der Konsistenz und der unvermeidbaren, nachträglichen Änderungen zu lösen.

Es bleibt nichts anderes übrig, als zur ersten Näherung an ein Problem zunächst einen Schritt "Grobkonzeption" vorzunehmen. Aber hier liegt auch weder der Hauptaufwand im Phasenkonzept noch der Hauptangriffspunkt gegen das Phasenkonzept. Natürlich ist auch klar, daß hier die schwerwiegenden Fehler gemacht werden können. Wird das Problem im Ansatz falsch erkannt, kann die falsche Lösung nur noch weggeworfen werden. Für diese kreative Phase des Gesamtsystem-Entwurfs hilft einem im Grunde genommen weder ein Phasenmodell noch sonst eine Methode bei der Findung der richtigen Lösung.

Alle angebotenen Methoden, wie Kreativitätstechniken, Top-down-Vorgehen etc., sind nur Vehikel, die eine gewisse Systematik im Vorgehen oder etwa auch nur in der Art und Weise der Dokumentation aufzwingen oder nahelegen. Sie sind insofern hilfreich, die Problemerkennung und Lösung muß aber nach wie der Entwickler selbst schaffen.

Neue ldeen im Entwicklungsprozeß sind gefordert

Die Entwickler in dieser kreativen Phase in ein zu enges Korsett zu schnüren, ist wenig sinnvoll. Fest steht allerdings auch, daß Vorgaben über die zu erreichende Detaillierung da sein müssen. Die in dieser vorgelagerten Phase zu erarbeitenden funktionalen Gliederungspunkte sowie die Struktur der Datenbasis gehören direkt in das Data Dictionary. Die beschreibenden Texte dazu sollen flüssig lesbar sein. Das heißt Prosa mit möglichst vielen grafischen Erläuterungen ist am besten.

Es ist natürlich leicht gesagt, aber Grunde genau richtig: Das Grobkonzept soll nur so weit detailliert werden, wie das Problem zu diesem frühen Zeitpunkt klar durchschaubar ist. Es ist damit weitgehend pflegefrei und ermöglicht dem Unkundigen den Einstieg in die Zusammenhänge und die Zielsetzung des konzipierten Systems.

Danach würde im Phasenmodell die aufwendige Erstellung von Fachinhaltsbeschreibungen, Dateientwurf und Fein-Design beginnen. In dem Maße, in dem es möglich wird, durch einfache Prototypisierung beziehungsweise interaktive, zeitsparende Codierung von vorführbaren Programmskeletten mit der Fachabteilung direkt am lebenden Objekt zu proben, in dem Maße wird auch die zeitraubende Erstellung und laufende Änderung von Anwenderprogrammbeschreibungen im Entwicklungsprozeß uninteressanter.

Das gleiche gilt auch für das Programm-Fein-Design, das aus Sicht heute verfügbarer Programmiersprachen und weit verbreiteter Organisationsstrukturen in den DV-Abteilungen fast als historisches Relikt zu betrachten ist.

Bei der früher üblichen Arbeitsteilung zwischen Systemanalyse und Codierung war das Fein-Design als Wissenwermittlung zwischen Systemanalytiker und Programmierung zweifellos notwendig. Mit der Zusammenfassung beider Tätigkeiten in einer Person kann die Notwendigkeit schon angezweifelt werden, insbesondere wenn man noch folgendes beachtet:

Betrachtet man ein Assembler-Programm, so ist es sicher angebracht, zu dem Source-Code ein passendes DV-technisches Fein-Konzept zu haben, das erstens Fehlcodierungen vermeiden hilft und zweitens später ermöglicht, den Programmaufbau und etwa benutzte Tricks schneller zu durchschauen.

Die Notwendigkeit einer DV-technischen Programm-Dokumentation nimmt aber in dem Maße ab, wie der Source-Code des Programms lesbarer und leichter änderbar wird. Am besten wird dies heute deutlich, wenn man zum Beispiel den Source-Code eines Programms für ein hochentwickeltes Generatorsystem mit dem eines Assembler-Programms vergleicht.

Genauso kann das komplette Fein-Design der Daten vor Beginn der Programmierung entfallen, wenn ein Datenbankkonzept oder Interface-Software zur Verfügung steht, die den logischen Feldzugriff von Anwendungsprogrammen aus ermöglicht. Damit ist nämlich die weitestgehende Datenunabhängigkeit und eine gegen Daten-Fein-Design-Fehler behebungsfreundliche Programmierung erreicht.

Bleibt die Frage nach den programmübergreifenden Dokumenten für die Wartung und Pflege des Systems. Hier fordert die Praxis neben dem gut lesbaren Programm-Source eine Cross-Referenzdokumentation. Sie muß mindestens die Verwendung von Dateien, Datenfeldern, Programmbausteinen etc. in Programmen und umgekehrt enthalten. Idealerweise sollte diese Cross-Referenz-Information bereits zum Editierungszeitpunkt des Programm-Source-Codes extrahiert und das Data-Dictionary gepflegt werden.

Zurück zu den eingangs erwähnten und kritisierten, integrierten Entwicklungsumgebungen. Natürlich ist klar, daß es nicht ideal ist, Konzepttexte auf dem Schreibsystem X zu halten, die Zeichnungen dazu in der Schublade und das Fein-Design sowie die Programm-Sources dazu auf dem Großrechner.

Unabhängig von allen inhaltlichen Dingen kann man von den heutigen Vorgehensmodellen lernen, daß das ideale SW-Entwicklungssystem auf eine einheitliche, Grundlage von Basissystemen gestellt werden muß. Eine gemeinsame Datenbasis für alle Dokumente, einheitliche Editierungs- und Aufbereitungsmöglichkeiten für alle Dokumente inklusive Programm-Source etc. sind erforderlich. Darüber hinaus darf aber von dem implementierten Vorgehensmodell nicht zuviel verlangt werden. Man muß sich davon frei machen, daß es möglich wäre, eine nach dem Phasenmodell stufenweise, detaillierte Dokumentation bis hin zum Programm mit Hilfe des Vorgehensmodells inhaltlich konsistent zu halten. Von solchen Möglichkeiten, die uns vielleicht in ferner Zukunft die künstliche Intelligenz beschert, sind wir ganz weit entfernt.

Viel näher liegen Systeme, die erlauben und erzwingen, gut lesbaren und leicht änderbaren Programm-Code zu schreiben. Der Begriff Vorgehensmodell als Synonym für eine integrierte Software-Entwicklungsumgebung ist neutral, er ist nur zu eng mit dem Phasenmodell verknüpft worden. Nach den oben ausgeführten Überlegungen ist es eher geraten, ein Vorgehen zu implementieren, das nach einer gründlichen Grobkonzeption die folgenden Arbeiten zu einem evolutionären Entwicklungsschritt zusammenfaßt. Das Ganze auf der Basis eines Data Dictionary, einer Datenbank mit logischem Feldzugriff und einer Hochsprache, die leicht lesbaren und leicht änderbaren Code erzwingt. Wenn man über diese Voraussetzungen verfügt, kann man Änderungen im Programm-Source und in der Datenbasis genauso oder leichter als in einem in Prosa geschriebenen Fein-Design durchführen. Wenn dazu die Hochsprache leicht lernbar, leicht lesbar ist und eine Prototypisierung für die Fachabteilung erlaubt, sind wesentliche historische Argumente für das Phasenmodell überlebt.

Der kombinierte Einsatz von Data Dictionary und Datenbanksystemen zusammen mit dem disziplinierten Gebrauch von Programmiersprachen der vierten Generation oder generierender Systeme erlaubt die Verschmelzung von Phasen heute schon.

Beobachtet man die Praxis, so ist dies aussichtsreicher und wirkungsvoller, als mit unzulänglichen Mitteln der überholten Fiktion einer konsequenten Durchführung des Phasenmodells und einer konsistenten, umfangreichen Dokumentation hinterherzulaufen.

*Klaus Fagenzer ist Kundenbereichsleiter der Heyde & Partner GmbH, Bad Nauheim.

Je früher man einen Fehler entdeckt, desto billiger ist die Behebung; je sorgfältiger man konzipiert, strukturiert und dokumentiert, desto billiger werden Programmierung und Wartung - dennoch, der Praktiker kennt die damit verbundenen Probleme:

1. Das Phasenkonzept verlangt die Darstellung der gleichen Sachverhalte in verschiedenen Dokumenten. Zum Beispiel ein fachliches Grobkonzept für das Fachabteilungsmanagement, ein DV-Grobkonzept für das DV-Management, eine Fachinhaltsbeschreibung für die, Fachabteilung, ein Feindesign als Vorlage für die Programmierung etc. Es handelt sich also um das Problem der Redundanz, das zwangsläufig zur Inkonsistenz führen muß.

2. Je detaillierter funktionale und prozedurale Abläufe beschrieben werden, desto größer wird das Volumen an Dokumentation. Es ist schwierig, letztlich unmöglich, zu erwarten, daß eine Fachinhaltsbeschreibung von mehreren hundert Seiten Umfag in der Breite in allen Details stimmig ist. Die hier versteckten Fehler führen später zu verheerenden Reprogrammierungsarbeiten.

3. Es ist natürlich und Gott sei Dank unvermeidbar, daß die Organisatoren und Programmierer im Laufe der Beschäftigung mit einem Problem dazulernen. Das heißt, man hat das Problem, neu gewonnene Erkenntnisse in die Dokumente vorheriger Phasen einzuarbeiten. Dies wird um so schwieriger und aufwendiger, aber auch um so notwendiger, je detaillierter die Dokumente werden.

4. Trotz größter Mühe In der Erstellung und phasenweiser Detaillierung der Dokumentation für die Fachabteilung können die gefürchteten nachträglichen Änderungswünsche während der Programmierung und Einführung nicht verhindert werden. Auch hier gilt, daß mit der näheren Beschäftigung mit dem Problem und dem späteren Umgang mit dem "fertigen" System in der Fachabteilung dazugelernt wird. Diesen Prozeß kann eine vorab erstellte Dokumentation weder ersetzen noch verhindern.