Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

17.12.1993

Wartung ist keine vereinfachte Software-Neuentwicklung Die Organisation des Prozesses sollte stets erste Prioritaet haben

Altsoftware funktioniert trotz jahrzehntelanger Weiterentwicklung zwar immer weiter, doch wird ihre strukturelle Qualitaet mit jedem Eingriff schlechter und ihre Wartbarkeit unbefriedigender. Ueberarbeitung im Einzelkaempfertum - und sei sie noch so trickreich - ist deshalb nicht gefragt. Klaus Schulz* plaediert dafuer, Re- Engineering zu einem festen Bestandteil des Wartungsprozesses zu machen.

Es gehoert zu den ernuechternden Momenten im Berufsleben eines hoffnungsvollen Informatikabsolventen, wenn er ein Programm zur Pflege anvertraut bekommt, das aelter ist als er selbst. Ein Generationskonflikt ganz neuer Art. Da unser Informatiker voller Ideale ist und an das Gute in der Software glaubt, ist er bestrebt, nicht einfach die Aenderung, mit der er beauftragt ist, in das Programm hineinzuflicken, sondern den bereits mehrfach geaenderten Programmteil wieder neu und logisch zu strukturieren.

In dieser Situation gibt es mehrere Moeglichkeiten:

- Der umstrukturierte Teil des Programms verarbeitet die Daten genau so wie vorher der unstrukturierte. Falls es sich um einen groesseren umgearbeiteten Codeabschnitt handelt, ist diese Moeglichkeit eher unwahrscheinlich. Hat unser junger Protagonist wirklich so gut gearbeitet, dass diese Moeglichkeit eintritt, dann darf er sich gluecklich schaetzen, aber es dankt ihm niemand.

- Der umstrukturierte Teil enthaelt Fehler, die durch die Umstrukturierung entstanden sind, aber diese werden vor der Produktionsuebergabe erkannt mittels eines vollstaendigen Satzes von Testdaten, der fuer das Programm zur Verfuegung steht.

- Der umstrukturierte Teil enthaelt Fehler, ein Teil davon wird durch Testen erkannt und behoben. Ein paar Fehler aber bleiben zunaechst unentdeckt und treten ein paar Wochen spaeter in der Produktion auf.

Die Situation beinhaltet die ganze Problematik der Weiterentwicklung von Software. Vor 25 Jahren war die gedachte Software technisch auf dem Stand der Zeit, fachlich aber noch in den Kinderschuhen.

Im Lauf der Jahre ist die Verarbeitung ausgebaut worden - dafuer sorgt schon der Druck der Fachabteilung -, aber die technische Qualitaet hat mit jedem Eingriff gelitten.

Hier wirkt das zweite der fuenf Gesetze der Software-Evolution, die Lehman und Belady in Analogie zu den Hauptsaetzen der Thermodynamik Anfang der 70er Jahre formuliert haben: Die Entropie eines Systems nimmt mit seiner kontinuierlichen Weiterentwicklung zu, das heisst, seine Strukturiertheit nimmt ab, wenn nicht Arbeit zur Erhaltung oder Verbesserung der Struktur aufgewendet wird (vgl. die Abbildung). Nachdem sich die Software jahrelang bezueglich der Funktionalitaet positiv, aber bezueglich der technischen Qualitaet negativ entwickelt hatte, hat unser Informatiker ein Programm vorgefunden, dessen Wartbarkeit nur noch mit "unbefriedigend bis mangelhaft" zu bezeichnen ist, und wollte Arbeit in die Struktur des Programms investieren. Er ist ein Informatiker, der seine Arbeit ernst nimmt und nicht noch dieses und jenes Feld missbraucht, um die Aenderung irgendwie im Code unterzubringen. Haeufig haben jedoch solche Mitarbeitern keine Rueckendeckung von oben und passen sich nach einer Weile dem Arbeitsumfeld an.

Fuer die Ueberarbeitung der Struktur von Software gibt es einen Begriff: Re-Engineering. Gemeint ist damit weniger die Ueberarbeitung im Einzelkaempfertum, als vielmehr die bewusste und geplante Inangriffnahme von Problemen der technischen Qualitaet.

Meist gibt es einen Anlass dazu, ein uebergeordnetes Ziel, zum Beispiel die Portierung der Software, die Migration auf ein anderes Datenbanksystem, oder - siehe oben - die Notwendigkeit, eine funktionale Aenderung einzubauen, die aber in den gewachsenen Code nicht vernuenftig integriert werden kann.

Ueber Wartung wird nur wenig diskutiert

Softwarequalitaet ist in den letzten Jahren zunehmend thematisiert worden, vor allem im Zusammenhang mit ISO 9000 und dem Reifegradsmodell des SEI.

Die Aussage, dass kein Produkt auf Dauer besser sein kann als der Prozess, mit dem es erstellt wird, trifft nicht nur auf die Software-Neuentwicklung zu, sondern genauso auf die Wartung. Waehrend der Modellierung und Messung der Neuentwicklung relativ viel Aufmerksamkeit gewidmet wird, gibt es ueber den Wartungsprozess weniger oeffentliche Diskussion.

Er wird manchmal nur als eine vereinfachte Form des Neuentwicklungsprozesses gesehen, wobei die speziellen Teilaufgaben der Wartung wie Impact-Analyse, Pruefung auf unerwuenschte Nebeneffekte, Umstrukturierung beziehungsweise Re- Engineering, Regressionstest, Versions-Management etc. nicht angemessen beruecksichtigt werden.

Dabei sind die Produkte der Wartung wesentlich besser zu messen als die der Neuentwicklung: Die wenigsten Firmen koennen heute fundiert Komplexitaet oder Fehlerrate eines Fachentwurfs messen. Fuer lauffaehige Module sind diese Fragen einfacher zu beantworten. Damit die Messungen Aussagekraft bekommen, ist eine Kalibrierung und der Vergleich mit frueheren Ergebnissen notwendig.

Re-Engineering als Teil der Wartung

Waehrend bei der Neuentwicklung dafuer abgeschlossene Projekte vorliegen muessen, die in gewissem Sinne auch vergleichbar sind, bietet sich bei bereits eingesetzter Software die vorhergehende Version als Vergleichsbasis an. Da Versionen in kuerzeren Zeitraeumen abgeschlossen werden als Projekte, entsteht schneller eine Historie, die unter anderem ueber die Entwicklung der Qualitaet Auskunft geben kann.

Die These ist, dass mit zunehmendem Qualitaetsbewusstsein auch der Wartung mehr Aufmerksamkeit gewidmet werden und dass Re-Engineering ein fester Bestandteil des Wartungsprozesses wird, der ausgeloest wird entweder zur Vorbereitung von anderen Wartungsmassnahmen (siehe oben) oder durch Ursachenforschung als Reaktion auf sich verschlechternde Kennzahlen.

Welches nun ist der Bezugspunkt fuer die technische Qualitaet? Ein Assembler-Programm, das vor 25 Jahren mit den verschiedensten technischen Kniffen geschrieben wurde, zum Beispiel der dynamischen Modifikation von Sprunganweisungen, mag damals technisch dem Stand der Zeit entsprochen haben.

Gefaehrliche Vorliebe fuer den Einsatz von Tools

Der heutige State of the art ist - auch fuer Assembler - die strukturierte Programmierung und das Verbot von dynamischen Codemodifikationen (in Cobol der Alter-Befehl). Die technische Qualitaet des Programms verschlechtert sich also nicht nur durch die normale Wartungstaetigkeit, sondern auch durch den veraenderten Bezugspunkt.

Die Probleme werden verdeckt durch die Tatsache, dass ein Programmierer seine Programme und die angewendeten Kniffe kennt. In einem Reifegradmodell ist dies ein Charakteristikum der Stufe eins: Erfolg und Misserfolg haengen hauptsaechlich von den Individuen ab. Spaetestens wenn die Wartung durch andere Personen erfolgen soll, sei es die Urlaubs- oder Krankheitsvertretung oder eine Outsourcing-Firma, tritt das Problem zutage. Aehnlich wie bei der Software-Neuentwicklung gibt es auch auf dem Wartungssektor eine Vorliebe fuer den Einsatz von Tools, ohne dass eine Bereitschaft zur Klaerung und Verbesserung des Prozesses dahintersteht. Es gibt mittlerweile recht gute Re-X-Tools (siehe zum Beispiel die Uebersicht im CW Focus zur CW Nr. 34 vom 20. August 1993, Seite 26).

Wenn die Diskussion ueber technische Qualitaet ausgehend vom Tool gefuehrt wird und nicht im Bezug auf Ziele wie verbesserte Wartbarkeit und groessere Personenunabhaengigkeit des Codes, wird das Pferd vom Schwanz her aufgezaeumt. Die Erwartungen an das Tool sind ueberhoeht und werden notwendigerweise enttaeuscht.

In der Situation, in die wir unseren Junginformatiker hineingestellt haben, waere ein Re-X-Tool nur von nachgeordneter Wichtigkeit. An erster Stelle wichtig gewesen waere ein expliziter Auftrag zur Umstrukturierung des Codes mit einer moeglichst praezisen Zielangabe, an zweiter Stelle der vollstaendige Satz an Testdaten, an dritter Stelle ein Tool zum Regressionstest mit diesen Testdaten und an vierter Stelle ein Tool, das dem Informatiker hilft, den unstrukturierten Code zu durchleuchten.

Informatiker haben eine Tendenz, technische Aspekte eines Problems ueberzubewerten. Bei Problemen mit der Software-Entwicklung und - Wartung wird nach Tools Ausschau gehalten, und eine Programmiersprache glaubt man besonders gut anzuwenden, wenn man die neuesten technischen Kniffe einsetzt. Die Organisation des Prozesses oder die Lesbarkeit des Codes rangiert an zweiter Stelle. Wir sollten unsere Prioritaeten aendern.