Faßt man die bisherigen Stellungnahmen und generalisierenden Abstraktionen zusammen, die der Autor und andere immer wieder zum Thema der Software-Produktivität auch an dieser Stelle geboten haben, fragt man sich mit Recht, was sich nun eigentlich im Hinblick auf wirkliche Erfolge in der Betriebspraxis sagen läßt. Grundsätzlich sind wir nicht zufrieden mit der 75 Prozent betragenden potentiellen Verbesserung, die bei der Entwicklung und Wartung von Software erreichbar ist, wie bereits kürzlich unter dem Titel "Code-Zeilen kein Maß für Produktivität" (COMPUTERWOCHE vom 12. 6. 81) festgestellt.
Im Vergleich mit herkömmlichen Methoden der Softwareentwicklung ergibt diese Verbesserung zwar eine Senkung des Zeit- und/oder Kostenaufwands um 43 Prozent, sie läßt sich aber nur erzielen, wenn man alle Register zieht, die uns gegenwärtig mit den verfügbaren Programmierhilfen und -methodologien zur Verfügung stehen. Nun darf man zwar solche Verbesserungen nicht ignorieren, andererseits versteht sich von selbst, daß sie nur mit einem erheblichen Aufwand zu erreichen sind.
Gibt es denn wirklich keine einfachen Antworten und fertige Lösungen für dieses. anhaltende Dilemma? Wir möchten hier zwei in den Vereinigten Staaten bekannte und wertvolle Darstellungen des Stands der Technik zitieren, in denen auf diese Frage eingegangen wird. Bei der ersten handelt es sich um den Tagungsbericht einer Konferenz von 1980 über die Anwendung von Entwicklungssystemen der Association for Computing Machinery (ACM) und bei der zweiten um den Tagungsbericht des Anwendungsentwicklungs-Symposiums von Ende 1979, zu beziehen durch die Benutzerorganisation Share Inc., und Guide International Corp.
Es wurde schon öfters festgestellt, daß eine produktive Software-Entwicklung auf zweierlei Weise erreicht werden kann. Der eine Weg beruht auf dem Prinzip einer Minimierung des Codieraufwands und der zweite auf der Anwendung leistungsfähiger Entwicklungssysteme. Wir wollen einmal beide Möglichkeiten untersuchen. Was die Minimierung des Codieraufwands anlangt, hat das Reusable Code Productivity System am meisten Aufsehen erregt. Es wurde von einem Team von Softwareentwicklern der Missile Systems Division der Raytheon Co. beschrieben. Ausgangspunkt für diese Vorgehensweise bei der Entwicklung und Wartung kommerzieller Anwendungssoftware war die Beobachtung, daß von der einen zur anderen Anwendung 40 bis 60 Prozent des Codieraufwands redundant sind. Der Aufschwung des Reusable Code Systems stützt sich auf ein solides Fundament von Erfahrungen, die bei Raytheon angesichts eines umfangreichen Softwarebedarfs gesammelt werden konnten. Raytheon hat 120 Programmierer, die jährlich 1200 neue Programme zu schreiben und weitere 2000 bestehende Programme zu verbessern oder zu erweitern haben. Um die Annahme zu beweisen, daß eine umfangreiche Redundanz in dem Programmieraufwand enthalten war, wurde eine Funktionsklassifizierung von mehr als 5000 Cobol-Produktionsprogrammen erarbeitet. Wie die Ergebnisse erkennen ließen, konnten die Moduln in drei wohldefinierte DV-Kategorien gegliedert werden: in 29 Prozent Edit- und Selektionsprogramme, 26 Prozent Updateprogramme und 45 Prozent Reportprogramme. Die anschließende Prüfung ergab, daß 40 bis 60 Prozent des Codierungsaufwands in diesen Moduln redundant war und somit der Standardisierung bedurfte.
Das eigentliche Reusable Code System stützt sich auf zwei unagbhängige Verfahren. Das erste besteht aus wohldefinierten und standardisierten Funktionen und Operationen, die getestet und erprobt sind und praktisch aus der Schublade geholt werden können. Diese Cobol-Moduln oder -Bausteine haben Aufgaben, wie Steuerberechnung, Datenumwandlung, Teilnummernprüfung etc. und können aus der Reusable-Code-Bibliothek aufgerufen werden.
Der zweite Satz von Programmierhilfen sind fertige logische Strukturen zur Unterstützung der Updating-, Selektions- und Reportfunktionen. Diese Moduln sind nichts anderes als Programmschematas, die für eine bestimmte Anwendung nur ausgefüllt zu werden brauchen. Alle Anwendungsprogramme, die aus einem der Moduln oder, aus beiden entwickelt werden, sind nach Stil und Struktur gleich, was ihre anschließende Wartung erleichtert.
Was kommt nun aber bei dieser Vorgehensweise "unter dem Strich" heraust?
Leider hat der Programmierbereich von Raytheon keine detaillierte Statistik über die erzielten Verbesserungen erstellt. Es wurde lediglich festgestellt, daß mindestens eine umfangreiche Anwendung in bereits 36 Mann-Monaten durchgezogen werden konnte, während ursprünglich 126 Mann-Monate dafür vorgesehen waren. Eine zweite Anwendung wurde 40mal schneller entwickelt als eingeplant war.
"Schnell und einfach"
Das bringt uns zur zweiten Vorgehensweise. Sie beruht ebenfalls auf den Grundlagen einer Funktionsredundanz von einer Anwendung zur anderen. Daneben stehen transaktionsorientierte Systeme im Vordergrund. Die Leute bei der Data Concepts, Inc., haben dazu eine Methode entwickelt, die den DV-Fluß als eine Fertigungsstraße ansieht. Dieses Konzept hat zum Data Conveyor System geführt, daß aus dem Fully Automated Specifications/Structuring Technique (FAS!ST) und der System Implementation/Executor (SIMPL!E) besteht. Zur Herausstellung der erzielten Leistungssteigerung im Vergleich mit Cobol hat die Data Concepts die Statistik für einen komplizierten Fall aus der Unfallversicherung vorgelegt, aus der sich der folgende Vergleich ableiten läßt:
COBOL:
Entwicklungsdauer 4-8 Jahre
Mann-Jahre 100-300
Programmumfang 20-30 MByte
SIMPL!E:
Entwicklungsdauer 1 Jahr
Mann-Jahre 10
Programmumfang 500 KByte
Das Data Conveyor System behandelt eine Serie von Transaktionen als einen Satz einzelner Prozesse, vergleichbar mit einem Fertigungslos von Werkstücken auf einer Montagestraße. FAS!ST dient zur Definition und Eingabe von Transaktionen, während SIMPL!E sie ausführt. Die Verarbeitungsvorgänge an den Transaktionen erfolgen entweder automatisch oder durch das Fachpersonal an den Arbeitsplätzen.
FAS!ST und SIMPL!E sind Beispiele für eine zunehmende Zahl von Entwicklungssystemen, die Applikationsgeneratoren, Implementierungssysteme oder Aktivierungssysteme genannt werden. Sie beruhen weniger auf der eigentlichen Programmierung, sondern sind im Prinzip nichtprozedural, da sie die Angabe von Spezifikationen und erforderlichen Operationen verlangen. Diese werden dann innerhalb eines Rahmenwerks bestehender Systeme ausgeführt. Konventionelle Programmierschritte werden dadurch umgangen oder wenigstens auf ein Mindestmaß beschränkt.
Ein interessantes Merkmal solcher Systeme ist ihre Fähigkeit, Lösungen hervorzubringen. Man kann die gewünschte Wechselwirkung und Verarbeitung approximativ angeben und sie dann verfeinern, um den Wünschen und Erwartungen der Anwender genauer zu entsprechen. Bei jedem Schritt verfügt man dadurch gewissermaßen über ein Produktionssystem. Die verbleibende Herausforderung besteht dann nur noch darin, daß das allem zugrundeliegende Rahmenwerk angemessen hohe Leistungen ermöglicht.
Produktivitätssteigerung um den Faktor 10
Die Urheber von SIMPL!E geben eine Produktivitätssteigerung um den Faktor 10 im Vergleich mit Cobol an. Hinzu kommt, daß SIMPL!E hardwareunabhängig ist, was die Entwicklung von portabler Software gestattet, solange das Data Conveyor System auf einer Zielmaschine residiert. Schließlich sei noch der große Vorteil erwähnt, daß das System in der Lage ist, Anwendungssoftware zu erzeugen, die einen Umfang von etwa einem Fünfzigstel des Umfangs herkömmlicher Anwendungsprogramme hat, so daß man für Probleme von hoher Komplexität Minicomputer anstelle von großen Rechnern einsetzen kann.
Sollten diese beiden Beispiele noch nicht genügen, dem durch Produktivitätsprobleme gebeutelten DV-Leiter den Mund wässrig zu machen, dann sei mit einem dritten eine Art von letzter Zuflucht geboten.
Man suche sich eine Organisation wie The Master Programmer im kalifornischen Santa Rosa und lasse eine solche Softwarefabrik die Arbeit machen. Bei Lieferung eines angemessenen Satzes von Spezifikationen garantiert dieses Unternehmen die Entwicklung kommerzieller Anwendungsprogramme in Cobol zu einem Festpreis von im Durchschnitt höchstens tausend Dollar und einem Liefertermin von wenigen Monaten.
John Remillard, Präsident von The Master Programmer, behauptet, eine neue Vorgehensweise bei der Softwareproduktion entdeckt zu haben. Weiter behauptet er, seine Vorgehensweise hätte weder mit der Ausnützung von wiederverwendbarer Codierung noch mit nichtprozedural orientierten Applikationsgeneratoren zu tun. Im Gegensatz dazu hat Remillard eine Fertigungsstraßenorganisation geschaffen, in der die Codierung in Großserie erzeugt wird und zwar als Neucodierung generiert und nicht aus gespeicherten Routinen. Er verwies auf die Erzeugung eines aus 55 Moduln bestehenden Programms mit einem Umfang von 27 000 Codezeichen in knapp einem Monat. Außerdem garantiert er daß die Codierung strukturiert und dokumentiert ist.
(Übersetzt aus COMPUTERWORLD vom 13. Juli 1981 von Hans J. Hoelzgen, Böblingen)