Zum täglichen Brot der DV-Mannschaften gehören nach wie vor Programmausfälle, unvorhersehbar beendete Jobs sowie falsche Ergebnisse. Tests helfen, Software-Macken zu lokalisieren und zu beseitigen. Hans-Peter Niederhausen, Hauptabteilungsleiter bei der Fried. Krupp GmbH in Essen, ist jedoch davon überzeugt, daß die herkömmlichen Test-Methoden inzwischen weitgehend an die Grenzen ihrer Leistungsfähigkeit stoßen. "Es ist unbedingt notwendig", so Niederhausen, "alle Kräfte darauf zu konzentrieren, die Testverfahren zukünftig effektiver zu gestalten". Einen Ansatz sieht der Krupp-Manager darin, durchgängig alle erkannten Fehler statistisch zu erfassen und dadurch Schlüsse auf die Fehlerursache zu ziehen. Diese Vorgehensweise ermögliche es, gezielter zu testen. ih

Dieter Haase

Systemberater, Apollo GmbH, EDV- und Unternehmensberatung, Neuss

Die Datenverarbeitung ohne Probleme und Fehler ist sicherlich nur ein Wunschtraum. Ausfälle, abnormal beendete Jobs und falsche Ergebnisse sind das tägliche Brot einer DV-Mannschaft. Das Ziel sollte sein, die negativen Auswirkungen der Fehler auf den Servicegrad und die Produktivität durch Ausschalten von Fehlerquellen zu verbessern. Hierfür gibt es bis heute jedoch noch kein Patentrezept. Deshalb muß als erstes versucht werden, durch vorbeugende Aktivitäten und Maßnahmen die Fehlerquellen auszuschalten, zum anderen sind die auftretenden Fehler so zu behandeln, daß durch die Problemlösungen keine neuen Fehler erzeugt werden.

Insgesamt besteht ein großes Netz von Verknüpfungen und Abhängigkeiten zwischen

Jobs, Programmen, Prozeduren, Dateien, Listen und Steuerkarten. Hinzu kommen noch die Änderungen und Erweiterungen, welche bei der täglichen Arbeit anfallen und mehr oder minder das Bild dieses großen Netzes verändern. Heute wird immer noch versucht, durch ungesteuerte Improvisationen den Betrieb am Laufen zu halten, und eben dieser Ausweg führt zu den Fehlern, die im Vorfeld der DV-Planung ausgeschaltet werden können. Um also einen RZ-Betrieb möglichst fehlerfrei zu halten, muß bereits bei der Planung bedacht werden, wie die Arbeiten organisiert und durchgeführt werden sollen. Daraus ergibt sich die Forderung, die RZ-Abläufe zu dokumentieren, und zwar so, daß ausreichend Transparenz, Sicherheit und Übersicht in den Rechenzentrumsbetrieb gebracht wird. Als Basis für diese Dokumentation kann nur das aktuelle Job-Control dienen, welches allein die Abläufe im Rechenzentrum genau aufzeigt.

Dies kann eine manuelle Dokumentation nicht mehr bewältigen, und anfallende Fragen können bei manueller Dokumentation nicht sicher und schnell genug beantwortet werden. Denkt man weiter an die Aktualität dieser Dokumentation, bedarf es eben einer Softwarelösung, welche die Job-Control-Bibliothek und die Dokumentationen immer auf dem gleichen Stand hält. Alle RZ-Abläufe werden außerdem auf dieselbe Art und Weise dokumentiert. Bei auftretenden Fehlern kann jeder autorisierte Mitarbeiter mit Hilfe der aktuellen Dokumentation sofort den Arbeitsablauf analysieren und den Fehler lokalisieren. Es muß nicht mehr in allen Fällen auf die zuständigen RZ-Planer oder Programmierer zurückgegriffen werden, welche eben gerade dann nicht anwesend sind, wenn sie für so einen Fall gebraucht würden. Vielmehr können umgehend die erforderlichen Maßnahmen getroffen werden, um die Fehler zu beseitigen beziehungsweise Backup- oder Bypass-Funktionen zu aktivieren, wenn eine gründliche Fehleranalyse durch einen Programmierer erforderlich sein sollte. Ausfälle und Wiederholungsläufe können auf ein erträgliches Maß reduziert werden.

Ausschließen lassen sich Fehler jedoch nicht, bedenkt man nur die laufenden Veränderungen, welche den Ansprüchen an einen hohen Servicegrad entgegenstehen. Die Bewältigung der daraus auftretenden Probleme erfordern entsprechende Methoden und Verfahren, vor allem wenn man anschaut, wie heute Fehler beseitigt und Probleme verarbeitet werden: zum Beispiel falsche Eingabedaten oder eine fehlende Bedingung beziehungsweise Abfrage in einem Anwendungsprogramm, wodurch ein Job abnormal endet. Häufig werden bei solchen Fällen eben die Eingabedaten entsprechend manipuliert, damit der Ablauf sofort neu aufgesetzt und weitergefahren werden kann. Damit ist die aktuelle Störung zwar beseitigt, aber dieser Fehler tritt mit 100prozentiger Sicherheit später wieder auf. In diesem Zusammenhang gewinnen die heute schon umlaufenden Begriffe wie "Problem-Management" zur Beseitigung und Reduzierung von Störungen und "Änderungs-Management" zur Integration laufender Veränderungen einschließlich der Fehlerbeseitigung immer mehr an Bedeutung.

Durch Einführung der vorgestellten Methoden lassen sich Überraschungselemente im Rechenzentrumsbetrieb zu einem gewissen Teil ausschalten. Sie verhindern, daß durch Änderungen Fehler erzeugt und durch Probleme Krisen erzeugt werden. Das Einsetzen dieser Methoden kann die Zufriedenheit der Benutzer erhöhen.

Hans-Peter Niederhausen

Hauptabteilungsleiter Betriebswirtschaft, Fried. Krupp GmbH, Krupp Gemeinschaftsbetriebe,

Essen

Der Anteil der Kosten für die Software an den gesamten Datenverarbeitungskosten ist in der Vergangenheit stetig gestiegen. Die Kosten für das Testen von Programmen liegen im Entwicklungsprozeß schon über 40 Prozent der Entwicklungskosten und in der Nutzungsphase noch weit darüber. Obgleich allgemein bekannt ist, daß rund zwei Drittel der Kosten für Software in der Nutzungsphase anfallen, werden aus dieser Tatsache selten die notwendigen Konsequenzen gezogen. Dabei wird dieser Kostenblock immer dann offenkundig, wenn man sich vor Augen führt, wie viele Organisatoren und Programmierer mit der Pflege bestehender Programme beschäftigt sind, und wie wenige zur Neuentwicklung von Programmsystemen zur Verfügung stehen.

Die bekannten Verfahren des Software-Engineering zielen in erster Linie alle darauf ab, den Software-Entwicklungs-Prozeß zu optimieren. Die Testphase, die vor Eintritt in die Nutzungsphase notwendigerweise zu allen Software-Engineering-Verfahren gehört, ist dabei durchgängig methodisch am schlechtesten ausgebildet. Wie ein hochparameteriertes Standardprogramm mit über 100 Installationen nach einer umfangreichen Änderung zu testen ist, darüber geben die einschlägigen Verfahren keine Auskunft.

Testen in der althergebrachten Form ist weitgehend an die Grenzen seiner Leistungsfähigkeit gestoßen.

Es ist unbedingt notwendig, alle Kräfte darauf zu konzentrieren, daß Testverfahren effektiver werden. Ein Ansatz hierzu ist es, durchgängig alle erkannten Fehler statistisch zu erfassen. Anhand dieser Statistiken sind Schlüsse auf die Fehlerursachen zu ziehen. Aufgrund typischer Fehlerprofile ist es möglich, gezielter und damit erheblich kostengünstiger zu testen. Erste Ansätze hierzu sind jedenfalls sehr ermutigend.

Hans Günther Rockel

Leiter DV/Org., Firma Hanns Balzer, Lauterbach

Man erlaube mir eingangs die ketzerische Frage: "Fehler - was ist das?"

Die Frage ist aus gutem Grund angebracht, denn Fehler in der Anwendungssoftware halten sich in unserem Hause sehr in Grenzen. Unkontrollierte Programmabbrüche und auch versteckte Fehler sind keinesfalls an der Tagesordnung. Datenrekonstruktionen und umfangreiche Wiederholungsläufe haben zwar in der Vergangenheit bei uns des öfteren den Arbeitstag verlängert, sind aber mittlerweile als "Schnee von gestern" zu betrachten. Wodurch haben wir diesen hohen Sicherheitsgrad unserer Anwendungen erreicht?

Die Ursachen für Programmfehler liegen doch in der Regel in mangelhaften Programmen und / oder in unkorrekt geführten Datenbeständen. Um beides zu verhindern, treffen wir seit Jahren entsprechende Vorkehrungen.

Was die Programmentwicklung betrifft, so gehen wir sehr schulmäßig vor. Keinesfalls wird aufs "Blaue" hinaus programmiert, sondern jeder Programmentwicklung gehen die

nötigen organisatorischen Schritte voraus. Der Programmierer arbeitet äußerst gewissenhaft, deckt bei seinen Überlegungen alle nötigen Randprobleme ab und kalkuliert immer Fehlereinwirkungen von außen ein. Ist ein Programm erstellt und lauffähig, schließt sich eine sehr intensive Testphase an, wo das Programm so richtig auf "Herz und Nieren" geprüft wird. (Für Tests haben wir speziell für diesen Zweck vorbereitete Testdaten zur Verfügung.) Hat das Programm diese Stufe der Entwicklung durchlaufen, so erfolgt eine nochmalige visuelle Überprüfung durch einen zweiten Programmierer. Daran anschließend wird die Implementierung vorgenommen, wobei der erste und gegebenenfalls auch der zweite Lauf unter Kontrolle des Programmierers stehen. Erst danach bekommt der Job "freien Lauf".

Die zweite Komponente für den sicheren Programmlauf sind DV-technisch 100prozentig geführte Datenbestände. Das bedeutet, daß alle gespeicherten Informationen von den Übernahme- beziehungsweise Dateipflegeprogrammen sowohl auf Syntax als auch auf alle erdenkbaren Plausibilitäten überprüft werden. Nur "saubere Daten" werden übernommen.

Was ist aber zu tun, wenn wider Erwarten trotzdem ein Fehler auftritt?

Zunächst versucht der Programmierer, durch eventuell vorliegende Systemangaben über Linker und Compilerliste den Fehler zu lokalisieren. Gelingt ihm das nicht, so steht ihm aus dem Softwareprodukt "Programm-Checkout-Facility" eine Anzahl Kommandos für die Fehleranalyse zur Verfügung.

"Debug, Dump, Trace" sind nur einige und für jeden EDV-Profi ein Begriff. Alles in allem beinhaltet "PCF" an die 20 Kommandos, die sich der Programmierer für die Fehleranalyse nutzbar machen kann.

Fazit: Auf Softwarewerkzeuge für eine Fehlerlokalisierung ist gut verzichtbar, wenn bei der Programmentwicklung auf höchstmögliche Qualität geachtet wird.