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.

19.02.1999 - 

Notfall 2000/Daten in der Zeitmaschine

Wie man in Umstellungsprojekten Sicherheit und Zeit gewinnen kann

Von Helmut Wolf In diesem Jahr werden viele Programme älter aussehen, als sie tatsächlich sind: Sie werden künstlich gealtert, um zu prüfen, ob sie nach den Umstellungsarbeiten fit für das Jahr 2000 sind. Bisherige Erfahrungen mit sogenannten "Zeitreisen" zeigen, wie der Testzug schneller fahren kann.

Auf die Frage "Wie viele Fehler können Sie sich bei der Jahr- 2000-Umstellung leisten?" antworten die meisten Unternehmen: "In geschäftskritischen Anwendungen keine." Es verlangt schon einigen Aufwand, dieser Anforderung auch nur annähernd zu entsprechen.

Die Trefferquote bei der Suche nach fehlerhaften Datumsfeldern liegt bei heterogenen Systemen in der Regel unter 95 Prozent. Angesichts der Masse derartiger Stellen blieben mehr Fehlermöglichkeiten unentdeckt, als ein Unternehmen für hinnehmbar halten sollte. Zusätzlich treten weitere Fehler durch die Umstellung auf. Ohne Test ist daher kein Unternehmen sicher, den oder die geschäftskritischen Fehler gefunden und beseitigt zu haben.

In den laufenden Projekten setzen die Tester in der Regel auf zwei unterschiedliche Verfahren. Die erste Vorgehensweise heißt "Zeitraffer". Sie bringt Anwendungssysteme Schritt für Schritt in das Jahr 2000, indem sie die dazu erforderliche Datengrundlage aufbaut.

Dazu bildet man das heutige Unternehmen, in der Regel auf einem separaten Rechner, möglichst produktionsnah nach. Mit Eingaben zu zeitabhängigen Geschäftsprozessen wie Wochen- oder Monatsendverarbeitung erreichen die Systeme das Jahr 2000. Die resultierenden Fehler müßten auf diese Weise sichtbar werden. Diese lassen sich aber nicht flächendeckend finden, weil ohne ein umfassendes Testverfahren Lücken bleiben und die Auswertung durch den Menschen mit Unsicherheiten behaftet ist.

Bei der Alternative "Zeitreise" geht es darum, Anwendungen in Teilen oder komplett auf vorher bestimmte Zeitpunkte in die Zukunft zu schicken. Das Systemdatum wird - soweit möglich - simuliert. Ein automatisierter Vergleich mit den heutigen Ergebnissen - die als korrekt gelten - soll Abweichungen aufdecken, die entweder von nicht entdeckten Datumsfeldern oder Fehlern aus der Umstellung stammen.

Erfahrungen aus über zwanzig Projekten mit Zeitreisen zeigen, daß diese Methode Fehler besser aufzudecken vermag als das Zeitrafferverfahren. Dem Zeitraffer entgingen viele Fehler, im schlimmsten Fall können dies die unternehmenskritischen sein.

Dafür gibt es mehrere Ursachen, in erster Linie die Menge der Datumsfelder und damit verbundenen Fehlerquellen. Ohne vorgegebene Soll-Ergebnisse und automatisierten Vergleich ist kein Mensch in der Lage, alle Ergebnisse in den Systemen mit der erforderlichen Qualität zu prüfen und auszuwerten.

Der Zeitraffer deckt zwar in der Regel Standardfälle ab, aber ohne systematische Testfallermittlung läßt sich für kritische Geschäftsprozesse keine hinreichend präzise Aussage treffen. Schließlich ist im Fall von Fehlern der Aufwand für eine Wiederholung der Überprüfung enorm, da man ganze Systeme wieder zurücksetzen müßte. Wegen des enormen Zeitdrucks ist dies vielerorts gar nicht mehr möglich.

Schon aus diesen Gründen sind Zeitreisen zu priorisieren. Ihre grundlegende Idee ist einfach: Heutige Anwendungssysteme arbeiten aus einer Sicht im Jahr 2000 fehlerfrei. Nach einer Umstellung sollen für jeden beliebigen Zeitpunkt die gleichen Ergebnisse geliefert werden. Zeichnet man Ein- und Ausgabensituationen der gegenwärtigen Systemlandschaft auf (Reference Test), so läßt sich der Programmcode nach seiner Änderung gegen diese Testkonserven testen (Current Date Test).

Damit ist aber noch nicht gewährleistet, daß in der Zukunft keine Fehler auftreten. Dies kann immer dann passieren, wenn eine Anwendung über die Jahr-2000-Grenze in die Zukunft oder zurück in die Vergangenheit rechnet. Zusätzlich sind Möglichkeiten des Datumsmißbrauchs (etwa 9.9.99) und das Schaltjahr (29.2.2000) zu prüfen. In der Regel planen Unternehmen mit fünf bis fünfzehn kritischen Zeitpunkten.

Ohne Automatisierung und Wiederholbarkeit der einzelnen Testläufe läßt sich diese Aufgabe nicht bewältigen, der Einsatz spezieller Werkzeuge ist unverzichtbar. Minimalvoraussetzung ist eine Testprozeßsteuerung, die gewährleistet, daß bei Wiederholungen mit gleichen Ausgangszuständen die gleichen Tests durchgeführt werden. Das heißt, Datenbasis und Eingaben bei Testwiederholungen müssen exakt die gleichen sein, um einen Vergleich durch Werkzeuge zu ermöglichen. Zusätzlich sind "Roboter" wie Capture-/Replay-Tools und Vergleichswerkzeuge erforderlich, die den Arbeitsaufwand und menschliche Fehlerquellen drastisch reduzieren.

Für die einzelnen Testkonserven müssen darüber hinaus sowohl die Datumsfelder in Bestands- und Bewegungsdaten als auch die Systemzeit gleichzeitig und synchron in die Zukunft transferiert werden. Denn zu Schwierigkeiten kommt es immer, wenn "Data-Ager"- Tools nicht oder nur mit großem Aufwand diese Einheit gewährleisten.

Bekommt etwa ein Bankkunde bei Überschreiten eines Kredit- limits im Januar 1999 einen Mahnbrief, so kann bei einem Test der entsprechenden Anwendung im Jahr 2000 eine Sperrung des Kontos erfolgen. Denn mit ei- nem unveränderten Eingabedatum "01/1999" ist das Konto seit über einem Jahr überzogen.

Von besonderer Bedeutung ist die Erfahrung, daß rund fünf Prozent aller Datumsfelder fachlich altern müssen. Das heißt, eine Wochenendverarbeitung am Sonntag, den 1.3.1998, muß für den Test im Jahr 2000 wieder an einem Sonntag laufen. Fälle wie "letzter und erster Werktag der Woche", die Monatsendverarbeitung, Ferien- und Zinskalender sind nur einige jener Verarbeitungsregeln, die Unternehmen sehr unterschiedlich handhaben. Wer diese beiden Voraussetzungen nicht berücksichtigt, erhält bei einem automatisierten Vergleich eine derart hohe Anzahl von Fehlermeldungen, daß solch ein Verfahren allein aus zeitlichen Gründen nicht mehr durchführbar ist.

Zeit und Geld sparen Projekte auch dann, wenn sich Analyse- ergebnisse aus frühen Schritten in ein Zeitreise-Tool übernehmen lassen. Denn Tausende von Datumsfeldern kann man nicht noch einmal von Hand eingeben. Von großem Nutzen sind hier elektronische Überleitungen, wenn die Daten für Tests aus Informationsquellen wie Repositories oder aus Tools des Konfigurations-Managements kommen. Natürlich sind solche Werkzeuge von Vorteil, die sich auf den verschiedenen Plattformen eines Unternehmens einheitlich einsetzen lassen.

Laufende Jahr-2000-Tests bestätigen, daß nur das Zeitreise- verfahren die nötige Qualität für unternehmenskritische Anwendungen aufweist. In mehr als 50 Prozent der Umstellungspake- te fanden sich noch Fehler, und diese wären bei der Zeitraffermethode zum Teil gar nicht oder nur zufällig aufgefallen. So bekamen zum Beispiel bei einem Einzelhandelsunternehmen einige aktive Märkte im Jahr 2000 das Kennzeichen ,0'', das bedeutet: keine Warenanlieferung. Dieses Kennzeichen bekommen sonst nur Märkte, die gerade neu aufgebaut werden.

Die Anzahl von spät entdeckten Fehlern ist auch dann nicht geringer, wenn man für Analyse und Umstellung systematisch Werkzeuge eingesetzt hat. Diese Fehler betreffen sogar Anwendungen, die eigentlich keine Probleme aufwerfen dürften, weil sie zum Beispiel mit vierstelliger Jahreszahl und in jüngster Vergangenheit programmiert wurden.

Wer sich keine Gedanken über die Zahl seiner DV-Fachleute, die Organisationsstruktur und Abläufe macht und Testaktivitä- ten zu spät oder ohne den erforderlichen Erfahrungshintergrund startet, muß fast zwangsläufig mit höherem Aufwand rechnen. Deshalb empfehlen sich für das Testing Pilotprojekte mit einer Dauer von vier bis sechs Wochen, die den gesamten Ablauf der Prüfungen dem Profil des Unternehmens anpassen (Proof-of-concept).

Der letzte Startpunkt zum Testen kritischer Projekte ist dabei der 1. Oktober 1999. Dies ist möglich, da solche Piloten nicht nur simulieren, sondern schon fertig getestet sind und die Erfahrungen direkt einfließen können.

Ist die Menge der zu bewältigenden Arbeit zu hoch, hilft eine Priorisierung der Geschäftsprozesse und Anwendungen. Zeitreisen mit systematischer Testfallermittlung werden hier nur in kritischen Bereichen durchgeführt. Danach wird, je nach Abstufung, der Testaufwand reduziert, und unkritische Systeme werden teilweise gar nicht getestet. Die Deutsche Bahn AG zum Beispiel hat auf diese Weise innerhalb eines Jahres über 250 Anwendungsgebiete einem Abnahmetest unterzogen.

Wenige Monate vor dem spannendsten Silvester seit langem ist keine Zeit mehr für Experimente. Die laufenden Jahr-2000-Projekte und ihre Erfahrungen mit Daten-Zeitreisen bieten eine gute Basis für den Test der umgestellten Systeme.

Vorsicht bei Zeitreisen!

IBMs Jahr-2000-Spezialist Bernd Dötsch erwähnt in seinem Beitrag (siehe Seite 56), daß bei testweisen Zeitverschiebungen auch fundamentale Termine für das System überschritten werden. Ihm zufolge ist es "häufig" vorgekommen, daß Anwender den Ablauf des Systempaßworts übersahen. Fatal.

In einer E-Mail an die COMPUTERWOCHE beurteilt Rolf Hansmann, I/S- Information-Manager der HMR AG, Frankfurt, Zeitreisen als "sehr gefährlich". Er erwähnt neben Paßwörtern "regelmäßige Abfragen, DHCP (Dynamic Host Configuration Protocol) mit TTL-Zeiten (Time to live) etc.", die "eine ganze Menge negativer Zeitwerte, mit denen ein System sonst nie konfrontiert wird", zur Folge haben. Seine Einschätzung: "Die Zeitreise zerstört mehr als das Y2K-Ereignis."

Wann kracht''s?

Unabhängig davon, ob die Systeme zum Jahresende fachlich akzeptabel umgestellt sind, ist mit vielen Programmabbrüchen zu rechnen. So werden 90 Prozent aller möglichen Fehler fünf Tage vor und nach dem 1. Januar 2000 auftreten. Ein Unternehmen mit 15 Millionen Lines of Code, von denen drei Prozent Datumsangaben haben, muß statistisch mit etwa 10000 unentdeckten Fehlern rechnen, von denen jeder einzelne einen Absturz zur Folge haben kann. Demgegenüber steht die Zahl von zehn bis 15 Abbrüchen, die das Unternehmen in diesen zehn Tagen mit der bestehenden Organisation maximal bearbeiten kann.

Angeklickt

Es gibt keine Anhaltspunkte für den Erfolg einer Jahreszahlen- Umstellung ohne eine Überprüfung, wie sich das modifizierte System zu verschiedenen Terminen im Jahr 2000 und danach verhalten würde. Solche Simulationsverfahren heißen Zeitraffer und Zeitreise. Der Autor stellt beide Testverfahren vor und bewertet sie - auch unter dem immer wichtiger werdenden Aspekt knapper Zeit. Außerdem spricht er Voraussetzungen für eine weitere Beschleunigung der Überprüfungen an.

Helmut Wolf ist Vertriebsleiter Tools bei der SQS Gesellschaft für Software-Qualitätssicherung mbH in Köln.