Tools beschleunigen oft nur eine Phase der SW-Entwicklung:

Für schnellen Erfolg reicht Einzweckwerkzeug

13.01.1984

Der Bedarf an qualifizierter Anwendungssoftware wächst deutlich schneller als die Entwicklungskapazitäten der Org./DV-Abteilungen. Viele Statistiken zeigen übereinstimmend, daß die meisten Anwender vor einem erheblichen Arbeitsberg stehen, der nicht selten ein Vielfaches der zur Verfügung stehenden Entwicklungskapazität pro Jahr ausmacht. Das ist ein untragbarer Zustand, der zudem nicht sein müßte - zumindest, wenn man den Schlagzeilen der Hersteller von SW-Tools glaubt.

In einem Wechselspiel zwischen den Wünschen der Anwender einerseits und Verbesserung der Leistungsfähigkeit der Hardware und Vergrößerung der Einsatzbreite von Datenverarbeitungssystemen andererseits sind die quantitativen und qualitativen Anforderungen an die Softwareentwickler den bestehenden Realisierungsmöglichkeiten davongelaufen. Diese unbestrittene Tatsache zeigt, daß die heute landläufig geübte Software-Entwicklungs-Praxis zur Bewältigung des Problems nicht ausreicht.

Es stellt sich die Frage, ob der Einsatz von Tools ein erfolgversprechender und kostengünstiger Weg aus dieser Misere ist.

Der Begriff Softwaretool umfaßt viele unterschiedliche Entwicklungshilfen. Im folgenden sollen solche Werkzeuge betrachtet werden, die aus formatierten Eingaben ablauffähige Programme erzeugen können.

In den letzten, Jahren ist die Einsatzbreite kommerzieller Rechenanlagen deutlich vergrößert worden. Dies wurde durch flexiblere, erweiterte und damit komplexere Betriebssoftware erreicht.

Um die neuen Möglichkeiten der Anwendungsprogrammierung zugänglich zu machen, sind entsprechend komplexe Schnittstellen geschaffen worden. Dies führte dazu, daß neben der Codierung der Anwendungslogik immer mehr Routinen zur Befriedigung dieser Schnittstellen notwendig wurden. Die aus technischen Gründen notwendigen Anweisungen machen heute nicht selten 20 bis 30 Prozent des Programmcodes aus.

Entwicklungsaufwand verlagern

Fast allen SW-Tools, die hier betrachtet werden sollen, ist gemein, daß sie diese offenkundige Schwachstelle ausräumen. Damit werden bei der Codierung Einsparungen erzielt. Der Lösungsweg und die Eignung solcher Tools sind aber verschieden und lassen eine Klassifizierung zu.

Typische Vertreter sind Einzweckwerkzeuge wie Report-, NP-Generatoren oder auch Online-Abfragesysteme.

Derartige Systeme kommen meist mit knappen statischen Beschreibungen der Anwendungsaufgabe aus. Wenn zum Beispiel aus fünf Zeilen Code die komplette Ausgabe einer Liste erzeugt werden kann, so ist der Effekt für sich betrachtet erstaunlich. Leider ist die Eignung solcher Tools nur auf eine einzige und meistens einfache Aufgabenstellung beschränkt. Die Hauptaufgabe der DV heute, nämlich die Erstellung und Pflege komplexen Anwendungssysteme, kann damit nicht nachhaltig gelöst werden.

Trotzdem kommt derartigen Einzweckwerkzeugen eine Bedeutung zu. Denkt man etwa an endbenutzerorientierte Dialogabfragesysteme, so zeigen Erfahrungen, daß die Systeme in den Fachabteilungen durchaus akzeptiert werden. Zwar belastet deren reger Gebrauch die Maschinen erheblich, jedoch kann der Entwicklungsaufwand bis zu 100 Prozent aus den DV-Abteilungen verlagert werden.

Neben den Einzweckwerkzeugen bleiben sozusagen als Rest die Mehrzweck- oder Universalwerkzeuge. Diese bieten sich zur mehr oder weniger effizienten Lösung fast aller Anwendungsaufgaben an. Sie sollen nach der Art des Lösungsansatzes unterschieden werden. Als erstes gibt es die klassischen generierenden Werkzeuge, die aus formatierten Eingaben Source-Code-Programme einer geläufigen Programmiersprache erzeugen.

Solche Systeme bedienen sich in den meisten Fällen theoretischer Grundlagen über mögliche und notwendige Programmstrukturtypen. Als Beispiele sind hier die strukturierte Programmierung, Gruppenverarbeitungs- oder Baumstrukturen zu nennen. Der Effekt dieser Werkzeuge liegt darin, aus kurzen, meist statischen Syntaxen, die eine spezielle Ausprägung eines bestimmten Strukturtyps beschrieben, mittels eines entsprechenden Generators die komplette Ablaufsteuerung nebst den technischen notwendigen Routinen zu erzeugen.

Die Mächtigkeit dieser Werkzeuge wächst mit den Möglichkeiten, verschiedene Strukturtypen möglichst in einem Programm zu unterstützen.

Insgesamt zielen diese Tools auf die Erstellung qualitativ besserer, das heißt, klar strukturierter und standardisierter Software ab. Die rationellere Herstellung ist dabei ein willkommener Nebeneffekt.

Es ist klar, daß die erreichbaren Einsparungen nur realisiert werden, wenn eine entsprechende methodische Grundausbildung der Mitarbeiter gewährleistet ist. Ansonsten können sich die Erwartungen leicht ins Gegenteil verkehren.

Da gerade die Aufwendungen für Wartung und Pflege von Anwendungssystemen den Hauptteil der Software-Budgets ausmachen - Statistiken reden von 60 bis 80 Prozent -, ist insgesamt gesehen der Produktivitätsgewinn durch den Einsatz dieser Art von Tools beträchtlich. Es erfordert nur etwas mehr Geld, bis die gewünschten Einsparungen zum Tragen kommen.

Als letztes darf die Gruppe der Tools der 4. Generation nicht fehlen. Sie sind von der Eignung her als Mehrzweck- oder Universalwerkzeuge anzusehen. Der Unterschied zu den oben aufgeführten generierenden Werkzeugen liegt im Lösungsansatz.

Die Tools der 4. Generation bedienen sich mächtiger prozeduraler Sprachen, die entweder durch Compiler oder Interpreter in ausführbare Programme überführt werden. Die Stärken dieser Werkzeuge liegen besonders in dem meist durchgehenden vollständig interaktiven Entwicklungsprozeß. Die Arbeit wird nicht durch Batch-Schritte wie Dateidefinitionen oder Katalogisieren unterbrochen und aufhalten.

Diese Stärke beziehen die Produkte aus einer sehr engen Integration von Data-Dictionary-, Datenbank- und Editor-Systemen. In der Praxis hat das aber oft zur Folge, daß gleichzeitig mit der Auswahl von Tools auch die Datenbank festgelegt ist - und also auch gekauft werden muß.

Die Integration bestehender oder fremder Programme ist bei diesen Systemen oft nur schwer oder unmöglich.

Da die Tools auf die übrige zugrunde liegende Systemsoftware zugeschnitten sind, können technisch notwendige Routinen unter der Anwendungsoberfläche abgewickelt werden. Das Niveau der Sprachen ist entsprechend hoch, so daß systemnahe Kenntnisse nicht erforderlich sind.

In der Folge sind neue Anwendungen relativ schnell zu erstellen. Es gibt aber systemmäßig keine methodische Stützung in der Strukturierung der Anwendungen. Der heute oft geäußerte Mangel an Standardisierung und klarer Strukturierung wird durch Tools der 4. Generation nicht behoben. Er wird lediglich dadurch gemildert, daß die Programme kleiner und deshalb leichter überschaubar werden.

Insgesamt gesehen sind die Ansätze einleuchtend, die mit den verschiedenen Typen von Tools verfolgt werden. Einsparungen zum Beispiel in der Codierung können regelrecht an den "Lines of Code" abgezählt werden. Tut man dies, ist das Ergebnis beeindruckend. Die versprochene, mindestens 40prozentige Produktivitätssteigerung ist damit scheinbar bewiesen.

Ein entscheidender Punkt wird dabei jedoch übersehen. Die Programmierung an sich ist eigentlich nur ein geringer Teil des Systementwicklungsprozesses und der späteren Wartung. Der große Teil des Aufwandes liegt in der Erarbeitung und der größte Teil in dem späteren Nachvollziehen der Anwendungslogik in Wartungsfällen. Insofern helfen die hier besprochenen Tools nur ein Teilproblem lösen, wobei die methodisch abgestützten generierenden Werkzeuge, was das Nachvollziehen der Anwendungslogik in Wartungsfällen betrifft, noch immer die besten Dienste tun.

Wartungsfall verlangt Anwenderlogik

Nicht nur die Eignung, sondern auch die Wirtschaftlichkeit der Softwaretools spielt eine Rolle. Um ein paar Eckwerte zu erhalten, ist eine globale Betrachtung durchzufahren. Dazu muß eine Annahme über das Verhältnis von Programmier- und Testzeit zu "Denkzeit" gemacht werden.

Geht man von einem Verhältnis eins zu eins aus, und unterstellt durch den Tooleinsatz eine 40prozentige Einsparung in Programmierung und Test, so ergibt sich über alles noch ein 20-Prozent-Effekt.

Das heißt aber nicht, daß durch den Einsatz eines Tools ab sofort jeder sechste Mitarbeiter in der DV-Organisation für neue Aufgaben freigesetzt wird. Diese Rechnung stimmt erst dann, wenn die Alt-Anwendungen gegen neue wartungsfreundlichere Applikationen ausgetauscht sind. Bei einer statistisch festgestellten Lebensdauer von Anwendungssoftware von zirka sieben Jahren kommt der Effekt erst nach dieser Zeit zum Tragen. Ein so gesehen nicht gerade berauschendes Ergebnis.

Bei einer Bedachten linearen Realisierung der Einsparungen heißt das, daß für jeden sechsten Mitarbeiter im Laufe von sieben Jahren eine Einsparung von dreieinhalb Mannjahren eintritt Geht man von 70 000 Mark Ehrlicher Personalkosten pro Kopf aus und diskontiert die jährlich zunehmenden Einsparungen über einen Zeitraum von sieben Jahren, so würde das immerhin noch eine Investition von 150 000 Mark für jeden sechsten Org./DV-Mitarbeiter rechtfertigen.

Tool verursacht Kosten

Sollte aber ein Datenbank- und Tooleinsatz die Notwendigkeit eines Daten- und Methodenbank-Administrators nach sich ziehen, würde in einer sechsköpfigen Abteilung im schlimmsten Falle gar nichts eingespart. Das Tool würde nichts als Kosten verursachen.

Diese theoretische Überlegung ergibt einen ersten Anhaltspunkt. Sie trifft aber nur da zu, wo lediglich ein bestehender Anwendungsbestand verwaltet, geändert und im Rahmen der Wartung nach und nach ersetzt

wird.

Dies ist aber nicht die typische Situation. Im allgemeinen wartet ein Entwicklungsschub auf die Erledigung. Es sind neue Anwendungsgebiete zu erschließen oder größere Komplexe von Altanwendungen auszutauschen. Die Entwicklung muß zügig vonstattengehen, damit die Ergebnisse nicht bereits bei ihrer Entstehung veraltet sind.

Diese Situation erfordert eine Kraftanstrengung der DV-Organisation. Eventuell durch Tools eingesparter Aufwand mündet nicht in der Freisetzung von Mitarbeitern, sondern diese werden sofort mit weiteren geplanten Aufgaben beschäftigt.

Unter wirtschaftlichen Gesichtspunkten macht dieser Tatbestand eine andere Betrachtungsweise notwendig. Geht man auch hier wieder von einem Produktivitätsgewinn von 20 Prozent aus, so müßte, um im gleichen Zeitraum die gleichen Ergebnisse zu erzielen, für eine jeweils fünfköpfiges Entwicklungsteam ein Sechster eingesetzt werden.

Unterstellt man die gleichen Personalkosten und den gleichen Diskontsatz wie oben, so ergibt sich ein Betrag von 120 000 Mark bei einer Projektlaufzeit von zwei Jahren für jeden durch Tools eingesparten Mitarbeiter. Müßte die fehlende Kapazität durch externe Unterstützung abgedeckt werden, wäre der Betrag leicht doppelt so hoch. Wartungsgesichtspunkte sind bei dieser Überlegungen jedoch ganz außer acht gelassen worden.

Die Überlegungen ergeben nur grobe Anhaltspunkte und sind natürlich nur so gut wie die unterstellten Annahmen. Stimmt es, daß durch ein Tool 40 Prozent Einsparungen in Programmierung und Test erreicht werden? Stimmt es weiter, daß ein Verhältnis eins zu eins zwischen "Denkzeit" und Programmierung und Test besteht?

Denkzeit minimal

In einem einfachen Fall, etwa einer Kontierungsliste, ist die Denkzeit (der Entwurf) minimal im Verhältnis zum Realisierungsaufwand in Cobol. Die Einsparung, die sich durch den Einsatz eines Reportgenerators ergibt ist für, dieses Problem enorm. Andererseits gibt es Berechnungsalgorithmen, die letztlich mit wenigen Statements codiert sind, deren Erarbeitung aber große Mühe bereitet.

Der Mix dieser Problemtypen ist von Anwendung zu Anwendung verschieden; ihn herauszufinden ist meistens eine Sache des Fingerspitzengefühls. Das Verhältnis eins zu eins ist jedoch für kommerzielle Anwendungssysteme erfahrungsgemäß keine schlechte Näherung.

Betrachtet man die eigentlich interessanten Tools, die hier als Universalwerkzeuge bezeichnet werden, so werden mit ihnen zweifellos Einsparungen in der Umsetzung von Anwendungslogik in ablauffähige Programme erzielt. Ob dabei der Einsparungsfaktor 20, 30, 40 oder 60 stehen muß, ist abhängig vom einzelnen Programm.

Im Bereich der Dialog-Programmierung, die ohne Werkzeuge gegenüber der Batch-Programmierung mit einer Fülle weiterer Routine- und Standardarbeiten belastet ist, dürfte die Zahl etwas höher liegen. Bei großen Batch-Programmen, die komplexe Anwendungslogiken realisieren, wird der Effekt etwas niedriger anzusiedeln sein. Um diese richtige Abschätzung zu finden, sind auch hier individuelle Analysen notwendig.

Es zahlt sich meist erst später aus

Die besprochenen Tools lösen das Produktivitätsproblem in Programmierung und Test für unterschiedliche Aufgaben unterschiedlich gut. Vor der Auswahl eines Tools muß deswegen die sorgfältige Betrachtung des eigenen Bedarfprofils stehen. Manchmal ist die Anschaffung eines preiswerten Einzweckwerkzeuges nützlicher - zumindest für den schnellen Erfolg - als ein teures Universalwerkzeug.

Da die hier betrachteten Tools nur eine Phase des gesamten Systementwicklungsprozesses beschleunigen, ist kurzfristig gesehen ihr wirtschaftlicher Nutzen, gemessen an den Gesamt-Entwicklungskosten, relativ gering. Er wird in absoluten Beträgen erst mit zunehmendem Entwicklungs- und Wartungsvolumen interessant. Daneben spielen aber auch qualitative Aspekte eine Rolle. Die besonders mit den methodisch abgestützten Werkzeugen erreichbare Standardisierung, die bessere Überwachung sowie der leichtere Personalaustausch haben eine Fernwirkung: Sie zahlen sich - wenn gleich schwer quantifizierbar - später aus.