Die Herausforderung Eine weit verbreitete Annahme ist, dass Software nicht altert, da Software als immaterielles Gut keinerlei Verschleißerscheinungen unterliegt. Diese Annahme ist aber falsch – Software altert. Die Umgebung, in der Software eingesetzt wird, verändert sich kontinuierlich und die dazugehörige Hardware und die Infrastruktur verändern sich. Wird die Software nicht ebenfalls kontinuierlich weiterentwickelt, so altert sie rasch relativ zu ihrer Umgebung. Dieses Problem ist vor allem im Bereich der großen betrieblichen Informationssysteme unter dem Oberbegriff Legacy bekannt. Es sind große Systeme im industriellen Einsatz, teilweise noch in FORTRAN oder COBOL geschrieben, die trotz suboptimaler Funktionalität und Qualität weiter unangepasst im Einsatz bleiben, da eine Optimierung an der Komplexität des Systems und dem Aufwand für eine Einarbeitung durch die heutigen Entwickler scheitert. Eine Neuerstellung solcher Systeme würde enorme Kosten und Probleme bei der Umstellung verursachen. Dieses bekannte Problem wird sich noch weiter verschärfen: Zum einen gewinnen die eingebetteten Systeme immer größere Bedeutung. Hier sind wir mit der Situation konfrontiert, dass aufwändige Software in langlebigen technischen Geräten eingesetzt wird. Zu welchen Problemen dies führt, zeigt sich zum Beispiel bei Systemen für den Betrieb der Space-Shuttle-Raumtransporter. Wie die New York Times am 12. Mai 2002 berichtete [7], ist es für die Nasa wesentlich günstiger, den verfügbaren Markt nach (fast) obsoleter Hardware abzusuchen bzw. gerade noch verfügbare Komponenten aufzukaufen, als die damit verknüpfte Software neu zu entwickeln oder auf neue Plattformen zu migrieren. Darüber hinaus macht die zunehmende Vernetzung von Systemen die Situation noch schwieriger. Systemgrenzen können oft nicht mehr klar definiert werden. Es ist manchmal nicht mehr möglich, vollständiges Wissen über das Gesamtsystem bereitzustellen. Trotzdem müssen ganze Anwendungslandschaften beherrscht werden. Das Ausschalten von Teilsystemen ist oft aufgrund der Vernetzung nicht möglich. Alterungsprozesse von Teilen gefährden das Gesamtsystem; dies lässt sich plakativ mit dem Begriff ,,Erosion von Softwaresystemen“ beschreiben. Notwendige Updates in existierenden, rund um die Uhr laufenden Softwaresystemen führen dann immer wieder zu erheblichen Problemen. Aktuelles Beispiel ist ein Softwareausfall Ende April 2009 beim Mobilfunkanbieter T-Mobile, dessen Netz für mehrere Stunden für Sprachund SMS-Dienste
[1]
Klaus Pohl,et al.
Software Product Line Engineering - Foundations, Principles, and Techniques
,
2005
.
[2]
Dirk Beyer,et al.
Efficient relational calculation for software analysis
,
2005,
IEEE Transactions on Software Engineering.
[3]
Michael A. Jackson,et al.
Problem Frames - Analysing and Structuring Software Development Problems
,
2000
.
[4]
Nicolas Guelfi,et al.
A metadata-based architectural model for dynamically resilient systems
,
2007,
SAC '07.
[5]
Manfred Broy,et al.
Evolutionary Development of Software Architectures
,
2002
.
[6]
Gregor Engels,et al.
Quasar Enterprise - Anwendungslandschaften serviceorientiert gestalten
,
2008,
Software Engineering.
[7]
Moritz Balz,et al.
Embedding process models in object-oriented program code
,
2009,
BM-MDA '09.
[8]
Michael Striewe,et al.
Embedding Behavioral Models into Object-Oriented Source Code
,
2009,
Software Engineering.
[9]
George C. Necula,et al.
Proof-carrying code: design, implementation and applications (abstract)
,
2000,
PPDP.
[10]
Florian Matthes,et al.
Introspective Model-Driven Development
,
2006,
EWSA.
[11]
George C. Necula,et al.
Proof-carrying code: design, implementation and applications (abstract).
,
2000
.