Dieses Kapitel legt die Grundlagen zu Software-Migrationen. Neben einer Definition und Begriffsabgrenzung werden Phasen untersucht, Ressourcen beschrieben und Risiken offenbart. Es wird ein grundsätzliches Verständnis einer Migration im Gegensatz zur klassischen Neuentwicklung geschaffen.
Software-Migration ist die Überführung eines Systems in eine andere Zielumgebung, ohne dabei die [fachliche] Funktionalität zu verändern (Gimnich und Winter 2005, S. 22). Im Gegensatz zur Softwareentwicklung ist die Grundlage für das Migrationsprojekt ein bestehendes System, dessen Umwelt sich verändert. Ziel ist es, das System an die modifizierten Gegebenheiten anzupassen, ohne Funktionalitäten zu reduzieren oder zu erweitern. Die funktionalen Anforderungen bleiben bestehen. Die Software-Migration grenzt sich daher von der Weiterentwicklung ab (Sneed et al. 2004, S. 19). Aus Sicht des Anwenders ergibt sich aus der Software-Migration nicht zwangsläufig ein Mehrwert. Nach erfolgreicher Umstellung kann er die gleichen Funktionen nutzen wie zuvor. Ohne Modifikation der Benutzerschnittstelle ist unter Umständen nicht bemerkbar, dass eine Migration stattgefunden hat. Die Frage nach der Sinnhaftigkeit der Software-Migration bei Anwendungssoftware ist berechtigt. Sie kann eine notwendige Vorstufe zur Implementierung neuer Funktionalität sein, wenn beispielsweise das Basissystem aufgrund monolithischer Eigenschaften keine Erweiterungen erlaubt. Der Mehrwert besteht in der Schaffung von zukünftigen Anpassungspotenzialen, die später bei einer Weiterentwicklung genutzt werden können. Durch Migration kann beabsichtigt sein, die Qualitätseigenschaften einer Software zu verbessert. Bei Umwandlung der Architektur von prozeduraler Programmierung zu objektorientiertem Paradigma kann die Änderbarkeit und Wiederverwendbarkeit erhöht werden. Die Performanz lässt sich durch Portierung auf schnellere Hardware optimieren. Durch Anpassung des User Interface kann eine höhere Benutzerfreundlichkeit erzielt werden.
Im Rahmen von Enterprise Application Integration (EAI) ist gewünscht, Software miteinander zu vernetzen, um die Kommunikation zu verbessern und Medienbrüche zu vermeiden. Dazu sind Schnittstellen erforderlich. Wenn eine Software im Unternehmen etabliert ist und ihren Zweck zufriedenstellend erfüllt, besteht der Bedarf diese Software auch weiterhin zu nutzen. Sind keine geeigneten Schnittstellen vorhanden, ist ganzheitliches EAI nicht umsetzbar. Hier bietet sich eine Migration an, um die Voraussetzungen für die Integration zu schaffen. Die vollständige Neuentwicklung ist vermutlich keine wirtschaftliche Alternative, da die Legacy-Software zu großen Teilen unverändert weitergenutzt werden kann. Es empfiehlt sich eine Migration.
Software-Migration kann eine Aktivität im Rahmen von Software Maintenance sein.
“Software Maintenance is the process of modifying a software system or component after delivery to correct faults, improve performance or other attributes, or adapt to a changed environment.” (IEEE 1990, S. 46)
Die Definition kann in drei Ausprägungsformen aufgespalten werden, für die Swanson bereits im Jahr 1976 Termini eingeführt hat (1976, S. 493). Die Begriffe wurden in den internationalen Standard ISO/IEC 14764:2006 übernommen und um die Kategorie preventive Maintenance erweitert (ISO/IEC 2006, S. 25), sodass ein umfassenderes Spektrum des Software Maintenance abgebildet wird.
1. Corrective Maintenance hat die Behebung identifizierter oder aufgetretener Fehler zum Ziel. Falls die zuvor definierten Anforderungen durch die Software nicht erfüllt werden, sind Korrekturen notwendig, die ebenfalls unter diese Kategorie fallen. Durch Migration allein werden Fehler einer Software nicht behoben. Die Korrekturen an einer besser strukturierten Software dürften jedoch durch Komplexitätsreduktion mit weniger Aufwand verbunden sein als im unstrukturierten Zustand.
2. Bei perfective Maintenance wird die Software verbessert oder erweitert. Die Verbesserung der Qualitätseigenschaften fällt unter diese Kategorie (insbesondere Performanz und Wartbarkeit). Die Ursache für perfective Maintenance sind unerkannte Anforderungen, die in der Entwicklungsphase nicht spezifiziert wurden und daher nachträgliche Anpassungen notwendig machen. Beispiele sind Implementierung neuer Funktionalität oder Erstellung einer Dokumentation durch Reverse Engineering. Migration kann geeignet sein, um Qualitätseigenschaften der Software zu verbessern. Das Laufzeitverhalten einer Software kann beispielsweise durch Austausch des Datenbankmanagementsystems verbessert werden, wenn schnellere Antwortzeiten für Datenabfragen erreicht werden.
3. Durch adaptive Maintenance soll ebenfalls eine Verbesserung oder Erweiterung der Software herbeigeführt werden. Im Unterschied zum perfective Maintenance sind Anpassungen aufgrund von Veränderungen der Systemumgebung notwendig. Daraus ergibt sich zum Beispiel ein Bedarf an Schnittstellen oder die Notwendigkeit zur Kompatibilität mit neuer Hardware. Für die Durchführung von Wartungsarbeiten dieser Kategorie ist Migration erforderlich. Das bestehende System soll in einer neuen oder modifizierten Zielumgebung weiterhin lauffähig sein und genutzt werden.
4. Preventive Maintenance wird vorsorglich durchgeführt, um mögliche zukünftige Probleme zu verhindern. Es wurden potenzielle Schwachstellen identifiziert, die beseitigt werden sollen. Migration kann sinnvoll sein, wenn antizipiert wird, dass eine andere Zielumgebung für die Legacy-Software besser geeignet ist (z. B. höhere Performanz und Sicherheit). Die Abgrenzung zum perfective Maintenance ist damit nicht trennscharf, da diskutiert werden kann, ob der Bedarf einer möglichen zukünftigen Performanzsteigerung nicht auch schon eine aktuelle, veränderte Anforderung darstellt.
Es konnte gezeigt werden, dass Migration im Rahmen von Software Maintenance von hoher Relevanz ist. Der Begriff ist weiter gefasst als Software-Migration, da eine Veränderung der Funktionalität nicht ausgeschlossen wird und die Zielumgebung nicht zwangsläufig gewechselt wird. Die Definition zeigt jedoch, dass Migration Teil der Wartung sein kann. Sie adressiert Probleme, die sich aus einer veränderten Situation ergeben. Für jede Kategorie kann eine Begründung zur Durchführung einer Migration aufgezeigt werden. Bei adaptive Maintenance ist sie sogar eine Notwendigkeit. Die Aufteilung ist als idealtypisch zu sehen. In der Praxis ist eine Kombination mehrerer Kategorien in einem Maintenance-Projekt wahrscheinlich. Während der Wartungsarbeiten muss mit Einschränkungen in der Nutzung der Software gerechnet werden, sodass die Projektleitung bemüht sein dürfte, angestaute Änderungswünsche zu bündeln und in einem Hergang zu realisieren. Dadurch kann der Aufwand gesenkt werden. Andererseits ist das Risiko eines Fehlschlags höher, da gleichzeitig mehrere Modifikationen durchgeführt werden und unvorhergesehene Wechselwirkungen auftreten können. Eine differenzierte Untersuchung im konkreten Fall, ob eine Zusammenfassung mehrerer Maintenance-Aufträge unter wirtschaftlichen Gesichtspunkten sinnvoll ist, ist empfehlenswert.
Software-Migration ist ein Teil des Software-Reengineering, wie sich am Beispiel der Workshopreihe „Reengineering Prozesse (RePro)“ zeigt, in der Software-Migration das Kernthema ist (Kaiser et al. 2005; Kaiser et al. 2006). „Software-Reengineering umfasst alle Aktivitäten, die auf die ursprünglich nicht geplante Wiederverwendung eines vorhandenen Software-Systems (Altsystem) oder von einzelnen Teilen dieses Systems bei der Erstellung eines neuen Software-Systems gerichtet sind“ (Baumöl et al. 1996, S. 193). Software-Migration ist damit Reengineering, da Vorhandenes wiederverwendet werden soll. Eine Unterscheidung ob ein neues System mit Komponenten aus einer Legacy-Software erstellt wird oder ob ein Altsystem bestehen bleibt und Bestandteile durch neue Komponenten ersetzt werden, ist nicht notwendig und kann in beiden Fällen als Migration bezeichnet werden. Im ersten Fall werden Altkomponenten in eine neue Software migriert. Im zweiten Fall werden neue Komponenten in ein Altsystem migriert. Software-Reengineering umfasst neben der Migration zum Beispiel noch Systemerhaltung, Integration, Erweiterung und Redokumentation (Gimnich und Winter 2005, S. 22). Wie bereits beschrieben kann Migration eine Voraussetzung für Integration und Erweiterung sein. Die Redokumentation eines vorhandenen Systems kann wiederum für die Migration vorteilhaft sein. Durch eine geeignete semantische Repräsentation der Software können Wiederverwendungspotenziale ermittelt werden und damit jene Teile identifiziert werden, die bestehen bleiben können.
Die Bezeichnung „Engineering“ stellt den Zusammenhang zur ingenieursmäßigen Durchführung der Aktivitäten her, das heißt der Einsatz von geeigneten Vorgehensweisen, Prinzipien, Methoden und Werkzeugen wird zugrunde gelegt (Broy und Rombach 2002, S. 438). Das deutet auf hinlängliche Komplexität des Vorhabens hin. Migration im Kontext von Software-Reengineering ist damit keine triviale Aufgabe. Sie ist als Projekt zu verstehen, das neben der Implementierung der adäquaten Planung, Steuerung und Kontrolle bedarf. Die ausschließliche Fokussierung auf die technische Durchführung wird dem...
