Software Reengineering


Hausarbeit, 2003

19 Seiten, Note: 1.3


Leseprobe


Inhaltsverzeichnis

Abbildungsverzeichnis

1 Einleitung
1.1 Überblick
1.2 Zielsetzung des Reengineering
1.3 Aufbau der Arbeit

2 Grundlagen des Reengineering
2.1 Begriffsdefinitionen
2.2 Die technologische Lücke im Software Lebenszyklus
2.3 Reengineering – Modelle
2.4 Argumente für ein Reengineering
2.5 Problemerkennung und Analyse
2.6 Restrukturierung
2.7 Reverse Engineering
2.8 CARE – Werkzeuge und Einsatzmöglichkeiten

3 Offene Probleme und Fazit

Literaturverzeichnis

Abbildungsverzeichnis

Abbildung 1 Begriffliche Einordnungen in das Gebiet des Reengineerings

Abbildung 2 Software – Lebenszyklus - Modell

Abbildung 3 Technologische Lücke im Software – Lebenszyklus

Abbildung 4 Allgemeines Modell des Reengineerings nach Chykovsky und Cross

Abbildung 5 Reverse Engineering und verwandte Prozesse

Abbildung 6 Der Reengineering Lebenszyklus

Abbildung 7 Vorgehensweisen zur Restrukturierung

Abbildung 8 Forward und Reverse Engineering

Abbildung 9 Vorgehensweisen beim Reverse – Engineering

Abbildung 10 Architektur von CARE – Werkzeugen

1 Einleitung

1.1 Überblick

Für viele der heute eingesetzten Softwaresysteme besteht aufgrund ihrer schlechten Wartbarkeit oder zwischenzeitlich veränderter Anforderungen der Bedarf einer Ablösung. Softwaresysteme altern, sie müssen durch neue ersetzt werden.

Als Alternative zur vollständigen Neuentwicklung eines Softwaresystems bietet sich das Software Reengineering an. Ein bestehendes Softwaresystem wird im Zuge eines Reverse Engineering analysiert und dokumentiert, danach restrukturiert und in einer abschließenden Phase des Forward Engineering neu implementiert [KAUFM94, S.1].

Das neu entstehende Systeme kann ein 1:1-Abbild des bestehenden Systems sein oder einzelne gezielte Erweiterungen der fachlichen Funktionalität aufweisen. Abhängig vom Umfang der Änderungen und Erweiterungen in der Anforderungsspezifikation, der Entwurfsspezifikation oder der Implementierung ergibt sich der jeweilige Lösungsraum für ein neu zu erstellendes Softwaresystem.

Im Zuge des Software Reengineering sind vielfältige Probleme zu lösen. So hängt z. B. der Erfolg der (Re-) Dokumentation eines Softwaresystems stark von der Qualität und dem Umfang der vorhandenen Dokumentation ab. Insbesondere sehr alte Softwaresysteme weisen hier erhebliche Defizite auf. Bei der Ablösung der bestehenden Softwaresysteme bestehen hohe Risiken. Abhängig vom Risiko und dem möglichen Einführungsaufwand sind hier geeignete Strategien für die Ablösung eines Softwaresystems zu definieren und umzusetzen [BISKR92, S.125].

Jedes neu erstellte Softwaresystem wird früher oder später zu einem Altsystem. Vor diesem Hintergrund bietet es sich an, Alterungsprozesse bereits bei der Neuerstellung eines Softwaresystems zu berücksichtigen, um die Wartung und ein ggf. später durchzuführendes Software Reengineering zu vereinfachen. Dadurch könnten die Kosten, die im Lebenszyklus eines Softwaresystems entstehen, nachhaltig reduziert werden.

1.2 Zielsetzung des Reengineering

Ausgehend von der genannten Problemstellung ist das Ziel des Reengineering in seiner weitesten Definition die Untersuchung, Analyse und Veränderung eines Systems, um es in neuer Form und / oder Umgebung wieder zu implementieren. Dies beinhaltet [BISKR92, S.125]:

- Die Darstellung des Systems auf höherer Abstraktionsebene
- Die technische Optimierung auf gleicher Stufe
- Die Beschreibung der Komponenten und deren Beziehungen
- Einen erneuten Entwicklungsprozess

1.3 Aufbau der Arbeit

Nach einem in Kapitel 1 kurz gehaltenen Einstieg in die Materie des Software Reengineerings, bildet Kapitel 2 die Grundbegriffe, Techniken und Verfahrensweisen ab. Hierbei geht es vornehmlich um die Fragen: Wie können die in der Praxis auftretenden Wartungsprobleme mit Hilfe des Reengineerings gelöst werden und wann ist ein Reengineering überhaupt möglich und sinnvoll? In Kapitel 2.8 wird eine Auswahl heutiger Unterstützungstools für das Reengineering (CARE) beschrieben. Zum Abschluss geht Kapitel 3 auf die noch bestehenden Probleme ein und bildet ein Fazit für die Anwendung des Reengineering.

2 Grundlagen des Reengineering

2.1 Begriffsdefinitionen

Das Reengineering lässt sich in das Reverse Engineering, die Restrukturierung und das Forward Engineering unterteilen. Die Redokumentation kann hierbei neben dem Design Recovery als Teilbereich des Reverse Engineering angesehen werden.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 1: Begriffliche Einordnungen in das Gebiet des Reengineerings, [CHCR90]

Da es im Gebiet des Software Reengineering sehr unterschiedliche Auffassungen von ein und demselben Begriff gibt, sollen im folgenden die Begriffe definiert werden.

Reengineering

„Ziel des Reengineering ist es, Wirksamkeit und Wirtschaftlichkeit einer bestehenden Informationsinfrastruktur durch den Einsatz qualitativ besserer Konzepte und Technologien zu erhöhen“ [REINDL91, S. 282]. Es wird nicht nur versucht, bestehende in verbesserte physische Anwendungssysteme zu überführen, sondern auch konzeptuelle Modelle aus vorhandenen Realisierungen abzuleiten. Reengineering umfasst sowohl die Beseitigung noch vorhandener Fehler in frühen Betriebsphasen, sowie auch die nachträgliche Anpassung an erweiterte oder geänderte funktionale und qualitative Anforderungen [REINDL91, S. 283].

Reverse – Engineering

Als Reverse – Engineering wird der Prozess der Analyse eines installierten Systems bezeichnet, der das Ziel hat, die Grundlagen für den Entwurf dieses Systems wiederzubeschaffen [HERO92]. Dies geschieht üblicherweise auf Basis vorhandener Quellcodes. Die so ermittelten Kontroll- und Datenstrukturinformationen werden in einem Repositorium abgelegt, einem Datenkatalog – System, das die spätere Wiederverwendung einzelner Komponenten ermöglicht [RICH92].

Restrukturierung

Von Restrukturierung spricht man, wenn qualitätsverbessernde Maßnahmen hinsichtlich der Systemstruktur ohne Berührung der bestehenden Funktionalität der Software oder einer Anpassung an neue Basistechnologien im Vordergrund stehen [FRAZ92].

Eine sehr weit verbreitete Form von Restrukturierung ist die Code-to-Code –Transformation, mit dem Ziel einer besseren Strukturierung des Source Codes (z. B. im Sinne von Structured Design von [YOCO79]). Es gibt jedoch auch andere Formen der Restrukturierung, wie z. B. die Datennormalisierung (data-to-data-Transformation) [KLGA95]. Ziel der Restrukturierung ist u. a. eine verbesserte Modularisierung, sowie Strukturierung und dadurch erhöhte Lesbarkeit und größere Testbarkeit.

Redokumentation

Redokumentation beinhaltet die Erzeugung einer für den Menschen verständlichen Darstellung des Quellcodes und seiner Funktionalitäten. Diese Untersuchung erfolgt auf derselben Abstraktionsstufe wie das System selbst. Es wird nur aus unterschiedlichen Sichten repräsentiert, z. B. mittels der Darstellung des Datenflusses, des Kontrollflusses oder der Modulstruktur. Zum Beispiel könnte aus vorhandenem Code mit einem Struktogramm-Generator automatisch ein Struktogramm erstellt werden [BALTZ98, S. 666].

Design Recovery

Beim Design Recovery wird aus einer Kombination von Code, existierenden Entwurfsdokumenten, persönlicher Erfahrung und Wissen über das Anwendungsgebiet rückwärts der Entwurf ermittelt.

Forward Engineering

Klassischer Ablauf von Softwareentwicklung. Ausgehend von den Anforderungen wird die Implementierung entwickelt [BALTZ98, S. 665].

2.2 Die technologische Lücke im Software Lebenszyklus

Ausgangspunkt für alle Betrachtungen im Hinblick auf den Prozess des Reengineerings ist, unabhängig von den verschiedenen Modellen, der Software - Lebenszyklus. Hier stellt sich die Frage, ob sich das Reengineering auf derselben methodischen Basis definieren lässt oder sogar Bestandteil des Software – Entwicklungsprozesses ist [KAUFM94, S.10].

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2: Software - Lebenszyklus – Modell [POBL93, S.18]

Reengineering – Projekte können auf jeder dargestellten Abstraktionsebene ansetzen, um Systempräsentationen auf derselben oder einer anderen Ebene, in eine neue Systempräsentation zu überführen. Eine Restrukturierung betrifft die Anpassung vorhandener Strukturen an neue Gegebenheiten, bei der eine Migration von einem Ausgangs- in ein Zielsystem auf gleicher Ebene stattfindet. Reverse – Engineering bezieht sich dabei immer auf zwei verschiedene Ebenen. Komplexere Reengineering – Prozesse kombinieren meist Tätigkeiten der Restrukturierung, des Reverse – Engineering und auch solche, die bei einer Neuentwicklung des Systems anfallen würden (Forward Engineering) [KAUFM94, S.8f].

Das aus allen Wirtschaftszweigen bekannte Phänomen der Technologischen – Lücke tritt bei der Software – Entwicklung wegen des starken Innovationsdrucks und verkürzter Lebenszyklen verschärft auf. Software – Produkte verbleiben meist auf dem Stand ihrer Erstentwicklung sind deutlich länger auf dem Markt, als die Technologie, auf der sie basieren [THUR93, S.39f].

Abbildung in dieser Leseprobe nicht enthalten

Abb. 3: Technologische Lücke im Software – Lebenszyklus [THUR93, S.40]

Mit fortschreitender Lebensdauer des Software – Produktes, wird die Notwendigkeit des Reengineering zur Anhebung der software – technischen Stufe immer offensichtlicher.

[...]

Ende der Leseprobe aus 19 Seiten

Details

Titel
Software Reengineering
Hochschule
Fachhochschule Braunschweig / Wolfenbüttel; Standort Wolfenbüttel  (FB Informatik)
Veranstaltung
Software Management
Note
1.3
Autor
Jahr
2003
Seiten
19
Katalognummer
V14129
ISBN (eBook)
9783638196147
Dateigröße
792 KB
Sprache
Deutsch
Anmerkungen
Dichter Text - einzeiliger Zeilenabstand
Schlagworte
Software, Reengineering, Software, Management
Arbeit zitieren
Aron Koch (Autor:in), 2003, Software Reengineering, München, GRIN Verlag, https://www.grin.com/document/14129

Kommentare

  • Noch keine Kommentare.
Blick ins Buch
Titel: Software Reengineering



Ihre Arbeit hochladen

Ihre Hausarbeit / Abschlussarbeit:

- Publikation als eBook und Buch
- Hohes Honorar auf die Verkäufe
- Für Sie komplett kostenlos – mit ISBN
- Es dauert nur 5 Minuten
- Jede Arbeit findet Leser

Kostenlos Autor werden