Die Arbeit ist aufgeteilt in die drei Hauptkapitel mit einem Grundlagenteil (Kapitel 2), der Typisierung (Kapitel 3) und der Aufwandsanalyse (Kapitel 4). Sie bauen inhaltlich aufeinander auf. Die Aufwandsanalyse verarbeitet zwar das Teilergebnis der Typisierung, kann jedoch auch separat gelesen werden. Die Hauptkapitel sind in sich hinreichend abgeschlossen. Allgemeines betriebswirtschaftliches und informationstechnologisches Verständnis wird beim Leser vorausgesetzt.
Kapitel 2 liefert eine Definition und Begriffsabgrenzung von Software-Migration. In der Darstellung der Phasen sind wesentliche Aktivitäten unter zeitlicher Gruppierung erläutert. Die Beschreibung der Ressourcen von Migrationsprojekten offenbart wichtige Mittel ohne die eine Durchführung nicht möglich ist. Unterkapitel 2.4 erörtert konstitutive Risiken.
Die Typisierung ist Hauptgegenstand von Kapitel 3. Zunächst sind Anforderungen an die zu suchende Lösung gestellt. Es folgt eine Beschreibung von Unterscheidungskriterien, die Bestandteil des Typisierungsergebnisses (Unterkapitel 3.7) sind.
In Kapitel 4 wird auf das Typisierungsergebnis zurückgegriffen und unter Aufwandsgesichtspunkten untersucht. Da der Begriff Aufwand in den Disziplinen zum Teil unterschiedlich belegt ist, erfolgt eine Begriffsabgrenzung. Unterkapitel 4.3 beschreibt die Aufwandsmatrix mit einer Zerlegung des Aufwands und Gegenüberstellung der wesentlichen Einflussfaktoren, die für beliebige Software-Migrationsvorhaben von Bedeutung sind. Für den Aufwandsvergleich (Unterkapitel 4.4) werden Anforderungen an eine brauchbare Lösung gestellt, ein Scoring-Modell entwickelt und bewertet.
Im letzten Kapitel 5 der Arbeit werden die Ergebnisse zusammengefasst und ein Ausblick gegeben. Der Anhang enthält eine Vergleichsmatrix, die im Kontext des Aufwandsvergleichs referenziert wird.
Inhaltsverzeichnis
Abbildungsverzeichnis
Tabellenverzeichnis
Abkürzungsverzeichnis
1 Einleitung
1.1 Motivation
1.2 Zielsetzung
1.3 Aufbau der Arbeit
2 Software-Migration
2.1 Grundlagen
2.2 Phasen
2.2.1 Justification
2.2.2 Legacy System Understanding
2.2.3 Target System Development
2.2.4 Testing
2.2.5 Migration
2.3 Ressourcen
2.3.1 Personal
2.3.2 Zeit
2.3.3 Infrastruktur
2.3.4 Software
2.3.5 Hardware
2.3.6 Dokumentation
2.4 Risiken
3 Typen von Migrationsvorhaben
3.1 Anforderungen an die Typisierung
3.2 Typisierung nach Projektgröße
3.2.1 Budget
3.2.2 Team
3.2.3 Projektdauer
3.3 Typisierung nach Migrationsobjekt
3.3.1 Systemsoftware
3.3.2 Anwendungssoftware
3.4 Typisierung nach Migrationsaspekt
3.4.1 Daten
3.4.2 Programmiersprache
3.4.3 Architektur
3.4.4 Benutzerschnittstelle
3.5 Typisierung nach Migrationsstrategie
3.5.1 Konversion
3.5.2 Kapselung
3.5.3 Reimplementierung
3.6 Typisierung nach Umstellungs- und Übergabestrategie
3.6.1 Punktumstellung und Punktübergabe (Big-Bang)
3.6.2 Langfristumstellung
3.6.3 Inkrementelle Paketumstellung
3.7 Morphologischer Kasten
4 Aufwand von Migrationsvorhaben
4.1 Begriffsdefinition
4.2 Aufwandsbeeinflussende Faktoren
4.2.1 Projektgröße
4.2.2 Objekt
4.2.3 Aspekt
4.2.4 Strategie
4.2.5 Umstellung und Übergabe
4.3 Aufwandsmatrix
4.4 Aufwandsvergleich
4.4.1 Anforderungen
4.4.2 Scoring-Modell
4.4.3 Bewertung
5 Fazit und Ausblick
Literaturverzeichnis
Anhang I
Abbildungsverzeichnis
Abbildung 1: Komponenten der effektiven Arbeitszeit
Abbildung 2: Magisches Dreieck des Projektmanagements
Abbildung 3: Exemplarische Risk-Map
Abbildung 4: Vorgehen zur Erstellung eines Projektbudgets
Abbildung 5: Beziehung zwischen Teamgröße und Projektdauer
Abbildung 6: Ebenenmodell einer Nutzermaschine
Abbildung 7: Punktumstellung und Punktübergabe (Big Bang)
Abbildung 8: Langfristumstellung
Abbildung 9: Inkrementeller paketweiser Übergang mittels Gateway(s)
Abbildung 10: Inkrementeller paketweiser Übergang ohne Gateway(s)
Abbildung 11: Zusammenhang zwischen Koordinations- und Kommunikationsaufwand und Anzahl Projektmitarbeiter
Abbildung 12: Zusammenhang zwischen Projektaufwand und Projektdauer
Abbildung 13: Zusammenhang zwischen LOC und Projektaufwand
Abbildung 14: Klassifikation von Datenfehlern
Tabellenverzeichnis
Tabelle 1: Vorgehensmodelle zur Software-Migration
Tabelle 2: Morphologischer Kasten zur Typisierung von Software-Migrationsvorhaben
Tabelle 3: Aufwand und Einflussfaktoren von Software-Migrations-vorhaben
Tabelle 4: Scoring-Modell zum Aufwandsvergleich von Software-Migrationen
Tabelle 5: Bewertungsskala für den Paarvergleich der Einflussfaktoren
Tabelle 6: Durchschnittlicher Random Consistency Index (R.I.)
Abkürzungsverzeichnis
Abbildung in dieser Leseprobe nicht enthalten
1 Einleitung
Software-Migration ist in der Praxis und Forschung ein eminentes Thema. Kapitel 1.1 liefert Ursachen für die Bedeutsamkeit und die Begründung, sich mit der Thematik differenziert auseinanderzusetzen. Die Zielsetzung (Kapitel 1.2) beschreibt das erstrebenswerte Ergebnis der Arbeit als Beitrag zur Wissenschaft und stellt den Anspruch, Lösungsvorschläge für die praxisgerechte Typisierung und Aufwandsanalyse zu entwickeln. Um dem Leser einen Gesamteindruck vom Umfang der behandelten Aspekte zu vermitteln, stellt Kapitel 1.3 den Inhalt und Aufbau der Arbeit vor.
1.1 Motivation
Eine sich schnell wandelnde Wirtschaft und Gesellschaft verlangt von Unternehmen hohe Flexibilität, um rechtzeitig auf Veränderungen am Markt reagieren zu können. Globalisierung führt zu einem hohen Konkurrenzdruck und verschärft den Wettbewerb. Als Folge müssen Strategien entwickelt und auf den veränderten Kontext angepasst werden. Durch Operationalisierung in den verschiedenen Unternehmensbereichen werden aus Teilstrategien Maßnahmen abgeleitet, damit auf allen Unternehmensebenen die Veränderungen adäquat Wirkung erzielen können. Im Rahmen des Business-IT-Alignments wird die IT-Strategie auf die Unternehmensstrategie abgestimmt. Dadurch können sich Änderungen der IT-Strukturen (z. B. Organisation, Hardware, Software und Infrastruktur) ergeben. Die Ausrichtung und Verbesserung der IT eröffnet wiederum neue Potenziale (z. B. Produktivität, Qualität und Innovation) für die Gestaltung der Geschäftsprozesse, wodurch sich ein Wechselspiel ergibt. Eine Voraussetzung für Business-IT-Alignment ist Flexibilität des Unternehmens aber auch der IT-Strukturen, damit die Anpassungen erfolgreich durchgeführt werden können.
Eine Beobachtung der existierenden IT-Systeme in Unternehmen (z. B. im Finanzsektor) zeigt, dass diese häufig eine heterogene Landschaft bilden und historisch gewachsen sind. Mit der Größe eines Unternehmens steigen die Anforderungen an die IT (z. B. Performanz, Funktionalität, Sicherheit). Durch Veränderung der Umwelt können neue Anforderungen entstehen. Aus Kostengründen werden bestehende Systeme nicht immer rechtzeitig reformiert oder ersetzt. Es bietet sich eine Migration an, die weniger Risiken beinhalten und kostengünstiger als eine Neuentwicklung sein kann. Altsysteme, die keine Skalierung zulassen, hemmen das Unternehmenswachstum und führen zu Flexibilitätseinbußen (Bisbal et al. 1997a, S. 1). Eine geeignete Migrationsstrategie ist erforderlich, um vorhandene Systeme an die veränderten Anforderungen anzupassen.
Die Migration ist mit Aufwand verbunden, aus dem sich Kosten für das Unternehmen ergeben. Zum einen fallen projektbedingte Kosten für Planung, Steuerung und Kontrolle an. Beispielsweise muss Personal bereitgestellt werden. Sofern für die spezifische Migrationsaufgabe keine eigenen qualifizierten Mitarbeiter zur Verfügung stehen, sind externe Berater zu beauftragen. Eine Infrastruktur ist erforderlich, die die Kommunikation unter den Beteiligten sicherstellt (z. B. Arbeitsplätze, Telefon und Internetzugang). Für das Projektcontrolling wird zum Beispiel eine Projektmanagement-Software eingekauft. Zum anderen werden migrationsspezifische Kosten verursacht. Das Altsystem muss einer Analyse unterzogen werden, um bereits erfüllte Anforderungen zu erkennen und wiederverwendbare Komponenten zu identifizieren. Für den Migrationszeitpunkt müssen gegebenenfalls Ausfallzeiten eingeplant werden. Keine Verfügbarkeit des Systems verursacht mittelbar Kosten, da die Produktivität und Qualität sinkt. Für den Betrieb von Testsystemen, mithilfe derer die Korrektheit der Migration geprüft wird, sind Hardware und Software erforderlich.
Für eine wirtschaftliche Betrachtung des Vorhabens ist eine Abschätzung des Aufwands zwingend erforderlich. Das heißt, es müssen sowohl projektbedingte als auch migrationsspezifische Kriterien Berücksichtigung finden. Die Genauigkeit der Einschätzung ist dabei abhängig von der verwendeten Methode und insbesondere von der Qualität der Datengrundlage. Die Problematik besteht folglich nicht nur in der Auswahl eines geeigneten Verfahrens, sondern auch in der Informationsbeschaffung, damit eine Anwendung überhaupt erst möglich ist und eine hinreichende Präzision liefert. Bei der Software-Migration kann die Beschaffung von Informationen über ein komplexes Altsystem mit erheblichem Aufwand verbunden sein, wenn beispielsweise keine Dokumentation vorliegt. In diesem Fall muss Reverse Engineering durchgeführt werden, um verwendbare Erkenntnisse über Verhalten und Struktur der Software zu extrahieren. Beim speziellen Fall der Daten-Migration ist bei großer Datenmenge die korrekte Erfassung der Vernetzung und Beurteilung der Qualität der Daten aufwändig. Andererseits sinkt der Entwicklungsaufwand, wenn Komponenten der Legacy-Software wiederverwendet und in das neue System übernommen werden können. Die Migrationsaufgabe verursacht folglich einerseits zusätzlichen Aufwand durch die Untersuchungsnotwendigkeit des Altsystems, der bei einer Neuentwicklung nicht entsteht und mindert andererseits Aufwand durch Wiederverwendungspotenziale. Aus diesem Grund ist eine pauschale Aussage, ob Migration oder Neuentwicklung kostengünstiger ist, nicht möglich und bedarf der Einzelfallunterscheidung.
Aufgrund der hohen Zahl an Migrationsprojekten in der Praxis ist die Aufwandsbestimmung für Software-Migrationsvorhaben ein bedeutendes Thema. Eine zufriedenstellende, angemessene Schätzmethode existiert jedoch nicht. Stattdessen müssen allgemeine Schätzverfahren für Softwareprojekte eingesetzt werden, die für die Software-Migration jedoch nicht spezifisch genug sind. Eine Gleichsetzung des Aufwands einer Neuentwicklung mit dem Aufwand der Migration ist nicht akzeptabel. Ebenso kann nicht generell eine Migration der Neuentwicklung bevorzugt werden. Eine genauere Kalkulation der Kosten im Einzelfall ist wünschenswert, um Auftragsangebote abgeben zu können, eine Wirtschaftlichkeitsbeurteilung zu ermöglichen und den Ressourceneinsatz zu planen. „You can’t control what you can’t measure“ (DeMarco 1982, S. 3). Die notwendigen Aktivitäten zur Migration unterscheiden sich jedoch bei unterschiedlichem Funktionsumfang der Software, Migrationsaspekten (z. B. Daten und Programmiersprache) und Eigenschaften des Altsystems. Daraus ergeben sich unterschiedliche Aufwendungen. Es ist eine Strukturierung und Typisierung von Migrationsvorhaben notwendig, um eine Unterscheidung grundsätzlicher Arten anhand wesentlicher Kriterien zu ermöglichen. Das Gesamtspektrum der Typen von Migrationen erweitert den Blickwinkel zur Identifikation wichtiger Einflussfaktoren des Aufwands.
1.2 Zielsetzung
Ziel der Arbeit ist die Entwicklung einer Typisierung zur Unterscheidung verschiedener Arten von Software-Migrationen. Es soll ein Überblick über die Vielgestaltigkeit von Migrationsszenarien gegeben werden, um eine umfassende Aufwandsanalyse vornehmen zu können. Dazu sind adäquate Kriterien zu erarbeiten, Begrifflichkeiten einzuführen und Ausprägungsformen zu untersuchen. Durch Einordnung eines konkreten Vorhabens in das Typenschema sollen seine wesentlichen Eigenschaften strukturiert dargeboten werden. Die Unterscheidungskriterien sind so zu wählen, dass sie in der Summe die Art der Migration vergegenwärtigen. Die Ausprägungen je Kriterium sind vollständig zu konzipieren, sodass jeweils eine Auswahl stattfinden kann.
Die Aufwandsanalyse soll die Ergebnisse aus der Typisierung berücksichtigen, damit gewährleistet ist, dass allgemeingültige Einflussfaktoren des Aufwands ermittelt werden, die für alle Typen von Software-Migrationen bedeutsam sind. Eine Auflistung der Zusammensetzung des Aufwands mit wesentlichen Einflussfaktoren ist erstrebenswert. Für eine hohe Relevanz der Arbeit ist das Finden einer geeigneten Abstraktionsstufe kritisch. Durch eine Vielzahl von feingranularen Faktoren leidet die Überschaubarkeit. Der Fokus ist auf entscheidende Gesichtspunkte mit geeigneter Verallgemeinerung zu setzen.
Idealerweise kann ein Modell entworfen werden mit dem die Einschätzung des Aufwands möglich ist, der aus der Schwierigkeit einer konkreten Migrationsaufgabe resultiert. Dazu sind Einflussgrößen zu identifizieren und deren Wirkungen im Modell darzustellen. Die Qualität der Lösung steigt mit ihrer Vielseitigkeit hinsichtlich Anpassbarkeit und Universalität, indem sie für eine Vielzahl von Migrationssituationen einsetzbar ist und gewinnbringende Erkenntnisse liefert. Anhand des Ergebnisses aus dem Modelleinsatz muss interpretierbar sein, ob eine zu bewertende Software-Migration mit eher großem oder kleinem Aufwand verbunden ist. Falls bei einem geringen Budget eine sehr aufwändige Migration bevorsteht, ist dann auch ohne Einsatz von komplizierten Kalkulationsverfahren eine Disparität zu erkennen. Ein praxisgerechtes Einsatzpotenzial ist anzustreben.
1.3 Aufbau der Arbeit
Die Arbeit ist aufgeteilt in die drei Hauptkapitel mit einem Grundlagenteil (Kapitel 2), der Typisierung (Kapitel 3) und der Aufwandsanalyse (Kapitel 4). Sie bauen inhaltlich aufeinander auf. Die Aufwandsanalyse verarbeitet zwar das Teilergebnis der Typisierung, kann jedoch auch separat gelesen werden. Die Hauptkapitel sind in sich hinreichend abgeschlossen. Allgemeines betriebswirtschaftliches und informationstechnologisches Verständnis wird beim Leser vorausgesetzt.
Kapitel 2 liefert eine Definition und Begriffsabgrenzung von Software-Migration. In der Darstellung der Phasen sind wesentliche Aktivitäten unter zeitlicher Gruppierung erläutert. Die Beschreibung der Ressourcen von Migrationsprojekten offenbart wichtige Mittel ohne die eine Durchführung nicht möglich ist. Unterkapitel 2.4 erörtert konstitutive Risiken.
Die Typisierung ist Hauptgegenstand von Kapitel 3. Zunächst sind Anforderungen an die zu suchende Lösung gestellt. Es folgt eine Beschreibung von Unterscheidungskriterien, die Bestandteil des Typisierungsergebnisses (Unterkapitel 3.7) sind.
In Kapitel 4 wird auf das Typisierungsergebnis zurückgegriffen und unter Aufwandsgesichtspunkten untersucht. Da der Begriff Aufwand in den Disziplinen zum Teil unterschiedlich belegt ist, erfolgt eine Begriffsabgrenzung. Unterkapitel 4.3 beschreibt die Aufwandsmatrix mit einer Zerlegung des Aufwands und Gegenüberstellung der wesentlichen Einflussfaktoren, die für beliebige Software-Migrationsvorhaben von Bedeutung sind. Für den Aufwandsvergleich (Unterkapitel 4.4) werden Anforderungen an eine brauchbare Lösung gestellt, ein Scoring-Modell entwickelt und bewertet.
Im letzten Kapitel der Arbeit werden die Ergebnisse zusammengefasst und ein Ausblick gegeben. Der Anhang enthält eine Vergleichsmatrix, die im Kontext des Aufwandsvergleichs referenziert wird.
2 Software-Migration
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.
2.1 Grundlagen
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 Gesamtumfang des Vorhabens nicht gerecht. Zusammenfassend lässt sich festlegen, dass wenn im Folgenden der Begriff „Software-Migration“ verwendet wird, ein Software-Reengineering-Projekt mit der Aufgabe Migration im Kontext des Software-Maintenance gemeint ist. Wobei ein Projekt ein „Vorhaben [ist], das im wesentlichen durch die Einmaligkeit der Bedingungen in ihrer Gesamtheit gekennzeichnet ist, wie z. B. Zielvorgabe, zeitliche, finanzielle, personelle und andere Begrenzungen, Abgrenzungen gegenüber anderen Vorhaben und projektspezifische Organisation“ (DIN 2009, S. 11).
2.2 Phasen
Die Auflistung der exakten Phasen der Software-Migration gestaltet sich als problematisch. Sie sind abhängig vom verwendeten Vorgehensmodell und der spezifischen Implementierung beziehungsweise Interpretation im Einzelfall. Software-Migration ist kein Selbstzweck, sondern eingebettet in ein Projekt. Je nach Zielsetzung können sich Phasen und deren Bearbeitungsintensitäten unterscheiden. Um einen möglichst allgemeingültigen Überblick der durchzuführenden Migrationsschritte zu geben, ist eine Phasen-Aggregation notwendig. Die klassische Projektdreiteilung in Planung, Durchführung und Kontrolle wird der Besonderheit der Migration nicht adäquat gerecht, obgleich zutreffend bei hinreichender Abstraktion. Eine Untersuchung dedizierter Vorschläge mit konkreteren Phasen ist wünschenswert. Tabelle 1 zeigt Vorgehensmodelle zur Software-Migration aufgrund einer Literaturrecherche deutsch- und englischsprachiger Publikationen, die explizit auf die Angemessenheit zur Durchführung einer Software-Migration hinweisen. Die Liste ist sortiert nach Jahr der Publikationen. Die Unterscheidung hinsichtlich des Fokus enthüllt, dass eine Betrachtung des Migrationsvorhabens auf differenten Abstraktionsebenen stattfindet. Daraus ergeben sich ungleiche Phasen und eine Hierarchie von der allgemeinen Kontextbetrachtung zur speziellen Daten- bzw. Programmiersprachen-Migration.
Abbildung in dieser Leseprobe nicht enthalten
Tabelle 1: Vorgehensmodelle zur Software-Migration
Quelle: Rosenberger 2010, S. 12
Die Rahmenwerke (Frameworks) liefern Hilfestellung zur Identifikation abstrakter Elemente im Migrationskontext, zum Beispiel Organisation, Projekt und Technologie (Bergey et al. 1997, S. 5), und sind für die Durchführung konkreter Migrationsvorhaben zu allgemein beziehungsweise müssen erst instanziiert werden. Sie können für die Erstellung oder Auswahl von Vorgehensmodellen der Software-Migration als Meta-Vorgehensmodelle fungieren. Für die Gewinnung von typischen Phasen sind sie zu abstrakt. Das Vorgehensmodell nach Brodie und Stonebreaker (1993) betrachtet die Migration von Informationssystemen aus technischer Sicht. Sneed (1995) konkretisiert die Planung von Software-Migrationen und sensibilisiert für eine wirtschaftliche Betrachtung. Es entsteht Aufwand, der im positiven Verhältnis zum Unternehmensnutzen stehen muss. Die Publikation bildet jedoch nicht den gesamten Projektverlauf ab. Die Vorgehensmodelle MIKADO (Aebi 1997) und Butterfly Methodology (Bisbal et al. 1997b) sind spezialisiert auf Daten-Migration und damit für eine allgemeine Phasenuntersuchung ungeeignet. Littlejohn und Wilkening widmen sich der Problematik der Migration der Programmiersprache (1996; Littlejohn et al. 1995).
Entsprechend dem eingeführten Begriffsverständnis der Software-Migration sind die Vorgehensmodelle auf Projektebene eine fruchtbare Erkenntnisquelle zur Identifikation von typischen Phasen. Sie haben für die Wirtschaftsinformatik eine besondere Bedeutung (Wiederverwendung und „Best-Practice“) und betrachten das Migrationsvorhaben ganzheitlich und möglichst vollständig. Bisbal et al. führen fünf Phasen ein (1997a, S. 3), die hinreichend generisch sind. Die Phasen der Vorgehensmodelle auf Projektebene können durch diese repräsentiert werden (Rosenberger 2010, S. 32) und dienen aus diesem Grund im Folgenden als Referenz zur Beschreibung typischer Schritte im Verlauf eines Migrationsprojekts.
2.2.1 Justification
Die zentrale Aufgabe ist die Begutachtung des Migrationsvorhabens unter wirtschaftlichen Gesichtspunkten. Das Ziel ist die Erstellung einer Cost-Benefit-Analyse und einer Risikoanalyse. Dazu können Qualitätsmetriken eingesetzt werden, um die technische Schwierigkeit einer möglichen Migration zu bestimmen und das sich daraus ergebende Risiko eines Fehlschlags. Zur Messung der Produktkomplexität des Legacy-Systems kann die Anzahl der Schnittstellen zwischen den Komponenten (z. B. Klassen, Module und Methoden) herangezogen werden (Seibert 2005, S. 310). Im Rahmen der Cost-Benefit-Analyse ist der Unternehmenswert des zu migrierenden Systems von hoher Bedeutung. Je größer der Beitrag zum Unternehmenserfolg ist, desto höher wird das Risiko bemessen. Kann die Migration eines ERP-Systems beispielsweise nicht wie geplant ausgeführt werden und weist danach fehlerhafte Funktionalität auf, so ist der Ablauf elementarer Unternehmensprozesse gestört und verursacht Kosten (z. B. für die Fehlerbeseitigung und Ausfallzeiten). Kommt es zu Verzögerungen während des Migrationsprojekts, so wirkt sich das negativ auf die Verfügbarkeit des Systems aus. Gleichzeitig ergeben sich aus der Migration einer Software mit hohem Unternehmenswert bisher ungenutzte Potenziale (z. B. Produktivität, Qualität, und Sicherheit), die durch die hohe Nutzung des Systems stärkere positive Auswirkungen auf den Unternehmenserfolg haben als die Software-Migration einer selten genutzten Anwendung. Das Vorhaben ist nur dann zu verfolgen, wenn den Kosten der Migration ein höherer zukünftiger Nutzen unter Berücksichtigung des Risikos gegenübersteht. In der Literatur zeigt Sneed in einem fünf-stufigen Planungsprozess ein praktisches Vorgehen für die Durchführung dieser initialen Phase (1995, S. 24 ff). Die Aktivitäten lassen sich gruppieren in:
1. Project justification
2. Portfolio analysis
3. Cost estimation
4. Cost-benefit analysis
5. Contracting
2.2.2 Legacy System Understanding
Das zu migrierende System muss spezifizierte Anforderungen erfüllen. Das Legacy-System erfüllt bereits die geforderte Funktionalität (andernfalls stellt sich die Migrationsaufgabe nicht). Um die bereits erfüllten Anforderungen zu identifizieren, muss das Verhalten und die Interaktion des Systems in seiner Domäne untersucht werden. Minderwertige oder nicht-vorhandene Dokumentation erschwert diese Aufgabe, da in diesem Fall Reverse Engineering notwendig ist (Bisbal et al. 1997a, S. 4). Dazu wird aus dem Programmcode eine Repräsentation mit höherer Abstraktion abgeleitet, mit dem Ziel, das Verhalten der Software für Menschen leichter bestimmbar zu machen. Die Ergebnisse des Reverse Engineering können zum Verständnis des Systems beitragen (Rosenberger 2009, S. 5) und damit Vorarbeit leisten, Softwareteile in eine andere Umgebung einzubinden (Stroulia und Systä 2002, S. 8 ff). Die Erzeugung von Modellen des Programmcodes (z. B. Datenmodelle, APIs, Funktionsbeschreibungen) impliziert das Verständnis der Software nicht per se. Es ist Expertenwissen erforderlich, um in Interaktion mit der Software aus den Beobachtungen Erkenntnisse zu erlangen, die bei der Spezifikation der Anforderungen an das zu migrierende System in seiner veränderten Umwelt dienlich sind. Zur Bewältigung der komplexen Aufgaben dieser Phase eines Migrationsprojekts finden sich in der Literatur zahlreiche Publikationen (Chin und Quilici 1994; Hahn 2004; Woods 1996).
2.2.3 Target System Development
In dieser Phase wird auf Grundlage der Anforderungen die Architektur des Zielsystems gestaltet. Das Ergebnis des Designs ist für die Erfüllung der Anforderungen elementar und damit kritisch für das Migrationsprojekt. Ist eine Anforderung beispielsweise „leichte Erweiterbarkeit“, wird eine komponentenorientierte Architektur (z. B. Drei-Schichten-Architektur) oder eine serviceorientierte Architektur (SOA) besser geeignet sein als ein monolithisches System, das in sich abgeschlossen ist. Nachdem die Architekturentscheidung gefallen ist, werden die notwendigen Vorbereitungen getroffen. Für eine SOA ist dies zum Beispiel die Bereitstellung der Infrastruktur (z. B. Repository und UDDI). Die Autoren Bisbal et al. gehen davon aus, dass zunächst die Anforderungen spezifiziert sind. Es ist hingegen auch denkbar, dass die Architekturentscheidung vorher gefallen ist und Auslöser für die Migrationsnotwendigkeit ist. Insbesondere im Kontext serviceorientierter Architekturen finden sich in der Literatur dafür zahlreiche Beispiele (Fuhr et al. 2009; Gimnich 2006, S. 18; Sahraoui et al. 2003; Streekmann 2009; Winter und Ziemann 2006, S. 16). In diesem Fall müssten die 2. Phase und die 3. Phase in der Reihenfolge getauscht und Anforderungen aus der Architektur der Zielumgebung abgeleitet werden.
2.2.4 Testing
Durch Testen wird sichergestellt, dass das Verhalten des migrierten Systems dem Verhalten im Urzustand aus funktionaler Sicht entspricht. Diese Phase wird mehrmals während der technischen Migration (5. Phase) durchgeführt, um bei einer iterativen Migration sukzessive die Korrektheit der Migrationsdurchführung zu verifizieren. Erfolgt die Migration in einem Schritt, findet das Testen anschließend statt. Die Notwendigkeit einer Testing-Phase macht deutlich, dass Fehler auftreten können und sich die migrierte Software nicht genauso verhält wie vor der Migration. Um Probleme zu identifizieren, die ausschließlich durch die Änderung der Umgebung entstanden sind, ist es wichtig, dass Weiterentwicklungen an der Software vom Migrationsprojekt ferngehalten werden. Die Ursachenanalyse für auftretende Fehler wird durch parallele Erweiterung der Softwarefunktionalität erheblich erschwert, da nicht immer eindeutig bestimmt werden kann, ob ein Problem durch die Software oder seine geänderte Umgebung ausgelöst wird. Falls weitere Funktionalität erwünscht ist, sollte diese nach dem Migrationsprojekt implementiert werden (Sneed 1995, S. 25).
2.2.5 Migration
Die Aktivitäten der fünften Phase sind für die technische Durchführung der Migration notwendig. Das Ziel ist die Überführung eines Legacy-Systems in eine veränderte Umgebung (Cut-Over) ohne die Arbeitsabläufe des Unternehmens zu stören. Je nach Art des Projekts (z. B. Komplexität, Risiken, Unternehmenswert) eignen sich unterschiedliche Migrationsstrategien.
Beim Big-Bang oder Cold-Turkey Ansatz erfolgt die Inbetriebnahme des migrierten Systems und gleichzeitige Abschaltung des Altsystems in einem Schritt (Bisbal et al. 1997a, S. 21). Dadurch kann im Erfolgsfall das Enddatum einer Migration genau geplant beziehungsweise bestimmt werden (Bundesministerium des Innern 2008, S. 142). Treten jedoch Fehler auf, können sich fatale Auswirkungen auf die Leistungsfähigkeit des Unternehmens ergeben, da das Altsystem bereits abgeschaltet ist und das migrierte System nicht voll funktionsfähig ist. Bei kritischer Unternehmenssoftware ist eine stufenweise, inkrementelle Migrationsstrategie zu bevorzugen. Durch kleinere Arbeitspakete werden die Risiken minimiert und die Kosten der Migration auf mehrere Perioden verteilt. Zudem wird berücksichtigt, dass sich Anforderungen während des Projekts ändern können, die dann in einem folgenden Zyklus aufgenommen werden. Beim Chicken Little Ansatz wird die Legacy-Software in unabhängige Komponenten zerlegt, die nach und nach auf die Zielumgebung migriert werden (Brodie und Stonebraker 1993, S. 3). Diese Strategie setzt Zerlegbarkeit voraus. Bei stark monolithischer Software sind umfassende Untersuchungen notwendig, um mögliche Inkremente identifizieren und bilden zu können (siehe 2. Phase: Legacy System Understanding).
Der Database First Ansatz beziehungsweise die Forward Migration Methode gibt eine Empfehlung hinsichtlich der Reihenfolge der Migration von Komponenten. Zunächst wird die Software mit einem neuen Datenbanksystem lauffähig gemacht, bevor Anwendungs- und Benutzeroberflächenmigration folgen. Grundlage ist die Theorie, dass das Datenbanksystem von elementarer Bedeutung ist und die Harmonisierung zwischen zu migrierender Software und Datenbanksystem für die weiteren Migrationsaktivitäten erforderlich ist.
Beim Database Last Ansatz respektive bei der Reverse Migration Methode wird die Reihenfolge umgekehrt (Bisbal et al. 1997a, S. 22 f). Zunächst interagieren die bereits migrierten Komponenten mit der Altsystemdatenbank bis im letzten Schritt das Datenbanksystem in die Zielumgebung migriert wird.
Beim Composite Database Ansatz werden Legacy-System und Zielsystem parallel betrieben. Das Zielsystem wird inkrementell (neu-)entwickelt, um dieselbe Funktionalität des Legacy-Systems unter Verwendung neuer Technologien und Paradigmen bereitzustellen. Das hohe Risiko der einschrittigen Datenmigration (wie beim Database First und Database Last Ansatz) wird dadurch gemindert, allerdings um den Preis des hohen Aufwands einer Neuentwicklung.
Beim Butterfly Ansatz werden für die Dauer der Migration temporäre Datenbanken eingerichtet. Die ursprüngliche Datenbank wird für Schreibzugriffe gesperrt und zur Read-Only Datenquelle. Eine spezielle Komponente leitet Schreibanfragen der Legacy-Software an eine temporäre Datenbank weiter. Leseanfragen liefern entweder Daten aus der ursprünglichen Datenbank oder den temporären Datenbanken. Somit sind die Daten stets aktuell und die Datenmigration kann inkrementell erfolgen. Einen detaillierten Überblick dieses Ansatzes liefern die Autoren Bisbal et al. (1997b, S. 200-205).
Bei Wrapping wird die zu migrierende Software in ihrer Urform belassen. Der Zugriff auf Funktionalitäten erfolgt über Middleware, die in der geänderten Zielumgebung betriebsbereit ist und die Software kapselt (Majnar und Sneed 1998, S. 86). Selbst wenn keine Schnittstellen verfügbar sind, kann der Wrapping-Ansatz verfolgt werden (z. B. mit Hilfe von Screen Scraping).
2.3 Ressourcen
Eine Ressource ist ein Mittel, um eine Handlung zu tätigen oder einen Vorgang ablaufen zu lassen. Eine Ressource kann ein materielles oder immaterielles Gut sein. Da während der Software-Migration mehrere Handlungen getätigt werden, sind ergo Ressourcen notwendig, die eine Durchführung überhaupt erst möglich machen. Die Definition ist umfassender als der Marx‘sche Begriff „Arbeitsmittel“, der sich auf materielle Dinge beschränkt, die für die Durchführung von Produktionsprozessen erforderlich sind (1967, S. 194). Die Bezeichnung „Ressource“ ist daher geeigneter, da bei der Software-Migration insbesondere auch immaterielle Güter von Belang sind. Für Projekte sind typische Ressourcen zum Beispiel Personal, Zeit, finanzielle Mittel und Geräte. Die allgemeine Definition umfasst Mittel auf unterschiedlichen Abstraktionsebenen. Beispielsweise werden Büroräume, Arbeitsplätze und Telefonanschlüsse für eine Projektdurchführung benötigt. Dabei können die Begriffe durch ihre jeweiligen Vorgänger subsummiert werden. Eine vollständige Auflistung aller notwendigen Ressourcen verschiedener Software-Migrationsvorhaben gestaltet sich als problematisch, da mit abnehmender Verallgemeinerung beinahe unendlich viele Ressourcen identifiziert werden können. Es sollte nicht Ziel sein, einen Katalog zu erstellen, der bis zum Bleistift und Papier alles beinhaltet. Eine Zusammenfassung wesentlicher Ressourcen, die Kostenquellen bedeuten und für die Aufwandsanalyse von Interesse sind, ist anstrebenswert. Basis für die Ermittlung kann ein Projekt sein, dessen Bedarfsmittel um jene Ressourcen angereichert werden, die speziell bei der Software-Migration beansprucht werden. Die zu wählende Abstraktionsebene scheint beliebig. Beispielsweise könnte die Bezeichnung „Personal“ oder „interne Mitarbeiter“ und „externe Mitarbeiter“ gewählt werden. Bei der Software-Migration kann die Notwendigkeit von Microsoft Visual Studio in der Ressource „Software“ verallgemeinert werden. Für Konsistenz und Einheitlichkeit sind im Folgenden wesentliche Ressourcen beschrieben, die bei allen Software-Migrationsvorhaben benötigt werden oder zumindest typischerweise gebraucht werden. Für das bereits angeführte Beispiel bedeutet das, dass die Ressource „externe Mitarbeiter“ unter Personal zusammengefasst werden kann. Externes Personal ist nur dann notwendig, wenn das verlangte Migrationswissen innerhalb des Unternehmens nicht ausreichend ist oder nicht genügend Arbeitskraftkapazitäten existieren. Anhand der Gliederungsunterpunkte dieses Kapitels lassen sich nachfolgend bei der Typisierung Kostentreiber ermitteln, da Ressourcen nicht per se vorhanden sind, sondern knappe Güter darstellen, deren Beschaffung mit Aufwand verbunden ist. Daraus ergibt sich die Motivation, die Ressourcen von Software-Migrationsvorhaben im Rahmen dieser Arbeit zu sondieren.
2.3.1 Personal
Die zur Leistungserbringung eingesetzten, bezahlten Mitarbeiter eines Unternehmens werden als Personal bezeichnet (Gabler 2010). Es sind Menschen, die in jeder Art von Organisation in abhängiger Stellung arbeiten und innerhalb einer institutionell abgesicherten Ordnung eine Arbeitsleistung erbringen. Der Begriff Personal deutet damit auf überindividuelle Ordnungen hin, in denen Menschen nicht beliebig handeln, sondern für übergeordnete Ziele von Organisationen agieren. Das Ziel der Software-Migration ist der Projekterfolg, der mitunter dann erreicht wird, wenn die gewünschten Komponenten migriert wurden und das System dieselbe Funktionalität aufweist (s. Kapitel 2.1). Ohne Personal kann ein Projekt nicht durchgeführt werden. Damit handelt es sich um eine erfolgskritische Ressource. Die Komplexität der Aufgabe erfordert qualifizierte Menschen mit fachlicher und technischer Fähigkeit, die nicht immer innerhalb des Unternehmens verfügbar sind. Ein tiefes Verständnis des Altsystems ist obligatorisch, um Restrukturierungstätigkeiten durchführen zu können ohne die Lauffähigkeit des Systems zu destruieren. Bei Spezialsoftware kann beispielsweise der Hersteller geeignetes Personal mit adäquatem Know-How bereitstellen, da ihm der Quellcode zur Verfügung steht. Diverse IT-Consulting-Dienstleister haben sich auf Software-Migration spezialisiert und bieten entsprechende Dienste an (3i-Infotech 2010; ArtinSoft 2010; IBM 2010; Primeleaf 2010). Das zeigt, dass Bedarf an Experten von Fremdunternehmen gedeckt werden kann.
Die Basis für die Planung ist die Informationsbeschaffung über den erforderlichen Umfang und der benötigten Qualität der Ressource Personal (Oechsler 2006, S. 162). Da ein Projekt einen definierten Start und ein definiertes Ende hat, ist der Rahmen für die Dauer des Bedarfs bereits determiniert. Wobei berücksichtigt werden muss, dass nicht unbedingt alle Mitarbeiter während des gesamten Projekts benötigt werden. Software-Analysten werden zum Beispiel insbesondere in der Phase „Legacy System Understanding“ benötigt (s. Kapitel 2.2). Projektmanager begleiten das Vorhaben während der gesamten Dauer. Kernaufgabe ist die Ermittlung der Anzahl an Projektmitarbeitern mit bestimmter Qualifikation. Die Kosten für die Beschäftigung sind dann bekannt und können in die Aufwandsschätzung des Software-Migrationsvorhabens einfließen.
Aufwand = Dauer * Anzahl Personaleinheiten * Stunden/Monat
(Fiedler 2005, S. 121)
Anhand der Gleichung lässt sich der Personalaufwand berechnen, wenn Dauer, Anzahl Personaleinheiten und Stunden/Monat bekannt sind. Beispielsweise wird die Projektdauer auf zehn Monate geschätzt, es stehen zehn Mitarbeiter zur Verfügung, die 100 Stunden pro Monat Arbeit leisten, dann ergibt sich Aufwand von 10.000 Stunden. Die Gefahr beim Einsatz derartiger Gleichungen besteht in der Suggestion von Genauigkeit. Da jedoch kein Parameter mit hundertprozentiger Wahrscheinlichkeit angegeben werden kann, ist die Richtigkeit des Ergebnisses fraglich. Zudem wird mit Durchschnittswerten geplant, sodass es bei kurzen Projekten sinnvoller sein kann, die Stunden differenziert für jeden Monat zu errechnen (Fiedler 2005, S. 121). Es wird nicht berücksichtigt, dass Mitarbeiter unterschiedlicher Qualifikation benötigt werden. Stattdessen erfolgt eine Zusammenfassung zu Anzahl Personaleinheiten, wodurch der Eindruck entsteht, Mitarbeiter könnten beliebig ausgetauscht werden. Es darf allerdings vermutet werden, dass erfahrenere Mitarbeiter gleiche Arbeit schneller erledigen können als Anfänger. Dadurch ergibt sich eine unterschiedliche Aufwandshöhe. Falls im nächsten Schritt aus dem Aufwand eine monetäre Größe ermittelt werden soll (z. B. für eine Wirtschaftslichkeitsuntersuchung), muss bei der Personalbezahlung ebenfalls mit Durchschnittswerten gearbeitet werden. Ergo muss die Gleichung als Faustformel verstanden werden, die nicht zur differenzierten Detailplanung eingesetzt werden sollte.
Die Genauigkeit der Berechnung hängt von der Exaktheit der Datengrundlage und der Antizipation künftiger Ereignisse ab. Durch Störeinflüsse können sich Veränderungen ergeben. Beispielsweise hat der Ausfall eines Mitarbeiters durch Krankheit negative Konsequenzen für die Projektdurchführung. Terminliche Vorgaben können nicht mehr eingehalten werden, die Qualität oder der Umfang des Migrationsergebnisses sinkt oder es ergibt sich zusätzlicher Aufwand für die Akquise eines Ersatzmitarbeiters. Es muss berücksichtigt werden, dass die bezahlte Arbeitszeit nicht immer der effektiven Arbeitszeit entspricht. Abbildung 1 stellt Komponenten der effektiven Arbeitszeit auf.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 1: Komponenten der effektiven Arbeitszeit
Quelle: Bühner 2005, S. 186; Kohlöffel 1988, S. 41
Die Leistungserbringung durch Menschen setzt gute Personalmotivation voraus. Der Projekterfolg ist mitunter abhängig von Individuen. Durch geeignete Maßnahmen (z. B. Schaffung eines angenehmen Arbeitsklimas) kann die effektive Arbeitszeit erhöht werden, wenn die Bereitschaft zur produktiveren Leistungserbringung erreicht wird. Inwieweit die Ausfallzeiten durch Krankheit, Kur und Unfall aus Abbildung 1 beeinflussbar sind, darf diskutiert werden. Für den interessierten Leser liefert Kolb umfassenden theoretischen Hintergrund zum Thema Mitarbeitermotivation (2008, S. 360ff.).
Die Personalbeschaffung ist abhängig von „wettbewerbsbedingten Erfordernissen, der Abeitsmarktsituation, des normativen Regelungsrahmens und der spezifischen Arbeitnehmerinteressen“ (Oechsler 2006, S. 218). Durch diese Verflechtung ergibt sich Kompliziertheit der bedarfsgerechten Personalbeschaffung. Bühner begegnet dieser Problematik mit dem Modell eines integrierten Planungsprozesses in Form eines Planungskalenders, bei dem strategische Aspekte unter zeitlicher Betrachtung in einem Top-Down-Verfahren zu Maßnahmen verfeinert werden (2005, S. 33).
2.3.2 Zeit
In jedem Projekt ist die Zeit eine bedeutende Komponente. Dies ergibt sich daraus, dass Start- und Endtermin definiert sind. Alle Aktivitäten werden in einem vorgegebenen Zeitrahmen durchgeführt. Um die Projektdauer zu bestimmen, kann der Umfang und die gewünschte Qualität betrachtet werden oder sie ist bereits durch externe Bedingungen gegeben (z. B. feste Releasezyklen).Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2: Magisches Dreieck des Projektmanagements
Quelle: Keßler, Winkelhofer 2004, S. 55
Abbildung 2 veranschaulicht den Sachverhalt, dass „Zeit und Termin“, „Ziele, Leistung, Qualität, Nutzen“ und „Kosten und Personalkapazitäten“ nicht unabhängig voneinander sind. Falls die Projektdauer verkürzt wird, können weniger Ziele erreicht werden oder die Kosten steigen, da mehr Personal beschäftigt werden muss. Falls zwei Eckpunkte des Dreiecks gegeben sind, so ergibt sich zwangsläufig die dritte. Es sollte beachtet werden, dass das Dreieck ein Modell ist, das von der Realität abweicht. Projekttermine lassen sich nicht beliebig verschieben und durch ein höheres Budget oder mehr Mitarbeiter kompensieren. Dazu müsste uneingeschränktes paralleles Arbeiten möglich sein. Bei sequentiellem Migrieren von Softwarekomponenten ist dieser Umstand jedoch nicht gegeben. Typischerweise lautet die Fragestellung bei der Software-Migration ferner nicht, welcher Migrationsumfang mit gegebenem Budget und Zeitrahmen erreicht werden kann, sondern die Projektdauer beziehungsweise die Kosten ergeben sich aus den gewünschten Migrationszielen. Aufgrund zu knapper Zeitvorgaben nur einen Teil des Programmcodes einer Java-Webanwendung nach ASP.NET zu portieren, dürfte inakzeptabel sein, da im Ergebnis keine lauffähige Software erzeugt wird. Zudem muss eine Lockerung der Termindringlichkeiten nicht zwangsläufig zu geringeren Kosten führen. Für die verlängerte Projektdauer muss wiederum Personal beschäftigt und bezahlt werden.
Die Ressource Zeit kann nicht beliebig „beschafft“ werden. Während mit genügend Budget beispielsweise unbeschränkt Hardware gekauft werden kann (Verfügbarkeit vorausgesetzt) unterliegt die Zeit höherer Gewalt. Das Unternehmen kann nicht ändern, dass ein Tag aus 24 Stunden besteht. Neben der quantitativen Eigenschaft, weist Marr auf die qualitative Dimension hin (2001, S. 14). Beschäftigungszeit an Wochenenden und Feiertagen kann aufgrund von Sonderzulagen und damit verbundenen höheren Kosten von besonderer Bedeutung sein. Mittagspausen sind aus Unternehmenssicht weniger wichtig als produktive Arbeitszeit, in der Wertschöpfung stattfindet.
2.3.3 Infrastruktur
Eine Infrastruktur vernetzt Menschen, Hardware und Software und ermöglicht so den Informationsaustausch. Projektarbeit ist Teamarbeit und erfordert Kommunikation unter den Beteiligten. Es muss sichergestellt sein, dass die Mitarbeiter einen Arbeitsplatz, erforderlichenfalls mit Internetanbindung, zur Verfügung gestellt bekommen. Falls die Stakeholder räumlich getrennt sind, kann mittels elektronischer Dienste und Netze eine Verbindung hergestellt werden (z. B. Telekommunikation, Internetanbindung, VPN). Dabei sollte beachtet werden, dass hinreichende Qualität der Dienste zur Verfügung steht. Falls über Voice-Over-IP (VoIP) kommuniziert wird, ist zusätzliche Bandbreite notwendig. Wenn große Datenmengen zwischen den Akteuren ausgetauscht werden müssen, kann eine schlechte Datenleitung ein Hindernis für die Produktivität sein. Andererseits ist eine schnellere Anbindung in der Regel mit höheren Kosten verbunden, sodass ein Abwägen stattfinden muss. Hohe Effizienz der Bandbreite ist wünschenswert, die dann erreicht wird, wenn sie gleichmäßig hoch in Anspruch genommen wird. Für die Verwaltung der IT-Infrastruktur werden wiederum Personalressourcen benötigt. Netzwerkadministratoren stellen die Verfügbarkeit, Erreichbarkeit und Qualität sicher. Autorisierte müssen Zugang zu benötigten Netzwerkressourcen erhalten (bspw. Testdaten, Testsystem und Projektinformationen). Diese Daten sind vom Zugriff durch Fremde zu schützen (z. B. mittels Firewall und VPN). Bei multikulturellen Teams in unterschiedlichen Zeitzonen entsteht Managementaufwand zum Abbau von kulturellen Barrieren. Hier zeigen sich Abhängigkeiten und Verbindungen zwischen den Ressourcen. Dadurch ergibt sich Planungskomplexität.
[...]
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen.