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.06.1998 - 

Problem 2000/In Umstellungsprojekten Prioritäten setzen

Integration der Fachbereiche macht Jahr-2000-Tests wirtschaftlicher

Der 1. Januar 2000 rückt näher, und gleichzeitzig steigt die Zahl der Anbieter von Werkzeugen, die einfache und schnelle Lösungen von außen versprechen: Jede Woche kommen neue Allround-Werkzeuge auf den Markt. Doch auch bei Projekten in Zeitnot gilt: Das wichtigste Know-how des Unternehmens, die fachliche Kompetenz, kann nicht von außen kommen.

Dieses interne Fachwissen ist es, auf das es beim Testen der umgestellten Systeme ankommt. Geprüft wird nämlich in erster Linie nicht, ob die Schnittstelle zwischen zwei Systemkomponenten softwaretechnisch ideal konfiguriert ist, sondern ob etwa eine Überweisung termingerecht erfolgt.

Deshalb empfiehlt es sich, daß der Auftraggeber selbst die Projektverantwortung trägt und nicht an einen der beteiligten Externen - Tool-Lieferanten, Softwarehaus, Berater oder Outsourcer - abgibt. Er kennt die fachlichen Anforderungen an sein System am besten und kann die notwendigen Schritte am schnellsten vorantreiben.

Was muß getestet werden?

Hinzu kommt, daß die verbleibenden anderthalb Jahre in den meisten Unternehmen nicht mehr ausreichen, um alle Funktionen komplett durchzutesten. Wer jetzt noch mehr als 10000 Programme umzustellen und durchzutesten hat, stößt schlicht an Grenzen. Ein Projekt von dieser Größenordnung ist nur noch durchführbar, wenn außergewöhnlich hohe Ressourcen bereitstehen.

Wer heute noch ausschließlich mit der Umstellung beschäftigt ist oder gar den Startschuß für sein Jahr-2000-Projekt noch nicht gegeben hat, muß deshalb entscheiden: Welche Anwendungen sind unternehmenskritisch, welche nicht? Diese Fragen können nur die Fachbereiche beantworten.

Ein geeignetes Verfahren ist zum Beispiel eine ABC-Analyse. (In der US-Literatur findet sich analog der Begriff "Triage" aus dem Rettungswesen. Danach kümmern sich Sanitäter und Ärzte zuerst um die Opfer, die nur mit ihrer Hilfe eine Überlebenschance haben. Siehe auch CW 17/98, Seite 60)

Nach dieser Vorgehensweise werden drei im Detail weiter differenzierbare Dringlichkeitsstufen einer Umstellung eingeführt. Mit ihrer Hilfe legen die Fach- experten, die Umsteller und die Tester so früh wie möglich fest, welche Prozesse im Unternehmen von vorrangiger Bedeutung sind und ohne DV-Unterstützung nicht auskommen. Anhand des Ergebnisses kann die Projektleitung entscheiden, an welchen Stellen die vorhandenen Ressourcen den größten Nutzen bringen.

Das kann für einen Finanzdienstleister heißen, daß er für einzelne nur intern relevante Teile seiner IT keine Testfallermittlung betreibt, um sich auf Anwendungen mit Außenwirkung zu konzentrieren. Denn wenn zum Beispiel aufgrund eines Jahr-2000-Fehlers fällige Lebensversicherungsverträge nicht ausgezahlt werden können, ist dies für das Unternehmen verheerend.

Der eigentliche Jahr-2000-Test ist der Future Date Test. Die Umstellung, gefolgt von Referenz- und Current Date Test, sind nur Vorbereitungen für diese abschließende Überprüfung, während der die Daten auf eine Zeitreise geschickt werden, um zu prüfen, ob die umgestellten Anwendungen auch wirklich mit dem neuen Datum zurechtkommen (siehe untenstehenden Kasten). Insbesondere für unternehmenskritische Anwendungen wird der Future Date Test zu einem Muß, wenn nicht das Prinzip Hoffnung herrschen soll.

Tests untereinander verzahnen

Das höchste Tempo erreicht ein Jahr-2000-Projekt sicherlich dann, wenn die einzelnen Schritte von Anfang an miteinander verzahnt sind. Verzahnung macht dann Sinn, wenn die Umstellung noch nicht vollständig abgeschlossen ist. Nur so können die Ergebnisse aus Testfallermittlung und Umstellung direkt in die Überprüfungen einfließen. Verantwortlich dafür ist das Projekt-Management.

Dabei führt zum Beispiel nicht nur der Umsteller zusammen mit den Know-how-Trägern aus den Fachbereichen eine Analyse der DV-Systeme durch. Zusätzlich ist möglichst schon in diesem Stadium der spätere Tester dabei, der darauf achtet, daß seine Anforderungen ebenfalls einfließen. Das erspart ein zweifaches Audit zwischen Fachbereich und Umstellern sowie zwischen Fachbereich und Testern.

Die DV-Experten müssen hier dafür sorgen, daß die Umstellungspakete so geschnürt werden, daß sie nahtlos in den Future Date Test übergehen können. So kann bei zentralen Modulen auch eine Call-Schnittstelle zwischen zwei Paketen existieren. Wenn ein Aufruf eines Moduls - etwa das Übertragen des Datums in die Datenbank - nicht entsprechend umgestellt ist, ein anderes Paket diese Funktion jedoch benötigt, muß der Future Date Test so lange warten, bis auch diese Umstellung komplett ist.

Rolle der Tools oft überschätzt

Deshalb müssen die Umstellungspakete von Anfang an so definiert und abgegrenzt sein, daß der Future Date Test schon frühzeitig greifen kann. Er liefert dem Umsteller die Informationen, ob sein Paket "sauber" ist und er das nächste Anwendungspaket angehen kann.

Die Rolle der Werkzeuge bei der Jahr-2000-Umstellung wird oft überschätzt. Selbstverständlich gehören sie zur Grundausstattung einer Modifikation. Aber sie sollten sich auch an folgenden Fragen hinsichtlich ihrer Eignung für die Checks messen lassen:

- Unterstützt ein Tool mehr die Entwickler oder den Fachbereich, der die Abnahme durchführt?

- Wie groß ist die Unterstützung bei der Planung und beim Test-Management?

- Berücksichtigt das Werkzeug die Konfiguration der Testumgebung?

- Inwieweit trägt es dazu bei, die Testausführung zu automatisieren?

Vorhandene Tools integrieren

Nicht weniger wichtig ist es, wie sich die Werkzeuge einbinden lassen: Denn das Ziel sollte es sein, ein weitgehend automatisiertes Testsystem aufzubauen, das eine heterogene Systemlandschaft abdecken kann und damit über das Jahr-2000-Projekt hinaus von Nutzen ist. Sei es für die Euro-Umstellung oder andere Projekte. Anstatt sich eine Vielzahl von neuen Tools anzuschaffen, ist es daher oft sinnvoller, die bereits vorhandenen mit dem Ziel der Automatisierung in das neue Testsystem zu integrieren.

Auch wenn die Zeit inzwischen knapp ist, bleibt die Durchführung eines Pilotprojekts ein wichtiger Erfolgsfaktor für die Jahr-2000-Aufgabe. Die Entscheidung zum Beispiel über die Verteilung und den Einsatz der Mitarbeiter fällt damit leichter. Wer einmal festgestellt hat, welche Prozesse ordentlich und - noch wichtiger - nicht wie vorgesehen laufen, kann große Überraschungen im laufenden Projekt vermeiden.

Die SQS Gesellschaft für Software-Qualitätssicherung mbH in Köln hat erfahren, wie Standardisierung Zeit spart. Waren es anfangs 20 bis 40 Manntage, so stellt das Unternehmen ein Basistestsystem heute innerhalb von acht bis zehn Tagen auf die Beine. Was vor allem durch Standardisierung und Parametrisierung der Testprozeduren sowie durch die Flexibilität der eingesetzten Tools gelang.

Externe Hilfe kann bei solchen Aufgaben sehr nützlich sein, da viele Beratungshäuser heute über umfangreiche Erfahrungen in Jahr-2000-Projekten verfügen. Entscheidend bleiben aber die Entscheidungs- und Know-how-Träger in der eigenen Firma. Vor allem wenn die Zeit für Umstellung und Testen knapp wird, können nur sie den DV-Experten mitteilen, welche Anwendungen auch im neuen Jahrtausend über Wohl und Wehe des Unternehmens entscheiden und daher auf Herz und Nieren zu prüfen sind.

Test-Prozeduren

Der Referenztest erzeugt auf Basis des nicht umgestellten Systems ein Soll-Ergebnis, das als Vergleichsbasis dient. Mit ihm werden die Testergebnisse der umgestellten Programme aus Current Date Test oder Future Date Test abgeglichen.

Der Current Date Test überprüft die umgestellten Programme im Rahmen des heutigen Betriebs unter den gleichen Datumsbedingungen wie im zugehörigen Referenztest.

Der Future Date Test ist der eigentliche Jahr-2000-Test. Mit ihm wird der Testbestand von heute mit den erwarteten Soll-Ergebnissen in einer simulierten Zukunft auf Korrektheit überprüft. Die Daten werden auf Zeitreise geschickt und zum Beispiel mit dem Ausführungsdatum 3. Januar 2000 getestet.

Angeklickt

Die Zeit bis zum 1. Januar 2000 wird knapp, gleichzeitig stellen viele Unternehmen fest, daß sie den Aufwand für das Testen der umgestellten Software unterschätzt haben. Auch bei Zeitnot bleiben, so analysiert der Autor, die grundsätzlichen Regeln für Jahr-2000-Projekte gültig. Wirtschaftlich arbeitet, wer die Fachbereiche konsequent in ein Boot mit Umstellern und Testern holt, wer zunächst ein Pilotprojekt fährt, ein automatisiertes Testsystem aufbaut und - soweit noch möglich - Umstellung und Test gemeinsam plant und verzahnt. Daneben stellt der Autor die verschiedenen Stufen des Jahr-2000-Tests vor.

* Dr. Martin Wieczorek ist leitender Berater für Softwarequalitäts-Management bei der SQS Gesellschaft für Software-Qualitätssicherung mbH in Köln.

Abb: Wenige zentrale Faktoren entscheiden über die Wirtschaftlichkeit von Jahr-2000-Projekten. Quelle: CW