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.

15.08.1980 - 

Erfolgversprechend ist nur ein Bündel projektbegleitender Vorbeugemaßnahmen:.

Kochrezepte zur Software-Wartung gibt's nicht

Da allmählich für fast alle Anwendungsgebiete im kommerziellen EDV-Bereich ausreichend Software zur Verfügung steht und genügend Entwicklungstechniken zur Verfügung stehen, hat sich bei der Software das Schwergewicht mehr und mehr von der Entwicklung zur Wartung hin verlagert. Wartungsfreundliche Programme sind heute besonders gefragt, haben doch Untersuchungen ergeben, daß die Kosten für die Wartung das zwei- bis vierfache der Entwicklungskosten betragen.

Warum ist Wartung erforderlich?

- Fehler aus dem Programmentwurf und der Codierung müssen beseitigt werden.

- Änderungen aufgrund von Mißverständnissen zwischen Organisation und Programmierung müssen vorgenommen werden.

- Änderungen aufgrund gestiegener oder wechselnder Anforderungen vom Anwender sollen durchgeführt werden.

- Anpassungen an Systemumstellungen oder -erweiterungen müssen vorgenommen werden.

- Erweiterungen von Programmen im Rahmen eines Stufenplans sind notwendig.

"Kochrezepte" zur Wartung von Software gibt es nicht. Leider sind nur allgemeine Richtlinien oder Maßnahmen aufzuzählen, deren Einhaltung zwar Disziplin, Arbeit und Geld kostet, sich letztlich aber bezahlt macht.

Diese Maßnahmen sind im wesentlichen vorbeugender Art. Sie sollen helfen, Fehler in der Programmentwicklung von vornherein zu vermeiden, so daß die spätere Wartung in Form von Fehlerbeseitigung weitgehend entfällt; zum anderen sollen sie für Änderungen, Anpassungen und Erweiterungen Schnittstellen schaffen, die den Wartungsaufwand verringern helfen.

Das normale EDV-Projekt besteht aus folgenden Phasen

Jede dieser Phasen kann in viele weitere Unterphasen aufgegliedert werden.

Der Entwicklungszeitraum erstreckt sich - je nach Projektgröße - auf drei Monate bis drei Jahre (und mehr). Bei sehr vielen Projekten wird - da man ja so viel Zeit hat - in der Anfangsphase der Entwicklung geschludert. Die Gründe dafür sind Nachlässigkeit, mangelnde Einsicht, unqualifiziertes Personal, falsches Kostendenken etc. Probleme werden stillschweigend vor sich hergeschoben, wobei sie einem am Ende der Entwicklung über den Kopf wachsen können.

Voruntersuchung, Grobplanung und Detailplanung sind die "Denkphasen" des Projektes. Was hier versäumt wird, muß in den "Arbeitsphasen" Programmierung, Installation und Wartung nachgeholt werden. Sorglosigkeit in der Planung ist verständlich, da die Planer die Arbeit, die sie planen, selten selbst verrichten müssen.

Anders sieht der Projektverlauf aus, wenn in die "Denkphase" mehr investiert wird. Damit ist ein zeitlicher Aufwand verbunden, den man aber in den Arbeitsphasen leicht wieder aufholt.

Je komplizierter und umfangreicher das Projekt wird, desto größer wird die Anzahl der Probleme; aber der Schwierigkeitsgrad der Probleme nimmt durch stufenweises Lösen kontinuierlich ab. Merksatz: Je gründlicher die Entwicklung, desto geringer der Wartungsaufwand.

Zur Detaillierung der Projektphasen und zu den zugehörigen Checklisten verweise ich auf entsprechende Literatur und Seminare (die leider vielfach daran kranken, daß sie zu wissenschaftlich und zu kompliziert sind). Weitsicht in allen Stufen der Projektentwicklung macht sich bezahlt:

- Was wird sich im System voraussichtlich ändern?

- Wie können verlorengegangene Informationen oder Daten wiedergewonnen werden?

- Wer wird die Programmierung, Installation und Wartung übernehmen?

- Sind die mir gelieferten Aussagen, die die Basis für meine Projektarbeit bilden, glaubhaft?

Der Programmierer als Puffer

Der Programmierer ist fast in jedem EDV-Projekt ein Puffer. Auf ihn wird die gesamte Schuld an einem möglichen Scheitern des Projektes abgeladen. Die Planer verlassen sich darauf, daß der Programmierer ihre Fehler erkennt und im Programm abfängt. Den Anwender trifft selten die Schuld an fehlerhaften Ergebnissen, da sein Input - besonders am Bildschirm - nicht dokumentiert wird. So ist der Programmierer dazu verurteilt, Fehler zu suchen, zu bereinigen und auch noch den Schuldigen zu benennen. Meistens ist er es selbst. Woran liegt das?

Programmieren heißt nicht Codieren und fängt nicht mit OPEN INPUT... an. Die Programmierphase teilt sich in folgende Schritte:

- Planung der Programmierarbeiten

- Design des Programmes

- Ablaufplan der Programmlogik

- Codieren

- Erfassen

- Compilieren

- Test vorbereiten

- Schreibtischtest

- Maschinentest

Auch hier gilt: Je mehr in die "Denkphase" investiert wird, desto geringer sind Test- und Wartungsaufwand.

In den Phasen Planung, Design und Ablaufplan werden die Weichen für wartungsfreundliche Programme gestellt. Das Schwergewicht soll hier liegen auf

- funktioneller Gliederung des Programmes,

- Modulbildung

- Einsatz von geeigneten Entwicklungstechniken,

- Schnittstellenbeschreibung der Moduln.

Eines der größten Probleme in der Programmierung stellt die Fehlerabhandlung dar. Oft sehen wir folgende Codierung:

REWRITE Record INVALID KEY

STOP RUN.

Es ist möglich, jeden denkbaren Fehler im Programm abzufangen, doch mit welchem Aufwand! Ich schätze, daß in einem fast absolut sicheren Dialogprogramm die Instruktionen folgendermaßen verteilt wären:

20 Prozent der Instruktionen für den Normalfall; Beispiel: Sollbuchung im Kontenstammsatz

20 Prozent der Instruktionen für den Extremfall; Beispiel: diese Sollbuchung hat den Betrag Null

20 Prozent der Instruktionen für die voraussehbaren Fehler; Beispiel: der Kontenstammsatz fehlt bei dieser Sollbuchung

40 Prozent der Instruktionen für den theoretisch denkbaren Fehler; Beispiel: beim Zurückschreiben des Kontenstammsatzes tritt die Invalid-Key-Bedingung auf.

Hier helfen nur abteilungseigene Richtlinien zur Fehlerbehandlung, allgemeine, einheitliche Richtlinien zur Programmierung und mehr Zeit.

Dokumentation: ungeheuer teuer und selten brauchbar

Man kann Programme nur warten, wenn eine aussagefähige Dokumentation vorhanden ist. Umwandlungslisten reichen hier nicht aus. Voraussetzung für eine gute Dokumentation ist ein Ordnungssystem. Die meisten Ordnungssysteme sind hervorragend ausgeklügelt, werden aber von den Mitarbeitern wenig benutzt, weil der Aufwand zu groß ist. Wenn Arbeitsanweisungen einen dicken Ordner füllen, liest sie kaum einer.

Das Erarbeiten eines guten Dokumentationssystems ist ungeheuer teuer und schwierig, das Einhalten dieses Systems weit mehr. Das ist auch ein Grund, weshalb man so selten auf brauchbare Systeme trifft.

Bei der Entwicklung eines Projektes soll der beste Analytiker Projektleiter der Analyse und der beste Programmierer Projektleiter der Realisierung sein. Ihre Aufgaben bestehen in der Hauptsache darin:

- Aspekte für Wartungsfreundlichkeit zu erkennen,

- Richtlinien für vorbeugende Wartung zu schaffen und

- die Einhaltung der Richtlinien zu kontrollieren.

Für diese Aufgaben muß Zeit kalkuliert, gewährt und ausgenutzt werden.

In der Wartung findet man vielfach Anfangsprogrammierer. Warten, Ändern und Anpassen ist langweilig, mühsam, verlangt Konzentration und ein bißchen Glück. Lob und Dank sind dabei nicht zu ernten. Kein Wunder, daß man diese Arbeit gern dem aufs Auge drückt, der sich nicht wehren kann. Eine höhere Gehaltsstufe reizt hier wahrscheinlich auch den fortgeschrittenen Programmierer. Wartung ist eine Aufgabe für die Besten!

Turnusmäßige Mitarbeiterkonferenz

Patentrezepte zur Wartung von Software gibt es nicht. Den Wartungsaufwand verringert man am besten durch vorbeugende Maßnahmen bei der Software-Entwicklung. Die Erarbeitung eines Katalogs von Maßnahmen kostet Geld und Zeit; beides sollte aufgebracht werden. Für drei wichtige Phasen sind Richtlinien zu erstellen:

- für die Planung des Projektes von den Systemanalytikern,

- für die Realisierung des Projektes von den Programmierern,

- für das Operating von den Operatoren.

Jeweils die Mitarbeiter, die am längsten im Unternehmen mit Erfolg tätig sind, sollen federführend den Maßnahmenkatalog ausarbeiten.

Für regelmäßige Arbeitstagungen über das Jahr verteilt - müssen die Mitarbeiter zur Verfügung stehen. Das Ergebnis - ob mittel, gut oder ausgezeichnet - muß unter voller Verantwortung der Geschäftsleitung als bindend im Unternehmen eingeführt werden. Wer sich nicht zu diesem Entschluß durchringt, schiebt auch dieses Problem wieder stillschweigend vor sich her.

*Volker Elstermann ist freiberuflicher DV-Berater und Ausbilder in 6374 Steinbach.