Die oft zitierte Softwarekrise hat nach Einschätzung von Gerhard Rienecker* vor allem eine Ursache: Zu viele Software-Entwickler beschäftigen sich mit der Wartung alter Programme. Soll die Krise beseitigt werden, so der Autor in seinem engagierten Beitrag, müssen "Tool- und Methodengläubigkeit" hinter die eigentliche Aufgabe, die Reduzierung des Wartungsaufwandes, zurückgestellt werden.

Der heutige Zustand im Bereich der Software-Entwicklung wird mit Begriffen wie Softwarekrise, Anwendungsstau, Systemzoo etc. beschrieben.

Der Grund für diese Situation liegt nicht zuletzt in der Tatsache, daß Software immateriell ist und somit vordergründig keine Anforderungen an Konstruktionseigenschaften, Stabilität oder Lebensdauer zu stellen sind. Lange handelte man nach der Devise: "Hauptsache, es läuft."

Die Konsequenz dieser saloppen Vorgehensweise ist die schlechte Wartbarkeit der entstandenen Produkte. Etwa 70 Prozent aller Software-Entwickler bemühen sich, die Systeme im Betrieb zu halten, die über der obengenannten Devise erstellt worden sind. Diese Situation führt dazu, daß die Entwicklungsdauer neuer Systeme in Ermangelung qualifizierter Software-Entwickler für den Anwender unbefriedigend hoch ist.

Mögliche Eskalation dieser Situation: Systeme sind zum Zeitpunkt der Einführung veraltet oder müssen sofort an die neuen Markterfordernisse angepaßt werden. Der immaterielle Charakter von Software erzeugt also ein Krankheitsbild, das allgemein als Softwarekrise zu diagnostizieren ist. Dabei sind folgende Ausprägungen vorherrschend:

- Produktivitätskrise (Anwendungsstau),

- Qualitätskrise (erhöhter Wartungsbedarf),

- Sicherheitskrise (verunsichertes Entwicklungs-Management).

Krisen-Prophylaxe oder Krisen-Management

Heute steht fest, daß der Löwenanteil der Kosten eines Softwaresystems bei heutiger Entwicklungsmethodik im Bereich der Wartung anzusiedeln ist. Meistens stimmt folgende Faustregel: 60 Prozent Wartung, zehn Prozent Planung und 30 Prozent Neuentwicklung. Es gilt also heute, diesen Bereich hinsichtlich seiner Problemstellungen zu untersuchen und Maßnahmen zur Kostenreduktion zu ergreifen.

Der Weg aus dieser Krise weist in zwei Richtungen: entweder Krisen-Prophylaxe, wobei konstruktive Maßnahmen erforderlich sind, oder Krisen-Management, das korrigierende Maßnahmen erfordert. Die Vertreter der Krisenprophylaxe sehen den Ausweg aus dem Dilemma darin, Software ingenieurmäßig zu konstruieren, so daß entsprechende Krisenszenarien künftig vermieden werden können. Die konkreten Vorschläge zur konstruktiven Qualitätssicherung sind vielfältig, diffus und High-Tech-reklamierend, doch meistens ohne effizienten Beitrag zum Problemlösungsauftrag.

Dem Autor sei an dieser Stelle ein persönliches Wort erlaubt. Es gibt zwei Maßnahmen im Bereich der Konstruktion, um markante Fortschritte zu erzielen: die Normierung und die Transparenz. Normierung führt zu Wiederverwendbarkeit und damit zur Reduktion von Analysen, Konzepten, Entwürfen und dem Realisierungsaufwand. Mehr Transparenz über Unternehmen und Systeme stellt die Voraussetzung für die Wiederverwendung dar.

In Langzeituntersuchungen wurde festgestellt, daß bei der Entwicklung neuer Systeme nur 15 Prozent des zu implementierenden Codes wirklich neu waren, bei 85 Prozent dagegen wurde das Rad ein zweites Mal erfunden. Hier liegt meines Erachtens der wirkliche Produktivitätsansatz für große Informatikbereiche. Es muß darum gehen, die Tool- und Methodengläubigkeit zu erschüttern und statt dessen eine neue Ordnungspolitik einzufahren.

Kommen wir zum Krisen-Management. Vielfach werden DV-Manager mit folgender Situation konfrontiert:

- Systeme, die vor Jahren entwickelt wurden, sind zu betreiben. Oft sind sie nicht beschrieben und müssen außerdem erweitert werden.

- Weder ist im Fachbereich das Wissen über die Fachfunktionalität vorhanden, noch weiß die DV-Abteilung über die Implementierung der Fachfunktionalität Bescheid.

- Die Qualitätsanforderungen an die Ergebnisse, die das System erzeugt, sind sehr hoch.

- Die Qualität der Implementierung kann kaum geprüft werden, da die technischen Voraussetzungen hierzu fehlen.

- Systemerweiterungen dürfen bestehende Fachfunktionalitäten nicht beeinträchtigen.

Der tägliche Arbeitsauftrag ist die Quadratur des Kreises. Dies fährt zur Demotivation und damit schließlich zur Kapitulation gegenüber einer Aufgabe, die landläufig unter dem Begriff Wartung bekannt ist, von uns aber als Software-Management für existente Systeme geführt und verkauft wird.

Informatiker, die sich mit krisenanfälligen Systemen beschäftigen müssen, können mit intellektueller Begierde auf die Krisenprophylaxe blicken und auf das Jahr 2000 beziehungsweise auf ihre Pensionierung hoffen. Erst dann werden sich die dortigen Verheißungen in der konkreten Arbeitswelt niederschlagen.