- Auf dem Hamburger Anwendergespräch der Gesellschaft für Informatik zum Thema "Computergestützte Methoden zur Entwicklung kommerzieller Programmsysteme" sprachen Sie in Ihrem Einführungsreferat mehrfach von der derzeitigen Software-Krise. Wie läßt sich belegen, daß es diese Software-Krise tatsächlich gibt?
Man muß die gesamtwirtschaftliche Bedeutung der Software-Herstellung, Software-Wartung und des Betriebes von Software-Systemen betrachten. Dabei ist zweierlei festzustellen: Zunächst hat sich das Kosten/Leistungs-Verhältnis bei der Erstellung von Software-Systemen im Lauf der Zeit kaum nennenswert verbessert; im Gegenteil, wir müssen trotz verbesserter Arbeitsorganisation im Bereich der manuellen Software-Produktion eine Kostensteigerung feststellen. Gleichzeitig hat sich das Kosten/Leistungs-Verhältnis der maschinellen Computersysteme drastisch verbessert. Wir können heute Computerleistungen zu einem Bruchteil der Kosten in Anspruch nehmen, die vor etwa zehn Jahren aufzubringen waren. Das führte zu einer entsprechenden Verschiebung der Budgets. Es gibt Untersuchungen, die zeigen, daß sich der Kostenanteil für die Nutzung der maschinellen Datenverarbeitung sehr entscheidend zu Lasten der Software-Kosten verschiebt. Nicht nur die Software-Entwicklungskosten steigen überproportional, vor allem erhöht sich der Anteil der Software-Wartungskosten. Diese machen heute schon mehr als 50 Prozent der Gesamt-Kosten aus, und es läßt sich absehen, daß deren Anteil in Zukunft noch großer wird.
- Meinen sie, daß die Bedeutung dieses Software-Wartungsproblems genügend erkannt wird?
Wer sich mit Fragen der Software-Herstelung und des Software-Engineering beschäftigt, übersieht häufig, daß nach dem Abschluß der Software-Entwicklung erst der große Kostenblock anfällt. Über den Lebenszyklus eines Software-Produktes gerechnete betragen heute, schon die Wartungskosten ein Mehrfaches der Herstellungskosten. Die meisten Software-Abteilungen von Großanwendern setzen heute schon mehr als die Hälfte ihrer Personalkapazität für Wartungsaufgaben ein. Dieses Auslastungsverhältnis war vor zehn Jahren bekanntlich anders. Damals ging es in erster Linie um Neuentwicklung von Programmsystemen.
- Gibt es zu diesen Themen eigentlich empirisch belegte Zahlen?
Wir müssen hier vor allem auf entsprechende Untersuchungen aus den USA zurückgreifen. Da gibt es ein sehr signifikantes Beispiel aus dem Militärischen Bereich: Nachgewiesen wurde daß die Entwicklungskosten Je Befehl 75 Dollar betrugen. Die späteren Wartungskosten erreichten das 55fache der Entwicklungskosten, nämlich rund 4000 Dollar pro Befehl. Die gesamtwirtschaftliche Bedeutung der Software-Kosten wird auch daran deutlich, daß in den USA im Jahre 1976 rund 50 Milliarden Mark für Software-Entwicklung und Software-Wartung ausgegeben wurden.
Entsprechende Untersuchungen gehen außerdem davon aus, daß sich diese Kosten künftig jährlich um mehr als 20 Prozent, steigern werden. Entsprechende Zahlen wurden für die Bundesrepublik Deutschland in einer Diebold-Untersuchung für das Jahr 1975 vorgelegt. Hier wird von einem jährlichen Aufwand von 7 Milliarden Mark ausgegangen. Diese Zahl dürfte jedoch im Vergleich mit den amerikanischen Verhältnissen zu niedrig angesetzt sein. Trotzdem zeigt sie, welche volkswirtschaftliche Bedeutung eine Reduzierung dieses Kosten-Volumens um nur zehn Prozent hätte.
- Was sind die inhaltlichen Merkmale der Software-Krise?
Zu den weiteren Merkmalen der Software-Krise zähle ich die Probleme, die sich aus der mangelnden Zuverlässigkeit großer Systeme ergeben. Es ist bekannt, daß mit zunehmender Komplexität der EDV-Anwendungen der Mensch immer größere Schwierigkeiten hat, Software-Systeme dieser Größe mit manuellem und herkömmlichen Techniken zu beherrschen. Hinzu kommt, daß die Zuverlässigkeit nütz zunehmender Komplexität der Systeme abnimmt. Dies zeigt bereits eine einfache Rechnung auf der Grundlage der Zuverlässigkeits-Teorie. Nehmen wir zum Beispiel eine Systemkomponente
eine Zuverlässigkeit von 99 Prozent hat und ein System aus zehn solcher Komponenten gleicher Zuverlässigkeit besteht, dann hat das Gesammt-System eine Zuverlässigkeit von nur noch rund 90 Prozent. Daraus folgt die unabdingbare Forderung, daß die einzelnen Systemkomponenten in ihrer Zuverlässigkeit möglichst nahe an die 100-Prozent-Grenze gebracht werden müssen. Dies ist mit manuellen Mitteln aber kaum zu erreichen. Daher muß man dafür Sorge tragen, daß in der Zukunft geeignete computergestützte Methoden für die Entwicklung zuverlässiger Anwendersysteme zur Verfügung stehen und daß diese dann auch in der Praxis genutzt werden.
- Einiges gibt es ja schon zur computerunterstützten Systementwicklung. Ihre Bemerkungen deuteten an, daß Sie aber mit dem derzeit Angebotenen noch nicht zufrieden sind?
Es kann nicht bestritten werden, daß es eine nennenswerte Anzahl von geeigneten
Software-Tools gibt, die dazu beitragen, können, einzelne Probleme bei der Software-Entwicklung und Software-Warture zu entschärfen. Allerdings muß auch festgestellt werden, daß es noch kein System gibt, das alle diese einzelnen Software-Werkzeuge integriert und diese für eine simultane und umfassende System-Entwicklung verfügbar macht.
- Sie fordern also den Werkzeugkasten aufeinander abgestimmter Verfahren. Welche Tools mußten darin enthalten, sein?
Im Bereich der computergestützten Software-Entwicklung müssen den Partialsystemen nun Totalsysteme folgen. Ein solches Totalsystem hätte insbesondere die folgende Funktionen zu erfüllen: Zunächst einmal müßten Projekt-Management und Projekt-Durchführung vereint werden. Meines Erachtens muß die Computer-Unterstützung sowohl den Bereich der Projektführung wie auch den Bereich der Erstellungshilfen und Wartungshilfen umfassen. Des weiteren kommt es darauf an, eine neue Benutzer-Schnittstelle für die Kommunikation zwischen Anwender und Computer zu definieren mit deren Hilfe der Sacharbeiter Problemlösungen so beschreiben kann, daß sie mit maschineller Hilfe in fehlerfreie Computer-Programme umgesetzt werden können. Dazu müßten Werkzeuge kommen, die es dem Systemanalytiker ermöglichen, den Softwareentwurf zu optimieren. Außerdem sollte es möglich sein, maschinelle Testverfahren zur Verfügung zu haben, die unter anderem durch Implementations-Simulationen dem Anwender zeigen, ob seine Vorstellung von der Problemlösung mit der Programmrealisierung identisch ist. Und schließlich gehört zur Computerunterstützung ein umfassendes Dokumentationssystem das den Anwender in die Lage versetzt, weniger aufwendig zu warten, so daß auf diesem so wichtigen Gebiet Kosten werden können.
- Soweit das Problem. Wo zeigen sich Lösungen?
Grundsätzlich lassen sich drei Wege beschreiten, um die Softwarekrise zu meistern. Zunächst einmal kann man daran denken Standard-Anwender-Software zu produzieren. Dies hat allerdings zur Voraussetzung, daß die Anwender bereit sind, sich den damit gegebenen Standards ohne Einschränkung anzupassen.
- Muß man diesen Weg heute nicht als gescheitert betrachten?
Diese Formulierung würde ich nicht unbedingt zustimmen; allerdings muß man erkennen, daß bislang noch nicht gezeigt werden konnte, bis zu welchem Umfang allgemein verbindliche Standards und Normen auf diesem Gebiet durchgesetzt werden können. Im übrigen ist bekannt, daß die sogenannte Standard-Anwendersoftware in der Praxis nicht existiert, sondern durch zusätzliche Anpassungen und zusätzlichen Wartungsaufwand modifiziert und damit entstandardisiert wird.
- So wird an wohl auf andere Wege hoffen müssen?
Der zweite Ansatz kann darin bestehen, parametergesteuerte Programm-Generatoren zu verwenden. Allerdings hat sich auch hier, insbesondere im Bereich der Kleinrechner, gezeigt, daß diese Systeme zu wenig flexibel sind. Spezielle Anwenderwünsche erfordern stets aufwendige manuelle Nacharbeit. Auch dieser Weg bringt keine befriedigende Lösung.
- Das ist harte Kritik an den Systemen Variat, Triasis, Firm, MAS und wie Sie alte heißen.
Man muß sich entschließen, die Realität der Praxis so zu sehen, wie sie sich nun mal darstellt.
- Gibt es einen dritten Weg, der aus der Software-Krise weist?
Dieser Weg wird uns bereits durch amerikanische Entwicklungen vorgezeichnet. In den USA kennt man bereits Problem- und Systembeschreibungstechniken, die den Benutzer in die Lage versetzen, auf dieser Grundlage mit Hilfe von Software-Werkzeugen komplett lauffähige Anwendersysteme zu erzeugen. Diese Technik wird zusätzlich unterstützt durch begleitende Maßnahmen im Bereich der Dokumentation, der Testhilfe und bestimmter Planungshilfen für den Software-Entwickler.
- Wie könnte eine solche höhere Ebene der Kommunikation zwischen Mensch und Maschine aussehen?
Ich denke hier im Hinblick auf Aussagefähigkeit an sehr komprimierte Problembeschreibungs-Sprachen, die es ermöglichen, mit einfachen und auf die Psychologie des Benutzers zugeschnittenen Formulierungen zum Beispiel Daten-Strukturen und Programmverarbeitungs-Funktionen zu definieren. Das Ziel muß es sein, Problembeschreibungs-Standards zu vereinbaren, die den Benutzer zwingen, sich nur noch auf den weg endlichen Gehalt seiner Problemlösung zu beschränken, indem sie ihm möglich wenig Freiheit zur eigenen Verfügung lassen. Die traditionellen höheren Programmiersprachen überfordern den Endbenutzer, weil sie zu viele Alternativen anbieten, um Problemlösungen zu formulieren, und dadurch eher verwirren. Ein reduzierter Befehlsvorrat würde zu kompakten und übersichtlichen Problemformulierungen zwingen; diese könnten von Generatoren in ablauffähige Programme umgesetzt werden. Dies ist genau das Kernproblem. Wie zum Beispiel die Diskussion um die Goto-freie Programmierung zeigt, ist es durchaus möglich, Verarbeitungsfunktionen durch, eine statische Formulierung des Programminhaltes ohne spezifische Festlegung des dynamischen Programmablaufes hinreichend genau zu beschreiben. Es gibt ja erste Generator-Systeme dieser Art für die Realisierung simpler Batchanwendungen. Noch nicht geklärt ist, ob sich das Konzept auch für komplexe Probleme, insbesondere für den Mensch-Maschine-Dialog, nutzen läßt. Dies dürfte möglich sein, wenn es gelingt, typische Formen des Ablaufes einer Mensch-Maschine-Kommunikation festzulegen und diese dann computergestützt zu generieren. Allerdings muß man gerade in diesem Zusammenhang betonen, daß hier die Forschung insbesondere im empirischen Bereich bislang noch wenig Belege für die Praktikabilität dieser Konzeption geliefert hat. Trotzdem kann man optimistisch sein, da heute bei Softwarehäusern schon Versuche in dieser Richtung unternommen werden.
- So verhaltener Optimismus?
Es gibt zwar beträchtliche Schwierigkeiten, doch sie werden gelöst werden, weil die Bedingungen der Praxis dazu zwingen. Die Explosion der Softwarekosten muß eingedämmt werden, wenn wir nicht Gefahr laufen wollen, daß die weitere Verbreitung der Computeranwendung eingeschränkt wird, weil schließlich die Softwarekosten prohibitiv teuer werden.
Professor Dr. Dieter B. Pressmar (41)
ist Ordinarius für betriebswirtschaftliche Datenverarbeitung an der Universität Hamburg. Nach dem Studium an der TH Stuttgart (Maschinenbau) und der TU München (Wirtschaftswissenschaften) ging er 1963 an das Institut für Unternehmensforschung der Uni Hamburg. 1973 wurde er auf den neu eingerichteten DV-Lehrstuhl der Wirtchaftswissenschaftlichen Fakultät berufen. Sein Hauptarbeitsgebiet: Computerunterstützte Entwicklung von Planungs- und Informationssystemen. Seit Anfang des Jahres ist Pressmar Vorsitzender der Deutschen Gesellschaft für Operations Research.