Die gesamte IT-Welt sieht sich mit einer enormen Herausforderung konfrontiert. Bis zum Jahr 2000 muß jede Software auf den Jahrtausendwechsel umgestellt werden. Jedes Unternehmen muß reagieren. Denn diese Umstellung haben eine absolut fixen Endtermin, der sich auf keinen Fall verschieben läßt. Das bringt erhebliche Aufwände zeitlicher und monetärer Art mit sich. Im zweiten und letzten Teil ihres Beitrags stellen Gerd Niklisch* und Uwe Schütt* dar, welche konkreten Lösungen sich anbieten.Die Kosten
Die Erfahrungen einer großen amerikanischen Versicherung (laut Untersuchung der IBM) haben ergeben, daß mehr als 1.400 komplexe Programme im Einsatz sind. In diesen Programmen wurden durch Analyseprogramme mehr als 400 Datumsfelder identifiziert. Es waren beziehungsweise sind zwar nur fünf Prozent des Codes betroffen, aber zirka 90 Prozent der Programme sind zu modifizieren. Der Projektaufwand für die Analyse, Dokumentation, Korrektur der Programme und den Modul- und Systemtest wurde auf 53 Mannjahre geschätzt. Die Untersuchung einer deutschen Großbank hat ergeben, daß von insgesamt 21.000 Programmen ungefähr 9.000 Assembler- und 8.500 COBOL-Programme sind. Von den Assemblerprogrammen sind zirka 24 Prozent und von den COBOL-Routinen über 90 Prozent vom Jahrtausendwechsel betroffen. Eine erste Aufwandsschätzung Mitte 1995 betrug 6.500 Manntage. Heute geht man davon aus, daß diese Schätzung eher zu niedrig als zu hoch war. Durch den Einsatz von geeigneten Tools kann der Aufwand in erheblichem Maße reduziert werden, stellt aber trotzdem einen nicht zu unterschätzenden Aufwand dar.
Die Schätzungen für die weltweiten Ausgaben für den Jahrtausendwechsel liegen laut Computerwoche vom 15. März 1996 bei ungefähr 380 Milliarden Mark. Für Deutschland wird das Volumen auf grob 30 Milliarden Mark geschätzt. Eine genaue Zahl läßt sich derzeit allerdings kaum verläßlich erstellen, da der Umfang einfach zu groß ist und die vorliegenden Informationen noch nicht ausreichen.
Ein mittelgroßes Unternehmen setzt durchschnittlich bis zu 8.000 Programme für die Unterstützung des betriebswirtschaftlichen Werteflusses ein. Laut Untersuchungen und Analysen der Gartner Group und der IBM muß mit Kosten von zirka Mark 1,00 Mark bis 1,50 pro LOC (Line of Code) bezogen auf die Gesamtprojektkosten geplant werden.
Mit geeigneten Tools für die Analyse, Konvertierung und die Testphase lassen sich die Kosten erheblich senken. Jedoch ist nicht alles automatisierbar und der Teufel liegt im Detail. Sicherlich werden häufig die meisten Programme unproblematisch maschinell oder manuell umzustellen sein. Probleme ergeben sich aber gerade bei den "alten Schätzchen", für die keine Dokumentation mehr vorliegt und auch der Ursprungsautor nicht mehr verfügbar ist. Hier ist eine detaillierte Analyse und ein sorgfältiges Testkonzept zwingend erforderlich, um nicht Schiffbruch zu erleiden, da auch betriebswirtschaftliches Know-how erforderlich ist, um geeignete Testfälle aufzubauen und die Ergebnisse qualifiziert prüfen zu können. Gerade der Qualitätssicherung und den Testaktivitäten kommt in diesem Projekt eine höhere Bedeutung oder besser gesagt ein höherer Anteil gegenüber anderen Projektphasen in üblichen Entwicklungsprojekten zu.
Die Vorgehensweise in Einzelschritten
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 beziehungsweise 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 Systemtests 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?"
Dies sind nur einige wenige Fragen, die verdeutlichen sollen, wie wichtig eine genaue Analysephase für das gesamte Projekt ist.
Die Projektphasen
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 Gesamtaufwands ein. Der größten 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.
Die genannten drei Phasen lassen sich wie folgt weiter gliedern beziehungsweise detaillieren:
Projektdefinition/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 beziehungsweise Datumsaufrufen analysiert werden. Auch hier ist der Einsatz von Tools zur maschinellen Untersuchung sinnvoll. Als wesentliche Erkenntnis aus vergleichbaren Projektaufgaben 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 Prozent garantieren. Es sei denn, daß alle Regeln/Konventionen, die verwendet werden, vorher mit Parametern beziehungsweise 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 (zum Beispiel Vornamen, Phantasiebegriffe und vieles mehr). 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 Prozent 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, beziehungsweise 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 Testphase jedoch nur mit einem exakten Testkonzept und Produktionsübergabeverfahren kontrolliert werden. Nur so kann eine erneute "Verschmutzung" der Programme vermieden werden.
Mit etwa 50 Prozent 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.
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, also auch über alle Applikationen hinweg, so daß die einzelnen Arbeitsschritte für die Konvertierung besser geplant und die erforderlichen Ressourcen effizienter bereitgestellt 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.
*Gerd Nicklisch und Uwe Schütt sind Mitarbeiter der Emprise Software Consulting GmbH in Hamburg.