Noch einmal die bekannten Zahlen: In der Bundesrepublik sind heute etwa 95000 Personen als Organisatoren, Systemanalytiker oder Programmierer tätig, durchschnittlich zu Gesamtkosten von etwa 75000 Mark pro Mannjahr. Die Personalkosten für Software-Erstellung und Wartung belaufen sich somit auf rund 7 Milliarden Mark pro Jahr. Eine zehnprozentige Produktivitätssteigerung hätte einen volkswirtschaftlichen Nutzen von jährlich 700 Millionen Mark. Warum nicht 20 Prozent?
Die in der Bundesrepublik installierten rund 100000 Universalrechner, Prozeßrechner und MDT-Anlagen, im Gesamtwert von 26 Milliarden Mark erfordern jährliche Aufwendungen von etwa 6 Milliarden Mark für Miete, Verzinsung und Abschreibung. Auf Testzeiten entfallen etwa 15 Prozent der Betriebszeit, weitere 8 Prozent auf Wiederholungsläufe wegen Softwarefehlern. Wenn diese Zeiten um zehn Prozent vermindert würden, ließen sich jährlich weitere 140 Millionen Mark einsparen. Warum nicht 20 Prozent?
Mit den genannten Daten belegt die Unternehmensberatung Diebold Deutschland GmbH die wirtschaftliche Bedeutung der Verbesserung der Software-Produktions-Methoden. Diebold stellte kürzlich in Bonn die Studie "Einsatzmöglichkeiten software-technologischer Methoden mit Normungseffekt" auf einer GMD-Tagung vor (siehe Seite 1 "Vom Programmgesellen zum Software-Ingenieur").
"Die Milliarden-Verschwendung"
Man hat diese Problematik auch die "Milliarden-Verschwendung" genannt, Die Diebold-Studie belegt, daß in der Tat bereits zahlreiche Werkzeuge vorhanden sind, die die gewünschte Produktivitätssteigerung durch ingenieurmäßige Software-Produktion ermöglichen könnte. Indes, nur etwa 5,3 Prozent des derzeitigen DV-Personals, haben während ihrer Berufsausbildung eine Unterweisung in software-technologischen Methoden erfahren, nur rund 15 Prozent der heutigen Software-Entwickler haben eine abgeschlossene DV-Ausbildung. Das insgesamt mangelhafte Wissen der Anwender über software-technologische Methoden ist wohl die Hauptursache dafür, daß an der Grenze der vierten Hardware-Generation meist noch nach Verfahren der zweiten Software-Generation analysiert und programmiert wird.
Andererseits stellt Diebold aber auch fest, daß wegen "schlechter Handhabbarkeit und Bedienungsunfreundlichkeit" die wenigen Anwender, die teilweise mit hohen Kosten Programmierwerkzeuge (normierte Programmierung, Entscheidungstabellen, Generatoren, Makro-Sprachen etc.) erwarben, die zumindest 30 Prozent nicht einsetzen.
Resignation wäre falsch
Das Dilemma wird ständig größer, denn zunehmend wächst der Aufwand für Programmpflege und -wartung gegenüber der Programm-Neuentwicklung, der heute schon bei größeren DV-Installationen über die Hälfte der Manpower beansprucht und bei einigen Anwendern bereits anteilsmäßig 90 Prozent ausmacht. Hier rächen sich die Sünden der Vergangenheit besonders wirkungsvoll. "Verwendungsnachweise für Software-Bausteine" wären zu fordern, die zudem verhindern könnten, daß allenthalben Programmteile neu geschrieben werden, die für andere Anwendungen bereits vorhanden sind. Helfen würden ferner "Projektstandards", "Beschreibungsstandards", "Schritthaltende Dokumentation" und all das, was unter den Begriffen "Top Down Design", " Hierarchie Verfeinerung", "Strukturierte Programmierung" und "Test- und lntegrationsstrategien" zu Recht zunehmend zumindest theoretisches Interesse bei den Anwendern findet. Nur Praxis-Erfahrung hat kaum einer.
Die Schwierigkeiten potenzieren sich, wenn all diese Verfahren - so wünschenswert sie auch sind - gleichzeitig eingeführt werden sollen. Das gelobte Land liegt klar vor Augen, der Weg allerdings ist schrecklich weit. Resignation wäre jedoch falsch am Platz. Man muß sich nur entscheiden, womit man beginnen will.