Der Vertriebsingenieur bei der Business Computer Group von Hewlett-Packard, Computerfuturologe James Martin hat vorausgesagt, daß die Anwender bis 1990 etwa 93mal soviel Programmcode brauchen wie heutzutage erzeugt wird. Das würde einen Bedarf von 27,9 Millionen Programmierern bedeuten. Aus dem Zusammenhang gerissen erscheint eine solche Feststellung unsinnig und von weit hergeholt. Sie veranschaulicht aber treffend die Notwendigkeit sich intensiv mit der Produktivität des Programmierens auseinanderzusetzen. Ohne gründliches Verständnis des Programmierprozesses und der verschiedenen Richtungen, die mittlerweile diskutiert werden, läßt sich das Problem nicht lösen. Die etablierten Großunternehmen haben von jeher gute Erfahrungen mit ausgefeilten analytischen Methoden der Systemanalyse und Projektimplementierung gemacht; kleinere Unternehmen sind typischerweise weniger formal vorgegangen.
Modernste Verfahren
Zwei der modernsten, heute angewandten Entwicklungsverfahren sind ohne Zweifel das Structured Design (Yourdon und Constantine) und das Prototyping, die beide an entgegengesetzten Enden des Implementierungsspektrums ansetzen. Beide lassen sich aber je nach gegebener Situation und vorliegendem Bedarf mit hoher Effektivität anwenden. Um beurteilen zu können, wie sich diese Methoden in den Programmierprozeß einfügen lassen, muß man sehr genau wissen, um was es geht.
Nun hängen zwar am "Prototyping" von früher her noch negative Assoziationen, die man unter dem Stichwort "des Faulen Wegs zur Systemanalyse" rubrizieren könnte. Prototyping bietet allerdings die Möglichkeit, eine Anwendung schon sehr früh in der Implementierungsphase überblicken zu können. Was man in der Tat heute noch mit den herkömmlichen Prototypinghilfen erreicht, ist eine Verkürzung des Zeitaufwands für die Analyse, um dafür mehr Zeit für das Codieren und Testen zu haben - in der Hoffnung, den Zeitaufwand für das Gesamtprojekt zu verkürzen.
Gerade jetzt vollziehen sich aber einige Veränderungen und Neuerungen in der Datenverarbeitung, die das Prototyping attraktiver machen, als es noch vor einigen Jahren war. Unter anderem handelt es sich um folgende Veränderungen:
- Führungskräfte höherer Ebenen verlangen heutzutage oft Lösungen, ohne die Zeit zu einer Analyse ihres Bedarfs zu haben.
- In vielen Unternehmen verlangen die Endbenutzer früher als bisher, in den Systementwurfszyklus eingeschaltet zu werden.
- Die Hersteller arbeiten an der Entwicklung von Prototyping-Sprachen, die als Sprachen der vierten Generation angesehen werden können (Makrocodegeneratoren).
- Diese Makrocodegeneratoren reduzieren das Codieren und Testen, also den zeitraubenden Teil des Prototyping-Projekts.
Mit den neuen Hilfen ist die Analyse nicht mehr so kritisch, wie sie es noch mit den Hilfsmitteln der dritten Generation war, da der Zeitaufwand zum Codieren und Testen erheblich verkürzt werden kann.
Prototyping sollte angewandt werden, wenn es gilt, den Endbenutzer mit sofortigen Resultaten zu bedienen, die Benutzergemeinschaft mehr für den Programmierprozeß zu engagieren und falls es unmöglich ist, die Endbenutzer in den Entwurfsprozeß einzubeziehen.
Die Anwendung neuer Makrocodegeneratoren bietet die Möglichkeit, leichter auf einmalige Anforderungen zu reagieren und nach Bedarf ad hoc Datenbankwartungen durchzuführen. Die Anwendung dieser Hilfsmittel ist eine wahre Wohltat, hat man ihre Vorteile erst einmal begriffen.
Structured Design und strukturiertes Programmieren haben in den letzten Jahren eine enorme Publizität gehabt. Sie versuchen, die Komplexität dadurch zu verringern, daß man unhandliche Probleme in handliche Segmente aufgliedert. Im Prinzip gibt es zwei Denkschulen zum strukturierten Programmieren: "Datenfluß" und "Datenstruktur" genannt.
Verfahren wie Ed Yourdons "Bubble Charts", Jean-Dominique Warniers "Warnier-Diagramme", Meyers und Constantines "Datenflußdiagramme", Nicklaus Worths "Schrittweise Verfeinerung" sowie "Pseudocode" und "Structured English" sind die am häufigsten angewandten und zitierten Verfahren.
Standardisierte Denkweisen
Debatten über das Für und Wider von Goto sind kennzeichnend für das Fehlen einer Standardisierung der Denkweisen, die in diese Verfahren eingegangen sind. Einige der grundsätzlichen Bedenken im Zusammenhang mit diesem Prozeß sind die Unabhängigkeit von Moduln, die zwischen den Moduln bewegten Datenmengen, der Grad, in dem ein Modul eine einzelne Funktion erfüllt sowie die Größe des Moduls.
Strukturierte Vorgehensweisen beim Programmieren erzwingen auch eine Strukturierung des ganzen Implementierungsprozesses. Eine Befolgung der in diesem Verfahren enthaltenen Regeln verbessert die Chancen, daß der Code gleich auf Anhieb richtig ist, die für logische Korrekturen aufgewandte Zeit wird verkürzt und die Möglichkeit einer Identifizierung von Unterprogrammen, die nur einmal codiert zu werden brauchen, wird größer.
Aus COMPUTERWORLD vom 26. April 1982 übersetzt von Hans J. Hoelzgen, Böblingen.
Vergleiche auch in der Rubrik "Software", Seite 48, den Artikel von James C. Wetherbe "Systementwicklung: Heuristik oder Prototyping?"