Jahrtausendwechsel Was Manager über Y2000-Projekte wissen sollten oder wieviele Wege führen nach Rom Gerd NicklischUwe SchüttDie Zeit verrinnt unaufhaltsam. Ein Phantom schleicht durch die IT-Welt. Der Jahrtausendwechsel kommt und damit nähert sich ein kritisches Datum. Es ist zwar nicht der vielbeschworene Weltuntergang, hat aber etwas mit den magischen Nullen zu tun. Tatsächlich sieht sich die gesamte IT-Welt mit einer enormen Herausforderung konfrontiert, die mathematisch zwar sehr leicht erklärbar und auch lösbar ist, aber erhebliche Aufwände zeitlicher und monetärer Art fordert. Auch die Risiken für die betroffenen Unternehmen sind nicht zu unterschätzen. Sowohl betriebswirtschaftliche Anwendungen, Systemsoftware als auch PCs sind betroffen. Jedes Unternehmen, gleich welcher Größe, muß reagieren. In der Tat steht die gesamte IT-Welt vor einem Problem; und das Schlimmste: Diese Projekte haben eine absolut fixen Endtermin, der sich auf keinen Fall verschieben läßt. Die Vorgehensweise In der Vorphase eines Projektes zum Jahrtausendwechsel müssen neben den allgemein üblichen Fragen bereits einige wichtige Punkte beantwortet werden: Welche Personalressourcen stehen zur Verfügung, bzw. müssen zur Verfügung gestellt werden? Wird das Projekt zentral realisiert oder nur zentral koordiniert? Wie sieht das Beziehungsgeflecht der Anwendungen untereinander aus? Welche Sourcen erzeugen welche Load-Module? Wieviel Lines of Code gibt es? Welche Hardwareressourcen (CPU, Mainframe, Client/Server, PC, Plattenspeicher) müssen berücksichtigt werden? Wieviel Plattenspeicher wird für Anwendungs- und Systemtest benötigt? Wie sieht das Procedere für einen Systemtest aus? Wie wird ein Systemtest über verschiedene Unternehmensbereiche hinaus gestaltet? Sind Client/Server und oder PC-Programme oder -Anwendungen betroffen? Was passiert mit Programmen, die sowohl alte als auch neue Datumsformate benötigen? Wie wird bei Weiterentwicklungen / Änderungen sichergestellt, daß nicht neue Fehler bereits bereinigte Programme wieder "verschmutzen". etc. Dies sind nur einige wenige Fragen, die verdeutlichen sollen, wie wichtig eine genaue Analysephase für das gesamte Projekt ist. Die "klassische" Projektvorgehensweise Ein Projekt zum Jahrtausendwechsel läßt sich generell in drei grobe Phasen untergliedern: Projektdefinition / Analyse Modifikation ASI-Test Anwendungs-, System- und Integrationstest), Implementierung, Dokumentation Alleine die Analysephase nimmt ein Drittel des Gesamtaufwandes ein. Der größte Anteil sollte allerdings für den ASI-Test eingeplant werden, da insbesondere der Integrations- und Implementierungstest Ausmaße annimmt, wie sie vorher nur in den seltensten Fällen durchgeführt wurden. Projektdefinition und Analyse Diese Phase beinhaltet den Projektbeginn (Bereitstellung aller Ressourcen) und die Analyse der durchzuführenden Aufgaben. Eine genaue Analyse der Programme auf Vollständigkeit (existieren noch alle Sourcen zu den Load-Module) und Nutzungsverhalten (welche Programme oder Applikationen) werden wann, wo wem und wie oft genutzt) geben Auskunft darüber, welche Programme überhaupt auf Datumsfelder untersucht werden müssen. Auch lassen sich mit diesen Analyseergebnissen Prioritäten für das Projekt festlegen und der Projektumfang kann genauer definiert werden. Der gezielte Einsatz von Software-Tools kann zu erheblichen Reduzierungen des Gesamtaufwandes führen, da dann wirklich nur solche Applikationen konvertiert werden, die auch entsprechend im Einsatz sind. Die Applikationen müssen anschließend auf das Vorhandensein von Datumsfeldern bzw. Datumsaufrufen analysiert werden. Auch hier ist der Einsatz von Tools zur maschinellen Untersuchung sinnvoll. Als wesentliche Erkenntnis aus vergleichbaren Projekt- aufgaben ist zu bewerten, daß eine vollautomatisierte Konvertierung von Programmen nicht oder nur zum Teil möglich ist, da solche Konvertierungstools, die selbständig den Source-Code verändern, nur eingeschränkt einsetzbar sind. Solange nicht hundertprozentig gewährleistet ist, daß alle Programme nach einheitlichen Konventionen und Regeln realisiert wurden, kann kein Tool die richtige Umstellung zu 100% garantieren. Es sei denn, daß alle Regeln/Konventionen, die verwendet werden vorher mit Parametern bzw. Programmsteuerungen eingestellt werden können. Diese komplexe Aufgabenstellung wird jedoch nur von wenigen Tools teilweise unterstützt. Eine Eigenart von Entwicklern war und ist die Verewigung von persönlichen Wiedererkennungsmerkmalen in den Programmen. Hierzu zählt auch in einigen Fällen die eigenwillige Bezeichnung von Datumsfeldern mit eigenen Begriffen (z.B. Vornamen, Phantasiebegriffe u. v. m.). Ein Analyseprogramm kann in diesen Fällen beispielsweise diese Datumsfelder nicht identifizieren und interpretieren. Kurzum, auch manuelle Prüfungen sind nicht durch noch so raffinierte Programme vollständig auszuschließen. Konvertierungsphase Die reine Konvertierungsphase, sprich das Realisieren der Modifikationen an Programmen, Datenbanksystemen, Prozeduren und Job Control nimmt als Fleißaufgabe mit 20% des Gesamtaufwands relativ wenig Zeit und Kosten in Anspruch. Es werden Tools angeboten, die nicht nur Datumsfelder erkennen, sondern auch automatisch konvertieren. Nach bisherigen Erfahrungen sollte man die Ergebnisse aber sehr kritisch betrachten, da eine automatische Konvertierung bei der Komplexität auch lückenhaft sein kann; ohne die Leistungsfähigkeit solcher Konvertierungsprogramme in Frage stellen zu wollen. Eine manuelle Nachkontrolle sollte auf jeden Fall erfolgen, um frühzeitig Konvertierungslücken festzustellen. Normalerweise findet ein Konvertierungsprogramm natürlich nur solche Datumsfelder, die den "normalen" Namenskonventionen entsprechen, bzw. Standardaufrufe des jeweiligen Compilers für das Datum oder die Zeit benutzen. Ein weiteres Problem ergibt sich aus den laufenden Änderungen der Programme während und nach der Analyse/Umstellungs- und Testphase. Anweisungen über Standardkonventionen bilden die Voraussetzung, daß sich "alte Fehler" nicht wieder einschleichen. Sicher kann die jedoch nur mit einem exakten Testkonzept und Produktionsübergabeverfahren kontrolliert werden. Nur so kann eine erneute "Verschmutzung" der Programme vermieden werden. Testphase Mit ca. 50% des Gesamtaufwands nimmt die Testphase den größten Teil ein. Alleine die reine Testphase umfaßt die Bereiche: Anwendungstest Systemtest Integrationstest Für die Testphase ist ebenfalls der Einsatz von Tools sinnvoll, die in der Lage sind, Daten und Zeiten entweder für bestimmte oder für alle Programme, Applikationen und Jobs vorzugeben, die bereits in der Zukunft liegen. Vorteilhaft sind solche Tools, die mit einem virtuellen Datum arbeiten, da dann bereits heute schon das Jahr 2000 simuliert werden kann, ohne eine komplette Testumgebung vorhalten zu müssen. Darüber hinaus beinhaltet diese Phase die Implementierung und die gesamte Dokumentation der durchgeführten Modifikationen. Die iterative Projektvorgehensweise Eines hat sich beim Lesen von Artikeln und bei Gesprächen mit Anwendern und Anbietern von Service- und Produktleistungen deutlich gezeigt. Es ist absolut illusorisch zu denken, daß insbesondere die Konvertierungsphase sich mit geeigneten Tools automatisch und ohne manuellen Aufwand lösen läßt. Viele Anbieter versuchen dies zu suggerieren, aber selbst wenn ein Scannerprogramm 98 Prozent aller Datumsfelder findet (ob und mit welchem Aufwand für die Definition des Regelwerkes diese überhaupt bewerkstelligt werden kann, sei einmal dahingestellt), bleiben zwei Prozent nicht gefundener Datumsfelder oder Routinen übrig, die wiederum aber zu einem Abbruch der Programme führen können. Hat man alle Datumsfelder und Routinen gefunden, muß entschieden werden, ob man eine Programmfunktion oder die Datenbasis ändern will. Eine funktionale Änderung des Programms hat den großen Vorteil, daß sich diese Änderung auf genau diese Programm beschränkt und keine Auswirkungen auf Folgeprogramme hat. Eine Änderung der Datenbasis hat zur Folge, daß eventuell auch alle Folgeprogramme geändert werden müssen; unter Umständen auch Programme aus ganz anderen Funktionsblöcken. Eine automatische Konvertierung kann also ohne manuellen Aufwand nicht funktionieren. Neben der "klassischen" Vorgehensweise bietet sich die iterative Vorgehensweise an, die sich in folgende Schritte gliedert: Gliederung in Untersuchungsbereiche bzw. Funktionsblöcke Bearbeitungszyklus je Untersuchungsbereich bzw. Funktionsblock Ablauf testen Fehler analysieren Programme oder Datenbasis ändern Ablauf erneut testen Gesamtabnahme-Test Gliederung in Untersuchungsbereiche bzw. Funktionsblöcke Diese auf den ersten Blick einfache Aufgabe kann sich als komplexer herausstellen, als man zunächst glaubt. Jede Anwendungsentwicklungsabteilung hat feste Zuständigkeiten, so daß eine rste Gliederung naheliegend ist. Aber sind diese meist gewachsenen Zuordnungen noch sinnvoll? Gibt es nicht vielleicht Überschneidungen zwischen diesen Abteilungen, die einen durchgängigen Test erschweren könnten? Müssen überhaupt alle Programme untersucht werden? Gibt es eventuell Applikationen, die nicht in einen zuvor definierten Bereich zugeordnet wurden, weil es sich um bereichsübergreifende Applikationen handelt? Und selbst wenn die sachliche Zuordnung klar geregelt ist, weiß jeder Verantwortliche welche Programme namentlich in seinen Zuständigkeitsbereich fallen? Erfahrungen zeigen, daß der Grad der Organisation der Bibliotheken im Bereich Anwendungsentwicklung je nach Installation sehr unterschiedlich ist. Einige Anwender haben sehr akribische Verfahren für die Freigabe von Programmen in die Produktion und wissen von jedem Programm ganz genau, wo der Source-Code steht und welche Version gerade in Produktion läuft. Andere Unternehmenbenutzen dagegen eine Vielzahl von Ladebibliotheken in Produktion, einige Lademodule sind in mehreren Bibliotheken vorhanden, zum Teil mit der gleichen Version, zum Teil aber auch in abweichenden Versionen, für andere Lademodule ist nicht mehr bekannt, aus welchen Source-Membern sie gebildet wurden und wo dieser Source-Code zu finden ist. Es empfiehlt sich also auch hier mit einer globalen Bestandsaufnahme zu beginnen. Ein gut gepflegtes Dictionary kann hier gute Diensteleisten. Vermutlich kann man sich aber nicht hundertprozentig auf die Vollständigkeit und Aktualität dieser Daten verlassen. Vielleicht fehlt aber auch eine wichtige Zusatzinformation: Welche Programme werden tatsächlich noch benutzt und welche sind längst überflüssig? Bestehen beim Anwender Zweifel hinsichtlich dieser Aussagen, sollte im Vorfeld mit einer Bestandsaufnahme begonnen werden. Hierfür gibt es Inventory-Tools, die u.a. folgende Funktionalitäten bieten: Ermittlung aller Lademodul-Bibliotheken, LPA-Bibliotheken usw. Ermittlung aller Lademodule, deren Versionen, Duplikate usw. Zuordnung der Lademodule zu Produkten oder Anwendungen Ermittlung aller Source-Bibliotheken Ermittlung aller Source-Member, deren Versionen, Duplikate usw. Zuordnung der Source-Member zu Lademodulen inkl. Identifikation fehlender Source-Member, unklarer Versionen usw. Aufzeigen der Lines of Code (LOCs) Messung aller Lademodul-Nutzungen über einen definierten Zeitraum inkl. Ermittlung nicht mehr benutzter Lademodule Praxiserfahrungen in Europa und in den USA haben ergeben, daß auf Grund dieser Ergebnisse zwischen 10 und zum Teil über 30 Prozent der Programme nie oder nur selten benutzt wurden. Durch die unterschiedliche Mentalität beim Kauf von Software in europäischen und amerikanischen Unternehmen ist in Europa ein Wert zwischen 10 und 20 Prozent realistisch. Durch die Reduzierung der ursprünglichen 100 Prozent auf dann vielleicht nur noch 80 Prozent, ergeben sich erhebliche Einsparungspotentiale sowohl monetärer als auch zeitlicher Art. Iterationszyklen Die folgenden Schritte können parallel zueinander in diversen Abteilungen oder Projekten gleichzeitig ablaufen. Empfehlenswert ist aber der Start mit einem Pilotprojekt, um die Vorgehensweise zu testen, einen Leitfaden für weitere Projekte zu erstellen und die internen Multiplikatoren zu schulen. Hierfür sollte der Anwender möglichst erfahrene Mitarbeiter zusammenziehen, welche die Abläufe des Unternehmens gut kennen und fähig sind, in anderen Projekten als Projektleiter oder Fachberater das erworbene Wissen zu verbreiten. Als erstes müssen im definierten Untersuchungsbereich alle potentiellen Datumsprobleme identifiziert werden, um diese dann zu analysieren und geignete Korrekturmaßnahmen einzuleiten. Prinzipiell bestehen für zur Identifikation der Datumsprobleme drei Möglichkeiten: visuelle Inspektion des Codes maschinelles Scannen aller Datumsfelder in den Programmen Test des Arbeitsablaufes bzw. Funktionsblockes mit einem simulierten virtuellen Datum Die erste Möglichkeit scheidet vermutlich schon aus Aufwandsgründen aus. Die zweite Möglichkeit erscheint verlockend, aber es zeigt sich sehr schnell, daß das Regelwerk für solch einen Scanner sehr komplex sein kann und der Anwender trotzdem nie sicher sein kann, ob alle Stellen gefunden wurden. Auch wenn es strikte Standards für die Namenskonventionen in einem Unternehmen gibt, bleibt die Frage, ob alle Programme von der Historie betrachtet, bereits mit diesen Konventionen realisiert wurden, und ob sich alle Programmierer (interne und externe) an diese Standards gehalten haben. Mehr Sicherheit verspricht die dritte Möglichkeit. Mit dem pragmatischen Ansatz des "Probierens", kann sehr schnell getestet werden, wie sich eine Anwendung mit einem simulierten Datum, z. B. dem 01.01.2000, noch richtig funktioniert. Hierfür sind natürlich Testdaten erforderlich, die auch sachlogisch zu diesem simulierten Datum passen. Am Markt gibt es intelligente Tools zur Migration bestehender Datenbestände. Im einfachsten Fall bricht das untersuchte Programm mit einem Fehler ab, aber viel wahrscheinlicher ist, daß das Programm dürchläuft und Daten liefert, die nicht konsistent sind. Auch hierfür gibt es Tools am Markt, die einen Abgleich der Testdaten mit vorherigen Ergebnissen unterstützen (Regression Test Tools). In diesem Fall ist das sogar relativ einfach, da die Menge der datumsabhängigen Felder begrenzt ist. Soweit so gut. Die fehlerverursachenden Programme sind bekannt. Vermutlich läßt sich aufgrund der Testergebnisse auch schon einigermaßen genau bestimmen, wo in den Programmen die Fehlerursache liegt. Glücklich schätzen können sich die Unternehmen, in denen die Autoren der Programme noch tätig sind. Ist dies nicht der Fall, so wird auch hier einiges an Aufwand entstehen, da sich andere Programmierer zunächst in die Logik der Programme einarbeiten müssen. Der Anwender kennt nun die Fehlerursache und kann sich an die Bereinigung machen. Also einfach das Datumsfeld in der Eingabedatei auf von sechs auf acht Stellen erweitern. Oder? Mitnichten! Das untersuchte Programm steht am Ende einer Verarbeitungskette, die die Datei verarbeitet. Das erstellende Programm gehört zu einem anderen Funktionsblock und - Murphy's Gesetz schlägt zu - es übernimmt das Datum aus einer anderen Datei. Hier zeigt es sich, wie wichtig eine genaue Inventur der bestehenden Organisation ist. Ein Lichtblick bleibt dem Anwender: Es hätte auch schlimmer kommen können. Verläßt man sich nur auf Scanner-Tools, so kann es passieren, daß man nicht nur ein Datum sucht, sondern einer Vielzahl. Leider weiß man nicht, daß eine große Anzahl völlig unkritisch ist, da sie nirgends für Berechnungen herangezogen werden, sondern z.B. nur das letzte Datum einer Änderung dokumentieren. Aber genau hier ist auch der Ansatz für eine alternative Vorgehensweise verborgen. Der Anwender weiß, in welcher Funktion das Datum verwendet wird. Muß das Datum wirklich in der Datenbasis verändert werden? Was ist über die fachlichen Zusammenhänge bekannt? Werden im betreffenden Fachbereich tatsächlich Vorgänge bearbeitet, die über hundert Jahre dauern? Kann man nicht durch eine sachlogische Änderung des Algoritmus das Programm so ändern, daß das Programm richtig läuft ohne die Datenbasis ändern zu müssen? Eine funktionale Änderung eines Programmes ist in vielen Fällen einer Modifikation der Datenbasis vorzuziehen. Durch diese iterative Vorgehensweise kann sich der Anwender Stück für Stück vorarbeiten und kann sich hundertprozentig sicher sein, kein Datumsfeld übersehen zu haben. Sicher wird es nicht immer so einfach wie in oben beschrieben sein. Projketmitarbeiter aus parallelen Projekten werden Wünsche an andere Projektleiter herantragen und häufig wird man an einer Änderung der Datenbasis nicht herumkommen. Dann muß der Anwender in einer konzertierten Aktion mit allen betroffenen Projekten eine Änderung der Copy-Strecke vornehmen und möglichst zeitgleich einsetzen. Sind alle Teilprojekte erfolgreich abgeschlossen, muß ein abschließender Gesamttest durchgeführt werden. Mit Hilfe der Datensimulation kann der Anwender nachweisen, daß alle Anwendungen auch im Jahr 2000 fehlerfrei laufen. Fazit Alle Verantwortlichen kennen das Problem, viele haben auch schon Pläne, aber nur wenige haben auch bereits Projekte aufgesetzt. Selbst in großen Banken und Versicherungen existiert das Projekt nur als Name und die Besetzung ist oder wird in Kürze mit einem Projektmitarbeiter vorerst begonnen. Dies haben aktuelle Umfragen und Analysen der Gartner Group ergeben. Sicherlich gibt es keinen Grund in Panik zu verfallen und sämtlichen Horrorszenarien Glauben schenken, aber der zeitliche Druck nimmt Tag für Tag zu. Außerdem werden häufig die benötigten Personalressourcen firmenintern nicht zu decken sein, und am Markt sind nicht unendlich Ressourcen frei. Das Projektteam sollte sich auf jeden Fall der Unterstützung des Managements und der Geschäftsführung sicher sein, auch wenn diese umfangreichen Projektarbeiten nicht primär zu Verbesserung/Stärkung der Wettbewerbssituation führen und somit den Charakter von überflüssiger Arbeit vermitteln. Selbst wenn die eigenen Programme und Anwendungen "sauber" sind, kann es durch Daten von außen (Kunden und Lieferanten) zu Schwierigkeiten kommen. Also sollten die in Frage kommenden Kunden und Lieferanten im Projekt berücksichtigt werden. Eine genaue und ausführliche Inventur der gesamten Software (Vendor-Software und Eigenentwicklungen) ist notwendig, denn nur dann kann ein entsprechendes Projektmanagement aufgesetzt werden. Eine genaue Inventur ist nicht nur Grundvoraussetzung für eine genaue Projektdefinition, sondern hat auch den Vorteil, einen sehr genauen Überblick über Fremdsoftware und Eigenapplikationen im Unternehmen zu erhalten. Mit diesen Analyseergebnissen können gleichzeitig Kosten eingespart werden, wenn zum Beispiel Fremdsoftware installiert ist, die gar nicht oder nur sehr wenig genutzt wird (Kündigung der Wartung). Für das Projekt 2000 ist es insbesondere wichtig zu wissen, welche Load-Module zu welchen Applikationen gehören und aus welchen Source-Modulen diese generiert wurden. In welchen Bibliotheken stehen die Module, wieviele unterschiedliche Versionen gibt es und welche User und welche Applikationen benutzen welche Version. Ein weiteres sehr wichtiges Ergebnis dieser Inventurphase sollte die Anzahl der Lines of Code (LOC) sein, und zwar pro Modul, als auch über alle Applikationen hinweg, so daß die einzelnen Arbeitsschritte für die Konvertierung besser geplant und die erforderlichen Ressourcen effizienter bereit gestellt werden können. Als zusätzliche Sicherheitsmaßnahme sollte auch bei noch so gründlicher Planung ein Notfallplan erstellt werden. Auch ein gutes Projektteam und das beste Projektmanagement kann eventuelle "Störfälle" nicht hundertprozentig ausschließen. Eine der größten softwaretechnischen Herausforderungen muß in den Unternehmen in den nächsten Jahren gelöst werden. Und wer rechtzeitige Vorsorge geschaffen hat, wird sich entscheidend schneller wieder seinem originären Geschäft widmen können und die freien Ressourcen in sinnvolle Weiterentwicklungen für die Stärkung der eigenen Wettbewerbsposition einsetzen können. EMPRISE Software +Consulting GmbH