CC-REPRINT. Durchführung großer Reengineering-Projekte am Beispiel einer Datenbankumstellung. Jens Borchers CC GmbH, Wiesbaden

Transkript

1 CC-REPRINT Durchführung großer Reengineering-Projekte am Beispiel einer Datenbankumstellung Jens Borchers CC GmbH, Wiesbaden Published in: Software-Entwicklung - Methoden, Werkzeuge, Erfahrungen '93

2 Copyright No part of this document may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying and recording, for any purpose without the written permission of CC GmbH. Information in this document is subject to change without notice and does not represent a commitment on the part of CC GmbH. This document and the referenced software described in this document is furnished under a license agreement or nondisclosure agreement. The document and the referenced software may be used or copied only in accordance with the terms of the agreement. It is against the law to copy the document or the software on any medium except as specifically allowed in the license or nondisclosure agreement. Copyright 2002 CC GmbH. All rights reserved

3 Jens Borchers CC GmbH, Wiesbaden Durchführung großer Reengineering-Projekte am Beispiel einer Datenbankumstellung Zur erfolgeichen Durchführung von großen Reengineering-Projekten, zu denen u. a. "klassisch" auch der Wechsel des Datenbanksystems gehört, sind eine Reihe von Randbedingungen und Regularien zu beachten, die in diesem Beitrag am Beispiel einer großen Datenbankumstellung dargestellt werden. Dabei wird auch auf Aspekte eingegangen, die zwar außerhalb der eigentlichen Reengineering-Aufgabe liegen, auf die Durchführung aber enormen positiven - und leider auch negativen - Einfluß haben können. In diesem Beitrag werden einige dieser aktoren anhand konkreter Praxiserfahrungen dargestellt. Die für eine Datenbankumstellung spezifischen Aspekte werden ebenfalls dargestellt, können aber nicht im Mittelpunkt dieses Beitrages stehen. 1. Einleitung Der Begriff "Reengineering" wird heute i.d.r. für die Durchführung von Veränderungen an Softwarekomponenten benutzt, mit denen eine bestimmte technische Veränderung oder qualitative Verbesserung dieser Komponenten erreicht werden soll. Reengineering-Aufgaben gehören damit zu dem Bereich der sog. adaptiven Wartung, bei der zwar die Komponenten der technische Implementationsebene verändert werden dürfen, nicht aber die betriebswirtschaftliche unktionalität für den Benutzer. ür eine umfassende Einführung zum Themenkreis "Reengineering" kann z. B. (1) benutzt werden. Unter dem Oberbegriff "Reengineering" werden eine Reihe weiterer "Re-" Begriffe in der Literatur verwendet, die aber hier nicht weiter ausgeführt wer- Reprint aus Software-Entwicklung - Methoden, Werkzeuge, Erfahrungen '93 Seite 1

4 den sollen (vgl. z. B. (2)). Das Ziel dieser einzelnen Aspekte des Reengineering ist i.d.r. die Softwarekomponente "Programm" bzw. "Modul". Einen Reengineering-'Klassiker" stellen die hier als Beispiel betrachteten Umstellungen (in der englischsprachigen Literatur als "Conversion" bzw. "Migration" bezeichenet) dar. Diese können einen mehr oder weniger großen Bereich des Hardware- und Software-Systems betreffen, z. B.! die gesamte Hardware- und Systemsoftwareumgebung (bei Herstellerwechsel),! Teile der System-Softwareumgebung (Betriebssystem, Datenbank, TP- Monitor,...)! den Wechsel der Programmiersprache (inkl. Umstellung auf neueren Sprachstandard der gleichen Sprache),! den Wechsel der Benutzeroberfläche oder! den Wechsel der Software-Produktionsumgebung. Im Beispiel-Projekt heißt die Aufgabe: "Ablösung des bestehenden CODASYL-Datenbanksystems durch ein relationales System und Umstellung aller CODASYL-Datenbankbefehle auf SQL-Standard-DML". Aus dieser Aufgabe lassen sich die in diesem Projekt zu bearbeitenden Software-Komponenten bestimmen:! die gesamte Datenbank-Beschreibung (CODASYL-Schema nach SQL- DDL),! alle Programme, die mindestens einen Datenbankbefehl enthalten ( rage: Ist dieses wirklich die Gesamtmenge aller zu betrachtenden Programme?),! die Job-Control-Streams für alle Batch-DB-Programme,! die DB-bezogenen Ressourcendefinitionen im TP-Monitor,! die sonstigen DB-bezogene Infrastruktur-Komponenten! alle DB-bezogenen Dokumentationen (inkl. Data Dictionary-Einträge),! und - last but not least - alle physikalischen Datenbank-Bestände! In Umstellungsprojekten - speziell im Datenbank-Bereich - kommen praktisch alle Teilaspekte vor, die in Reengineering-Projekten zu beachten sind, daher stellen sie ein gutes Anwendungsbeispiel dar. Im folgenden werden die folgenden Teilaspekte von Reengineering-Projekten betrachtet: Reprint aus Software-Entwicklung - Methoden, Werkzeuge, Erfahrungen '93 Seite 2

5 ! Grundprinzipien und Globalstrategie! Projektorganisation und - ablauf! Umstellungs-infrastruktur 2. Grundprinzipien und Globalstrategie Im Gegensatz zu DV-Projekten, in denen betriebswirtschaftliche unktionalität neu zu schaffen bzw. in wesentlichen Teilen zu ändern ist, haben Reengineering-Projekte folgende Vorteile:! die Projektaufgabe läßt sich eindeutig definieren;! eine Involvierung von achabteilungen für die Erstellung von Spezifikationen ist nicht erforderlich;! das Know-how der betriebswirtschaftlichen Hintergründe ist nicht notwendig;! die Durchführung hat in großen Teilen den Charakter einer " ließfertigung", läßt sich dementsprechend gut planen und steuern;! Teilaufgaben lassen sich ggf. so gut herauslösen, daß sie extern vergeben werden können:! die Kontrolle, daß korrekt gearbeitet wurde, ist mit Hilfe von Regressionstests eindeutig möglich. Um die o. g. Vorteile auch wirklich nutzen zu können, darf allerdings von einem Grundprinzip niemals abgewichen werden: Die im Zuge des Projektes vorgenommenen Veränderungen an den betroffenen Software-Komponenten dürfen in keinster Weise die betriebswirtschaftliche unktionalität der Softwaresysteme verändern. Ein Verstoß gegen dieses Prinzip (nach der Devise: "Wenn wir die Programme ohnehin anfassen, könnten wir doch gleich...") ist für die erfolgreiche Durchführung eines Reengineering-Projektes hochgradig gefährlich! Das estschreiben dieses Grundprinzips stellt damit die wichtigste Aufgabe zu Beginn des Projektes dar. Eine weitere wichtige Entscheidung ist die estlegung der globalen Projektstrategie. Dazu existieren prinzipiell folgende Varianten:! Punktumstellung: Bei dieser Strategie werden alle betroffenen Softwarekomponenten in einem möglichst kurzen Zeitraum bearbeitet und zu einem Zeitpunkt gemeinsam in der neuen orm in die DV-Produktion übernommen. Diese Strategie hat mehrere gravierende Nachteile (insbesondere ihr hohes Produktionsrisiko) und fällt daher für große Reengineering-Projekte wie die betrachtete Umstellung i.d.r. aus. Reprint aus Software-Entwicklung - Methoden, Werkzeuge, Erfahrungen '93 Seite 3

6 ! Langfristumstellung: Bei einer langfristig angelegten Umstellung bzw. Reengineering-Maßnahme werden alle betroffenen Softwarekomponenten erst dann bearbeitet, wenn sich dieses im Rahmen der normalen Wartungsaktivitäten durchführen läßt. Diese Strategie birgt die große Gefahr, daß sich die Umstellung über einen extrem langen Zeitraum hinzieht oder gar zu einer "unendlichen Geschichte" wird. ür eine DB-Umstellung steht diese Strategie aufgrund der technischen Restriktionen praktisch nicht zur Verfügung.! Paketorientierte Umstellung: Diese Umstellungsstrategie, bei der der gesamte Umstellungsstoff vorab in definierte Pakete zerlegt wird (wobei diese entweder aufgrund von technischen, wie z.b. bei einer DB- Umstellung, oder organisatorischen Randbedingungen gebildet werden), die nacheinander in einem überschaubaren Zeiträumen berarbeitet werden, ist in großen Projekten die erfolgversprechendste. Sie erfordert zwar einen höheren Planungs- und Koordinationsaufwand, trägt aber u. a. zu einer Risikominimierung bei. Wie bereits dargestellt, stehen für eine Datenbankumstellung nur die Alternativen Punkt- oder Paketumstellung zur Verfügung. Im konkreten all wurde aufgrund des Umfang des Stoffes (ca Programme, ca. 500 Record-Typen, über Online-Transaktionen pro Tag, DB-Volumen einige zig Gigabyte) für eine paketorientierte Umstellung entschieden. 3. Projektorganisation und -ablauf Ohne an dieser Stelle auf die notwendige Projektorganisation im einzelnen eingehen zu können, sollen i. f. die groben Phasen des Projektablaufs und eine mögliche Projektorganisation skizziert werden. Zur Durchführung eines großen Reengineering-Projektes wie einer Datenbankumstellung gehören die folgenden groben Phasen:! Erstellung der Konzeption und - noch nicht toolunterstützte - Durchführung eines "Mini"-Piloten auf Basis des erstellten Arbeitsplanes (detaillierter Netzplan)! Erarbeiten der Umstellungs-Pakete und ihrer Bearbeitungsreihenfolge auf Basis der technischen Randbedingungen! Erstellen des Umstellungs-"Kochbuchs" mit detaillierten Regeln für die Bearbeitung der einzelnen Software-Komponenten! Herstellen/Kauf einer Werkzeugumgebung zur Automatisierung der wichtigen Umstellungsaufgaben Reprint aus Software-Entwicklung - Methoden, Werkzeuge, Erfahrungen '93 Seite 4

7 ! Einrichten der Projektorganisation (s.u.) mit zunächst geringer Besetzung und Durchführung eines aussagekräftigen Pilotpaketes (mit Ziel Produktionseinsatz!)! Ggf. Oberarbeiten des Umstellungssystems aufgrund der Pilot-Erfahrungen! Durchführen der eigentlichen paketorientierten Umstellung mit voller Mitarbeiterzahl in einem überschaubaren Zeitraum Wie bereits oben dargestellt wurde, kann ein Umstellungsprojekt - nach genauer Spezifikation des Regelwerkes (entspricht in der ertigungsindustrie einem Arbeitsplan) - praktisch "fabrikmäßig" abgewickelt werden. Dazu bedarf es aber einer rigiden Projektorganisation mit detailliert festgelegten Kommunikationsmechanismen. Eine solche Projektorganisation besteht bei einer Datenbankumstellung aus:! Projektkoordination, die nicht nur die Projektaktivitäten steuert, sondern auch den gesamten Umstellungsstoff verwaltet. Insbesondere hat diese Stelle die Koordination der Umstellungsaktivitäten mit anderen Wartungsaktivitäten innerhalb der DV durchzuführen. Die wichtigste Aufgabe dieser Stelle ist aber (die politische), die Grundregel der 1:1-Umstellung konsequent durchzusetzen.! Testgruppe, die für die Erstellung der Testdaten in der Quellumgebung verantwortlich ist. Die Arbeit einer solchen Gruppe wird bei Reengineering-Projekten häufig ganz "vergessen" ("Wir testen dann die umgestellten Programme" - rage: Aber wie?) oder aber zumindest grob unterschätzt.! Datenbankdesign-Gruppe, die für die Überführung der bestehenden Datenbankbeschreibung (im konkreten all ein CODASYL-Schema) in die neue orm (SQL-DDU) verantwortlich zeichnet.! Datenkonvertierungs-Gruppe, die für die physikalische Überführung der Datenbankbestände von der alten in die neue orm (und für Einzelfälle auch umgekehrt) verantwortlich ist. Die größte Menge an umzustellenden Beständen resultiert dabei aus den Testdaten! Reprint aus Software-Entwicklung - Methoden, Werkzeuge, Erfahrungen '93 Seite 5

8 ! Programmkonvertierungs-Gruppe, die für die Umstellung der Programm-Quellen verantwortlich ist. Der Nachweis, daß die umgestellten Programme ihre identische unktionalität behalten haben, ist ebenfalls zunächst hier durchzuführen.! Qualitätssicherungs-Gruppe, die durch eigene Prüfungen sicherstellt, daß sowohl die unktionalität identisch abgebildet wurde, als auch, daß die umgestellten Komponenten den Standards genügen.! Produktionseinsatz-Gruppe, die neben ihrer normalen Linienaufgabe, gewartete Programme in die DV-Produktion zu übernehmen, speziell die Übernahme von umgestellten Programmen und Datenbanken unterstützt und umstellungsspezifische Anforderungen (wie z. B. nächtliche Konvertierungen von Datenbanken aus der alten in die neue orm bzw. umgekehrt) in die Produktionsabläufe integriert. Diese Gruppe kontrolliert insbesondere Performanceaspekte, aus denen ggf. Regeländerungen für die Umstellung resultieren können. Alle aufgeführten Gruppen arbeiten auf Basis des verabschiedeten Arbeitsplans die Umstellungspakete nacheinander ab. Dabei werden für jedes Paket die dafür verantwortlichen Entwickler insbesondere zur Erstellung von Testdaten und Klärung von Einzelproblemen mit hinzugezogen. Während der Umstellung eines Paketes bleiben natürlich alle zugehörigen Softwarekomponenten für andere Wartungsaktivitäten gesperrt. Ein Abweichen von dieser Regel führt zu drastisch erhöhtem Koordinationsaufwand und einer Risikoerhöhung beim Produktionseinsatz (von den gegenseitigen Schuldzuweisungen im ehlerfall gar nicht zu reden.). Sie sollte daher ebenso rigide durchgesetzt werden wie die Grundregel der 1:1-Umstellung. 4. Umstellungs-Infrastruktur Eine wichtige - und ebenfalls häufig unterschätzte - Rolle für den Erfolg einer Reengineering-Maßnahme spielt die Herstellung einer definierten und vor allem isolierten Umstellungsinfrastruktur. ' Bedenkt man, daß bei einer paketorientierten Umstellung, die sich über einen Zeitraum von einigen Monaten erstreckt, nur ein verhältnismäßig kleiner Teil der Software-Komponenten für andere Aktivitäten gesperrt ist, andererseits das "Normalgeschäft" aber parallel weiterläuft, so sieht man sehr schnell die Reprint aus Software-Entwicklung - Methoden, Werkzeuge, Erfahrungen '93 Seite 6

9 Notwendigkeit einer sauberen "Abschottung" der Umstellungsinfrastruktur in der Entwicklungsumgebung. Diese Isolierung wäre natürlich dann optimal, wenn das Projekt auf einer total getrennten Hardware abgewickelt werden könnte (wobei dieses wiederum andere Aufgaben zur olge hätte). Da sich eine derartige Isolierung aber i.d.r. nicht durchführen läßt, muß diese durch andere Mechanismen in der normalen Entwicklungsumgebung realisiert werden. Die dazu notwendigen Regeln und Regularien entsprechen dabei weitestgehend denen zum Aufbau von isolierten Testumgebungen z. B. für Abnahmetests von achabteilungen. Dazu gehört u. a.! Alle Programme außer den "Testlingen" werden in ihrer Produktionsversion genutzt.! Alle anderen Softwarekomponenten, die zwar nicht verändert, aber genutzt werden, dürfen nicht parallel verändert werden.! Alle Datenbanken werden isoliert (sowohl für die Testdatenerstellung als auch die Reruns in der Zielumgebung).! Basisdatenbestände, die von vielen Testläufen lesend genutzt werden, dürfen zwischenzeitlich nicht verändert werden.! Alle sonstigen Ressourcendefintionen (z. B. für TP-Monitor,etc.) dürfen nicht verändert werden.! Basis-Systemsoftware darf nicht verändert werden,! etc. Gerade das Einfrieren aller Programm-Bibliotheken für den Zeitraum von Beginn der Testdatenerstellung für ein Paket bis zum Ende der entsprechenden Regressionstests für das Zielsystem stellt dabei einen kritischen Punkt dar. In letzter Konsequenz führt dieses zu einem eigenen reigabe-management für die Umstellung mit allen damit zusammenhängenden Aufgaben. Die Abschottung der Datenbankumgebungen sowohl in der Quell- als auch in der Zielumgebung (und dort mehrfach je nach Anzahl der Mitarbeiter, die Programmkonvertierungen durchführen!) stellt eine weitere für ein Umstellungsprojekt "lebenswichtige" Aufgabe dar, die sich technisch allerdings im konkreten Projekt gut bewältigen läßt. Ein weiterer Erfolgsfaktor, der häufig drastisch unterschätzt wird, sind die für die Umstellung benötigten Zusatzressourcen, und hier insbesondere Plattenplatz. ür die Umstellungsumgebung und die Menge der vorzuhaltenden Testbestände ergibt sich in der Summe schnell ein Mehrfaches der Produktionsdatenmenge, selbst wenn mit reduzierten Testbeständen gearbeitet wird. Ein Mangel dieser Ressourcen kann eine Umstellung schneller zum Stoppen Reprint aus Software-Entwicklung - Methoden, Werkzeuge, Erfahrungen '93 Seite 7

10 bringen als mancher andere Einflußfaktor! 5. Resümee Auch wenn Reengineering-Projekte den Vorteil einer klaren Zieldefinition und der Möglichkeit zu einer fertigungsorientierten Abwicklung haben, so sind für ihre erfolgreiche Durchführung dennoch einige wichtige Regularien und Randbedingungen zu berücksichtigen. Diese liegen zum größten Teil nicht in der eigentlichen Reengineering-Aufgabe selbst, sondern vielmehr in der Absicherung des Umstellungsprojektes gegen - ungewollte - remdeinflüsse und der Bereitstellung genügender Ressourcen. Diese zu minimieren, stellt damit neben der Erstellung genauer Regularien und Planungen einen der Eckpfeiler zum Projekterfolg dar. Literatur (1) McClure.C.: The Three R's of Software Automation: Reengineering, Repository, Reusability, Englewood Cliffs, Prentice Hall, 1992 (2) Borchers, J.: Reengineering-Ansätze zur Verbesserung der Wartung und Software-Qualität mit Hilfe von CASE-Tools - ein Praxisbericht, in: Wagner.B, et al.: Reverse Engineering: Sanierung, Dokumentation und Strukturierung vorhandener Software, Ehningen b. Böblingen, expert-verlag, 1992 Reprint aus Software-Entwicklung - Methoden, Werkzeuge, Erfahrungen '93 Seite 8