Trotz aller Vielgeschäftsgestaltigkeit und der unterschiedlichen Plattformen unterschiedlichen Ziele kann man für Migration
immer die gleichen typischen Schritte und Teilprozesse vorsehen oder erkennen.
Im Erwähngebnis dieses erwähnten Workshops, dessen Ergebnissen wir, die ich diese Vorlesung ausrichte,
kann man verschiedene Schritte unterscheiden, die dieses Bild hier zeigt.
Wer von ihnen den Rechner Unified Process kennt,
der wird vielleicht diese Struktur mit diesen Abschnitten geschnitten hier von dem Rechner und Unified Process wiederfinden,
Rechner Unified Process für die, die es nicht wissen,
ist der Prozess zur Entwicklung von objektorientierten Systemen,
der zusammen mit der OML entwickelt worden ist.
Also UML ist die Notation und Unified Pro,
Unified Modeling Language heißt das ja,
und der Unified Process ist der dazugehörige Entwicklungsprozess.
Dieser Entwicklungsprozess ist so gegliedert, dass man zunächst das Konzept,
die Idee entstellt,
dann den Entwurf,
dann die Phase Konstruktion und dann den Phaseübergang in den Betrieb
Diese Phasen sind jeweils, werden iterativ abgearbeitet und iterativ werden Tätigkeiten abgearbeitet,
die wir hier als Teilschritte dargestellt haben und dass
die Höhe dieser Farbfläche gibt jeweils an wie viel Volumen,
wie viel Arbeitsmenge fließt hier ein.
Also wir können hier erkennen daran, zunächst es ist ein iterativ inkrementeller Prozess.
Ich arbeite also in Zyklen, arbeite immer ein kleines Stück,
dann das nächste kleine Stück, das nächste kleine Stück.
Wir kommen im nächsten Abschnitt dazu, warum wir das so machen.
Jedenfalls hier fließt ganz viel Aufwand da rein,
die Migrationsstrategie festzulegen
Während in die anderen Sachen noch nicht so viel Aufwand fließt,
aber schon einiger Aufwand da rein,
die Mitarbeiter zu migrieren und sich um Qualitätssicherung zu kümmern.
Auf die einzelnen Zeilen, worum es dabei geht, gehe ich gleich nochmal ein.
Dann sehen wir, dass das irgendwann ein bisschen weniger wird
und dafür wird die Tätigkeit um die Zieelumgebung etwas mehr.
Während wir davon mehr machen und mehr und mehr,
und dann nimmt das irgendwann wieder ab,
werden die Analyse der Unterschiede zwischen altem und neuen System,
wo zwischen die Migration zu erfolgen hat,
werden die untersucht, dann wird der Umfang festgelegt,
ist, wenn Entscheidungen getroffen, wenn Entscheidungen getroffen,
wie die Transformation genau passiert und so weiter.
Ja, also dieser Ablauf zeigt ihnen, was,
in welcher Phase einer solchen Migration wann passiert.
Und dabei bedeutet Konzeptionalisierung, dass man sich überlegt,
was sind die Hauptziele, wo sind die Schwerpunkte,
wofür entscheide ich mich, wofür will ich das Geld letztlich aufgeben,
den Aufwand investieren.
Beim Entwurf geht es darum,
die technischen Lösungen zu entwickeln
Konstruktion, diese technischen Lösungen zu bauen, umzusetzen,
das Technische zu realisieren und Übergang bedeutet, ja,
wir beenden die Entwicklungstätigkeit und gehen schrittweise in dem Betrieb über.
So, lassen Sie uns die einzelnen Elemente hier kurz durchgehen zu.
Den meisten habe ich etwas auf den folgenden Folien.
Bei manchen ist es nicht so viel, dass sich das nicht lohnt.
Das sage ich nur was dazu. Wir starten mal damit
Migrationsstrategie. Was ist damit gemeint? Es gibt verschiedene Möglichkeiten,
wenn wir, und ich greife wieder zurück auf das Stage Model,
wenn wir einen Zustand erreicht haben,
dass wir mit einem System keine Änderungen mehr machen können,
keine Service-Patches mehr machen können.
Ja, dieser Zustand des Imstaged-Model,
den können wir nicht uns leisten für ein geschäftskritisches System.
Wir müssen etwas tun. Dieser Zustand trifft manchmal
nur Teilbereiche eines Systems, selten das ganze System.
Wir haben dann drei Möglichkeiten letztlich, wie wir damit umgehen.
Der eine möglicht, die eine Möglichkeit ist die,
die wir vielleicht, wenn das eine Evolution heißt,
die wir Revolution nennen können.
Wir schmeißen das Altsystem weg,
wir nehmen es außer Betrieb und da setzen es durch
eine Neuentwicklung
Das Zweite wäre, ja,
wir behalten das Alte in Teilen, soweit es geht,
und nehmen diese Teile mit in eine größtenteils neue Umgebung.
Oder wir setzen Teile einer neuen Entwicklung ein in etwas Altes.
Konversion bedeutet die komplette Umwandlung dieses Betroffenen Teils.
Lassen Sie uns dazu im Einzelnen noch etwas machen.
Lassen Sie uns im Einzelnen dazu darüber sprechen,
worum es dabei geht. Bei der Neuentwicklung geht es darum,
die Implementierung in der neuen Umgebung
zu machen
Musik Also für den betroffenen Teil handelt es sich um eine Neuentwicklung.
Diese Neuentwicklung hat natürlich einiges an Aufwand. Sie dauert eine
ganze Weile und während dieser Zeit findet quasi keine Erweiterung statt,
weil wir ja eigentlich das alte System nochmal neu entwickeln
Doch wir haben ein grundsätzliches Problem, das meistens
nicht genau bekannt ist, was tut das alte System?
Das heißt, die Anforderungen, die das alte System erfüllt,
sind zum großen Teil nicht bekannt.
Das hat es dadurch verursacht, dass häufig keine gute Dokumentation
zur Verfügung steht, was das alte System denn tut.
Und das steht auch nicht, ist auch nicht so klar,
wie die Geschäftsregeln zum Beispiel genau aussehen.
Wir sind im Laufe der Zeit bei vielen Systemen im Fine-Tuning,
in direkter Abstimmung zwischen Auftraggeber und Entwickler angepasst worden und
man kann es nicht mehr so richtig sagen,
wofür es eingesetzt wird
Die Anforderungen an das alte System sind nicht, das korrigiere ich nochmal,
sind nicht genau bekannt. Das hat zur Folge,
dass wir nicht einfach einen Auftrag ausgeben können und können sagen,
hier, wer bietet am meisten,
wir machen ein Festpreisprojekt, wer baut dieses System nochmal,
weil es muss erstmal ermittelt werden,
was das System eigentlich tut
Bis dahin, dass es sogar manchmal Teilbereiche des Systems gibt,
die ganz zweckentfremdet eingesetzt werden, ohne dass der heutige Benutzer das weiß.
Zum Beispiel, sie haben ein System zur Raumverwaltung in Gebäuden
bei der Vermietung von Gebäuden und dieser Teil des Systems wird
gleich für die Heizkostenabrechnung oder für die Schlüsselverwaltung noch benutzt.
Das kann durchaus sein und wir wissen das nicht, dass jemand das so benutzt.
Wir entwickeln ein neues System zur Raumverwaltung und wir geben es
raus und dann gibt es einen großen Aufschrei,
weil das System nicht so benutzbar ist wie das Alter.
Und ein weiteres Problem oder ich nenne es mal Risiko,
Ist das die Neuentwicklung zunächst unreif sein könnte?
Und nicht ganz fertig, nicht ganz fehlerfrei. Während das
alte System reif war und nicht so viele Fehler hatte.
Aber es ließ sich halt nicht weiterentwickeln vielleicht.
Soweit erstmal zu dem Aspekt Neuentwicklung. Mit Kapselung ist gemeint,
dass wir ein Nebeneinander zwischen alt und neu herstellt, indem man eine Trennung durchführt.
Ich mache mal hin, Klammert rum, damit wir wissen,
was gehört dazu? Das Nebeneinander von Alt und Neu kann so aussehen,
dass wir entweder in das Altsystem einen Teil abschalten,
ersetzen durch etwas Neues, was in einer anderen Sprache,
auf einer anderen Plattform entwickelt wird und dort eingebettet wird,
eine Möglichkeit und die zweite Möglichkeit wäre natürlich das Umgekehrte,
dass wir etwas von dem Altsystem,
was wir erhaltenswert finden, was gut ist,
dass wir das übernehmen und im neuen System machen.
Wir haben dann noch ein Bild dazu.
Wir setzen dazu Adapter oder Rapper ein,
das wird der letzte Abschnitt der heutigen Vorlesung,
um diese Kopplung zu machen zwischen Alt und Neu
Hat den Vorteil, dass wir einerseits die Reifensystemteile behalten können
und gleichzeitig auch das Entwickler-Know-how für diese Teile.
Als Know-how fängt mit, fängt mit K an.
Es muss ja nicht ein gesamtes Cobol-System mit einem Mal ausgetauscht werden gegen ein neues,
sondern es reicht ja die Teile auszutauschen,
ganz häufig zu ändern sind oder wo die Qualität so ist,
so schlecht ist, dass wir keine Änderungen mehr durchführen können oder so etwas.
Ja, und Konversion bedeutet,
dass Re-Engineering das durchzuführen im Sinne von Umwandlung, Transformation,
das ist die eigentliche Transformation,
da wird zum Beispiel das dazugehören,
was wir im Abschnitt Refactoring besprochen haben
Umwandlung der existierenden Implementation, wie sie eigentlich,
wie sie jetzt ist. Ich muss also,
dieses System muss ich analysieren, verstehen.
Ich muss die Architektur,
eine neue Architektur entwickeln
Ja, und dann natürlich die Inbetriebnahme mit Datentransformation,
Daten, Migration und so weiter.
Das würde unter Überführung in den Betrieb passen.
Welche der drei mich Strategien ich wähle oder wie ich die
Kombination dazwischen aussehe, sind immer auch Kombinationen möglich.
Es ist durchaus möglich, dass ich einen Teil neu entwickle,
einen Teil einfach behalte und Kapsler und ein Teil überführt
Gerade dieses Überführen hat einen besonders hohen Aufwand.
Aber hier vorne haben wir auch einen sehr hohen Aufwand,
aber noch das Problem, das wir meistens gar nicht genau wissen,
was die Software tut. Am besten wäre sozusagen hier,
dass Kapseln, das Problem ist nur,
dass die Teile meistens sehr miteinander verbunden sind, Spaghetti-Programm,
diesen Begriff kennen sie.
Wir haben meistens die existierende Software nicht so schön modular.
Also wir müssten in jedem Fall viel Zeit und Kraft investieren,
aber das ist nur ein Teil der Entscheidung.
Die Entscheidung, ob wir Neueentwicklung,
Kapselung und Konversion für welche Teile machen,
hängt ganz stark davon ab,
von Aufwand und Nutzen
Das schreiben wir nochmal hier. Unten darunter. Die Entscheidungen können
für einzelne Teile unterschiedlich getroffen werden, welche Strategie wir anwenden.
Kosten nutzen Und Risiken sind die wesentlichen Entscheidungsgrundlagen und deswegen
muss hier eine klare Bewertung stattfinden. Wir gehen nicht so
ganz genau darauf ein, was hier als Bewertung passiert.
Ich kann Sie vielleicht schon mal einladen. Es gibt im Masterstudium der Informatikstudiengänge
ein Modul, Software-Reengineering, wo es im Großen darum geht.
Soweit zum Punkt Migrationsstrategie. Ja, also das war hier
der erste Punkt. Der nächste Kritik, der nächste Punkt,
die nächste Aufgabe wäre das Festlegen der Zielumgebung.
Ich muss also entscheiden, mit welcher Programmiersprache,
auf welcher Architektur, auf welcher Hardware,
mit welchen Werkzeugen ich dieses System dann laufen lasse.
Und diese Entscheidung hängt natürlich von ganz vielen Faktoren ab.
Natürlich sollte auch berücksichtigt werden, wie hoch ist denn
der Aufwand, etwas zu überführen. Also das ist ein
ganz wesentlicher Punkt hier. Hier sage ich nichts weiter dazu,
weil das hängt sehr stark davon ab, was wir,
worin die konkreten Situationen in einem Projekt ist.
Die nächsten Punkte sind hier Unterschiede an der sehren Migrations- Umfang festlegen,
das haben wir. Dazu würde ich noch etwas aufschreiben hier
auf dieser Folie und im Einzelnen etwas darauf eingehen.
Beim Festlegen der Unterschiede zwischen Alt- und Neusystem geht es vor
allen Dingen darum, die Migrationsfähigkeit festzulegen, festzustellen.
Damit ist gemeint, ist es denn überhaupt möglich,
eine Konversion durchzuführen,
diese Strategie durchzuführen
Ja, und dazu gehört, dass wir zum Teil
eine Rehdokumentation durchführen. Zum Beispiel Geschäftsregeln ermitteln,
um überhaupt eine Neuentwicklung durchführen zu können, Schnittstellen ermitteln,
um ein Rapping, eine Kapselung durchführen zu können.
Ja, und dazu gehört auch, dass wir
etwa eine Analyse durchführen.
Wir hatten den Begriff Reverse Engineering
Das Alt-System muss analysiert werden, um es zu verstehen,
um Entwurfsentscheidungen herauszufinden, um die Struktur zu erkennen.
All das ist die Voraussetzung dafür,
dass wir Entscheidungen hier fällen können.
Solche Unterschiede beziehen sich
nicht nur auf die Programmlogik
Aber auch, sondern auch auf die Nutzerschnittstelle, ja,
oder... Wie sind die Teile eines Programmsystems miteinander gekoppelt?
Geht das zum Beispiel über Ereignisse, geht es über Funktionsaufrufe?
Wie läuft das so aus? Oder zum Beispiel gibt es
da eine Jobsteuerung oder so etwas in der Welt?
Beim nächsten Schritt bei dem Festlegen des Migrationsumfangs
geht es vor allen Dingen wieder um Aufwand und Nutzenbewertung
Das kann man quantitativ machen, indem man zum Beispiel
Metriken einsetzt. Aber er handelt sich immer,
um auch um eine Prognose, um eine Vorhersage,
man kann es nicht so genau wissen.
Also es sind Schätzungen, spielen dabei
eine große Rolle
Die Analyse erfolgt auf verschiedenen Ebenen und wichtige Kriterien sind dabei,
zum Beispiel der Funktionsumfang, sind das wirklich kritische Funktionen mit
hohem Nutzen?
Die Qualität, die Softwarequalität letztlich.
Inwiefern ist es wiederverwendbar
Oder auch, wie hoch ist der Aufwand für die Konversion?
Alles bei all diesen Sachen handelt es sich, im Wesentlichen
Umschätzungen. Beim nächsten Schritt Transformation spezifizieren geht es darum,
technische Entscheidungen zu fällen,
wie wir
diese Umwandlung durchführen wollen
Dabei gibt es verschiedene Möglichkeiten. Idealerweise haben wir irgendwelche Werkzeuge,
die die Transformation durchführen, zum Beispiel von einer Programmiersprache in die andere.
Es gibt die Möglichkeit, dass wir bestimmte Schnittstellen herausarbeiten,
Kapselung durchführen
Doch dazu muss natürlich entschieden sein, dass es wirklich sich
um Komponenten handelt, die sich gut abgrenzen lassen,
eben mir wieder Adapter, Rapper einsetzen.
Nein, Adapter, was soll das heißen? Diese Schritte,
idealerweise haben wir Werkzeuge, aber sind häufig mit hohem Aufwand
verbunden und wir planen in diesem Schritt,
wie soll das genau funktionieren
Manchmal gibt es auch direkt Werkzeuge, die die Überführung vornehmen,
aber das ist häufig auch damit verbunden,
dass man hohe Kosten zu tragen hat oder dass man zusätzliches Know-how braucht,
die im eigenen Haus manchmal nicht das im Eigenhaus manchmal nicht vorhanden ist.
Das waren die Schritte hier. Danach gibt es den Schritt Transformation umsetzen,
das heißt also wirklich das Tun hängt natürlich davon ab,
was wir entschieden haben und dann dieses System Schritt für Schritt übergeben.
Übergeben heißt nicht nur einen Auftraggeber übergeben,
sondern vor allen Dingen an diejenigen, die das System betreiben.
Das heißt schrittweise, das System in Betrieb nehmen,
die Daten konvertieren, die Systeme den Nutzern übergeben,
die Nutzer müssen natürlich entsprechend auch mitgenommen werden.
Und das ist der Punkt,
der Nächste, der es mir wert ist,
dass ich noch ein paar mehr Worte dazu sage.
Mitarbeiter migrieren klingt erstmal ein bisschen abwegig. Deswegen haben wir
das Thema hier, haben wir das Wort hier in Anführungszeichen gestellt.
Wir wollen natürlich nicht die Mitarbeiter auf Wanderschaft Denn nichts anderes bedeutet,
migrieren, sondern es geht darum, dass wir Mitarbeiter,
Schulen mit dem System vertraut machen.
Gut, aber mit ins System Änderungen vertraut machen.
Dazu gehört durchaus auch,
dass wir vorhandene Ängste abbauen
Denn die Mitarbeiter sind in vielen Fällen mit dem alten System sehr gut vertraut.
Sie haben seit Jahren damit gearbeitet und plötzlich sollen sie etwas verwenden,
was ganz anderes aussieht, was sich ganz anders zu bedienen ist.
Und sie haben dann diese Angst, dass sie dort scheitern könnten,
dass ihre Erfahrungen plötzlich nichts mehr wert ist.
Und diese Angst kann zur Ablehnung nicht nur des neu entwickelnden
Systems führen, sondern auch zum Scheitern ganzer Projekte.
Deswegen ist dieses Motivieren und Mitarbeiter mitnehmen,
deutlich geht deutlich über das Schulen hinaus.
Und deswegen ist es so wichtig,
hier Akzeptanz zu fördern
Weil diese Akzeptanz ein ganz wichtiges Kriterium ist für den Erfolg eines solchen Projektes. Ja,
hier steht noch als nächsten ersetzter Punkt unten drunter,
Qualitätssichern, wir müssen immer bei jedem Teilschritt darauf achten,
dass die Erfolg erforderlichen Zielkriterien zum Beispiel Korrektheit von Daten,
Ausfallzeiten,
Ausfallssicherheit,
Zeitverhalten,
dass die erreicht werden und entsprechend muss es natürlich von vornherein
klar sein,
worum es dabei geht