Aktivitäten während des Lebenszyklus
-
Einführung
-
Referenzversion erstellen
-
Vorwärts mit RUP
-
Weiterentwicklungszyklus
-
Zusammenfassung
-
Referenz
Zusätzliche Themen:
-
Konzepte
-
Richtlinien
-
White Paper
|
Ein traditionelles System ist als ein System definiert, das "...sich Änderungen und Weiterentwicklungen zur Anpassung
an neue und sich ständig änderende Geschäftsanforderungen widersetzt". [1] Normalerweise ist
ein solches System groß und alt. In diesem Kontext bedeutet es auch "ein System, das ursprünglich mit einem anderen
Prozess als RUP entwickelt worden ist".
Mit "Weiterentwicklung" meinen wir ein wichtiges Projekt für die Aktualisierung, Integration oder Neuentwicklung eines
traditionellen Systems. Diese Roadmap beschreibt also nicht, wie RUP für die fortlaufende Wartung reifer Systeme
verwendet werden kann.
Zuallererst wird gewöhnlich eine Vision für die vorgeschlagene Weiterentwicklung definiert, die Fragen wie die
folgenden beantwortet:
-
Wo liegt der Wert Ihres traditionellen Systems?
-
Wie möchten Sie Ihr System weiterentwickeln?
-
Gibt es eine Kosten-Nutzen-Analyse, die die geplante Weiterentwicklung unterstützt?
Eine ausführliche Beschreibung dieser Themen finden Sie in Richtlinie: Vision für die Weiterentwicklung traditioneller Systeme definieren.
Bei der Weiterentwicklung traditioneller Systeme sind gewöhnlich die folgenden Herausforderungen zu bewältigen:
-
Das System lässt sich schwer verstehen.
-
Die Dokumentation ist veraltet.
-
Die ursprünglichen Entwickler sind nicht verfügbar, und die restlichen Mitarbeiter verfügen nur über
begrenztes Wissen in Bezug auf die eigentliche Funktionsweise des Systems.
-
Das System wurde mit älteren Softwareentwicklungsmethoden und- technologien entwickelt, die für künftige
Entwicklungsarbeiten unter Umständen nicht mehr geeignet sind.
Die grundlegenden Prinzipien des RUP gelten gleichermaßen auch für Projekte, in denen traditionelle Systeme
weiterentwickelt werden.
Diese Prinzipien sind:
-
Frühe Risikominderung
-
Iterative Entwicklung
-
Fortschrittsbewertung basierend auf konkreten, messbaren Nachweisen
-
Organisation auf der Basis kleiner, fähiger Teams
-
Ständige Überprüfung der Qualität
-
Scope-Management
-
Nur die wirklich erforderlichen Arbeitsergebnisse produzieren
Diese Prinzipien bilden bereits die Basisvorlage für den RUP-Lebenszyklus mit seinen vier Phasen (Konzeption,
Ausarbeitung, Konstruktion und Übergang), die auf ein Projekt für ein traditionelles Systems vollständig anwendbar
sind. Damit sind dann auch die meisten Aktivitäten im Bereich Projektmanagement von RUP anwendbar.
Die Anpassung des Rational Unified Process (RUP) für die Weiterentwicklung traditioneller Systeme wird im Folgenden
ausführlicher beschrieben.
Um über das Stadium der reinen Anwendung des RUP-Lebenszyklus hinwegzukommen und andere Disziplinen des RUP zu
verwenden, müssen Sie einen Ausgangspunkt etablieren. Sie müssen eine Mindestgruppe essenzieller Arbeitsergebnisse
identifizieren, die das traditionelle System beschreiben.
Je nach Umfang der Weiterentwicklung müssen Sie mehr oder weniger der folgenden Artefakte haben:
-
Anforderungen
-
Architektur und Design
-
Tests
-
Benutzerdokumentation
Nachdem Sie diese Referenzversion von RUP-Arbeitsergebnissen erstellt haben, können Sie mit dem Projekt so fortfahren,
als wäre es ein RUP-Weiterentwicklungszyklus.
Für die Erstellung einer minimalen Gruppe von Arbeitsergebnissen, die es Ihnen erlaubt, Ihr Projekt gemäß RUP
fortzusetzen, müssen Sie gewisse Rückentwicklungsarbeiten an Ihrem traditionellen System durchführen. Mit
Rückentwicklung meinen wir zu versuchen, genug Informationen zu ermitteln, zu extrahieren oder erneut zu erstellen, um
in der Lage zu sein, nahezu so weiterarbeiten zu können, als wäre das Projekt ursprünglich mit RUP entwickelt worden.
Dies ist der Punkt, an dem viele Projektleiter bereit sind, sich gegen RUP zu entscheiden, weil sie denken, dass
Rückentwicklung eine große Zeitverschwendung ist. Die Rückentwicklung muss jedoch kein so großer Aufwand sein, da die
Absicht nicht darin besteht, jedes einzelne Arbeitsergebnis erneut zu erstellen, sondern die Schlüsselattribute des
aktuellen Systems zu verstehen und festzustellen, was bewahrt und was ersetzt bzw. aktualisiert werden sollte.
Sie können die RUP-Vorlagen für diese Arbeitsergebnisse zusammen mit den zugehörigen Richtlinien und Prüflisten
verwenden, aber wahrscheinlich möchten Sie die Vorlagen zuerst anpassen, um nicht in die Falle zu treten, Elemente zu
dokumentieren, die Sie gar nicht benötigen. In vielen Fällen können Sie (im ersten Durchgang) die Vorlagen durch
Querverweise "ausfüllen", d. h. angeben, in welchem Vorhandenen Dokument die entsprechenden Informationen enthalten
sind. Wenn die vorhandene Dokumentation online im HTML-Format vorliegt, können Hyperlinks verwendet werden.
Dieser Schritt, die Erstellung einer Referenzversion, ist nicht RUP-spezifisch. Egal welchen Prozess oder welche
Methode Sie verwenden, um voranzukommen, Sie müssen auf jeden Fall eine gewisse Rückentwicklung des vorhandenen Systems
betreiben. Die Website Renaissance, ein Esprit-Projekt
zum Software Reengineering, ist eine gute Informationsquelle für Rückentwicklung.
Anforderungen
Der vielleicht größte Wert eines traditionellen Systems ist der, dass es als Anforderungsspezifikation für das neue
System dient.
Als wir beispielsweise mit Rational Apex begonnen haben, enthielt der erste Entwurf unseres Visionsdokuments Folgendes: "...es muss zunächst einmal alles tun,
was Rational Environment (Version Delta) tut, und es darf dies nicht langsamer tun". Anschließend haben wir
Abweichungen von Rational Environment spezifiziert: Features hinzugefügt, Features gelöscht.
Ein intelligentes Team dokumentiert die Anforderungen eines traditionellen Systems niemals rückblickend. Sie müssen
also die ganzen Anforderungen nicht vollständig neu erfassen, Sie müssen nur Ihre Schlüsselanwendungsfälle
identifizieren. Wahrscheinlich haben Sie sie bereits im aktuellen Benutzerhandbuch beschrieben. Es kann schon genügen,
einen Bestand der Anwendungsfälle (Bericht: Fragebogen über das Anwendungsfallmodell) zu haben. Sie müssen nur die
Anwendungsfälle detailliert beschreiben, die Sie ändern müssen. Viele nicht funktionale Anforderungen können aus der
Vertriebs- oder Installationsdokumentation abgeleitet werden: Fähigkeiten, Größe und Leistungsmerkmale,
Betriebssysteme, Hauptspeicher, Peripheriegeräte, andere Software, allgemeine Vorgaben und die meisten der
Qualitätsattribute. Wenn Sie kein Anforderungsmanagementtool verwenden, ist dies wahrscheinlich der richtige Zeitpunkt,
um damit zu beginnen. Ein weiteres wertvolles Artefakt, das Sie während der Rückentwicklung erstellen sollten, ist ein
Glossar mit den im traditionellen System verwendeten Begriffen.
Dieses Artefakt kann im weiteren Verlauf als unbezahlbar erweisen.
Architektur und Design
Ihr traditionelles System muss mit objektorientierten (OO) Techniken nicht vollständig neu gestaltet werden. Sie
benötigen jedoch eine Mindestmenge von Informationen zur Architektur. Sie erstellen ausgehend von der Implementierungssicht ein minimales Softwarearchitekturdokument, in dem Sie die verschiedenen Subsysteme,
die Hauptteile des Codes und die kritischen Schnittstellen beschreiben. Anhand dieser Informationen können Sie Ihre Deployment-Sicht und Ihre Prozesssicht
ermitteln, wenn das traditionelle System ein verteiltes System ist. Sie benötigen ein genaues Inventar der vorhandenen
Software, das die einzelnen Elemente und die Beziehungen zwischen diesen Elementen klar identifiziert. Wenn Sie
Software noch nicht unter Konfigurationsmanagement gestellt ist, ist dies genau der richtige Zeitpunkt, damit
anzufangen.
Die Beschreibung der Schnittstellen und Einsatzszenarios für diese Schnittstellen ist ein entscheidender Faktor. Später
werden Sie die Subsysteme ermitteln, die von der Weiterentwicklung nicht betroffen sind: die stabilen,
wiederverwendbaren Basisteile des traditionellen Systems. Benötigen Sie eine detaillierte Softwaredesigndokumentation
und diese Schnittstellenbeschreibungen? Wenn Sie sie haben und ihnen vertrauen können, ist das zwar hilfreich, wenn
nicht, sollten Sie keine größeren Anstrengungen unternehmen, diese zu erzeugen, bevor Sie nicht genau wissen, welche
Teile geändert werden müssen. Und selbst dann sollten Sie von Fall zu Fall entscheiden. Mit Hilfe von Tools sind diese
Rückentwicklungsarbeiten eine Sache von ein paar Tagen.
Außerdem müssen Sie die verschiedenen zu migrierenden Datenquellen Ihres traditionellen Systems ermitteln und ihr
Datenprofil in der Datenmigrationsspezifikation dokumentieren. Diese Informationen sind
entscheidend, wenn Sie mit der Datenzuordnung zwischen vorhandenen Datenquellen und den Datenquellen beginnen, die in
der neuen Version des Systems benötigt werden.
Tests
Die für das traditionelle System entwickelten Tests, Testscripts, Testfälle und Fehlersimulationen sind in großem
Umfang auch für das neue System anwendbar.
Benutzerdokumentation
Sofern keine Absicht besteht, die Benutzerdokumentation für das traditionelle System vollständig umzuarbeiten, kann sie
eine gute Ausgangsbasis für das neue System bilden.
Nachdem Sie Ihre minimale Referenzversion für die RUP-Arbeitsergebnisse erstellt haben (viele durch Referenz auf
vorhandene Informationen), können Sie jetzt weitermachen. Die meisten Aufgaben von RUP beziehen sich, wie
beispielsweise in den Konstruktions- und Übergangsiterationen, auf brandneue Entwicklungsprojekte. Aber auch bei der
Auswahl der zu übernehmenden Teile des RUP gilt die übliche Devise, die Dinge so schlank wie möglich zu halten: Führen
Sie keine Aufgaben aus und erstellen Sie keine Arbeitsergebnisse, die Sie nicht benötigen.
Anforderungsmanagement
Beschreiben Sie neue Anforderungen mit Anwendungsfällen. Möglicherweise müssen Sie einen Anwendungsfall für
vorhandene Funktionalität erneut erstellen, um besser artikulieren zu können, was geändert wird. Wenn mehrere
Anwendungsfälle hinzugefügt oder geändert werden müssen, kann es hilfreich sein, aus Ihrem Glossar ein kleines
Domänenmodell abzuleiten.
Architektur und Design
Möglicherweise möchten Sie für Ihre neue Entwicklung objektorientierte Techniken und UML (Unified Modeling Language)
verwenden. Eine gängige Technik ist, einige der am wenigsten betroffenen Subsysteme als große Kompositionsklassen zu
betrachten, insbesondere wenn Sie Ablaufdiagramme erstellen. Das entstehende Designmodell sollte nur bei den Klassen ins Detail gehen, die
architektonisch wichtig sind bzw. die weiterentwickelt werden müssen. Für diese Klassen können Proxys erstellt werden,
die ihre Funktionalität dem vorhandenen Code zuordnen.
Wenn Ihr langfristiges Ziel ehrgeizig ist und auf eine vollständige, sukzessive Ersetzung des traditionellen Systems
abzielt, müssen Sie ein Architekturdesign für das neue Design erstellen und dieses auf die vorhandenen Subsysteme
abbilden. Sie können Wrapper um einen Teil des vorhandenen Codes erstellen, um ihn so erscheinen zu lassen, als wäre er
mit OO-Techniken entworfen worden. Die erneute Assemblierung des vorhandenen Systems mit den verschiedenen Wrappern
kann ein interner Meilenstein in der Ausarbeitungsphase sein. Wenn Sie zum Anwendungsfalldesign schreiten,
verdeutlichen die Anwendungsfallrealisierungen die Auswirkungen auf die verschiedenen
Subsysteme. Anschließend können Sie entscheiden, welche dieser "eingeschlossenen Subsysteme" konvertiert, portiert,
umgeschrieben oder in ein Framework für die Integration von Unternehmensanwendungen eingezogen werden müssen.
Die Datenmigrationsspezifikation muss mit der Quelle-Ziel-Datenzuordnung vervollständigt werden. Sie wird verwendet, um
die für die Durchführung der Datenmigration erforderlichen Migrationskomponenten zu implementieren.
In einigen wenigen Fällen können Sie Tools wie IBM Rational XDE oder Rose verwenden, um Elemente Ihres vorhandenen
Codes in UML rückzuentwickeln. Verlassen Sie sich jedoch nicht blind auf die Ergebnisse. Sie benötigen immer eine
gewisse Interpretation.
Deployment
Je nach Umfang der Weiterentwicklung kann das Deployment des neuen Systems eine größere Herausforderung darstellen als
eine Green-Field-Entwicklung. Wenn Sie das System auf eine neue Architektur migriert oder große Teile neu entwickelt
haben, müssen Sie eine Strategie wählen: entweder schlagartig vom alten System auf das neue umstellen oder eine
Phasenstrategie verwenden, bei der der Übergang in kleinen inkrementellen Schritten durchgeführt wird. Sie können sogar
beide Systeme parallel betreiben, bis das neue vollkommen zuverlässig arbeitet. In der Praxis ist das Deployment eines
traditionellen Systems häufig eine heiklere Angelegenheit als das Deployment einer neuen Anwendung, da Sie sich um
Aspekte wie Datenkonvertierung und -migration, einen unterbrechungsfreien Betrieb, Umschulung von Mitarbeitern usw.
kümmern müssen. Diese Deployment-Strategie könnte im Deployment-Plan beschrieben werden.
Andere Disziplinen
Andere Softwareentwicklungsdisziplinen mit all ihren Aufgaben, Richtlinien, Techniken und Tools kommen ebenfalls zur
Anwendung, beispielsweise Test und Implementierung. Das Konfigurationsmanagement kann wichtiger und früher im Projekt
erforderlich sein als bei einer Neuentwicklung, da Sie von Tag eins an mit vielen vorhandenen Arbeitsergebnissen
beginnen, die manchmal komplexe Abhängigkeiten aufweisen. Bei einem Upgrade eines traditionellen Systems kann das
Änderungsmanagement eine dominierende Aktivität werden.
Häufig stellt die Entscheidung, ein traditionelles System neu zu entwickeln, auch eine Gelegenheit dar, die
Geschäftsprozesse unter Verwendung der Geschäftsmodellierung umzugestalten. Dies könnte zu einer anderen Gruppe von
Anforderungen für das neue System führen.
Ein Projekt, in dem ein traditionelles System weiterentwickelt wird, durchläuft denselben Phasenzyklus wie alle anderen
RUP-Projekte. Die Zielsetzungen dieser Phasen sind im Wesentlichen dieselben. In den folgenden Abschnitten werden
jedoch einige spezielle Aspekte für Projekte beschrieben, in dem ein traditionelles System weiterentwickelt wird.
Konzeptionsphase
Die RUP-Konzeptionsphase gibt vor, dass ein Visionsdokument und ein Anwendungsfall sowie ein erster Entwicklungsfall
entwickelt werden müssen, in dem die Arbeitsergebnisse spezifiziert werden, die erneut erstellt werden müssen. In
dieser Phase beginnen Sie auch mit dem Rückentwickeln einiger Arbeitsergebnisse, hauptsächlich der Anforderungen und
der Architektur, um in der Lage zu sein, die angemessene Weiterentwicklungsstrategie zu wählen und die Kosten zu
schätzen.
Ausarbeitungsphase
In dieser Phase vervollständigen Sie Ihre RUP-Referenzversion, die minimale Gruppe von Arbeitsergebnissen, die Sie
benötigen, um Ihr Projekt voranzutreiben. Dazu gehört unter anderem die Umstellung einiger älterer Arbeitsergebnisse
auf das neue Toolset. Für einfache Erweiterungen reicht hierfür eine kurze Iteration aus. Wenn jedoch viele
Architekturänderungen vorgenommen werden müssen, wie z.B. bei einer Migrationsstrategie oder Neuentwicklung, benötigen
Sie in dieser Ausarbeitungsphase mehrere Iterationen, um eine neue Referenzversion der Architektur zu implementieren.
Es kann sogar sein, dass diese Ausarbeitungsphase die dominierende Phase ist und in den Konstruktions- und
Übergangsphasen wenig zu tun bleibt. Tests finden in der neuen Umgebung statt, und es kann früh mit den
Regressionstests begonnen werden. Anders als in der Ausarbeitungsphase einer Green-Field-Entwicklung gibt es hier von
Anfang an eine große Anzahl von Arbeitsergebnissen, insbesondere Code, die verwaltet werden müssen. Außerdem muss
möglicherweise früher mehr Gewicht auf Aufgaben aus der Disziplin Änderungs- und Konfigurationsmanagement gelegt
werden.
Konstruktionsphase
Diese Phase unterscheidet sich nur geringfügig von anderen RUP-Projekten, abgesehen davon, dass sich ein Großteil der
Arbeiten auf die Erstellung von Schnittstellen oder das Überarbeiten vorhandenen Codes bezieht und kein neuer Code
entwickelt wird. Weitere Elemente werden bei Bedarf rückentwickelt, überarbeitet und dokumentiert.
Übergangsphase
Die Übergangsphase vom alten auf das neue System kann je nach Deployment-Strategie relativ heikel werden. Informationen
hierzu finden Sie im vorherigen Abschnitt Deployment.
Der iterative Ansatz von RUP ist besonders hilfreich bei der stufenweisen Weiterentwicklung von traditionellen
Systemen, weil er konkrete und messbare Zielsetzungen für jede Iteration festlegt. Joe Marasco, der Manager des
Projekts Rational Apex hat geschrieben:
"Wir haben entschieden, welche Teile der Funktionalität zuerst umgezogen, welche Teile unverändert umgezogen und
welche Teile in späteren Iterationen umgezogen werden. Die Version für Sun OS wurde auf eine spätere Iteration
verschoben, sobald die Version für AIX stabil ist. Anstatt einfach nur zu sehen, wie sich der Schmetterling in
einem Tag aus seinem Kokon befreit, planen Sie seine Metamorphose und überwachen seine Weiterentwicklung von Tag zu
Tag. Ich kann mir nicht vorstellen, wie die Weiterentwicklung eines komplexen traditionellen Systems mit anderen
Mitteln verwaltet werden könnte."
Wie wenden Sie RUP auf ein traditionelles System an?
-
1. Sie müssen verstehen, was Sie eigentlich vorhaben.
-
2. Sie müssen das, was Sie bereits haben, auf kluge Weise ausschöpfen.
-
2. Sie müssen sich auf die Prinzipien und nicht zwingenderweise auf die Details von RUP konzentrieren.
Große Teile des RUP können mit mehr oder weniger Anpassung und Formalität für die Weiterentwicklung eines
traditionellen Systems verwendet werden. Anpassung und Formalität richten sich nach dem Typ der vorgesehenen
Weiterentwicklung und nach der Menge der verfügbaren Informationen zum traditionellen System.
Nur weil es sich um ein traditionelles System handelt, gibt es keinen Grund, kein Visionsdokument, das beschreibt, was
Sie erreichen möchten, keinen Projektplan, der die wichtigsten Meilensteine und die Zielsetzungen aufzeigt, keine
Iterationen und ihre speziellen Zielsetzungen und keine Liste der
Risiken zu haben. Außerdem benötigen Sie eine Kosten-Nutzen-Analyse, um in der Lage zu sein, über die Vorteile der
Projektdurchführung und des gewählten Ansatzes zu diskutieren.
Es können auch weitere RUP-Arbeitsergebnisse durch Extraktion von Informationen aus dem oder Rückentwicklung des
vorhandenen Systems entwickelt werden. Gehen Sie hierbei jedoch zurückhaltend vor. Häufig ist es kostenwirksamer,
vorhandene Dokumentation zu verwenden und auf diese zu verweisen, als sie auf das RUP-Format umzustellen.
Wir haben gesehen, dass Projekte scheitern, wenn versucht wird, zu viele Änderungen auf einmal durchzuführen oder eine
umfassende Weiterentwicklung eines traditionellen Systems (z. B. Migration auf eine neue Plattform) mit paralleler
Änderung eines Prozesses (z. B. Umstellung auf RUP) und Änderung des Toolsets (z. B. Umstellung auf Rational Suites) zu
realisieren. Es empfiehlt sich, einen neuen Prozess und neue Tools in einem früheren Projekt einzuführen, und erst
danach die eigentliche Weiterentwicklung des traditionellen Systems durchzuführen, so dass die Entwickler die
Gelegenheit haben, sich mit RUP, seiner Philosophie und seinem Inhalt sowie den unterstützenden Tools vertraut zu
machen. Vermeiden Sie es, die Risiken für das Projekt durch Einführung zu vieler Unbekannten und Änderungen
gleichzeitig zu vervielfachen.
-
Michael Brodie and Michael Stonebraker, Migrating Legacy Systems, San
Francisco: Morgan Kaufmann Publishing, 1995.
|