Blickt man auf die EDV-Abteilungen bei Anwendern aller Größenordnungen, so läßt sich heute ein allmählicher Wandel in den Vorstellungen über die Arbeitsweisen feststellen. Der Programmierer als Künstler, der im Alleingang Softwareentwicklung betreibt, tritt in seiner Bedeutung zurück. Erwartet und angestrebt wird vielmehr eine arbeitsteilige, effiziente Softwareproduktion, die adäquate Werkzeuge und Methoden gezielt einsetzt. Der Vergleich mit spezialisierten Vorgehensweisen in den Entwicklungsabteilungen von Industriebetrieben liegt nahe.
In den 60er Jahren - - bei kleineren EDV-Anwendern vielfach noch bis heute - wurde eine Aufgabenstellung, die man als automatisierbar erkannt hatte, häufig direkt an die Programmierung übergeben. Eine Voruntersuchungsphase fand nicht statt; wo es sie gab, war sie vergleichsweise kurz und hinsichtlich des erwarteten Ergebnisses nicht präzise definiert.
Seit Ende der 60er Jahre darf die Bedeutung einer organisatorischen Vorphase der Anwendersoftware-Entwicklung als erkannt gelten. Als "SYSTEMANALYSE"-Phase bezeichnet sollte diese Phase die geplanten, mittels eines Rechners zu realisierenden Anwendungen erstmals genau zu erheben und abzugrenzen gestatten. Auch über die anfallenden Kosten sollte vor Beginn der Programmierung eine möglichst genaue Abschätzung erarbeitet werden.
EDV unabhängig von der Fachabteilung
Am Ende der SYSTEMANALYSE-Phase stand in der Regel schon ein Systementwurf , vorgestellt zumeist in der Form eines Datenflußplans. Dieser Plan war - und ist vielfach noch heute - Gegenstand der Gespräche zwischen dem späteren Anwender (als Auftraggeber) auf der einen und den EDV-Organisatoren/Systemanalytikern und Programmierern (als Auftragnehmer) auf der anderen Seite.
Die Aufgabenstellungen, die in der beschriebenen Weise realisiert wurden, beschränkten sich dabei auf einzelne, isolierte Funktionsbereiche. Auftragsabwicklung, Lohn und Gehalt, Finanzbuchhaltung sind Beispiele. Stapelanwendungen überwogen. Es war die "operationale Ebene" in den Unternehmen, die mit ihren einfachen, wiederkehrenden Aufgabenstellungen zuerst mit dem Rechner leben lernte.
Systementwürfe in der Gestalt von Datenflußplänen enthielten bereits zahlreiche Elemente der vorgesehenen Realisierung. Ob die Zusammenfassung einer Reihe von Funktionen in einem ihrer Funktionsblöcke und die Angabe einer bestimmten Eingabe- und Ausgabe-Peripherie entwurfstechnisch sinnvoll waren, vermochte der Anwender nicht mehr nachzuvollziehen. Er verließ sich auf das Fachwissen der EDV-Experten und hoffte, daß die Systemausgaben das enthielten, was er erwartete.
"Implementierungsabhängigkeit"
Mit den Datenflüssen wurden in der Regel auch bereits die Datei-Inhalte festgelegt. Dabei stellten die EDV-Organisatoren und Programmierer auf die verfügbare Handware ab. Alle Entwurfsentscheidungen erfolgten vergleichsweise maschinennah; sie waren weniger problemorientiert denn realisierungsorientiert. Man spricht auch von "Implementierungsabhängigkeit" der verwendeten Methoden und Werkzeuge.
Solange die Anwendungsprogramme und -systeme einer Benutzerorganisation an Zahl klein blieben und sich auf die operationale Ebene konzentrierten, hielten sich Änderungsdienst- und Reorganisationsprobleme in Grenzen. Dies änderte sich, sobald die EDV einen erheblichen oder den überwiegenden Anteil aller wiederkehrenden Prozesse der operationalen Unternehmensebene übernommen hatte. Probleme der Datenredundanz (manche Häuser führen 8 verschiedene Kundendateien) mit hohem Änderungsdienst und der Ablaufredundanz (13 verschiedene Programme enthalten den gleichen, nur jeweils, anders realisierten Gruppenwechsel-Algorithmus) binden 50 bis 70% und mehr der gesamten Softwareentwickltugskapazität. Vor dieser Situation stehen wir heute.
Prüft man viele der bisher verfügbaren Entwicklungsinstrumente daraufhin, ob sie als Hilfsmittel zur Lösung der Redundanz- und Änderungsdienstprobleme tauglich sind, so läßt sich eine Grenze ihres Einsatzes feststellen. Dies gilt vor allem, wenn der Anwender in wachsendem Maße Informationsbedürfnisse auch auf der dispositiven Unternehmensbene befriedigt wissen möchte und nicht warten kann, bis z. B. eine Anfrage mühsam in einer problemorientierten oder gar Assembler-Sprache kodiert und ausgetestet ist.
Datenbanken mit Query-Sprachen
Als Werkzeug der Bewältigung von zwei der genannten Probleme - Änderungsdienstintensität und kurzfristige Auskunftsbereitschaft - bieten sich heute die Datenbanksysteme und die ihnen eigenen mächtigen Query-Sprachen an. Als Hilfsmittel zur Verringerung von Ablaufredundanz kommt in wachsendem Maße die von Dijkstra und Wirth entwickelte Methodologie des Strukturierten Programmierens und des Strukturierten Systementwurfs in Betracht. Beide Instrumente lassen die Erwartung zu bisherige Mehrfachentwicklungen zugunsten von weniger redundanten, dabei transparenten und kostengünstigeren Implementierungen abzulösen.
Auf der anderen Seite handelt es sich sowohl bei den Datenbanksystemen (als Instrument der Zentralisierung von Datenbeständen) als auch bei der Disziplin des Strukturierten Programmierens um wenig anwendernahe Instrumente. Diese Tatsache führt dazu, daß Anwendungen und Anwendungssysteme (besonders auch Dialogsysteme) nicht mehr sofort mit den diesen Werkzeugen eigenen sprachlichen Mitteln anwendernah dargestellt (spezifiziert) werden können. Es muß vielmehr eine für den Anwender unmittelbar verständliche, problemorientierte Form der Beschreibung von Aufgabenstellungen gefunden werden.
Solange Anfragen an eine Datenbank betrachtet werden, bieten sich die jüngeren Query-Sprachen als ein solches problemorientiertes und weniger Implementierungsabhängigkeit schaffendes Werkzeug an. Wo die Mächtigkeit der Datenbanksprachen nicht mehr ausreicht, steht mit den Präzedenzstrukturen, die als reine Funktionsdiagramme den Datenflußplan ersetzen können, ein neues, ebenfalls implementierungsunabhängiges Entwicklungsinstrument bereit.
Das Ende der isolierten Programme
Die implementierungsunabhängige problemorientierte Darstellung von Anwendungen ist auch Voraussetzung für Systementwurfstätigkeit im eigentlichen Sinne: Die - zentralisierte - Datenorganisation und die Ablauforganisation sind jetzt ein Resultat der Berücksichtigung vieler unterschiedlicher Anwendungen in einer Rechnerinstallation. Isolierte und einen zusätzlichen aufwendigen Änderungsdienst auslösende Programme und Programmsysteme überwiegen nicht mehr.
Neben Werkzeugen wie den Datenbanksystemen und der Strukturierten Programmierung hat die Informatik dort, wo sie anwendungsorientierte Lösungen entwickelte, zu einer genaueren Zuordnung einzelner Entwicklungsinstrumente zu Phasen der Softwareproduktion beigetragen. Die rechte Hälfte der Tabelle zeigt eine solche Werkzeug-Phasenzuordnung. Die Liste der genannten Methoden und Techniken erhebt keinen Anspruch auf Vollständigkeit; sie enthält jedoch die wichtigen Hilfsmittel des Systementwicklers. Die Phasenuntergliederung erfolgte unter Berücksichtigung der heute verfügbaren Werkzeuge. Ausgangsmaterial und erwartetes Teilergebnis lassen sich jeweils in ihrem Inhalt genau umreißen. Zusammenfassungen hier voneinander abgegrenzter Entwicklungsschritte sind möglich und üblich; so unterscheidet z. B. ein großer Anwender aus dem Elektrobereich zwischen Vorstudienphase, Anwendungsanalyse-Phase, System-Spezifikationsphase, Systementwurfsphase und Systementwicklungsphase.
Software-Konstruktion
Ein Vergleich der linken und der rechten Tabellenhälfte zeigt im oberen Bereich - bis einschließlich der lokalen Durchführbarkeitsstudie - nur einen geringen Zuwachs in der Zahl der Werkzeuge. Neu ist die betonte Abgrenzung und damit die Spezialisierung in isolierbare Teilentwicklungsschritte. Sie macht erstmals auch im Bereich der Softwareproduktion ein genaues Steuern und Überwachen des Software-Konstruktionsprozesses möglich. Dagegen überwiegen neu entwickelte Werkzeuge in der Entwurfsund Implementierungsphase. Aber auch hier zeichnet sich der Aspekt eines systematischen EDV-Projektmanagements deutlich ab: Die Vorschläge von CODASYL zur Datenbankadministration als Aufgabe und das "Chief Programmer Team" von Baker und Mills seien nur als Stichworte genannt .
Drei Haupt-Funktionen lassen sich als Folge des starken Anwachsens in den verfügbaren Methoden und Techniken der Softwareproduktion erkennen:
1.EDV-Organisation und Systemanalyse: Hier werden die Spezifikationen für ein neues System schrittweise in Zusammenarbeit mit dem Anwender entwickelt.
2. In der folgenden Phase des Systementwurfs ist die - zentralisierte - Datenorganisation festzulegen, und die anwendernah spezifizierte Ablaufstruktur eines (Dialog-)Systems ist strukturiert gemäß Dijkstra / Wirth zu entwickeln.
3. Der als Ergebnis der Entwurfsphase vorliegende Konstruktionsplan des Anwendungssystems wird in Programmcode umgesetzt. Die verwendeten Sprachen und Programmgeneratoren bleiben austauschbar. Programmierung ist nicht mehr auf die Kenntnis nur einer Sprache beschränkt. Sie wird zu einer spezialisierten Disziplin der Implementierung.
Ob die genannten Spezialisierungen auch als Berufsbilder in der Datenverarbeitung Eingang finden werden, kann heute noch nicht gesagt werden. Ansätze dazu sind in den USA erkennbar.
* H. Schwamm und H.-J. Dörfel sind Geschäftsführer der INFORMATICA-Schulung und Beratung, Darmstadt-Wixhausen.