6 Reengineering - Universität Stuttgart
6 Reengineering - Universität Stuttgart
6 Reengineering - Universität Stuttgart
Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.
YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.
Softwaretechnik II<br />
ST II<br />
§ 6 <strong>Reengineering</strong><br />
Lernziele<br />
– Wissen, warum und wann Software <strong>Reengineering</strong>?<br />
– Wissen, dass Software <strong>Reengineering</strong> alle Aktivitäten, deren Ziel die<br />
qualitative Verbesserung, Aufbereitung und Weiterentwicklung von<br />
Software ist, umfasst<br />
– Prozesse „Reverse Engineering“, „Respezifikation“, „Restrukturierung“ und<br />
„Redokumentation“ kennen<br />
– Methodologien, Tools und Praktiken des Software <strong>Reengineering</strong>s kennen<br />
Literatur<br />
– K. Cremer: Graphbasierte Werkzeuge zum Reverse Engineering und<br />
<strong>Reengineering</strong>, Deutscher <strong>Universität</strong>sverlag, 2000<br />
– K. A. Ingle: Reverse Engineering , McGraw-Hill Education, 1994<br />
– F. Lehner: Softwarewartung und <strong>Reengineering</strong>, Deutscher<br />
<strong>Universität</strong>sverlag, 1994<br />
© 2013 IAS, <strong>Universität</strong> <strong>Stuttgart</strong> 255
Softwaretechnik II<br />
ST II<br />
§ 6 <strong>Reengineering</strong><br />
6.1 Warum Software <strong>Reengineering</strong>?<br />
6.2 Reverse Engineering<br />
6.3 Respezifikation<br />
6.4 Redokumentation<br />
6.5 Programmtransformation<br />
6.6 Hinweise für die Praxis<br />
© 2013 IAS, <strong>Universität</strong> <strong>Stuttgart</strong> 256
6.1 Warum Software <strong>Reengineering</strong>?<br />
ST II<br />
Komplexe, gewachsene Systeme sind (oft) nicht austauschbar!<br />
© 2013 IAS, <strong>Universität</strong> <strong>Stuttgart</strong> 257
6.1 Warum Software <strong>Reengineering</strong>?<br />
ST II<br />
Ziel:<br />
Modernisierung<br />
von Altsystemen<br />
© 2013 IAS, <strong>Universität</strong> <strong>Stuttgart</strong> 258
6.1 Warum Software <strong>Reengineering</strong>?<br />
ST II<br />
Warum Software <strong>Reengineering</strong>?<br />
Aber:<br />
“<strong>Reengineering</strong> intereressiert mich nicht,<br />
meine Programme funktionieren!”<br />
– Wann wird auf einen neuen Computer oder<br />
Sprachstandard umgestellt?<br />
– Wann wird auf eine andere Programmiersprache umgestellt?<br />
– Wie lange wird mein Betriebssystem noch unterstützt?<br />
– Wie offen ist mein System bezüglich der<br />
Integration neuer Technologien?<br />
– Besitze ich eine aktuelle Programmdokumentation?<br />
– Steigt mein Wartungsaufwand nur, um den Ist-Zustand zu erhalten?<br />
– Wie gut läßt sich das System in seinem aktuellen Zustand zur Erfüllung<br />
gegebener und künftiger Erfordernisse verwenden?<br />
– Verhält sich das System in allen erdenklichen Situationen robust?<br />
© 2013 IAS, <strong>Universität</strong> <strong>Stuttgart</strong> 259
6.1 Warum Software <strong>Reengineering</strong>?<br />
Aufwand für die Pflege von Software-Altsystemen<br />
(Live-Mitschrieb)<br />
ST II<br />
Aufwand<br />
für Pflege<br />
Sanierung<br />
Nutzungsdauer<br />
© 2013 IAS, <strong>Universität</strong> <strong>Stuttgart</strong> 260
6.1 Warum Software <strong>Reengineering</strong>?<br />
ST II<br />
Kosten Software-Wartung<br />
Wartungskosten pro Jahr > 1<br />
Vermögenswert < 10<br />
Sanierungsbedarf hoch<br />
= = 10 Jahre Nutzung<br />
Sanierungsbedarf gering<br />
Vermögenswert = Kosten für Neuentwicklung unter Beachtung<br />
des tatsächlichen Funktionsbedarfs<br />
© 2013 IAS, <strong>Universität</strong> <strong>Stuttgart</strong> 261
6.1 Warum Software <strong>Reengineering</strong>?<br />
ST II<br />
Was ist Software <strong>Reengineering</strong>?<br />
Unter <strong>Reengineering</strong> versteht man den Prozess der Analyse und<br />
der strukturellen Veränderung existierender Programme mit dem<br />
Zweck, die qualitativen Eigenschaften<br />
– Portabilität<br />
– Wartbarkeit (Produktivität)<br />
– Wiederverwendbarkeit<br />
zu verbessern.<br />
© 2013 IAS, <strong>Universität</strong> <strong>Stuttgart</strong> 262
6.1 Warum Software <strong>Reengineering</strong>?<br />
ST II<br />
Das <strong>Reengineering</strong> umfasst:<br />
– Die nachträgliche Erzeugung und Verbesserung einer Dokumentation<br />
Redokumentation<br />
– Die nachträgliche Erstellung der Spezifikation, um eine CASE-Umgebung<br />
nutzen zu können<br />
Respezifikation<br />
– Die nachträgliche Strukturierung und Formatierung von Programmen, die<br />
schlecht lesbar sind<br />
Restrukturierung<br />
– Die Wiederverwendung bewährter Programme<br />
Reuse<br />
– Verbesserung der Möglichkeit, die Programmiersprache zu wechseln<br />
Recycle<br />
– Erweiterung und Änderung von Programmen während des Betriebs<br />
Redesign<br />
© 2013 IAS, <strong>Universität</strong> <strong>Stuttgart</strong> 263
6.1 Warum Software <strong>Reengineering</strong>?<br />
ST II<br />
Wann sind Software <strong>Reengineering</strong> Maßnahmen notwendig?<br />
Technische Anforderungen<br />
= verwendete Technik<br />
erfüllt<br />
fachlich<br />
sanieren<br />
beibehalten<br />
nicht erfüllt<br />
aussondern<br />
neu entwickeln<br />
technisch<br />
sanieren<br />
nicht erfüllt<br />
erfüllt<br />
Fachliche Anforderungen<br />
= Funktionen<br />
© 2013 IAS, <strong>Universität</strong> <strong>Stuttgart</strong> 264
6.1 Warum Software <strong>Reengineering</strong>?<br />
ST II<br />
Bewertungsfaktoren für <strong>Reengineering</strong> Maßnahmen<br />
– Kosten für <strong>Reengineering</strong><br />
– Kosten für Pflegearbeiten<br />
– Vermögenswert<br />
– Zu erwartende Lebensdauer<br />
– Zukünftige Anforderungen<br />
– Zeitbedarf für Sanierung<br />
– Verfügbarkeit von Werkzeugen<br />
– Mitarbeitersituation<br />
© 2013 IAS, <strong>Universität</strong> <strong>Stuttgart</strong> 265
6.1 Warum Software <strong>Reengineering</strong>?<br />
ST II<br />
Einflussfaktoren für <strong>Reengineering</strong> Maßnahmen<br />
Wartungskosten<br />
Alter der<br />
Software<br />
Erreichbarkeit<br />
Wartungsumgebung<br />
Benutzerfreundlichkeit<br />
Wartungsressourcen<br />
Erfahrung<br />
Sicherheitsanforderungen<br />
Code-<br />
Qualität<br />
Technische<br />
Abschätzung<br />
Wirtschaftliche<br />
Abschätzung<br />
Risikoabschätzung<br />
Andere<br />
Abschätzungen<br />
Werkzeugunterstützung<br />
Ablauf<br />
Management<br />
Entscheidungsprozess<br />
Politik<br />
Projektwachstum<br />
Geschäftsziele<br />
Lebenserwartung<br />
des Codes<br />
Dokumentation<br />
Neue<br />
Technologien<br />
Wartungsproduktivität<br />
Entscheidung<br />
© 2013 IAS, <strong>Universität</strong> <strong>Stuttgart</strong> 266
6.1 Warum Software <strong>Reengineering</strong>?<br />
ST II<br />
Kosten/Nutzen-Vergleich<br />
NW<br />
AW<br />
DS<br />
*( KS<br />
E *<br />
AW<br />
AW<br />
NW )<br />
1<br />
mit DS > 0<br />
Abkürzungen:<br />
AW<br />
NW<br />
DS<br />
E<br />
KS<br />
ZE<br />
Alte Wartungskosten/ZE vor Sanierung<br />
Neue Wartungskosten/ZE nach Sanierung<br />
Dauer der Sanierung in ZE<br />
Lebenserwartung in ZE<br />
Kosten der Sanierung / ZE<br />
Zeiteinheit (z.B.: 1 Monat)<br />
© 2013 IAS, <strong>Universität</strong> <strong>Stuttgart</strong> 267
6.1 Warum Software <strong>Reengineering</strong>?<br />
ST II<br />
Beispiel für eine Kosten-Nutzen-Analyse<br />
AW<br />
NW<br />
DS<br />
10.000 € / Monat (2 Mitarb.)<br />
5.000 € / Monat (1 Mitarb.)<br />
2 Monate<br />
KS Tool 10.000 € + Lohnkosten 10.000 €<br />
10.000 € / Monat<br />
E<br />
5 Jahre = 60 Monate<br />
Faktor: 0.5625<br />
E<br />
1 Jahr = 12 Monate<br />
Faktor: 0.75 < 1<br />
© 2013 IAS, <strong>Universität</strong> <strong>Stuttgart</strong> 268
6.1 Warum Software <strong>Reengineering</strong>?<br />
ST II<br />
Risiken bei Neuentwicklung/Risiken bei <strong>Reengineering</strong><br />
– Neuentwicklung<br />
Aufwand/Kosten werden unterschätzt<br />
Hohe Fehlerrate in Einführungsphase<br />
Neuentwicklung generiert neue Anforderungen<br />
– <strong>Reengineering</strong><br />
Entfremdung durch Restrukturierung<br />
Parallel zur laufenden Systempflege<br />
Je umfangreicher die Sanierungsmaßnahmen sind,<br />
um so mehr Fehler sind im neuen System<br />
© 2013 IAS, <strong>Universität</strong> <strong>Stuttgart</strong> 269
6.1 Warum Software <strong>Reengineering</strong>?<br />
ST II<br />
<strong>Reengineering</strong> Tätigkeiten<br />
Bestandsaufnahme<br />
Kosten-Nutzen-<br />
Analyse<br />
Kosten > Nutzen<br />
Planung<br />
Respezifikation/Analyse<br />
Redokumentation<br />
Restrukturierung/<br />
Transformation<br />
Abschlusstest<br />
Integration<br />
© 2013 IAS, <strong>Universität</strong> <strong>Stuttgart</strong> 270
6.1 Warum Software <strong>Reengineering</strong>?<br />
ST II<br />
Vorstudie<br />
– Bestandsaufnahme<br />
Feststellung des Gesamtumfangs in LOC<br />
Programmiersprache, Dialekte<br />
Qualitätsbestimmung<br />
Komplexitätsbestimmung<br />
Prüfung des Einsatzes von Werkzeugen<br />
Verfügbarkeit von qualifizierten Mitarbeitern<br />
– Kosten/Nutzen-Analyse<br />
Aufwandsabschätzung Neuentwicklung<br />
Aufwandsabschätzung <strong>Reengineering</strong><br />
Einsparungen in der Wartungsphase<br />
Kostenreduktion durch preiswerte Hardware/ Standardsoftware<br />
© 2013 IAS, <strong>Universität</strong> <strong>Stuttgart</strong> 271
6.1 Warum Software <strong>Reengineering</strong>?<br />
ST II<br />
Projektplanung<br />
– Modulweise Umstellung<br />
Evolutionäre Integration neuer Module<br />
Gemischter Betrieb<br />
Zeitunkritisch<br />
– Komplett-Umstellung<br />
Einfrieren des Gesamtsystems<br />
Abrupter Wechsel zwischen altem und neuem System<br />
Zeitkritisch<br />
© 2013 IAS, <strong>Universität</strong> <strong>Stuttgart</strong> 272
6.1 Warum Software <strong>Reengineering</strong>?<br />
ST II<br />
Abschlusstest<br />
Überprüfung der korrekten Funktion durch Vergleich der Testergebnisse des<br />
alten und des neuen Systems<br />
Protokollierung<br />
– Benutzungsschnittstelle<br />
– Datenbank-Transaktionen<br />
– Funktionstrace/Datentrace<br />
– Prozess-I/O<br />
© 2013 IAS, <strong>Universität</strong> <strong>Stuttgart</strong> 273
6.1 Warum Software <strong>Reengineering</strong>?<br />
ST II<br />
<strong>Reengineering</strong> Vorgehensweisen<br />
Spezifikation 1<br />
Redesign<br />
Spezifikation 2<br />
Abstraktion<br />
Generierung<br />
Ursprung<br />
z. B.:<br />
Quellprogramm in Fortran,<br />
schriftliche Unterlagen,<br />
Know-How<br />
Transformation<br />
Restrukturierung<br />
Metriken<br />
Übersetzung<br />
Redokumentation<br />
Instrumentierung<br />
Ergebnis<br />
z.B.:<br />
Quellprogramm in C,<br />
Übersichtsdiagramme,<br />
strukturierter Code<br />
© 2013 IAS, <strong>Universität</strong> <strong>Stuttgart</strong> 274
Frage zu Kpaitel 6.1<br />
ST II<br />
Frage zu Kapitel 6.1<br />
Welche qualitativen primären Eigenschaften soll Software <strong>Reengineering</strong><br />
verbessern?<br />
Antwort<br />
f<br />
<br />
Dokumentation<br />
Reaktionszeit<br />
<br />
Produktivität<br />
<br />
Wiederverwendbarkeit<br />
© 2013 IAS, <strong>Universität</strong> <strong>Stuttgart</strong> 275
Softwaretechnik II<br />
ST II<br />
§ 6 <strong>Reengineering</strong><br />
6.1 Warum Software <strong>Reengineering</strong>?<br />
6.2 Reverse Engineering<br />
6.3 Respezifikation<br />
6.4 Redokumentation<br />
6.5 Programmtransformation<br />
6.6 Hinweise für die Praxis<br />
© 2013 IAS, <strong>Universität</strong> <strong>Stuttgart</strong> 276
6.2 Reverse Engineering<br />
ST II<br />
Was ist Reverse Engineering?<br />
Reverse Engineering beinhaltet die Analyse existierender Programme mit<br />
dem Zweck:<br />
– Die Komponenten und deren Beziehung zu bestimmen<br />
– Das Programmsystem in anderer Form und auf höherer Abstraktionsebene<br />
zu beschreiben.<br />
© 2013 IAS, <strong>Universität</strong> <strong>Stuttgart</strong> 277
6.2 Reverse Engineering<br />
ST II<br />
Reverse Engineering<br />
Anforderungs-<br />
Analyse<br />
REQ 1<br />
REQ 2<br />
REQ 3<br />
Requirementspezifikation<br />
Respezifikation<br />
+<br />
Reverse Engineering<br />
manuelle<br />
Interaktion<br />
Programmanalyse<br />
Dokumentation<br />
PROG 1<br />
Grobentwurf<br />
MOD 1 MOD 2 MOD 3<br />
F 1 F 2 F 3<br />
Entwurfsspezifikation<br />
(high level)<br />
Respezifikation<br />
+<br />
manuelle<br />
Interaktion<br />
Respezifikation<br />
Feinentwurf<br />
Entwurfsspezifikation<br />
(low level)<br />
Implementierung<br />
Forward Engineering<br />
Programmquelle<br />
© 2013 IAS, <strong>Universität</strong> <strong>Stuttgart</strong> 278
Softwaretechnik II<br />
ST II<br />
§ 6 <strong>Reengineering</strong><br />
6.1 Warum Software <strong>Reengineering</strong>?<br />
6.2 Reverse Engineering<br />
6.3 Respezifikation<br />
6.4 Redokumentation<br />
6.5 Programmtransformation<br />
6.6 Hinweise für die Praxis<br />
© 2013 IAS, <strong>Universität</strong> <strong>Stuttgart</strong> 279
6.3 Respezifikation<br />
ST II<br />
Respezifikation<br />
– Respezifikation ist Bestandteil des Reverse Engineering<br />
– Aus allgemeinen Informationen, der vorhandenen Dokumentation, dem<br />
Quelltext und dem funktionalen Verhalten des Programms wird die<br />
Beschreibung der Anforderungen und des Entwurfs nachempfunden<br />
Anforderungsspezifikation<br />
Entwurfsspezifikation<br />
Quellcode und Dokumentation<br />
© 2013 IAS, <strong>Universität</strong> <strong>Stuttgart</strong> 280
6.3 Respezifikation<br />
ST II<br />
Vorgehensweise bei der Respezifikation<br />
Schritt 1:<br />
Analyse des Quellcodes bezüglich der Struktur<br />
Schritt 2:<br />
Ergänzung der Struktur durch funktionale Aspekte<br />
Schritt 3:<br />
Vollständige Beschreibung, welche die Beziehungen zwischen<br />
den Anforderungen, dem Entwurf und dem Quellcode beschreibt<br />
Schritt 4:<br />
Überprüfung der Respezifikation<br />
© 2013 IAS, <strong>Universität</strong> <strong>Stuttgart</strong> 281
6.3 Respezifikation<br />
ST II<br />
Zusammenhang zwischen Quellcode, Entwurf und Anforderungen<br />
REQ 400:<br />
REQ 410:<br />
REQ 420:<br />
Anforderungs-<br />
Spezifikation<br />
Funktion X<br />
Funktion Y<br />
A<br />
X1<br />
Y1<br />
C<br />
X2<br />
X3<br />
X4<br />
Y2<br />
Y3<br />
D<br />
Entwurfs-<br />
Spezifikation<br />
B<br />
X5<br />
X6<br />
X7<br />
E<br />
{<br />
Quellcode<br />
{<br />
© 2013 IAS, <strong>Universität</strong> <strong>Stuttgart</strong> 282
Frage zu Kpaitel 6.3<br />
ST II<br />
Frage zu Kapitel 6.3<br />
In welchen Situationen ist der Einsatz von Reverse Engineering<br />
Maßnahmen sinnvoll?<br />
Antwort<br />
f<br />
<br />
<br />
<br />
Wenn die bestehende Software nicht weggeworfen werden kann<br />
Wenn die vorhandene Datenstruktur wieder verwendet werden kann<br />
Wenn die Kosten der Neuentwicklung signifikant hoch sind<br />
© 2013 IAS, <strong>Universität</strong> <strong>Stuttgart</strong> 283
Softwaretechnik II<br />
ST II<br />
§ 6 <strong>Reengineering</strong><br />
6.1 Warum Software <strong>Reengineering</strong>?<br />
6.2 Reverse Engineering<br />
6.3 Respezifikation<br />
6.4 Redokumentation<br />
6.5 Programmtransformation<br />
6.6 Hinweise für die Praxis<br />
© 2013 IAS, <strong>Universität</strong> <strong>Stuttgart</strong> 284
6.4 Redokumentation<br />
ST II<br />
Redokumentation<br />
Unter Redokumentation versteht man die nachträgliche Erstellung und<br />
Aktualisierung der Programmdokumentation<br />
Sichten:<br />
Kontrollfluss<br />
Datenfluss<br />
Programm<br />
Datenstrukturen<br />
Aufrufstruktur<br />
© 2013 IAS, <strong>Universität</strong> <strong>Stuttgart</strong> 285
6.4 Redokumentation<br />
ST II<br />
Nutzen einer Redokumentation<br />
– Besseres Verständnis, mehr Übersicht<br />
– Transparenz für neue/andere Mitarbeiter<br />
– Gute Dokumentation erhöht Akzeptanz beim Auftraggeber<br />
– Höhere Wiederverwendbarkeit durch eine leicht verständliche,<br />
aktuelle und präzise Dokumentation<br />
© 2013 IAS, <strong>Universität</strong> <strong>Stuttgart</strong> 286
6.4 Redokumentation<br />
ST II<br />
Redokumentation<br />
Der Ist-Zustand<br />
eines vorhandenen<br />
Programms wird<br />
am Projektende<br />
oder in der<br />
Wartungsphase<br />
nachträglich<br />
dokumentiert<br />
Nassi-<br />
Shneidermann-<br />
Diagramme<br />
Crossreferenzlisten<br />
Dokumentation<br />
andere<br />
Informations-<br />
Quellen<br />
+<br />
REVERSE<br />
ENGINEERING<br />
Quellprogramm<br />
© 2013 IAS, <strong>Universität</strong> <strong>Stuttgart</strong> 287
6.4 Redokumentation<br />
ST II<br />
Alternativen:<br />
Manuell, werkzeugunterstützt:<br />
– Quelltext-Formatierer<br />
– Struktogramm-Generatoren<br />
– Respezifikations- und Dokumentationswerkzeuge<br />
Beispiele für Werkzeuge:<br />
– Goose<br />
Menge von Werkzeugen zur Analyse des Entwurfs eines objektorientierten<br />
Softwaresystems, die am FZI Karlsruhe entwickelt wurden<br />
– SRF Generator<br />
Ein Kommandozeilenwerkzeug zur Fact Extraction aus Java Systemen<br />
– TableGen<br />
Ein Kommandozeilenwerkzeug für C/C++ Systeme<br />
Film: Reverse Engineering mit Rose 2000<br />
© 2013 IAS, <strong>Universität</strong> <strong>Stuttgart</strong> 288
Frage zu Kpaitel 6.4<br />
ST II<br />
Frage zu Kapitel 6.4<br />
Welche Nutzen bringt die Redokumentation?<br />
Antwort<br />
f<br />
<br />
Besseres Verständnis und mehr Übersicht<br />
Anzeigen eines Programmablaufplans<br />
<br />
Erhöhung der Akzeptanz beim Auftraggeber<br />
<br />
Transparenz für neue/andere Mitarbeiter<br />
© 2013 IAS, <strong>Universität</strong> <strong>Stuttgart</strong> 289
Softwaretechnik II<br />
ST II<br />
§ 6 <strong>Reengineering</strong><br />
6.1 Warum Software <strong>Reengineering</strong>?<br />
6.2 Reverse Engineering<br />
6.3 Respezifikation<br />
6.4 Redokumentation<br />
6.5 Programmtransformation<br />
6.6 Hinweise für die Praxis<br />
© 2013 IAS, <strong>Universität</strong> <strong>Stuttgart</strong> 290
6.5 Programmtransformation<br />
ST II<br />
Sprachtransformation<br />
höhere<br />
Programmiersprache<br />
höhere<br />
Programmiersprache<br />
Assembler<br />
manuell<br />
automatisch<br />
interaktiv<br />
Assembler<br />
© 2013 IAS, <strong>Universität</strong> <strong>Stuttgart</strong> 291
6.5 Programmtransformation<br />
ST II<br />
Vorgehensweise<br />
bei der<br />
Programmtransformation<br />
Quellprogramm<br />
(z.B. FORTRAN)<br />
Preprozessor<br />
Scanner<br />
Parser<br />
Symboltabelle<br />
Strukturtabelle<br />
Quellcode-<br />
Generator<br />
Bereitstellung der<br />
Laufzeitroutinen aus<br />
der alten Programm-<br />
Umgebung in der<br />
neuen Programmiersprache<br />
Laufzeitbibliothek<br />
Quellprogramm<br />
(z.B. C)<br />
Übersetzbares und ablauffähiges<br />
Programmsystem<br />
© 2013 IAS, <strong>Universität</strong> <strong>Stuttgart</strong> 292
Softwaretechnik II<br />
ST II<br />
§ 6 <strong>Reengineering</strong><br />
6.1 Warum Software <strong>Reengineering</strong>?<br />
6.2 Reverse Engineering<br />
6.3 Respezifikation<br />
6.4 Redokumentation<br />
6.5 Programmtransformation<br />
6.6 Hinweise für die Praxis<br />
© 2013 IAS, <strong>Universität</strong> <strong>Stuttgart</strong> 293
6.6 Hinweise für die Praxis<br />
ST II<br />
<strong>Reengineering</strong> bedeutet:<br />
Investition zur Sicherung alter Investitionen<br />
Vorteile des <strong>Reengineering</strong>s<br />
– Möglichkeit der Rettung großer getätigter Softwareinvestitionen<br />
– Steigerung der Produktivität bei der Softwarewartung und<br />
der Weiterentwicklung<br />
– Portabilität durch Verwendung von Standards<br />
– Kostenreduktion durch Wiederverwendung bewährter Komponenten<br />
– Einfache Integration neuer Technologien<br />
– Höhere Zufriedenheit der Mitarbeiter<br />
– Einfache Adaption von Produkten<br />
– Verbesserung der Softwarequalität<br />
© 2013 IAS, <strong>Universität</strong> <strong>Stuttgart</strong> 294
6.6 Hinweise für die Praxis<br />
ST II<br />
Grenzen des <strong>Reengineering</strong>s<br />
Einschränkungen beim Gebrauch automatisch arbeitender Werkzeuge:<br />
– Programmtransformation<br />
Neuer Quellcode ist schwierig zu warten<br />
– Restrukturierung<br />
unterschiedliche Sichtweisen<br />
Programm wird größer<br />
Effizienz nimmt ab<br />
– Respezifikation, Dokumentation<br />
Nur formale (syntaktische) Sprachelemente werden ausgewertet<br />
– Einschränkungen bei der manuellen Arbeit<br />
• lange Dauer<br />
• fehleranfällig<br />
• unbeliebt<br />
© 2013 IAS, <strong>Universität</strong> <strong>Stuttgart</strong> 295
Vorbereitungsfragen<br />
ST II<br />
Vorbereitungsfragen zu § 6<br />
Frage 1: <strong>Reengineering</strong> (WS 03/04)<br />
Im Rahmen einer großen Softwareinvestition wurde vor 10 Jahren eine<br />
verfahrenstechnische Anlage automatisiert. In diesem Jahr müssen Teile der Anlage<br />
durch weiterentwickelte Hardware ersetzt werden. Es besteht die Möglichkeit die<br />
Software komplett neu zu entwickeln oder sie zu sanieren. Welches Verfahren<br />
schlagen Sie vor? Begründen Sie Ihre Aussage.<br />
Frage 2: <strong>Reengineering</strong> (WS 05/06)<br />
Ein Softwaresystem, das zur Steuerung einer verfahrenstechnischen Anlage<br />
eingesetzt wird, verursacht 800.000 € Wartungskosten pro Jahr. Die Neuentwicklung<br />
kostet 10 Millionen €. Besteht ein Sanierungsbedarf? Begründen Sie Ihre Aussage.<br />
© 2013 IAS, <strong>Universität</strong> <strong>Stuttgart</strong> 296
Change language