Softwaremigration in der Praxis

Übertragung alter Softwaresysteme in eine moderne Umgebung
 
 
dpunkt (Verlag)
  • 1. Auflage
  • |
  • erschienen am 8. Januar 2016
  • |
  • 336 Seiten
 
E-Book | ePUB mit Wasserzeichen-DRM | Systemvoraussetzungen
E-Book | PDF mit Wasserzeichen-DRM | Systemvoraussetzungen
978-3-86491-889-6 (ISBN)
 
Softwaremigration behandelt die Überführung eines Softwaresystems in eine andere Zielumgebung, ohne dessen Funktionalität zu verändern. Sie ist damit eine für die Praxis wesentliche Strategie zum Erhalt bestehender Softwaresysteme.



Die Autoren beschreiben zunächst die Grundlagen der Softwaremigration und stellen Prozess- und Vorgehensmodelle zur Migration aus Literatur und Praxis vor. Ferner wird ein generischer Prozess, der Reference Migration Process (ReMiP), dargestellt, der auf alle Migrationsprojekte in angepasster Form anwendbar ist. Der Leser erhält zudem einen detaillierten Überblick über Methoden, Techniken und Werkzeuge zur Durchführung einer Migration.



Acht Migrationsfallstudien aus Europa verdeutlichen die konkrete Migrationspraxis. Abschließend findet der Leser einen Leitfaden für die Migration in eine serviceorientierte Architektur (SOA) durch die Bereitstellung von Web Services.



Aus dem Inhalt:



* Grundlagen und -begriffe der Softwaremigration

* Migrationsprozesse aus Forschung und Praxis

* Der Reference Migration Process (ReMiP)

* Methoden und Techniken der Softwaremigration

* Softwaremigrationswerkzeuge

* Migrationsprojekte aus der Praxis als Fallstudien

* Zukünftige Migrationstrends wie SOA und Web Services



Ein umfangreiches Quellenverzeichnis und ein ausführlicher Index runden das Buch ab.
  • Deutsch
  • Heidelberg
  • |
  • Deutschland
  • 10,36 MB
978-3-86491-889-6 (9783864918896)
3864918898 (3864918898)
weitere Ausgaben werden ermittelt
Harry Sneed ist seit 1967 in der IT tätig. In dieser Zeit konnte er vielfältige Erfahrungen sammeln als Programmierer, Analytiker, Projektleiter, Laborleiter, Berater, Geschäftsführer, Trainer, Hochschuldozent, Forscher und Autor. Seine Schwerpunkte sind Softwaremanagement, Softwaremetrik, Softwaremigration und Softwaretest.



Dipl.-Inform. Ellen Wolf ist als Requirements Engineer und Qualitätsmanagerin bei dem IT-Beratungshaus Cassini Consulting GmbH in Frankfurt tätig. Als Beraterin, Trainerin und Coach mit den Schwerpunkten rund um das Thema Quality Lifecycle Management war sie für Kunden bisher in zahlreichen IT-Projekten sowohl beratend als auch operativ im Einsatz.



Frau Prof. Dr. Heidi Heilmann hat nach dem Studium (VWL und BWL) zunächst bei der IBM Deutschland GmbH und dann als geschäftsf. Gesellschafterin bei der Integrata AG gearbeitet. Danach wechselte sie an die Fachhochschule Furtwangen und war ab 1986 14 Jahre am Betriebswirtschaftlichen Institut, Abteilung ABWL und Wirtschaftsinformatik der Universität Stuttgart tätig.
  • Intro
  • Vorwort
  • Inhaltsübersicht
  • 1 Einleitung zum Thema Softwaremigration
  • 1.1 Die Motivation für Softwaremigration
  • 1.2 Zum Zustand der IT in der betrieblichen Praxis
  • 1.3 Alternativen zur Bewältigung von Altlasten
  • 1.3.1 Neuentwicklung
  • 1.3.2 Ablösung durch Standardanwendungssoftware
  • 1.3.3 Migration der Altsysteme
  • 1.4 Migrationsstrategien
  • 1.4.1 Reimplementierungsstrategie
  • 1.4.2 Konversionsstrategie
  • 1.4.3 Kapselungsstrategie (Wrapping)
  • 1.4.4 Auswahl einer geeigneten Strategie
  • 1.5 Umstellungs- und Übergabestrategien
  • 1.5.1 Punktumstellung und Punktübergabe (Big Bang)
  • 1.5.2 Langfristumstellung
  • 1.5.3 Inkrementelle Paketumstellung
  • 1.5.4 Inkrementelle Paketumstellung mit Komponentenersatz
  • 1.5.5 Inkrementelle Paketumstellung mit Paralleleinsatz
  • 1.6 Zur Wirtschaftlichkeit einer Softwaremigration
  • 1.6.1 Betriebswirtschaftliche Sicht
  • 1.6.2 Projektmanagement-Sicht
  • 1.6.3 Technische Sicht
  • 1.7 Zum Aufbau des Buches
  • 2 Grundlagen und -begriffe der Softwaremigration
  • 2.1 Abgrenzung des Themas Migration
  • 2.1.1 Neuentwicklung, Weiterentwicklung und Evolution
  • 2.1.2 Integration
  • 2.1.3 Wartung und Maintenance
  • 2.1.4 Reengineering
  • 2.1.5 Reverse Engineering
  • 2.1.6 Migration
  • 2.2 Migrationsprojekte
  • 2.2.1 Falsche Gründe für Migrationsprojekte
  • 2.2.2 Wahre Gründe für Migrationsprojekte
  • 2.3 Migrationsansätze
  • 2.3.1 Reimplementierung
  • 2.3.2 Konvertierung
  • 2.3.3 Kapselung
  • 2.3.4 Ein Beispiel zur Unterscheidung der Migrationsansätze
  • 2.4 Migrationsarten
  • 2.4.1 Datenmigration
  • 2.4.2 Programm-Migration
  • 2.4.3 Benutzungsschnittstellen-Migration
  • 2.4.4 Systemschnittstellen-Migration
  • 2.4.5 Systemmigration
  • 2.5 Anwenderoptionen
  • 2.5.1 Interne Migration mit eigenen Ressourcen
  • 2.5.2 Interne Migration mit fremden Ressourcen
  • 2.5.3 Externe Migration mit internem Test
  • 2.5.4 Externe Migration einschließlich Test
  • 2.5.5 Kriterien für die Entscheidung
  • 3 Migrationsprozesse aus Forschung und Praxis
  • 3.1 Chicken-Little-Migrationsansatz
  • 3.1.1 Zielsetzung und Idee des Chicken-Little-Ansatzes
  • 3.1.2 Chicken-Little-Migrationsobjekte
  • 3.1.3 Chicken-Little-Vorgehensmodell
  • 3.1.4 Bewertung des Chicken-Little-Ansatzes
  • 3.2 Butterfly-Migrationsansatz
  • 3.2.1 Zielsetzung und Idee des Butterfly-Ansatzes
  • 3.2.2 Butterfly-Vorgehensmodell
  • 3.2.3 Bewertung des Butterfly-Ansatzes
  • 3.3 Der Renaissance-Migrationsprozess
  • 3.3.1 Phasen im Renaissance-Migrationsansatz
  • 3.3.2 Das Renaissance-Integrationsmodell
  • 3.3.3 Bewertung des Renaissance-Ansatzes
  • 3.4 Das COREM-Migrationsverfahren
  • 3.4.1 Der Top-down-Ansatz
  • 3.4.2 Der Bottom-up-Ansatz
  • 3.4.3 Verschmelzung der beiden Ansätze
  • 3.4.4 Bewertung des COREM-Verfahrens
  • 3.5 Die Migrationsfabrik
  • 3.5.1 Zielsetzung und Idee der Migrationsfabrik
  • 3.5.2 Vorgehensmodell der Migrationsfabrik
  • 3.5.3 Bewertung der Migrationsfabrik
  • 3.6 SMART-Softwaremigration
  • 3.6.1 Zielsetzung und Idee von SMART
  • 3.6.2 SMART-Vorgehensmodell
  • 3.6.3 Bewertung des SMART-Ansatzes
  • 3.7 Objektorientierte Softwaremigration
  • 3.7.1 Zielsetzung des objektorientierten Ansatzes
  • 3.7.2 Objektorientiertes Vorgehensmodell
  • 3.7.3 Bewertung des objektorientierten Ansatzes
  • 3.8 Testgetriebene Migrationsprozesse
  • 3.9 Werkzeuggetriebene Migrationsprozesse
  • 4 Der Reference Migration Process (ReMiP)
  • 4.1 Prozessmodelle als Sammlung von Erfahrungswerten
  • 4.1.1 Erfahrungswerte aus der Softwaremigration
  • 4.1.2 Erfahrungswerte aus der Softwareentwicklung
  • 4.1.3 Synthese der Erfahrungswerte aus Entwicklung und Migration
  • 4.1.4 ReMiP als Prozess-Framework
  • 4.2 Struktur des ReMiP-Prozessmodells
  • 4.2.1 ReMiP-Phasen
  • 4.2.2 ReMiP-Meilensteine
  • 4.2.3 Kern- und Basisbereiche des ReMiP
  • 4.2.4 Prozessmodell des ReMiP
  • 4.3 Kernbereich Anforderungsanalyse
  • 4.3.1 Analyse der Anforderungen
  • 4.3.2 Dokumentation der Anforderungen
  • 4.4 Kernbereich Legacy-Analyse und -Aufbereitung
  • 4.4.1 Analyse des Legacy-Systems
  • 4.4.2 Globale Bewertung des Legacy-Systems
  • 4.4.3 Reverse Engineering des Legacy-Systems
  • 4.4.4 Vorbereitung des Legacy-Systems
  • 4.5 Kernbereich Zielsystementwurf
  • 4.5.1 Definition der Zielsystemkandidaten
  • 4.5.2 Verfeinerung der Zielsystemarchitektur
  • 4.5.3 Definition der Übergangsarchitektur
  • 4.5.4 Entwurf der Programme
  • 4.5.5 Entwurf der Benutzungsschnittstellen
  • 4.5.6 Entwurf der Datenbanken
  • 4.5.7 Spezifikation der Transformationen
  • 4.6 Kernbereich Strategieauswahl
  • 4.6.1 Erarbeitung der Migrationsstrategien für Zielsystemkandidaten
  • 4.6.2 Bewertung der Migrationsstrategien für Zielsystemkandidaten
  • 4.6.3 Auswahl der Migrationsstrategie
  • 4.6.4 Verwaltung der Migrationsstrategie
  • 4.7 Kernbereich Transformation
  • 4.7.1 Isolation des Migrationspakets
  • 4.7.2 Transformation des Migrationspakets
  • 4.7.3 Durchführung der Deltamigration
  • 4.7.4 Implementierung neuer Komponenten
  • 4.8 Kernbereich Test
  • 4.8.1 Definition der globalen Teststrategie
  • 4.8.2 Testspezifikation für das Migrationspaket
  • 4.8.3 Testdurchführung für das Migrationspaket
  • 4.8.4 Auswertung der Testergebnisse
  • 4.9 Kernbereich Übergabe
  • 4.9.1 Einrichtung der Zielumgebung
  • 4.9.2 Planung der Übergabe
  • 4.9.3 Entwicklung des Supportmaterials
  • 4.9.4 Durchführung der Übergabe
  • 4.9.5 Ablösung des Legacy-Systems
  • 4.10 Basisbereich Konfigurations- und Änderungsmanagement
  • 4.11 Basisbereich Projektmanagement
  • 4.12 Basisbereich Mitarbeiterqualifizierung
  • 4.13 Basisbereich Migrationsumgebung
  • 5 Methoden und Techniken der Softwaremigration
  • 5.1 Softwaremesstechnik
  • 5.2 Systembewertung
  • 5.3 Migrationsaufwandsschätzung
  • 5.3.1 Schätzung nach COCOMO II
  • 5.3.2 Schätzung mit Object Points
  • 5.3.3 Schätzung mit Data Points
  • 5.4 Migrationsplanung
  • 5.5 Migrationssteuerung
  • 5.6 Entwurfsmethoden
  • 5.6.1 Entwurf der Istarchitektur
  • 5.6.2 Entwurf der Sollarchitektur
  • 5.7 Code-Transformationstechniken
  • 5.8 Code-Reimplementierungstechnik
  • 5.9 Code-Kapselungstechniken
  • 5.9.1 Prozesskapselung
  • 5.9.2 Transaktionskapselung
  • 5.9.3 Programmkapselung
  • 5.9.4 Modulkapselung
  • 5.9.5 Prozedurkapselung
  • 5.10 Datenkonvertierungstechnik
  • 5.11 Datenkapselungstechnik
  • 5.12 Regressionstesttechniken
  • 5.12.1 Voller Regressionstest
  • 5.12.2 Selektiver Regressionstest
  • 5.13 Systemnachdokumentation
  • 5.14 Systemverwaltung
  • 6 Softwaremigrationswerkzeuge
  • 6.1 Codeanalysewerkzeuge
  • 6.1.1 Codeprüfung
  • 6.1.2 Codemessung
  • 6.1.3 Verfügbare Analysewerkzeuge
  • 6.2 Schätzwerkzeuge
  • 6.2.1 COCOMO-II
  • 6.2.2 SoftCalc
  • 6.3 Projektmanagementwerkzeuge
  • 6.4 Entwurfswerkzeuge
  • 6.5 Programmtransformationswerkzeuge
  • 6.5.1 Die prozeduralen Werkzeuge
  • 6.5.2 Die objektorientierten Werkzeuge
  • 6.6 Programmkapselungswerkzeuge
  • 6.6.1 Screen Scraping Tools
  • 6.6.2 Transaction Wrapping Tools
  • 6.6.3 Function Wrapping Tools
  • 6.7 Datenkonvertierungswerkzeuge
  • 6.8 Datenkapselungswerkzeuge
  • 6.8.1 Kapselung der Legacy-Datenbanksysteme
  • 6.8.2 Kapselung relationaler Datenbanken
  • 6.9 Regressionstestwerkzeuge
  • 6.9.1 Kommerzielle Testwerkzeuge
  • 6.9.2 Regressionstest einzelner Module
  • 6.9.3 Regressionstest der migrierten Systeme
  • 6.10 Nachdokumentationswerkzeuge
  • 6.11 Systemverwaltungswerkzeuge
  • 7 Migrationsfallstudien
  • 7.1 RCOST: Migration von COBOL-Client/Server-Systemen in eine Webumgebung
  • 7.1.1 Projekthintergrund
  • 7.1.2 Migrationsvorbereitung
  • 7.1.3 Migrationsdurchführung
  • 7.1.4 Lehren aus dem RCOST-Projekt
  • 7.2 Migration von Mainframe-COBOL-Programmen in eine UNIX-J2EE-Umgebung
  • 7.2.1 Projekthintergrund
  • 7.2.2 Schichtenarchitektur
  • 7.2.3 Erfahrungen mit der Kapselung alter Programme und deren Daten
  • 7.3 Eine inkrementelle Systemablösung
  • 7.4 Eine schrittweise COBOL-Migration in drei Akten
  • 7.4.1 Der erste Akt - Beseitigung der Altlasten
  • 7.4.2 Der zweite Akt - Zurück zu Standard-COBOL
  • 7.4.3 Der dritte Akt - Der Übergang zum IBM-Mainframe
  • 7.5 Migration einer Mainframe-Anwendung auf UNIX
  • 7.5.1 Machbarkeitsstudie
  • 7.5.2 Grundprämissen für das Projekt
  • 7.5.3 Gegenstände der Migration
  • 7.5.4 Regressionstest des migrierten Billing-Systems
  • 7.5.5 Erfahrungen aus der Migration des Billing-Systems
  • 7.6 Massenmigration von einem Bull-Mainframe auf verteilte UNIX-Rechner
  • 7.6.1 Projektorganisation
  • 7.6.2 Einrichtung von Gateways zwischen den Rechnern
  • 7.6.3 Aufbau einer Migrationsfabrik
  • 7.6.4 Projektresümee
  • 7.7 Das ARNO-Projekt
  • : Beispiel einer Migration von einem proprietären Mainframe-Rechner in eine offene UNIX-Umgebung
  • 7.7.1 Die Migration beginnt mit einer Studie
  • 7.7.2 Die Projektorganisation
  • 7.7.3 Die Vorbereitung der Migration
  • 7.7.4 Der Wechsel der Programmiersprache
  • 7.7.5 Der Konvertierungsprozess
  • 7.7.6 Der Testprozess
  • 7.7.7 »Migration« der Mitarbeiter
  • 7.7.8 Übergabe an die Linienorganisation
  • 7.7.9 Fazit einer erfolgreichen Migration
  • 7.8 Automatisierte Migration von COBOL in Java
  • 7.8.1 Die Ausgangssituation
  • 7.8.2 Alternative Lösungen
  • 7.8.3 Die Spezifikation der Reimplementierung
  • 7.8.4 Der Code-Konvertierungsprozess
  • 7.8.5 Das Konvertierungsergebnis
  • 7.8.6 Das Ergebnis als Zwischenstufe
  • 7.8.7 Eine testgetriebene Migration
  • 8 Die Zukunft der Migrationstechnologie
  • 8.1 Die aktuelle Migrationswelle - serviceorientierte Architekturen (SOA)
  • 8.2 Alternative Wege zur SOA
  • 8.2.1 Top-down-Migrationsansatz
  • 8.2.2 Bottom-up-Migrationsansatz
  • 8.2.3 Gemischter Migrationsansatz
  • 8.2.4 Voraussetzung für eine Migration zur SOA
  • 8.3 Die Bereitstellung von Web Services
  • 8.3.1 Web Services einkaufen
  • 8.3.2 Web Services mieten (Software on Demand)
  • 8.3.3 Web Services ausleihen
  • 8.3.4 Web Services entwickeln
  • 8.3.5 Web Services aus vorhandenen Systemen wiedergewinnen
  • 8.4 Ansätze zur Wiedergewinnung von Web Services
  • 8.4.1 Entdecken potenzieller Web Services
  • 8.4.2 Bewertung potenzieller Web Services
  • 8.4.3 Extrahierung des Codes für den Web Service
  • 8.4.4 Anpassung des Web-Service-Codes
  • 8.5 Test der Web Services
  • 8.6 Migration als Outsourcing-Geschäft
  • 8.7 Widerstände gegen Migration
  • 8.8 Das Rad dreht sich weiter
  • Literatur
  • Index

1 Einleitung zum Thema Softwaremigration


1.1 Die Motivation für Softwaremigration


Das Thema »Softwaremigration« ist ein Evergreen. Es ist immer aktuell, unabhängig davon, welche Softwaretechnologie gerade vorherrscht. Sicher ist: Auch die aktuelle Technologie wird nicht von langer Dauer sein. Wer schon länger mit der IT zu tun hat, wird wissen, dass Migration ein wiederholtes Ereignis bei jedem Anwender ist. Es tritt immer dann auf, wenn Hardware oder Software ausgetauscht werden, und dies ist recht häufig. Wenn sich in der IT-Umgebung etwas ändert, zieht dies andere Änderungen nach sich. Dieser Änderungsprozess findet in immer kürzeren Intervallen statt. Für den, der mit der IT weniger vertraut ist, mag es zunächst seltsam erscheinen, dass diese Welt so sehr mit sich selbst beschäftigt ist. Es werden Unsummen von Geld investiert, um den IT-Betrieb auf dem neuesten Stand zu halten, oft mit fragwürdigem Nutzen für die Benutzer. Die Antwort auf die Frage, warum dies so ist, hat mit der instabilen Natur dieser jungen Industrie zu tun.

Die IT-Industrie ist ständig auf der Suche nach sich selbst. Sie ist eine Kombination mehrerer Technologien - der Computer-, der Kommunikations-, der Speichertechnologie und nicht zuletzt der Softwaretechnologie. Wenn sich nur eine dieser Technologien ändert, sind die anderen mit betroffen. Wir wissen von Moore's Law, dass die Kapazität der Rechner sich alle 18 Monate verdoppelt, und dies seit Jahren [Glas99]. Die Kommunikationstechnologie verhält sich ähnlich. Seit der Verbreitung der Internetnutzung hat sich die Netzwerkkapazität um das Hundertfache vermehrt. Die Massenspeichertechnologie hat ihren eigenen Lebenszyklus und verdoppelt ihre Leistung alle zwei Jahre. Heute ist es möglich, im gleichen Speicherraum 10-mal so viele Daten zu speichern wie vor 20 Jahren. Die langsamste der IT-Technologien ist die Softwaretechnologie, die sich nur alle fünf Jahre verändert. Neue Sprachen und Entwurfsparadigmen setzen sich relativ zu den »härteren« Technologien nur deshalb so langsam durch, weil die Anwender sie erst erlernen müssen, und das dauert länger. Der Mensch bremst also die Softwareinnovation.

Die Anwendersysteme stützen sich auf die IT-Technologien und veralten in dem Maße, wie sie hinter die Möglichkeiten dieser Technologien zurückfallen. Sie werden dadurch im Laufe der Zeit mit dem Stand der anderen Technologien inkompatibel. Die Basissoftwarehersteller müssen immer mehr Aufwand betreiben, um die Rückwärtskompatibilität zu früheren Technologien aufrechtzuerhalten. Deswegen sind sie bemüht, die Anwender zur Übernahme der neuen Technologien zu bewegen. Welchen Nutzen der Anwender davon hat, ist eine andere Frage. Ein Paradebeispiel dafür ist das Thema SOA (serviceorientierte Architektur). Es sind nicht die Anwender, die danach rufen; sie haben noch genug damit zu tun, die Webtechnologie zu verdauen. Es sind die Softwareanbieter, vor allem die Applikationsanbieter, die den Anwendern diese neue Technologie regelrecht aufdrängen, weil es für sie bequemer und günstiger ist, einzelne Services bereitzustellen als komplette automatisierte Anwendungen in vielfachen Variationen [Andr04].

Die IT-Industrie muss die Weiterentwicklung ihrer Technologien finanzieren, also müssen sie verkauft werden. Die Anwender werden in ihrer Rolle als Abnehmer mit allen Regeln der Werbekunst beeinflusst (wobei die Fachpresse als williges Instrument der Industrie eine nicht unerhebliche Rolle spielt) und zuletzt mit Drohungen zur Einstellung der Wartung und Erhöhung der Wartungsgebühren bewegt, die neuen Technologien anzunehmen. Wenn das geschieht, steht eine Migration vor der Tür. Wenn es nach dem Willen der IT-Industrie ginge, würden die Anwender ihr ganzes Anwendungsportfolio alle fünf Jahre komplett ersetzen. Da sich dies aber kein Anwender leisten kann, bleibt ihm - um mit der fortschreitenden Technologie Schritt zu halten - nur übrig, seine alten Anwendungssysteme in die neueste technologische Umgebung zu versetzen bzw. zu migrieren [McDo02].

Softwaremigration ist deswegen das Schicksal der IT-Anwender. Sie werden damit konfrontiert, solange sie auf IT-Technologien angewiesen sind. Nur wenn die Anwendungssysteme völlig isoliert gegenüber ihrer technischen Umgebung wären, könnten sie so bleiben, wie sie sind, auch wenn die Umgebung sich wandelt. Dies ist seit jeher ein Qualitätsziel der Informatik gewesen, hat aber wenig Unterstützung durch die Industrie gefunden. Dieses Ziel steckt hinter Begriffen wie Portabilität, Interoperabilität, Konvertibilität und Wiederverwendbarkeit, die nie richtig verwirklicht worden sind. Durch die Trennung der Benutzerinteraktion von der Geschäftslogik und dieser wiederum von der Datenhaltung, also durch eine wohldurchdachte Systemarchitektur, kam man dem Ziel näher, zumindest einen Teil der Software vor Veränderungen in der Umgebung abzuschotten. Aber auch das haben bisher noch nicht alle Anwender erreicht.

Der Großteil der IT-Anwender unterliegt dem Modezwang der IT-Industrie, Neues auszuprobieren. Hinzu kommt die Notwendigkeit, Software möglichst schnell und bequem zu entwickeln. Dazu müssen die letzten Sprachen und der letzte technische Schnickschnack verwendet werden - und prompt sitzen die Anwender in der Technologiefalle. Ihre Software ist nur so lange betriebsfähig, bis die nächste Technologiewelle (siehe Abb. 1-1) über sie hinwegrollt [Stra98]. Spätestens dann steht die nächste Migration vor der Tür.

Abb. 1-1 Wellen der Veränderung

Jede Technologiewelle hinterlässt Strandgut am Ufer, für das die Softwarewelt den Begriff »Legacy-Systeme« geprägt hat; diese Systeme sind mit den Technologien der letzten oder vorletzten Welle entstanden. Da diese Technologiewellen immer schneller aufeinander folgen, häuft sich das Strandgut. Inzwischen liegt die Halbwertszeit eines Softwareprodukts bei weniger als fünf Jahren. Anwendungssoftware gehört also nach etwa fünf Jahren zu den Legacy-Systemen, ist veraltet und wird immer mehr zu einer Last. Es ist schwierig, diese alten Systeme mit den neuen zu verbinden, es ist aufwendig, sie fortzuschreiben, und es ist mühsam, sie zu korrigieren. Es ist auch nicht einfach, Personal zu finden, das sich damit befassen will. Für junge Informatiker gibt es nichts Schlimmeres, als sich mit alten Technologien herumzuplagen, nur wenige haben einen ausgesprochenen Hang zur Softwarearchäologie. Diese und andere Sorgen plagen Anwender und Benutzer alter Softwaresysteme. Sie sitzen in der sogenannten Legacy-Software-Falle [Snee02a]. Auswege aus dieser Falle sind mit hohen Kosten verbunden. Anwender können (siehe Abb. 1-2)

  • das alte System beibehalten wie bisher,

  • das alte System in eine moderne Umgebung migrieren,

  • das alte System in einer modernen Umgebung neu entwickeln,

  • das alte System durch Standardsoftware ersetzen.

Jede Alternative hat ihre Vor- und Nachteile, die in der Folge erläutert werden. Der Schwerpunkt dieses Buches liegt auf der zweiten Alternative (»das alte System in eine moderne Umgebung migrieren«), denn das versteht die Fachwelt allgemein unter Softwaremigration. Dazu wird ein generischer Prozess definiert, der auf alle Migrationsprojekte anwendbar und an sie anpassbar ist. Die Methoden, Techniken und Werkzeuge, die zu einer solchen Migration gehören, werden beschrieben. In Kapitel 7 schaffen Fallstudien die Verbindung zur betrieblichen Migrationspraxis.

Abb. 1-2 Alternative Auswege aus der Legacy-Falle

1.2 Zum Zustand der IT in der betrieblichen Praxis


Zu Beginn des 21. Jahrhunderts ist der Stand der IT in vielen Unternehmen alles andere als zufriedenstellend. Neue Technologien wurden zwar eingeführt, aber die alten Systeme blieben. Für ihre Ablösung fehlen Zeit und Geld. Da die Altsoftware sich über die Jahre akkumuliert, macht sie einen immer größeren Anteil des gesamten Softwarebestandes der Anwenderunternehmen aus. Demzufolge kann man den heutigen Status quo der IT in vielen Unternehmen als archaisch bezeichnen [SnSn03]. Kennzeichnend dafür ist eine Aussage in der Zeitschrift »IEEE Computer«, wonach die Chinesen gegenüber dem Westen im Vorteil seien, weil sie keine alten IT-Systeme zu erhalten hätten; sie könnten gleich damit beginnen, ihre Anwendungen mit den neuesten Technologien zu implementieren [Meye06].

Diese Aussagen treffen vor allem für große Unternehmen zu, die langjährige Computeranwender sind. Typische Beispiele hierfür sind Finanzdienstleister, Handelsfirmen und Behörden. Sie verharren nicht selten auf der Technologie der 70er- oder 80er-Jahre. Gleichzeitig ist ihre IT als Folge der Technologieevolution zu einer bunten, heterogenen Landschaft gewachsen, die sich aus einzelnen Insellösungen zusammensetzt. Anwendungen, die in Assembler, COBOL, PL/1 oder 4GL-Sprachen implementiert sind und auf Mainframe-Systemen laufen, sind in diesem Marktsektor eher Normalfall als Ausnahme. Die Daten sind oft noch in hierarchischen, netzwerkartigen oder bestenfalls semirelationalen Datenbanken gespeichert. Die...

Dateiformat: EPUB
Kopierschutz: Wasserzeichen-DRM (Digital Rights Management)

Systemvoraussetzungen:

Computer (Windows; MacOS X; Linux): Verwenden Sie eine Lese-Software, die das Dateiformat EPUB verarbeiten kann: z.B. Adobe Digital Editions oder FBReader - beide kostenlos (siehe E-Book Hilfe).

Tablet/Smartphone (Android; iOS): Installieren Sie bereits vor dem Download die kostenlose App Adobe Digital Editions (siehe E-Book Hilfe).

E-Book-Reader: Bookeen, Kobo, Pocketbook, Sony, Tolino u.v.a.m. (nicht Kindle)

Das Dateiformat EPUB ist sehr gut für Romane und Sachbücher geeignet - also für "fließenden" Text ohne komplexes Layout. Bei E-Readern oder Smartphones passt sich der Zeilen- und Seitenumbruch automatisch den kleinen Displays an. Mit Wasserzeichen-DRM wird hier ein "weicher" Kopierschutz verwendet. Daher ist technisch zwar alles möglich - sogar eine unzulässige Weitergabe. Aber an sichtbaren und unsichtbaren Stellen wird der Käufer des E-Books als Wasserzeichen hinterlegt, sodass im Falle eines Missbrauchs die Spur zurückverfolgt werden kann.

Weitere Informationen finden Sie in unserer E-Book Hilfe.


Dateiformat: PDF
Kopierschutz: Wasserzeichen-DRM (Digital Rights Management)

Systemvoraussetzungen:

Computer (Windows; MacOS X; Linux): Verwenden Sie zum Lesen die kostenlose Software Adobe Reader, Adobe Digital Editions oder einen anderen PDF-Viewer Ihrer Wahl (siehe E-Book Hilfe).

Tablet/Smartphone (Android; iOS): Installieren Sie die kostenlose App Adobe Digital Editions oder eine andere Lese-App für E-Books (siehe E-Book Hilfe).

E-Book-Reader: Bookeen, Kobo, Pocketbook, Sony, Tolino u.v.a.m. (nur bedingt: Kindle)

Das Dateiformat PDF zeigt auf jeder Hardware eine Buchseite stets identisch an. Daher ist eine PDF auch für ein komplexes Layout geeignet, wie es bei Lehr- und Fachbüchern verwendet wird (Bilder, Tabellen, Spalten, Fußnoten). Bei kleinen Displays von E-Readern oder Smartphones sind PDF leider eher nervig, weil zu viel Scrollen notwendig ist. Mit Wasserzeichen-DRM wird hier ein "weicher" Kopierschutz verwendet. Daher ist technisch zwar alles möglich - sogar eine unzulässige Weitergabe. Aber an sichtbaren und unsichtbaren Stellen wird der Käufer des E-Books als Wasserzeichen hinterlegt, sodass im Falle eines Missbrauchs die Spur zurückverfolgt werden kann.

Weitere Informationen finden Sie in unserer E-Book Hilfe.


Download (sofort verfügbar)

33,99 €
inkl. 19% MwSt.
Download / Einzel-Lizenz
ePUB mit Wasserzeichen-DRM
siehe Systemvoraussetzungen
PDF mit Wasserzeichen-DRM
siehe Systemvoraussetzungen
Hinweis: Die Auswahl des von Ihnen gewünschten Dateiformats und des Kopierschutzes erfolgt erst im System des E-Book Anbieters
E-Book bestellen

Unsere Web-Seiten verwenden Cookies. Mit der Nutzung dieser Web-Seiten erklären Sie sich damit einverstanden. Mehr Informationen finden Sie in unserem Datenschutzhinweis. Ok