Konzept: Weiterentwicklung traditioneller Systeme
Dieses Konzept definiert eine Roadmap für die Aktualisierung, Integration und Neuentwicklung eines traditionellen Systems.
Hauptbeschreibung
Aktivitäten während des Lebenszyklus
  1. Einführung
  2. Referenzversion erstellen
  3. Vorwärts mit RUP
  4. Weiterentwicklungszyklus
  5. Zusammenfassung
  6. Referenz
Zusätzliche Themen:

Einführung

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.

Referenzversion erstellen

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.

Vorwärts mit RUP

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.

Weiterentwicklungszyklus

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."

Zusammenfassung

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.

Referenz

  1. Michael Brodie and Michael Stonebraker, Migrating Legacy Systems, San Francisco: Morgan Kaufmann Publishing, 1995.