Software-Anbieter Cincom empfiehlt "facilitative" Werkzeuge:Mit Cobol und PLI ins Produktivitätsabseits

15.01.1982

DÜSSELDORF - Nimmt der Anwender nicht rechtzeitig Einfluß auf die sich abzeichnende Entwicklung. so wird er sich schon kurzfristig exorbitant steigenden Kosten seiner Softwareentwicklung und -wartung gegenübersehen. Diese Ansicht vertrat Thomas M. Nies. Präsident der Cincom Systems Inc., Cincinnati (USA). auf einem Kundenseminar in Düsseldorf. Nies glaubt jedoch. daß sich die kubisch anwachsenden Softwarekosten durch ebensohohe Verbesserungsraten für Programmierung und Wartung abfangen lassen.

Nies empfahl dem Auditorium - darunter Vertretern von MBB und Bayer - "a systems development system", wie es Cincom offeriere, um damit Wirtschaftlichkeitseffekte in Größenordnungen zwischen 500 und 2000 Prozent zu erzielen. Es gab jedoch Seminarteilnehmer, die in Gesprächen am Rande der Veranstaltung zu erkennen gaben, sie würden kleineren Zahlen eher zu vertrauen bereit sein, und ein Umschalten auf die gesamte Cincom-Produktlinie komme in ihrem Hause ohnehin nicht in Betracht.

Zur augenblicklichen Situation in der DV nannte Nies einige Kennzahlen. Demnach steigt die Nachfrage nach Applikationsprogrammen beim durchschnittlichen EDV-Anwender jährlich um 33 bis 34 Prozent. 1,5 Prozent der Unternehmensumsätze würden, wie das amerikanische Fachmagazin "Datamation" berichtet, für die Datenverarbeitung ausgegeben; davon wiederum stünden nur acht Prozent für die Entwicklung neuer Anwendungen zur Verfügung. Zehn codierte Zeilen pro Tag -so hätten es James Martin und das Savant Institute ermittelt - schaffe der Durchschnittsprogrammierer bei Programmen im Bereich zwischen 16 und 512 KB.

Nies dazu: "Hiring more programmers may be like hiring more ditchdiggers." Er spielte damit gleichnishaft auf das Problem eines Tiefbauunternehmens an, Kapazitätsengpässen durch den Einsatz moderner Maschinen oder durch mehr "Schaufelschwinger" beizukommen. 1963, fuhr der Cincom-Boß fort, habe der Wartungsanteil an den Softwarekosten noch bei 30, im vergangenen Jahr schon bei 65 Prozent gelegen. Weiter: Wenn die Probleme wachsen, wachsen auch die Anforderungen an die Tools, habe die amerikanische Unternehmensberatung Arthur D. Little festgestellt, und auch gute Tools könnten von einem bestimmten Punkt an unbrauchbar werden.

Warum die Probleme der Anwender besonders schnell wachsen, glaubt Nies zu wissen. Es sei darauf zurückzuführen, meinte er, daß sich in der DV die Erkenntnis noch nicht durchgesetzt habe, die Adam Smith bereits 1776 in seinem "Wealth of Nations" dargelegt habe: Aufteilung, Modularisierung der Arbeit erbringt große Wirtschaftlichkeitseffekte. "Insulation is very important", leitete Nies als Konsequenz daraus ab und forderte vom Anwender eine Aufsplittung seiner Softwarewelt in klar abgegrenzte Komponenten (siehe Abbildung).

In einem solchen Software-Umfeld, meinte Nies, seien Uralt-Programmiersprachen wie Cobol, PL/I oder Fortran fehl am Platze, und auch non-prozedurale "Special Purpose"-Dienstprogramme seien für Anforderungen großen Umfangs nicht mehr geeignet. Nies machte sich die Aussage James Martins zu eigen, nach der die EDV eine leistungsfähige, prozedurale und interpretative Sprache der vierten Generation benötige.

Der Cincom-Präsident skizzierte eine Software-Gesamtsicht, bei der der Anwender, aufbauend auf "Foundation"-Software (DB/DC), "facilitative" Software installiert (Data Entry, Query) und auf diese Grundlage seine Applikationen aufsetzt. Für jedes dieser Niveaus hatte Nies Produkte seines Hauses zu bieten. Eine besondere Rolle in seinen Ausführungen spielte "Mantis", das den gesamten Bereich der "facilitativen" Software abdecke, und TIS (Total Information System), mit dessen Hilfe der Anwender seine DB/DC-Software in die nächste logische Stufe, nämlich in Directory-gesteuerte und Datenstruktur-unabhängige Software, überführen könne.

Die Datenbank-Realität ist nach Nies' Darstellungen von einigen Problemen gekennzeichnet, so etwa von fehlender Datenunabhängigkeit, unterschiedlichen Architekturmodellen, unvollständigen Softwaresortimenten, Redundanz der Datendefinitionen, langsamen Kanälen und schlechten DDP-Eigenschaften. Solche Schwierigkeiten kenne das "directory driven concept" nicht, meinte Nies. Es kopple den Anwender vom DBMS ab, steuere das gesamte System einschließlich des DBMS und anderer Datamanagement-Software wie etwa VSAM und - vor allem - liefere dem Benutzer sein LUV (Logical User View).

Durch diese logische Perspektive erläuterte Nies, werde der Anwender von der Notwendigkeit befreit in jedes einzelne Programm eine Navigationslogik einzubauen.

Weniger Codierfehler und leichteres Testen schreibt Nies den LUV-Anwendern zu. So habe ein und dasselbe Programm in konventioneller Programmierweise 110, nach LUV-Manier 54 Codierzeilen benötigt. Eine Änderung habe sich in vier zusätzlichen LUV-Zeilen, aber in 32 weiteren konventionellen Zeilen ausgewirkt.