Wismar Internationale Graduation Services Ein Unternehmen der Hochschule Wismar. Fakultät für Wirtschaftswissenschaften.

Transkript

1 Wismar Internationale Graduation Services Ein Unternehmen der Hochschule Wismar Fakultät für Wirtschaftswissenschaften Formale Methoden Prof. Dr. Jürgen Cleve Thema: Software-Lebenszyklus Autor: Tobias Angele Datum:

2 Software-Lebenszyklus I Inhaltsverzeichnis I II Inhaltsverzeichnis... I Abbildungsverzeichnis... III 1 Einleitung Motivation Zielsetzung und Vorgehensweise Software-Lebenszyklus Definition Abgrenzung zum Produktlebenszyklus Probleme bei der Entwicklung von Software Stufen des Software-Lebenszyklus Vorgehensmodelle Wasserfallmodell Spiralmodell V-Modell Problemstellung Analyse/Entwurf Implementierung Test Einführung Pflege/Wartung Kostenverteilung im Software-Lebenszyklus Software-Alterung Definition Gründe für Software-Alterung Phasen der Software-Alterung Beispiele der Software-Alterung Das Jahr-2000-Problem Die Einführung des Euro Abhängigkeit vom Hersteller...16

3 Software-Lebenszyklus II 4 Software-Reengineering Definition Forward Engineering Reverse Engineering Restrukturierung Kosten des Reengineering Refactoring Definition Fallstudie Refactoring Einkapseln von Altsystemen Fazit...41 Literaturverzeichnis...43

4 Software-Lebenszyklus III Abbildungsverzeichnis Abb. 2.1 : QTK-Dreieck Abb. 2.2 : Stufen des Software-Lebenszyklus Abb. 2.3 : Wasserfallmodell Abb. 2.4 : Spiralmodell Abb. 2.5 : V-Modell Abb. 2.6: Kostenverteilung im Software-Lebenszyklus Abb. 3.1: Lebenszyklus langlebiger Software-Systeme Abb. 3.2: Risiko im Software-Lebenszyklus Abb. 4.1: Software Reengineering

5 Software-Lebenszyklus 1 1 Einleitung 1.1 Motivation Die Projektarbeit Software-Lebenszyklus wird im Modul Formale Methoden im dritten Semester des Masterstudiengangs Wirtschaftsinformatik an der Hochschule Wismar erstellt. Hauptgrundlage für das Modul und die Projektarbeit ist das Buch Software-Qualität von Dirk W. Hoffmann. Die Projektarbeit orientiert sich maßgeblich am Kapitel sieben Software- Lebenszyklus dieses Buches. 1.2 Zielsetzung und Vorgehensweise Ziel dieser Arbeit ist es, das Phänomen der Software-Alterung in den Kontext des Software- Lebenszyklus zu setzen und die Bedeutung bzw. die Auswirkungen darzustellen. Im Anschluss an die Einleitung werden einige Grundlagen, Fakten und Daten des Software- Lebenszyklus präsentiert, die das Thema näher beleuchten. Dies soll als Grundlage für das folgende Kapitel Software-Alterung dienen, in dem vor allem die Gründe und Phasen der Software-Alterung beleuchtet, aber auch die Auswirkungen aufgezeit werden. Auf dieser Basis werden im vierten Kapitel Software-Reengineering mögliche Ansätze aufgezeit, um den Phänomen der Software-Alterung effektiv und effizient entgegenzuwirken. Das abschließende Fazit fasst noch einmal die Erkenntnisse dieser Arbeit zusammen und hebt die wichtigsten Punkte hervor.

6 Software-Lebenszyklus 2 2 Software-Lebenszyklus 2.1 Definition Ein Software-Lebenszyklus beginnt vor der Markteinführung einer Softwarelösung und besteht aus den Phasen Problementstehung, Entwicklungsprozess, Implementierung und Nutzung und wird durch die Ablösung der Software durch ihren Nachfolger abgeschlossen. Auf die Entstehung eines softwaretechnisch zu lösenden Problems folgt der Prozess der Softwareentwicklung, dessen Phasen vom verwendeten Vorgehensmodell abhängig sind. Es gibt streng sequentiell ablaufende Vorgehensmodelle, wie das Wasserfall-Modell, und Neuere, wie das Spiral-Modell. Die Softwareentwicklung wird mit der Implementierung abgeschlossen und es folgt der produktive Einsatz der Software, in der auch Wartungsarbeiten vorgenommen werden. Unter Wartung versteht man sowohl das Beheben von Fehlern, als auch das Anpassen des Systems an eine veränderte Umgebung oder die Anreicherung durch weitere Funktionen. Beides führt zur Softwarealterung. Ein Software-Lebenszyklus endet schließlich durch die Ablösung des Systems durch ein Nachfolgeprodukt Abgrenzung zum Produktlebenszyklus Der Begriff Produktlebenszyklus umfasst im Vergleich zum Software-Lebenszyklus den Zeitablauf zwischen Markteinführung und Herausnahme eines Produkts aus dem Markt Probleme bei der Entwicklung von Software Software ist ein Produkt des Geistes und trägt immer die Handschrift des Entwicklers. Bereits bei der Erstellung kommt die persönliche Note des Entwicklers zum Tragen. Das mag für den Ein-Mann-Betrieb genügen, in größeren Betrieben und im Team müssen alle Beteiligten sich bestimmten Spielregeln unterwerfen. Aber selbst der Alleinprogrammierer sollte sich die Mühe machen, seine Arbeit nicht nur für den Augenblick zu gestalten. Es ist einleuchtend, dass ein sorgfältiger Entwurf und dessen Dokumentation genauso wichtig sind 1 vgl. Gabler Wirtschaftsinformatik-Lexikon 2 vgl. Gabler Wirtschaftsinformatik-Lexikon

7 Software-Lebenszyklus 3 wie die einwandfreie Funktion des Produktes. Es gilt vor allem, den ständig herrschenden Zielkonflikten zwischen Qualität, Kosten und Zeit bei der Erstellung, beim Vertrieb und in der Lebensdauer des Produktes entgegenzuwirken. Abb. 2.1: QTK-Dreieck 3 In diesem Kräftedreieck zwischen Qualität, Kosten und Zeit verhält es sich ähnlich wie beim Magischen Viereck in der Wirtschaft. Man kann jeweils nur zwei Faktoren festhalten und aufeinander abstimmen, den dritten hat man dann kaum noch unter Kontrolle. 3 Quelle: Wikipedia

8 Software-Lebenszyklus Stufen des Software-Lebenszyklus Der Softwarelebenszyklus lässt sich in mehrere Stufen einteilen, die in Abb. 2.2 aufgezeigt und im Folgenden näher beleuchtet werden. Ein Software-Lebenszyklus beginnt vor der Markteinführung einer Softwarelösung und besteht aus den Phasen Problementstehung, Entwicklungsprozess, Implementierung und Nutzung und wird durch die Ablösung der Software durch ihren Nachfolger abgeschlossen. Abb. 2.2: Stufen des Software-Lebenszyklus 4 Die Softwareentwicklung wird mit der Implementierung abgeschlossen und es folgt der produktive Einsatz der Software, in der auch Wartungsarbeiten vorgenommen werden. Unter Wartung versteht man sowohl das Beheben von Fehlern, als auch das Anpassen des Systems an eine veränderte Umgebung oder die Anreicherung durch weitere Funktionen. Beides führt zur Softwarealterung. Ein Software-Lebenszyklus endet schließlich durch die Ablösung des Systems durch ein Nachfolgeprodukt. 4 Quelle: Wikipedia

9 Software-Lebenszyklus Vorgehensmodelle Auf die Entstehung eines softwaretechnisch zu lösenden Problems folgt der Prozess der Softwareentwicklung, dessen Phasen vom verwendeten Vorgehensmodell abhängig sind. Es gibt streng sequentiell ablaufende Vorgehensmodelle, wie das Wasserfallmodell, und Neuere, wie das Spiral- oder V-Modell Wasserfallmodell Abb. 2.3: Wasserfallmodell 5 Eine dem Phasenmodell ähnliche Struktur hat das Wasserfallmodell. Die Entwicklung erfolgt von der Voruntersuchung bis zur Einführung des Produkts in mehreren Phasen. Nach jeder Phase findet eine Meilenstein-Sitzung statt, auf der das Ergebnis abgenommen werden muss, bevor in die nächste Phase übergegangen wird. Es besteht auch die Möglichkeit, bei mangelhaftem Ergebnis in die vorherige Phase zurückzukehren. 5 Quelle: Wikipedia

10 Software-Lebenszyklus Spiralmodell Das Wasserfallmodell ist wahrscheinlich der gebräuchlichste Lebenszyklusansatz, weil er dem gesunden Menschenverstand am nächsten steht - er wirkt natürlich. Das Spiralmodell (iterative Modell) des Software-Lebenszyklus wiederholt das Wasserfallmodell so lange, bis das Produkt fertig ist. Abb. 2.4: Spiralmodell 6 Diese Abbildung zeigt, dass der Spiralprozess mit der Analyse beginnt, mit dem Design fortfährt und dann zur Realisierung geht. Danach wird der Prozess wiederholt, indem er erneut mit der Analysephase beginnt. Mit dieser Methode kann das Entwicklungsteam das Projekt schrittweise vervollständigen. Möglicherweise werden beim ersten Durchlauf nur die unbedingt erforderlichen Funktionen berücksichtigt. Beim zweiten werden dann die wünschenswerten Funktionen hinzugefügt und bei einem letzten Durchlauf werden die exotischen Funktionen implementiert, die wahrscheinlich niemals benutzt werden. 6 Quelle: Wikipedia

11 Software-Lebenszyklus 7 Andererseits können auch mehrere Durchläufe nach dem Muster Analyse-Design- Realisierung erforderlich sein, bevor das System annähernd die Anforderungen der Endbenutzer erfüllt V-Modell Das V-Modell ist eine Weiterentwicklung des Wasserfallmodells. Es integriert die Qualitätssicherung in die Entwicklungsmethode. Das bedeutet, dass während des gesamten Entwicklungsprozesses eine Verifikation und Validierung der Teilergebnisse stattfindet [HB98]. Einigen Phasen des Wasserfallmodells wurden dazu geeignete Testszenarien zugeordnet. Auf jeder logischen Ebene des Entwicklungsprozesses findet eine Validierung bzw. Verifikation über entsprechende Anwendungsszenarien bzw. Testfälle statt, wie es die folgende Abbildung zeigt. Abb. 2.5: V-Modell 7 Bei der Verifikation wird durch geeignete Testfälle geprüft, ob der Entwickler die Software gemäß der Anforderungsspezifikation erstellt, d.h. ob die Software korrekt ist. Bei der Validierung wird über entsprechende Anwendungsszenarien die Eignung der Software bewertet. Dabei stellt sich die Frage, ob die richtige Software entwickelt wurde. Dieses Modell der Softwareentwicklung sieht eine regelmäßige Überprüfung durch die Kundenseite 7 Quelle: Wikipedia

12 Software-Lebenszyklus 8 vor. Die Kunden-Entwickler-Schnittstelle ist somit fester Bestandteil dieser Entwicklungsmethode. Der Nachteil bleibt die späte Implementierungsphase und folglich die späte Testphase der Software. Das Risiko, Fehler in der Anforderungsspezifikation in die Phase der Implementierung zu verschleppen, wird durch die Validierung geringer und der Kunde hat die Möglichkeit, Änderungen zu initiieren, anders als bei den vorangegangenen Modellen Problemstellung Definition der Aufgabe, die durch die Software zukünftig übernommen werden soll (aber nicht, wie die Leistungsmerkmale erreicht werden). Hier werden alle relevanten Funktions- und Qualitätsmerkmale spezifiziert. Die jeweiligen Angaben werden im Pflichtenheft/Lastenheft dokumentiert. Die Anforderungsdefinition muss - verständlich (auch für den Kunden), - präzise, - vollständig und konsistent sein. Das Ergebnis dieser Phase ist das Pflichtenheft, das in der Regel immer Bestandteil des Vertrags ist. Oft ist dabei auch eine vorläufige Benutzeranleitung Bestandteil des Pflichtenheftes Analyse/Entwurf Im Entwurf wird die Systemarchitektur festgelegt: - welche Module (Objekte, Klassen) gibt es? - welche Beziehungen bestehen zwischen ihnen? Häufig wird hier nach dem Top-Down Entwurf vorgegangen. Dabei wird das System in Komponenten zerlegt, die Komponenten in Unterkomponenten usw. Oft ist die Verwendung spezieller Architektur- oder Systembeschreibungssprachen sinnvoll. Ergebnis der Phase ist die Entwurfsbeschreibung, die die Systemarchitektur festhält.

13 Software-Lebenszyklus Implementierung In dieser Phase erfolgt die eigentliche Codeierung der Software. Ergebnis ist der Implementierungsbericht, der Details der Implementierung beschreibt (etwa Abweichungen vom Entwurf, Abweichungen vom Zeitplan, Begründungen dazu) Test Die Software wird verschiedenen Tests unterzogen, die in der Regel nach bestimmten Testszenarios durchgeführt werden. Dies beinhaltet vor allem den Test einzelner Module, aber auch teilweise bereits den Test der Software als Ganzes, bzw. mehrerer direkt voneinander abhängiger Module. Die Ergebnisse der Testphase sind zum einen der Testbericht, der die durchgeführten Tests und ihre Ergebnisse beschreibt, und zum anderen der getestete Programmtext der einzelnen Module Einführung Die Module werden zu einem Programm zusammengebunden und das Zusammenspiel der einzelnen Komponenten wird erneut sichergestellt. Die Einführungsphase kann teilweise mit der vorangegangenen Testphase verschmolzen sein Schließlich wird das gesamte System getestet, zunächst nur innerhalb der Entwicklungsorganisation (Alpha-Test), später bei ausgewählten Kunden (Beta-Test) Die Ergebnisse dieser Phase sind das laufende System und die Benutzeranleitung in endgültiger Form Pflege/Wartung Dies stellt die in jeder Hinsicht aufwendigste Phase im Software-Lebenszyklus dar. Die Pflege- und Wartungsphase ist, sowohl aus zeitlicher Sicht, als auch aus der Kostenperspektive gesehen, eine sehr umfangreiche Phase. Wie im Folgenden noch genauer aufgeführt, nehmen die Kosten für Pflege und Wartung ca. 67% der Gesamtkosten im Software-Lebenszyklus ein, davon werden wiederum ca. 20% für Fehlerbeseitigung, 20% für Adaption (z.b. Anpassung an neues Betriebssystem) und 60% für Perfektion (z.b. Umstellung von alphanumerischer auf graphische Schnittstelle) verwendet.

14 Software-Lebenszyklus Kostenverteilung im Software-Lebenszyklus Betrachtet man den Verlauf der Höhe der Kosten, die innerhalb des Software-Lebenszyklus entstehen, wird deutlich, welche Bedeutung die Phase der Pflege und Wartung (Maintenance) hat. In Abb. 2.6 wird plastisch dargestellt, inwieweit die einzelen Phasen für die Verursachung von Kosten verantwortlich sind. Abb. 2.6: Kostenverteilung im Software-Lebenszyklus 8 8 Quelle: Gilb, Tom: Principles of Software Engineering

15 Software-Lebenszyklus 11 3 Software-Alterung 3.1 Definition Die Software-Alterung ist für Software das Pendant zur Materialermüdung. Im Gegensatz zur allgemeinen Meinung unterliegt auch Software einer besonderen Art von Alterung. Sie hat keinen Verschleiß und auch keine Abnutzung, da sie nur aus digitalen Daten besteht, aber sie hat trotzdem nur eine begrenzte Lebenserwartung. Softwarealterung betrifft alle Systeme, die kontinuierlich weiterentwickelt werden. Einige Faktoren können aber die Alterung beschleunigen, wie zum Beispiel der Termindruck bei der Entwicklung oder hohe Ansprüche an die Wiederverwendung. Die Alterung kann daran erkannt werden, dass die Strukturen sehr komplex werden oder dass sich sie die Software nicht immer wie erwartet verhält. 3.2 Gründe für Software-Alterung Im Laufe der Zeit ändern sich die Gegebenheiten der Softwareumgebung. Es sind neue Techniken, Anforderungen und Formate entstanden, die bei der Entwicklung nicht vollständig bekannt waren oder vorhergesagt werden konnten bzw. aus Nachlässigkeit schlicht nicht beachtet wurden. Eine mangelnde Anpassung an diese Gegebenheiten kann zu Problemen, Fehlern oder einfach zu einem verringerten Nutzen des Programmes führen - im Extremfall bis zu dem Punkt, dass das Programm nicht mehr lauffähig ist. Auf der anderen Seite führen gerade diese notwendigen Anpassungen, Fehlerbehebungen, Erweiterungen des Funktionsumfanges oder andere Änderungen oft zu einem unstrukturierten Programm, einem unübersichtlichen Quelltext und zu neuen Fehlern; genau dies sind die Kennzeichen der Alterung von Software. Angeforderte neue Funktionen werden eher angebaut als nahtlos integriert. Wären diese Anforderungen von vornherein bekannt gewesen, wären sie besser integriert worden. Theoretisch kann man das System natürlich auch dementsprechend jedes Mal umgestalten, dann wären aber größere Teile von dem Umbau betroffen und der Umbau würde entsprechend teuer und länger dauern; aus Kosten- und Termingründen sind ideale Lösungen i.d.r. nicht möglich. Dieser Effekt wird oft als Degenerierung der Architektur bezeichnet. Das Ausmaß hängt stark von der Programmiersprache und von der Qualität des Erstentwurfs ab.

16 Software-Lebenszyklus 12 Ursprünglich klare und ohne große Dokumentation erkennbare Entwurfsentscheidungen werden nach mehreren Umbauten immer schwerer erkennbar. Typischerweise steigt der Arbeitsaufwand, das System zu verstehen, nach mehreren Umbauten deutlich an. Diese Aufwände sind dabei ein Hauptkostenfaktor für die Umbaukosten. Oft verschlechtert sich auch die Effizienz oder Leistung des Systems, weil in den neuen Funktionen Daten sicherheitshalber redundant gehalten werden oder die Verarbeitung umständlicher ist. Im Endeffekt werden Systeme nach vielen aufeinanderfolgenden Anpassungen fehleranfälliger, weniger effizient und immer schlechter wartbar. Von David Parnas wurde hierzu der Begriff Software-Alterung geprägt. Gegenmaßnahmen zur Software-Alterung sind: - ein guter Erstentwurf, in dem kommende Änderungen vorausgesehen worden sind und dementsprechend durch präventive Maßnahmen erleichtert werden ( design for change ). Dies verlangt viel Erfahrung in der jeweiligen Systemklasse oder Applikationsdomäne. Diese präventiven Maßnahmen können die Alterung deutlich verlangsamen, aber nicht ganz verhindern. - Reengineering, also Umbauten oder sonstige gezielte Maßnahmen, die die Qualität des Systems wieder anheben und Schwächen beheben. 3.3 Phasen der Software-Alterung Die Software-Alterung stellt eines der wichtigsten und zugleich am häufigsten missverstandenen Problemen großer Software-Systeme dar. 9 Der Begriff Software-Alterung ist dabei als schleichende Degradierung verschiedener Qualitätsparameter über die Zeit zu verstehen. 10 Trotz der sich rasch ändernden Technologien und Rahmenbedingungen im Software- Bereich, zeigen sich die ersten Symptome der Software-Alterung in der Regel erst nach einigen Jahren. Die Auswirkungen sind dann oft aber umso größer, da die Funktionalität oft kurzfristig nicht mehr gewährleistet ist und ein rascher Handlungsbedarf besteht, der oft sehr kostenintensiv auf die Betroffenen wirkt. Die meisten langlebigen Software-Produkte durchlaufen drei Phasen, die in Abb. 3.1 dargestellt sind. Die erste Phase spiegelt den klassischen Software-Entwicklungszyklus 9 vgl. Hoffmann, D. W. (2008): Software-Qualität 10 vgl. Hoffmann, D. W. (2008): Software-Qualität

17 Software-Lebenszyklus 13 wieder. Am Ende steht ein erstes Software-Produkt, das in der Regel für ein einziges Betriebssystem und eine einzige Hardware-Plattform entwickelt wurde. Jetzt entscheidet der Markt, ob die Software das Potenzial besitzt, zu einem langlebigen Produkt zu werden. Kann sich ein System erfolgreich am Markt etablieren, setzen in der Regel zwei parallele Entwicklungen ein die Code-Basis expandiert und das Produkt diversifiziert. Mit anderen Worten: Die Software wird erwachsen. 11 Abb. 3.1: Lebenszyklus langlebiger Software-Systeme 12 Während die stetig wachsende Code-Basis die unmittelbare Folge der permanenten Weiterentwicklung ist, hat die Diversifizierung mehrere Gründe. Zum einen entstehen in regelmäßigen Abständen neue Releases, die in den meisten Fällen voneinander getrennt gewartet und gepflegt werden müssen. Zum anderen keimt bereits nach kurzer Zeit der Wunsch auf, ein erfolgreiches Produkt auch für andere Hardware-Plattformen und Betriebssysteme verfügbar zu machen. Zusätzliche Produktvarianten entstehen, wenn für wichtige Kunden individuelle Modifikationen der Software vorgenommen werden. In dieser Phase ist die Diversifizierung bereits in vollem Gange und der effiziente Umgang mit verschiedenen Produktversionen und -varianten erfordert einen ausgeklügelten Entwicklungsprozess. 11 vgl. Dirk W. Hoffmann: Software-Qualität 12 vgl. Software-Qualität, Dirk W. Hoffmann

18 Software-Lebenszyklus 14 Mit zunehmender Lebensdauer beginnt fast zwangsläufig eine schleichende Degeneration der Code-Basis. Unter anderen sind es die ständig wechselnden Anforderungen, die im Laufe der Zeit viele kleine und große Änderungen an der Quelltextbasis nach sich ziehen. Wie der stete Tropfen den Stein werden die ehemals soliden Programmstrukturen immer weiter ausgehöhlt. Unzählige Fehlerkorrekturen tragen ihren Teil zu der Misere bei. Ähnlich wird der Alterungsprozess auch vom führenden Softwarehersteller Oracle dargestellt. Der Fokus der folgenden Abbildung 3.2 liegt jedoch vor allem auf dem Risiko, das der Anwender innerhalb des Software-Lebenszyklus zu tragen hat. Während die Implementierung einer neuen Software immer mit erheblichem Risiko einhergeht, beginnt nach einer variablen Phase der Sicherheit bereits die Degeneration, die wiederum nicht zu vernachlässigende Risiken birgt. Abb. 3.2: Risiko im Software-Lebenszyklus Beispiele für Software-Alterung Die wohl bekanntesten Beispiele der Software-Alterung waren das Jahr-2000-Problem und in gewissem Umfang auch die Einführung des Euro. 13 Quelle: Oracle

19 Software-Lebenszyklus Das Jahr-2000-Problem Angesichts des Jahreswechsels 1999/2000 wurde das Problem offenbar, dass mit der in vielen Computersystemen eingesetzten zweistelligen Jahreszahl 00 sowohl das Jahr 1900 als auch das Jahr 2000 bezeichnet wird und somit eine inakzeptable Mehrdeutigkeit eines Wertes vorliegt. Die Folgen dieses Fehlers wären ohne Korrektur in erster Linie falsche Sortierungen und Altersberechnungen gewesen. Weiterhin war es weit verbreitete Praxis, ungültige Datensätze durch die Verwendung der Zahl bzw. Ziffernkombination 00 ( Nichts ) zu identifizieren, jedoch trat diese Ziffernkombination mit dem Eintreten des Jahres 2000 dann auch als normaler Wert auf. Durch diesen Umstand behandelten viele Programme diese Datensätze nunmehr als ungültig. Im Weiteren gab es vor allem Rechenprobleme durch fehlerhafte Differenzbildung und fehlerhafte Erzeugung von Texten (typisches Beispiel hierfür wäre eine Datierung mit der Jahreszahl 1901 oder für das Jahr 2001). Bei damals älteren PCs kam hinzu, dass die interne Echtzeituhr nicht automatisch das Jahrhundert umschalten konnte, was weder vom BIOS noch von MS-DOS oder Windows 98 automatisch korrigiert wurde. Aufgrund dieser Probleme wurden im Vorfeld des Jahreswechsels 1999/2000 Katastrophenszenarien vorhergesagt, dass durch diesen Fehler Computerabstürze in großem Maß erfolgen würden und besonders sicherheitsrelevante Bereiche, die auf Computer angewiesen sind (Banken, Industrie oder auch Kraftwerke, im extremsten Fall der Vorhersagen sogar Atomwaffen), durch das Problem fehlgeschaltet oder gar lahm gelegt würden. Zum Jahreswechsel stellte sich dann aber heraus, dass die Industrie in der Regel gut vorgebeugt hatte. Weltweit wurden in vielen Projekten Programme und Datenbestände (vor allem auf Großrechnern) saniert, um den Y2K-bug zu vermeiden. Dennoch hatten viele Banken in der Silvesternacht einfach ihre Geldautomaten abgestellt, um Fehler zu vermeiden. Dieses Problem ist sozusagen mehr oder weniger historisch gewachsen. In den 1960er und 1970er Jahren war Speicherplatz sehr teuer und deshalb meist knapp, deshalb hatten die Programmierer soviel wie möglich an Speicherbedarf eingespart. Zum Beispiel wurden zur Speicherung von Jahreszahlen (in Dezimaldarstellung) nur die letzten beiden Ziffern (Jahr und Jahrzehnt) benutzt. Die ersten beiden Ziffern, die das Jahrhundert angeben, wurden nicht berücksichtigt, da man davon ausging, dass die Programme ohnehin nur für wenige Jahre in dieser Weise benutzt würden. Da aber viele Programme im Laufe der Jahre immer wieder auf vorangegangene Programm-Systeme aufbauten, dachte man nicht mehr daran, dass es einmal zu einer Umstellung auf die Zahl 00 kommen würde. Speziell EDVgesteuerte Hardwarekomponenten (ein sog. Eingebettetes System, engl. embedded system)

20 Software-Lebenszyklus 16 stellten ein Problem dar, da hier nicht einfach die Software umprogrammiert werden konnte, sondern die Hardware ausgetauscht oder deren Mikroprogramm geändert werden musste. Ende der 90er-Jahre war es kaum realistisch zu beurteilen, inwiefern die Y2K-Problematik von wirklicher Relevanz sein würde. Es gab kritische Stimmen in den Medien, die apokalyptische Versionen mit weltweiten Computerzusammenbrüchen prognostizierten, die möglicherweise eine Weltwirtschaftskrise auslösen könnten. Sorgfältige Analysen von Fachleuten wiesen jedoch auch reale Gefahren aus. Daraufhin wurde von einigen großen Unternehmen die genaue Untersuchung der Computersysteme angeordnet, um die befürchteten Folgen so gering wie möglich zu halten. Während einige Medien noch bis zum kritischen Jahreswechsel 1999/2000 besorgte Berichte verbreitet hatten, wurde es Anfang 2000 deutlich, dass die vorsorglichen Maßnahmen im Großen und Ganzen ausreichend waren Die Einführung des Euro Bei der Einführung des Euro stellte sich die Situation oft nicht ganz so kritisch dar, da dies vielfach schon bei der Umstellung zum Jahr 2000 berücksichtigt worden war bzw. oftmals die Einführung einer zusätzlichen Währung bereits im Leistungsumfang der Software enthalten war. Schwierigkeiten ergaben sich nur in Programmen, die ausschließlich mit einer Währung arbeiteten und den Änderungszeitraum überschneidende Berechnungen vornehmen können mussten. 3.5 Abhängigkeit vom Hersteller Die Alterung der Software führt dazu, dass der Anwender auch auf Änderungen der Software angewiesen ist. Bei proprietärer Software kann diese nur der ursprüngliche Hersteller liefern, der Nutzer ist damit auch nach dem Kauf von diesem abhängig. Bei Open-Source-Software besteht keine zwingende Abhängigkeit von einem bestimmten Hersteller. Da man durch die Aktualisierungen an den Hersteller gebunden ist, wird die illegale Nutzung von Software erschwert, da man auch einen Weg braucht, um an die Aktualisierungen der Software zu gelangen. Bei Microsoft Windows sind zum Beispiel einige Updates auf registrierte Benutzer beschränkt.

21 Software-Lebenszyklus 17 4 Software-Reengineering 4.1 Definition Es gibt zahlreiche Definitionen des Reengineering, hier wird die auf Chikofsky und Cross zurückgehende benutzt: Reengineering ist die Analyse und Änderung eines Systems mit dem Ziel, die Qualität zu verbessern und gleichzeitig die Funktionalität unverändert zu lassen. Teilweise wird dies auch als Software-Sanierung bezeichnet. Reengineering verursacht relativ viel Aufwand. Die Frage stellt sich daher automatisch, unter welchen Umständen man diesen Aufwand treiben sollte und wann er sich rentiert. Ausgelöst wird Reengineering immer durch eine Wartungsmaßnahme, also eine gewünschte Änderung des Systems. Sinnvoll ist Reengineering dann, wenn das System so schlecht strukturiert ist (ggf. infolge früherer Umbauten), dass die Seiteneffekte der geplanten Änderung nicht überblickt werden können und entsprechende Tests oder andere Maßnahmen zur Qualitätssicherung des neuen Systems extrem teuer würden. Beispiele hierfür sind fehlende Kapselungen von Datenstrukturen oder Vermischungen von Funktionen. Die Investitionen in das Reengineering amortisieren sich dadurch, dass die Kosten der eigentlichen Umbauten in vergleichbarer Höhe sinken und die Unsicherheitsfaktoren, die die Zuverlässigkeit des Systems gefährden, reduziert werden wenn die geplante Änderung die Architektur zu kompliziert machte und damit zu einem späteren Zeitpunkt zu erwartende weitere Umbauten verteuern würde. Reengineering besteht im Wesentlichen aus drei Hauptphasen (Reverse Engineering, Restrukturierung und Forward Engineering), die unterschiedlich stark ausgeprägt sein können und in Abb. 4.1 und im Folgenden detaillierter betrachtet werden.

22 Software-Lebenszyklus 18 Abb. 4.1: Software Reengineering Forward Engineering Der Begriff ist im Themengebiet des Software-Reengineering als Pendant zum Begriff Reverse Engineering geprägt worden. Er bezieht sich auf die Anwendung der Methoden und Werkzeuge der Systementwicklung bzw. des Software Engineering beim Software- Reengineering, um Softwareartefakte in eine implementierungsnähere Form zu überführen, d.h. von einer abstrakteren in eine konkretere Form bis hin zum Quellcode Reverse Engineering Beim Reverse Engineering wird diese Richtung, in der die Dokumente voneinander abgeleitet werden, gerade umgekehrt, d.h. aus Dokumenten der späten Phasen sollen Dokumente der früheren Phasen rekonstruiert werden. Beispiele hierfür sind - die Gewinnung von Quellprogrammen aus Binärcode (Decompilierung) und - die Gewinnung von Klassendiagrammen, Modulstrukturen, prozeduralen Abstraktionen usw. aus Quellprogrammen (Design Recovery). 14 Quelle: Google Pictures 15 vgl. Enzeklopädie der Wirtschaftsinformatik

23 Software-Lebenszyklus 19 Alle modernen Programmiersprachen beinhalten Konzepte und Sprachkonstrukte, durch die die Modulstruktur und die Beziehungen zwischen Modulen weitgehend explizit im Programmcode kenntlich gemacht werden und daher leicht extrahiert werden können. Allerdings sind selbst bei einer modernen Sprache wie Java nicht alle Aspekte eines Entwurfsklassendiagramms zuverlässig und automatisch erkennbar. Beispielsweise sind Beziehungen, die über Datenwerte in Attributen realisiert werden kaum von normalen Attributen unterscheidbar. Die nicht ganz perfekte Rekonstruktion der Modulstrukturen bei modernen Programmen ist noch harmlos im Vergleich zu den enormen Problemen, die man bei manchen älteren Programmiersprachen und Programmierstilen hat. Diese Systeme sind teilweise derart unstrukturiert, dass man sie überhaupt nicht durch eine vereinfachende Darstellung, wie sie letztlich in Klassendiagrammen und ähnlichen Darstellungsformen unterstellt wird, korrekt darstellen kann. Hinzu kommen hier oft praktische Probleme, dass man keine Analysewerkzeuge hat, die die alten Sprachen verarbeiten können oder die Gewinnung einer Programmdokumentation, die Entwurfsentscheidungen erklärt und begründet. Dies ist meist nicht automatisch, sondern nur manuell machbar und erfordert, bereits Klassendiagramme oder ähnliche Darstellungen der Modulstrukturen gewonnen zu haben. Dass überhaupt Dokumente der frühen Entwicklungsphasen fehlen und mühsam rekonstruiert werden müssen, hat mehrere typische Ursachen: - sie sind nie erstellt worden - sie sind verloren gegangen - sie sind nicht mehr gültig bzw. konsistent mit den Dokumenten der späteren Entwicklungsphasen, weil diese auf nicht mehr nachvollziehbare Weise abgeändert worden sind Ohne geeignete Programmanalysewerkzeuge sind die meisten Reengineering-Methoden nicht praktikabel. Speziell die Werkzeuge für das Design Recovery enthalten große Teile eines Compilers, weil sie wie ein Compiler zunächst das Programm in einem Syntaxbaum umwandeln und auf Korrektheit prüfen müssen; danach erzeugen sie aber keinen Code, sondern führen weitere Analysen durch (z.b. Datenflussanalysen) oder erzeugen externe Darstellungen der Programmstrukturen.

24 Software-Lebenszyklus Restrukturierung Unter einer Restrukturierung (restructuring) versteht man die Umformung eines Dokuments, i.d.r. des Programmquelltextes oder einer Architekturbeschreibung, auf der gleichen Abstraktionsstufe mit dem Ziel, die Qualität zu verbessern, unter Beibehaltung der funktionalen Eigenschaften. Anlass ist zwar i.d.r. eine erforderliche Änderung der Funktionalität, die Restrukturierung sollte trotzdem besser zunächst die alte Funktionalität reimplementieren. Die Re- Implementierung einer gar nicht mehr gewünschten Funktionalität wirkt auf den ersten Blick sinnlos, hat aber den großen Vorteil separat testbar zu sein und ggf. vorhandene Testfälle unverändert nutzen zu können. Würde man die Restrukturierung zusammen mit den geplanten Änderungen vornehmen, würden sich die Fehlerquellen addieren und die Fehlersuche u.u. wesentlich aufwendiger werden. 4.5 Kosten des Reengineering Reengineering-Projekte werden oft wesentlich teurer als geplant. Eine Ursache ist, dass die Kosten schwer zu schätzen sind, weil keine guten Schätzmethoden vorhanden sind und jedes Projekt sehr individuell ist. Selbst bei einer richtigen Schätzung ist es keineswegs immer klar, dass sich ein Reengineering lohnt. Die Alternative ist immer eine komplette Neuimplementierung, die mehrere potentielle Vorteile hat: - selbst bei einem gut verlaufenen Reengineering wird evtl. nicht die Qualitätsstufe erreicht wie bei einer Neuimplementierung - bei einer Neuimplementierung kann sofort die neue gewünschte Funktionalität realisiert werden - die Neuimplementierung der unveränderten Funktionen ist billiger als deren Erstimplementierung, weil im Allgemeinen zumindest Teile des vorhandenen Systems recycled werden können - man hat kennt nun die Auswirkungen der Design-Entscheidungen im bisherigen System und kann diese Erfahrungen ausnutzen - bei einer Neuimplementierung kann man den Aufwand sicherer schätzen Letztlich ist ein Reengineering nur dann wirtschaftlich, wenn es deutliche Kostenvorteile bei vertretbar guter Planungssicherheit bietet.

25 Software-Lebenszyklus Refactoring Definition Refactoring ist ein Sonderfall der Restrukturierung, die insbesondere im Kontext objektorientierter Sprachen sinnvoll anwendbar ist. Ausgangspunkt ist die Beobachtung, dass auch bei einer ganz normalen Erstentwicklung nicht immer alle Entwurfsentscheidungen optimal getroffen werden. Oft können schlicht nicht alle Konsequenzen überblickt werden, wodurch bei jeder Entwicklungstätigkeit Qualitätsmängel im Programm entstehen können. Die Idee besteht nun darin, derartige Qualitätsmängel sofort inkrementell während der Entwicklung zu beseitigen und dies als ganz normalen Teil von Entwicklungsprozessen aufzufassen. Damit die Kosten gering bleiben, sollen Refactorings folgende Merkmale aufweisen: - der Umbau ist vergleichsweise klein und überschaubar - sofort nach Umbau wird getestet um sicherzustellen, dass die Funktionalität des Systems unverändert geblieben ist Vor allem für objektorientierte Sprachen sind viele Refactorings auf Code- bzw. Architektur- Ebene entwickelt worden. 16 Derartige Refactorings beschreiben jeweils: - eine Schwäche bzw. einen Qualitätsmangel - die Umbaumaßnahmen, die zur Beseitigung des Mangels vorzunehmen sind Fallstudie Refactoring Gegeben ist ein Programm zum Erstellen von Rechnungen in einem Videoverleih: - welche Videos hat der Kunde wie lange ausgeliehen? - es gibt drei Arten von Videos: Normal, Kinder und Neuerscheinungen - es gibt Rabatt auf das verlängertes Ausleihen von normalen und Kinder-Videos (nicht jedoch für Neuerscheinungen) - es gibt Bonuspunkte für Stammkunden (wobei das Ausleihen von Neuerscheinungen Extra-Punkte bringt) 16 Quelle: Fowler, Martin: Refactoring - Improving The Design Of Existing Code

26 Software-Lebenszyklus 22 Ausgangssituation: Die Videoarten (pricecode) werden durch Klassen-Konstanten (unterstrichen) gekennzeichnet. Die gesamte Funktionalität steckt im Erzeugen der Kundenrechnung der Methode Customer.statement():

27 Software-Lebenszyklus 23 Sequenzdiagramm: Probleme mit diesem Entwurf: - nicht objektorientiert Filmpreise sind z.b. Kunden zugeordnet - mangelnde Lokalisierung Das Programm ist nicht robust gegenüber Änderungen - Erweiterung des Ausgabeformats (z.b. HTML statt Text) - Änderung der Preisberechnung: was passiert, wenn neue Regeln eingeführt werden? An wie vielen Stellen muss das Programm geändert werden? Ziel: Die einzelnen Faktoren (Preisberechnung, Bonuspunkte) voneinander trennen!

28 Software-Lebenszyklus 24 Aufspalten der Methoden ( Extract Method ): Im ersten Schritt muss die viel zu lange statement()-methode aufgespaltet werden. Hierzu wird das Refactoring-Verfahren Extract Method angewandt. Extract Method ist eine der meist verbreiteten Refactoring-Methoden. Es gibt ein Codestück, das zusammengefasst werden kann. Der Name der Methode soll dabei den Zweck der Methode erklären. wird zu:

29 Software-Lebenszyklus 25 Spezifisches Problem: Umgang mit lokalen Variablen.

30 Software-Lebenszyklus 26 Bewegen von Methoden ( Move Method ): Die Methode amountfor() hat eigentlich nichts beim Kunden zu suchen; vielmehr gehört sie zum Ausleihvorgang selbst. Hierfür wird das Refactoring-Verfahren Move Method eingesetzt. Eine Methode benutzt weniger Dienste der Klasse, der sie zugehört, als Dienste einer anderen Klasse. Es wird eine neue Methode mit gleicher Funktion in der anderen Klasse erzeugt. Die alte Methode wird in eine einfache Delegation abgewandelt oder ganz gelöscht. Spezifische Probleme: Informationsfluss, Umgang mit ererbten Methoden Anwendung: Wir führen in der Rental-Klasse eine neue Methode getcharge() ein, die die Berechnung aus amountfor() übernimmt.

31 Software-Lebenszyklus 27 Rental.getCharge(): Customer.amountFor(): Die umgearbeitete Customer-Methode amountfor() delegiert nun die Berechnung an getcharge(): Genau wie das Berechnen der Kosten kann auch das Berechnen der Bonuspunkte in eine neue Methode der Rental-Klasse verschoben werden etwa in eine Methode getfrequentrenterpoints().

32 Software-Lebenszyklus 28 Neue Klassen: Die Klasse Rental hat die neuen Methoden getcharge() und getfrequentrenterpoints(): Neues Sequenzdiagramm: Die Klasse Customer muss sich nicht mehr um Preis-Codes kümmern; diese Verantwortung liegt nun bei Rental. Die Klasse Rental hat die neuen Methode getcharge() und getfrequentrenterpoints():

33 Software-Lebenszyklus 29 Abfrage-Methoden einführen: Die while-schleife in statement erfüllt drei Zwecke gleichzeitig: - sie berechnet die einzelnen Zeilen - sie summiert die Kosten - sie summiert die Bonuspunkte Auch hier sollte man die Funktionalität in separate Elemente aufspalten, wobei uns das Refactoring-Verfahren Replace Temp with Query hilft. Replace Temp with Query: Eine temporäre Variable speichert das Ergebnis eines Ausdrucks. Der Ausdruck wird in eine Abfrage-Methode gestellt; die temporäre Variable wird durch Aufrufe der Methode ersetzt. Die neue Methode kann somit nun auch in anderen Methoden benutzt werden. wird zu:

34 Software-Lebenszyklus 30 Anwendung: In die Customer-Klasse werden zwei private Methoden eingeführt: - gettotalcharge() summiert die Kosten - gettotalfrequentrenterpoints() summiert die Bonuspunkte statement() ist schon deutlich kürzer geworden!

35 Software-Lebenszyklus 31 Neue Klassen: Neue private Methoden gettotalcharge() und gettotalfrequentrenterpoints(): Neues Sequenzdiagramm:

36 Software-Lebenszyklus 32 Einführen einer HTML-Variante: Da die Berechnungen von Kosten und Bonuspunkten nun komplett herausfaktorisiert sind, konzentriert sich statement() ausschließlich auf die korrekte Formatierung. Nun ist es kein Problem mehr, alternative Rechnungs-Formate auszugeben. Die Methode htmlstatement() etwa könnte die Rechnung in HTML-Format drucken: Weiteres Verschieben von Methoden: getcharge() und getfrequentrenterpoints() wird in die Klasse Movie bewegt.

37 Software-Lebenszyklus 33 Klasse Movie mit eigenen Methoden zur Berechnung der Kosten und Bonuspunkte: In der Rental-Klasse wird die Berechnung an das jeweilige Movie-Element delegiert:

38 Software-Lebenszyklus 34 Polymorphie statt Fallentscheidungen: Fallunterscheidungen innerhalb einer Klasse können fast immer durch Einführen von Unterklassen ersetzt werden ( Replace Conditional Logic with Polymorphism ). Jede Klasse enthält genau die für sie nötigen Berechnungsverfahren. Replace Conditional Logic with Polymorphism hat die allgemeine Form: Eine Fallunterscheidung bestimmt das unterschiedliche Verhalten, abhängig vom Typ des Objekts. Jeder Ast der Fallunterscheidung wird in eine überladene Methode einer Unterklasse bewegt. Die ursprüngliche Methode wird abstrahiert. Die afrikanische Schwalbe: wird zu:

39 Software-Lebenszyklus 35 Neue Klassenhierarchie Erster Versuch: Neue Eigenschaften: - die Berechnung der Kosten wird an die Unterklassen abgegeben (abstrakte Methode getcharge) - die Berechnung der Bonuspunkte steckt in der Oberklasse, kann aber von Unterklassen überladen werden (Methode getfrequentrenterpoints()) Problem dieser Hierarchie: Beim Erzeugen eines Movie-Objekts muss die Klasse bekannt sein; während ihrer Lebensdauer können Objekte keiner anderen Klasse zugeordnet werden. Im Videoverleih kommt dies aber durchaus vor (z.b. Übergang von Neuerscheinung zu normalem Video oder Kindervideo zu normalem Video und zurück).

40 Software-Lebenszyklus 36 Neue Klassenhierarchie Zweiter Versuch: Einführung einer Klassenhierarchie für Preiskategorien. setprice() ändert die Kategorie jederzeit! Neue Klassen-Hierarchie Price - Die Berechnungen sind für jede Preiskategorie ausfaktorisiert:

41 Software-Lebenszyklus 37 Neue Klassen-Hierarchie Price: Neue Klasse Movies: Die Movie-Klasse delegiert die Berechnungen jetzt an den jeweiligen Preis (price):

42 Software-Lebenszyklus 38 Die alte Schnittstelle getpricecode wird hier nicht mehr unterstützt; neue Preismodelle sollten durch neue Price-Unterklassen realisiert werden. Um getpricecode dennoch weiter zu unterstützen, würde man - die Preis-Codes wieder in die Klasse Movie einführen - die Klasse Movie wieder mit einer Methode getpricecode ausstatten, die analog zu getcharge() an die jeweilige Price-Subklasse delegiert würde - die Klasse Movie mit einer Methode setpricecode ausstatten, die anhand des Preiscodes einen passenden Preis erzeugt und setzt Alle Klassen im Überblick: So sieht die ausfaktorisierte Klassenhierarchie aus:

43 Software-Lebenszyklus 39 Sequenzdiagram: Dies ist der Aufruf der statement()-methode: Fazit: Der neue Entwurf - hat besser verteilte Zuständigkeiten - ist leichter zu warten - kann einfacher in neuem Kontexten wieder verwendet werden

44 Software-Lebenszyklus Einkapseln von Altsystemen Manche alte Softwaresysteme, die von hohem betrieblichen Wert sind, sind praktisch nicht mehr wartbar aus Gründen wie: - die benutzte Programmiersprache wird nicht weiterentwickelt - man findet auf dem Arbeitsmarkt für die vorhandene Technologie keine Fachleute mehr - die Dokumentation ist schlecht - das System ist undurchschaubar Wegen des Aufwands oder wegen des Fehlens von Dokumentation können die Systeme auch nicht in neuen Sprachen und Technologien reimplementiert werden. Solche Programme können nur als Ganze in neue Architekturen eingebettet werden. Für diese Einbettung gibt es je nach Randbedingungen mehrere technische Alternativen, die hier nicht vertieft werden sollen. Zwischen alten und neuen Programmen müssen Anpassungsschichten realisiert werden. Sofern ein Altsystem eingekapselt wird und dadurch z.b. eine Aufrufschnittstelle in einer objektorientierten Sprache erhält, stellt die einkapselnde Software den Wrapper dar.

45 Software-Lebenszyklus 41 5 Fazit Abschließend kann festgestellt werden, dass der Bereich Software-Lebenszyklus sich sicherlich allgemeiner Bekanntheit erfreut, jedoch von den meisten Anwendern viel zu nachlässig gesehen, oder erst gar nicht betrachtet wird. Insbesondere das über Thema Software-Alterung wird selbst in größeren Unternehmen wenig nachgedacht. Die Kosten, die daraus resultieren, steigen dabei natürlich ins Unermessliche. Den Vorteil daraus ziehen diejenigen, die vernünftige Maßnahmen bereits im Voraus treffen und der Software-Alterung effektiv entgegenwirken. Man ist der Software-Alterung nämlich nicht bedingungslos ausgeliefert und kann die Lebensdauer einer Software auch bewusst verlängern. Die heute übliche Software-Entwicklung mit Objektorientierung, die letztlich dazu führt, dass jede Funktion ihr eigenes, in sich abgeschlossenes Modul darstellt, eignet sich hierfür besonders, auch wenn sie bei komplexeren Anforderungen zur Unübersichtlichkeit neigt. Nicht zuletzt kann das geeignete Softwareentwicklungswerkzeug dazu beitragen, Designfehler weitestgehend zu vermeiden. Auch der Einsatz von serviceorientierten Architekturen führt zur gewünschten Modularisierung. Den Aspekten der Software-Alterung kann somit durch den Austausch einzelner Service-Bausteine begegnet werden. Eine andere Möglichkeit ist eine längere Designphase, in der bewusst überlegt wird, welche Funktionen die Software haben wird oder welche Möglichkeiten später noch genutzt werden können. Spätere Änderungen können dann gut eingepasst werden, da sie schon vorher eingeplant wurden. Auch einzelne Restaurierungsarbeiten können helfen. Es besteht immer die Möglichkeit, neuen Code gerade so einzubauen, dass er funktioniert, oder Teile der Software neu zu entwerfen, um neue Funktionen besser einbetten zu können. Die Lebensdauer einer Software hängt vor allem natürlich auch von ihrer Stabilität und Zuverlässigkeit im täglichen Einsatz ab. Die Anzahl von Fehlern aller Art ist dabei eine messbare Größe um dieses Kriterium zu quantifizieren. Innerhalb des Software- Lebenszyklus lässt sich die Testphase dazu nutzen, relevante Fehler aufzuspüren und zu

46 Software-Lebenszyklus 42 eliminieren. Die sinnvolle Definition von ausgewählten Testszenarien anhand relevanter usecases mit bekannten Daten entscheidet dabei wesentlich über den Erfolg solcher Testphasen. Vielfach vernachlässigt und unterschätzt, jedoch mindenstens genauso wichtig ist die lückenlose und verständliche Dokumentation aller Entwicklungsschritte und Testergebnisse. Verbunden mit einem ordentlichen Handbuch stellt dies den Einsatz der Software auch dann sicher, wenn die ursprünglichen Schöpfer und Anwender nicht mehr verfpgbar sein sollten und auf deren Wissen nicht mehr zurückgegriffen werden kann. Es lässt sich also gut erkennen, dass jede Phase des Software-Lebenszyklus Potential hat, der Software-Alterung aktiv entgegenzuwirken; es muss eben rechtzeitig erkannt und genutzt werden. Aufhalten lässt sich dieser Alterungsprozess natürlich nicht, jedoch kann dieser - ähnlich wie beim Menschen durch vorbeugende Untersuchungen und Behandlungen - erheblich verlangsamt werden und somit die Effizienz der eingesetzten Software deutlich gesteigert werden. Vor allem auch unter Betrachtung der Tatsache, dass der Trend seit einiger Zeit immer mehr zu teilweise sogar lizenzfreier Open Sorce Software geht, wird dieses Thema in den kommenden Jahren eine bedeutende Rolle spielen, wenn es um Wettbewerbsvorteile geht.

47 Software-Lebenszyklus 43 Literaturverzeichnis Enzeklopädie der Wirtschaftsinformatik ( ): abgerufen am von Fowler, Martin (1999): Refactoring - Improving The Design Of Existing Code. Addison- Wesley Gabler Wirtschaftsinformatik-Lexikon. Gabler Verlag Gilb, Tom: Principles of Software Engineering. Addison Wesley Pub Co Inc Hoffmann, D. W. (2008): Software-Qualität. Heidelberg: Springer-Verlag Berlin TEIA ( ): abgerufen am von Wikipedia ( ): abgerufen am von