"Qualität läßt sich in ein Produkt nicht hineisprüfen, sie muß hineinkonstruiert werden" - so die Forderung von Dr. Jürgen Gutmann* an die SW-Entwickler. Sein Fazit: CASE kann man heute genauso wenig kaufen wie CIM.
In der Phase "Lösungsvorschlag erarbeiten" geht es auch um die äußere Beschreibung der Modifikation und um die Aufwandsschätzung. Hier ist einerseits sicherzustellen, daß sich alle vorhandenen Komponenten in den bisher schon aufgetretenen Situationen unverändert verhalten. Andererseits wird festgelegt, was neue Komponenten zu leisten haben und wie sie mit den vorhandenen zusammenhängen.
Als erste Teilaufgabe ist die Absicherung des unveränderten Verhaltens zu betrachten. Wieder stellt die Verläßlichkeit der Dokumentation ein wichtiges Merkmal dar: Wenn nicht feststeht, daß das tatsächlich implementierte Verhalten eines Moduls mit der zugehörigen Beschreibung übereinstimmt, ist diese wertlos oder sogar schädlich. Implementierungssprachen, die eine saubere Spezifikation erfordern (zum Beispiel Modula oder Ada), beginnen erst, sich zu etablieren Strukturierte Entwurfs- und Spezifikationssprachen erfordern überdies Mitarbeiterqualifikationen, die oft noch nicht verfügbar sind
Meist ist es deshalb erforderlich, einen weniger formalen Weg zu gehen: Um zu entscheiden, ob ein Modul angegangen werden muß, sollte ein abgestuftes Ausschlußvorgehen möglich sein. Dazu braucht man die Dokumentationsstufen Zweckbestimmung, Beschreibung der Funktionen (Blackbox-Beschreibung) und Konstruktion (Whitebox-Beschreibung).
Zweckbestimmung und Blackbox-Beschreibung sollten immer manuell neben oder als spezieller Kommentar in der Quelle gepflegt werden. Die Konstruktion (zum Beispiel in Form von Ablaufplänen oder Strukturdiagrammen) neben den Quellen zu pflegen, überfordert die Disziplin der meisten Mitarbeiter und Organisationen. Deshalb sollte die Konstruktion Bestandteil der Quelle sein, darf aber auch nicht in manipulierenden Anweisungen untergehen.
Durch geeignete Konventionen muß es möglich sein, die Konstruktion (Kontrollstruktur) eines Modells aus der Quelle maschinell zu extrahieren; dies kann zum Beispiel durch Generatoren erfolgen, die in der Lage sind, ein Programm aus Konstruktion sowie datendeklarierenden und manipulierenden Statements zusammenzusetzen, oder auch durch Analysatoren, die die Konstruktion aus Programmquellen herauslösen.
Ein solches Vorgehen ist auch mit Cobol als Implementierungssprache möglich, wenn bei der Entwicklung geeignete Standards eingehalten werden. Insbesondere geht es hier um die Verwendung von Kontrollanweisungen - IF, PERFORM - und Festlegungen für den Programmkommentar.
Diese Diskussion mündet in drei weitere Forderungen an Produkt, SPU, Projektdurchführung und Entwicklungskonzept: Alle zu einer Komponente gehörenden Teilergebnisse - soweit sie von Menschen auswertbar sind - sollten an einer Stelle gepflegt werden; entsprechende Mechanismen müssen das DBMS der Produktdatenbank oder die zur Pflege benutzten Werkzeuge verfügbar machen; Zweckbestimmung, äußere Beschreibung (Spezifikation) und interne Struktur (Konstruktion) müssen separierbar sein.
Soweit die Werkzeuge der Produktionsumgebung (Produkt-Datenbank-Management-System, Generatoren, Compiler) das nicht leisten gilt es, geeignete Konventionen und Standards im Entwicklungskonzept zu verankern und sie auch in der Projektdurchführung einzuhalten. Redundante Informationen der Dokumentation, zum Beispiel die interne Programmstruktur, dürfen nicht manuell gepflegt werden; dies müssen die Werkzeuge der SPU übernehmen - im Verbund mit geeigneten Konventionen und Standards.
Die zweite Teilaufgabe des Arbeitsschritts "Spezifikation der Modifikation" setzt sich mit der Definition und der äußeren Beschreibung neuer Komponenten auseinander. Der schwierigste Teil dieser Aufgabe ist - wie auch bei der Neuentwicklung - die Definition der Prozeßkomponenten, also die Festlegung, welche elementaren Aufgaben in welchen Modulen zusammengefaßt werden. Bei einer Neuentwicklung in einem überschaubaren Projektteam hat meist der erfahrenste Mitarbeiter die Rolle eines "Produktarchitekten"; er bestimmt die Modularisierung. Mitarbeiter mit der Eignung zum Produktarchitekten sind für gewöhnlich jedoch nicht mit der Wartung beschäftigt. Es besteht also die Gefahr, daß die ursprüngliche Produktstruktur durch Flickwerk in der Wartung allmählich zugedeckt wird Daraus ergibt sich eine weitere Regel: Die Modularisierung der Produktfunktionen muß nach einfachen und personenunabhängigen Kriterien erfolgen Das geschieht am besten durch die Festlegung einer einheitlichen Produktarchitektur im SW-Entwicklungskonzept.
Schichten-Architektur erleichtert Modifikationen
Die bekannten Abstufungen von externer Modulkopplung und internem Modulzusammenhang sind zwar hilfreich für die Modularisierung, aber in der Praxis häufig nicht konkret genug. Erfahrungsgemäß ist man besser bedient mit einer Produktarchitektur in Schichten; diese sollte klar voneinander abgegrenzte Aufgaben und Module aufweisen, die jeweils genau einer Schicht angehören Solch eine Architektur kann beispielsweise aus folgenden Schichten bestehen: Interaktionssteuerung, Sitzungssteuerung, anwendungsneutrale und applikationsspezifische Funktionen, Objekt- und Funktionsdienste sowie Datenzugriffssteuerung.
Bei fast jeder Modifikation ist unmittelbar klar, auf welche dieser Schichten sie wirkt. Das erleichtert die Entscheidung, wo geändert wird beziehungsweise welche neuen Module erforderlich sind. Zwischen den Schichten werden einheitliche Typen von Schnittstellen definiert - es handelt sich immer um Monitor/Server-Beziehungen. Das erleichtert die Verfolgung von Änderungen über Aufrufhierarchien.
Die Ergebnisse der Änderungsspezifikationen müssen bei den betroffenen Komponenten abgelegt werden können. Für eine sichere Trennung von Modifikationen sollte die Produktdatenbank möglichst über Mechanismen zur Verwaltung von Versionen und Varianten verfügen, mindestens aber über eine Zustandsverwaltung mit Enqueue-Dequeue-Mechanismen.
Der dritte Arbeitsabschnitt beschäftigt sich damit, die Modifikationen durchzuführen. Viele Köche verderben den Brei - das könnte auch ein Motto für die Wartung von Anwendungssoftware sein. Eine Konsequenz daraus betrifft die Organisation der Wartung: Es muß klar definierte Zuständigkeiten für Produkte- beziehungsweise Produktteile geben.
Die andere Konsequenz sind "Kochbücher", die Zutaten und Arbeitsschritte verbindlich beschreiben und - besonders hilfreich zur Selbstkontrolle - Bilder von Zwischen- und Endprodukten enthalten. Ihre Betonung sollte nicht auf der Erzeugung von kreativen Spitzenleistungen liegen, sondern auf der personenunabhängigen Qualität der Basisergebnisse. Denn die Verfeinerung einer Sauce mit zwanzigjährigem Bordeaux ist vergebliche Liebesmühe, wenn man mit einer Mehlschwitze begonnen hat.
Änderungsinformationen separat verfügbar machen
Dieses projektübergreifende Regelwerk gilt nicht nur für die Entwicklung; dort könnte man bei kleineren Vorhaben zur Not auch mit Ad-hoc-Vereinbarungen des Projektteams leben. Deshalb sind die Guidelines primär auf die Wartung ausgerichtet, um für die gesamte Lebensdauer des Produkts ein Mindestmaß an Personenunabhängigkeit zu gewährleisten.
Ein wichtiger Teil dieser Richtlinien betrifft folglich auch die Festlegung, wie Änderungen innerhalb der Komponenten gekennzeichnet und dokumentiert werden. So lassen sich Änderungsinformationen beispielsweise durch Generatoren oder Analysatoren aus den Quellen extrahieren und separat verfügbar machen. Das ist eine Voraussetzung für eine effektive vorbeugende Wartung, denn dadurch können geeignete Produktbereiche für Sanierungsmaßnahmen ausfindig gemacht werden.
Software wird durch Wartung eher schlechter als besser. Einem Mitarbeiter, der bei einer Änderung ein Programm verstehen soll, das sieben Jahre Einsatz mit 20 Modifikationen durch fünf Personen "erlebt" hat, können sich schon einmal die Haare sträuben. Da ist es beruhigend - und erleichtert darüber hinaus die Arbeit - wenn aus der Quelle ersichtlich ist, daß das Programm nicht von Anfang an so unübersichtlich war und Zweck beziehungsweise Bestandteile einer jeden Änderung nachvollziehbar sind.
Testumfang grotesk gegenüber der Codierung
Das Testen wird in der Wartung häufig noch stiefmütterlicher behandelt als bei der Entwicklung. Diese Prüfung ist aber um so wichtiger und schwieriger, als der unausrottbare Optimismus fast aller Softwerker, weniger Fehler zu machen als andere, und die Tendenz, die eigene Vorausschau auf mögliche Ausführungssituationen zu überschätzen, hier vehement durchschlägt. Es fällt auch schwer, sich daran zu gewöhnen, daß der Testumfang bei Änderungen und Erweiterungen in krassem Kontrast zum Umfang der Codierung steht. Wo in der Entwicklung Verhältnisse von 2:1 durchaus erreichbar sind, hat man es in der Wartung eher mit 10: 1 zu tun.
Die Palette sinnvoller Testunterstützung umfaßt deshalb neben interaktiven Testmonitoren die Speicherung von Testfällen bei den betroffenen Komponenten, beziehungsweise ihre separate Speicherung mit Verknüpfung auf die betroffenen Bestandteile in der Produktdatenbank.
Hinzu kommen Generatoren für Testtreiber und Stummel, Hilfen zur Instrumentierung von Quellen, zum Gewinnen von Testfällen durch Analyse der Modulspezifikation und -konstruktion sowie die automatisierte Testwiederholung, zum Beispiel Batch-Simulation von Online-Anwendungen. Eine optimale Funktionalität derartiger Einzelwerkzeuge ist aber nicht so wichtig wie ein hohes Integrationsvermögen - vor allem mit der zentralen Produktdatenbank.
"Flickwerk" braucht ständige Zerreißproben
Als vierter Arbeitsabschnitt folgt die Überprüfung der Ergebnisse einer Modifikation. Qualitätssicherung für die Wartung in einem Unternehmen zu etablieren ist für gewöhnlich noch schwieriger als in der Entwicklung. Denn bei der SW-Erstellung gibt es festgelegte Produktzustände (Phasenabschlußergebnisse), die im Zusammenhang auf Vollständigkeit, Konsistenz und lokale innere Qualität der Komponenten kontrolliert werden können. Die Menge der zu prüfenden Ergebnisse - und damit der Prüfaufwand - steht in einem vertretbaren Verhältnis zum geleisteten Entwicklungsaufwand.
Beim in der Wartung üblichen "FIickwerk" (Patching) besteht hingegen eine völlig andere Situation. Es geht hier ja nicht nur darum, die Wirkung des "FIickens" auf die User zu prüfen, sondern auch um die Qualität der Nahtstellen über die Benutzeroberfläche hinaus. Der Umfang einer verläßlichen Prüfung kann so leicht den Umfang der Änderung überschreiten.
Effektiver ist die Einrichtung von Revisionsmechanismen, die wie bei einer periodischen Autoinspektion wichtige Produktmerkmale überprüfen; sie erfordern aber ein langfristiges Wartungskonzept mit geplanten Releases. Zur Qualitätssicherung des "Patchwork" reichen dann Stichproben und die vom Produktmodell, der Produktarchitektur und dem projektübergreifenden Regelwerk bewirkten Einschränkungen der "künstlerischen" Freiheit.
Das heißt, neben der im wesentlichen von außen gesteuerten punktuellen Patch-Wartung muß eine langfristig angelegte, von innen gesteuerte Recycling-Wartung eingerichtet werden; sie erfordert die Planung und Realisierung von Teil-Releases ausgehend von Auswertungen der Patch-Wartung - zum Beispiel nach Fehlerschwerpunkten, überdurchschnittlichem Änderungsaufwand, wesentlichen Überschreitungen von Aufwandsschätzungen und Hinweisen der für die Patch-Wartung zuständigen Mitarbeiter. Auch eine periodische maschinelle Auswertung bestimmter Kerngrößen liefert Hinweise auf lohnende Sanierungsobjekte.
Je mehr Modifikationen vom Patchwork zum Recycling herübergezogen werden können, desto kostengünstiger ist die Wartung. Jedoch gilt es, diesen Vorteil abzuwägen gegenüber den Nachteilen, die der Fachabteilung in der Wartezeit zugemutet werden. Die Entscheidung, zu "patchen" oder auf das nächste Release zu warten, braucht den Konsens von Fach- und DV-Abteilung.
Der fünfte Arbeitsabschnitt schließlich befaßt sich mit der Einführung und Stabilisierung der Modifikation. Hierbei sind die Probleme der Konfiguration (Was muß alles in die Produktion eingebracht werden?) und der adressantengerechten Verteilung der geänderten Komponenten zu lösen.
Für die unmittelbar von Maschine und Benutzern verwendeten Komponenten - was der (Pre-)Compiler zusammenstellt und was TP-Monitor sowie DBMS benötigen - ist das noch ziemlich einfach. Schlechter sieht es häufig mit der zugehörigen Dokumentation aus, die in geänderter Form und passender Menge an die richtigen Adressen gelangen muß. Das liegt zum einen daran, daß die Modularisierung häufig vor der Dokumentation Halt gemacht hat; zum anderen werden Rollenkonzepte nur bezüglich der Berechtigungen für bestimmte Funktionen und Daten entwickelt, nicht aber auf die zugehörige Dokumentation ausgedehnt.
Daraus lassen sich die beiden letzten wartungserleichternden Merkmale ableiten: Zum Produktmodell gehört neben einer Definition der logischen Struktur einzelner Komponenten auch die Fähigkeit, Rollen definieren zu können, die benutzer- oder Benutzergruppen-spezifische Sichten auf die einzelnen Produktteile ermöglichen.
Die Dokumentation muß den Benutzern soweit wie möglich online zur Verfügung stehen. Schriftliche Erläuterungen sollte ein User nach seinem persönlichen Bedarf jederzeit selbst erzeugen können. Soweit es nicht ohne Handbuch geht, ist darauf zu achten, daß einzelne Abschnitte ersetzt werden können und Änderungen (möglichst mit Datum) markiert sind.
Die heutige Verteilung des Aufwands innerhalb der Informationstechnik - ein Drittel Neuentwicklung, zwei Drittel Wartung und Weiterentwicklung - macht es eigentlich überfällig, auch die CASE-Diskussion von der Wartungsseite anzugehen. Jedes der elf dargestellten Merkmale (siehe Kasten) kann einen Hinweis dafür liefern, in welche Richtung die eigene Entwicklung zu CASE, also zu einer ingenieurmäßigen Entwicklung und Instandhaltung von Software weitergehen könnte. CASE kann man - heute - genauso wenig kaufen wie CIM.
*Dr.Jürgen Gutmann ist Leiter des Bereichs Methoden und Verfahren bei der Heyde + Partner GmbH,Bad Nauheim.
_AU: