Gastkommentar

02.05.1997

Das Jahr 2000 wird uns bewußt machen, daß auch Software brechen kann. Deshalb muß ihr Fundament stimmen oder neu eingerichtet werden. Schließlich dürfen auch 2001 keine falschen Bescheide gedruckt oder unsinnige Behauptungen aufgestellt werden wie: "Material nie eingetroffen", "Ware alt und verfallen", "Flugziel unbekannt". Die Ursache für solche Fehlauskünfte sind zweistellige Datumsfelder, und deren Umwandlung in vierstellige ist kein Hexenwerk, sondern einfach Wartung - sogar wenig komplexe Wartung, wenn man von Assembler-Programmen absieht, zu denen vielleicht sogar die Quellen nicht mehr aufzufinden sind.

Wenig komplex - aber sehr zeitaufwendig. Deshalb kann es schlimme Folgen haben, wenn Manager automatisch darauf vertrauen, daß ihr Softwareteam die Datumsumstellung parallel zum Alltagsgeschäft schaffen wird. Meistens ist zunächst einmal nicht bekannt, ob, welche und wie viele Programme mit dem Jahr 2000 nicht klarkommen; sind es weniger als zehn, sind es hundert, womöglich tausend oder mehr? Ist die Fehlerbehebung beherrschbar? Für wie lange fallen Anwendungen aus? Ist ein Ausfall überhaupt vertretbar?

Planung tut not. In der Analyse gilt es zuerst, die problembehaftete Software zu erkennen und die damit verbundenen Risiken zu bestimmen. Danach läßt sich entscheiden, ob ein eigenes Jahr-2000-Projekt notwendig ist. Hardware-, Standardsoftware- und Systemlieferanten sollte man in die Untersuchung einbeziehen, um sich gegebenenfalls frühzeitig mit ihnen abstimmen zu können.

Die Umstellung der Datumsfelder ist zwar das eigentliche Ziel des Projekts, doch am aufwendigsten sind die anschließenden Tests. Es geht um Masse. Hier gilt es Übersicht zu bewahren, ein Rädchen muß ins andere greifen. So kann die Datumsumstellung eine Chance sein, nämlich zum Startschuß für systematisches und langfristiges Test-Management.