Prof. Dr. K.-P. Fähnrich / Thomas Riechert 1 Institut für Informatik Betriebliche Informationssysteme 21.06.2011 Prof. Dr. K.-P. Fähnrich / Thomas Riechert Vorlesung Software-Management Sommersemester 2011 Sanierung
Prof. Dr. K.-P. Fähnrich / Thomas Riechert 1
Institut für InformatikBetriebliche Informationssysteme
21.06.2011
Prof. Dr. K.-P. Fähnrich / Thomas Riechert
Vorlesung Software-ManagementSommersemester 2011
Sanierung
Prof. Dr. K.-P. Fähnrich / Thomas Riechert 2
Institut für InformatikBetriebliche Informationssysteme
21.06.2011
SWM. SanierungÜbersicht der Vorlesung
Begleitliteratur: Helmut Balzert, Lehrbuch der Software-TechnikQuelle der Grafiken und Tabellen: Helmut Balzert, Lehrbuch der Software-Technik,wenn nicht anders angegeben
(1) Grundlagen (2) Planung(3) Organisation: Gestaltung(4) Organisation: Prozessmodelle(5) Personal(6) Leitung(7) Innovationsmanagement(8) Kontrolle: Metriken, Konfigurations- und Änderungsmanagement(9) CASE(10)Wiederverwendung(11)Sanierung
Prof. Dr. K.-P. Fähnrich / Thomas Riechert 3
Institut für InformatikBetriebliche Informationssysteme
21.06.2011
SWM. SanierungHaus der Softwaretechnik (nach Balzert)
Einführung und ÜberblickLE 1
V Unternehmensmodellierung
2 LE
1 Grundlagen
LE 24
2 Objektorientierte Unternehmensmodellierung LE 25
I SW-Entwicklung
33 LE
6 Die Wartungs- & Pflegephase LE 34
5 Die Abnahme- und Einführungsphase LE 34
4 Die Implementationsphase
LE 33
3 Die Entwurfsphase
LE 23 - 32
2 Die Definitionsphase
LE 4 - 22
1 Die Planungsphase
LE 2 - 3
III SW-Qualitäts- Management
11 LE
6 Produktqualität – Syst. LE 18 - 19
5 Produktqualität – Komp.LE 14 - 17
4 Prozessqualität
LE 12 - 13
3 Manuelle Prüf- methoden LE 11
2 Qualitäts- sicherung LE 10
1 Grundlagen
LE 9
II SW-Management
8 LE
6 Kontrolle
LE 8
5 Leitung
LE 6 - 7
4 Personal
LE 5
3 Organisation
LE 3 - 4
2 Planung
LE 2
1 Grundlagen
LE 1
IV Querschnitte und Ausblicke
4 LE
4 Sanierung
LE 23
1 Prinzipien und Methoden LE 20
3 Wiederver- wendung LE 22
2 CASE
LE 21
Legende:
= Übergabe vonTeilprodukten
= Informationsaustausch
= Unterstützung
LE = Lehreinheit
Die in dieser VorlesungBehandelten Themen
= Einfluss
Prof. Dr. K.-P. Fähnrich / Thomas Riechert 4
Institut für InformatikBetriebliche Informationssysteme
21.06.2011
SWM. Sanierung
1. Zur Problematik2. Konzepte und ihre Terminologie3. Technik
Verpacken von Altsystemen
Verstehen von Altsystemen4. Kosten/Nutzen der Sanierung5. CARE-Werkzeuge
Begleitliteratur: Helmut Balzert, Lehrbuch der Software-Technik
Quelle der Grafiken und Tabellen: Helmut Balzert, Lehrbuch der Software-Technik,
wenn nicht anders angegeben
Gliederung - Problematik
Prof. Dr. K.-P. Fähnrich / Thomas Riechert 5
Institut für InformatikBetriebliche Informationssysteme
21.06.2011
SWM. SanierungFakten (nach [Sneed 92a]) 1
• Die Wartungskosten eines durchschnittlichen Anwender-unternehmens liegt zwischen 50 und 75% des gesamten DV-Budgets.
• Nur 30% sind individueller, problemspezifischer Natur. Der Rest ist softwaretechnisch identisch und ließe sich mit entsprechenden Standards abdecken.
• Ein typischer Anwender in den USA hat durchschnittlich 2200 Programme mit 1,15 Millionen Anweisungen, die 40 bis 50 Anwendungen abdecken.
• Ein typisches Programm in den USA ist meistens in COBOL geschrieben, lebt 5 bis 7 Jahre und enthält 700 Anweisungen.
• Ein Programm, das ein hierarchisches oder netzwerkorientiertes DBS benutzt, wird jährlich zwischen 10 und 20-mal angepasst.
Prof. Dr. K.-P. Fähnrich / Thomas Riechert 6
Institut für InformatikBetriebliche Informationssysteme
21.06.2011
SWM. SanierungWartungsaufwand
Verteilung des Wartungaufwandes (nach [Sneed 92 a])
Wartungsaufwand
OptimerungWeiterentwicklungFehlerbehebungAnpassung, Änderung
40 % Weiterentwicklung
16 % Optimierung20 % Anpassung und Änderung
24 % Fehlerbehebung und Stabilisierung
Prof. Dr. K.-P. Fähnrich / Thomas Riechert 7
Institut für InformatikBetriebliche Informationssysteme
21.06.2011
SWM. SanierungFakten (nach [Seed92a]) 2
• Deutsche Cobol-Programme sind zu 80% monolithisch, zu 77% unstrukturiert und enthalten zu 93% überflüssige, redundant gehaltene Daten.
• Ein Cobol-Programmierer verwaltet ca 1100 Data-Division-Anweisungen, 2000 Procedure-Division-Anweisungen und 270 Sprunganweisungen.
• Die Komplexität eines unstrukturierten Programms erhöht sich nach einer Korrektur um 4%, nach einer Änderung um 17% und nach einer Erweiterung um 26%.
• Ein Wartungsprogrammierer benötigt 47% seiner Zeit für die Programmanalyse, 15% für die Programmierung, 28% für den test und 9% für die Dokumentation.
• Die Wartungskosten je geänderte Zeile sind bei kleinen Anwendungen am höchsten.
Prof. Dr. K.-P. Fähnrich / Thomas Riechert 8
Institut für InformatikBetriebliche Informationssysteme
21.06.2011
SWM. Sanierung
1. Zur Problematik2. Konzepte und ihre Terminologie3. Technik
Verpacken von Altsystemen
Verstehen von Altsystemen4. Kosten/Nutzen der Sanierung5. CARE-Werkzeuge
Begleitliteratur: Helmut Balzert, Lehrbuch der Software-Technik
Quelle der Grafiken und Tabellen: Helmut Balzert, Lehrbuch der Software-Technik,
wenn nicht anders angegeben
Gliederung - Konzepte
Prof. Dr. K.-P. Fähnrich / Thomas Riechert 9
Institut für InformatikBetriebliche Informationssysteme
21.06.2011
SWM. Sanierung
Produkt-Definition
Definition
Produkt-Entwurf
Entwurf
Quellprogramme und Daten-beschreibungen
Implementierung
Existierendes, lauffähiges SW-System
Überarbeitete Anforderungen
Definition
Überarbeiteter Entwurf
Entwurf
Überarbeitete Quellcode und Dokumentation
Implementierung
Saniertes, lauffähiges SW-System
Rev
erse
Engin
e eri
ng
Forw
ard E
ngin
eering
Definitionsüberarbeitung
Entwurfsüberarbeitung
Programmüberarbeitung
Redokumentieren, Restrukturieren
Redokumentieren, Restrukturieren
Redokumentieren, Restrukturieren
Discompilierung, Disassemblierung
Rekonstruieren
Redefinieren Entwerfen
Implementieren
Compilieren, Assemblieren, Binden
Reengineering
Terminologie der Software-Sanierung
Prof. Dr. K.-P. Fähnrich / Thomas Riechert 10
Institut für InformatikBetriebliche Informationssysteme
21.06.2011
SWM. SanierungDefinitionen
Definitionen
Forward Engineering: stellt den normalen Entwicklungsablauf bei der Neuentwicklung von Softwaresystemen dar.
Reverse Engineering: Hierbei wird versucht, aus einem fertigen Produkt, z.B. einem Prozessor oder einem Schaltkreis, die Produktspezifikation abzuleiten.
Re-engineering (Renovierung): Umfasst alle Aktivitäten zur Änderung von Software-Altsystemen, um sie in einer neuen Form wieder implementieren zu können.
Sanierung: Umfasst alle notwendigen Reverse Engineering; Reengineering und Forward Engineering-Maßnahmen, um ein saniertes lauffähiges System zu erhalten, das definierte neue Ziele erfüllt.
Prof. Dr. K.-P. Fähnrich / Thomas Riechert 11
Institut für InformatikBetriebliche Informationssysteme
21.06.2011
SWM. Sanierung
1. Zur Problematik2. Konzepte und ihre Terminologie3. Technik
Verpacken von Altsystemen
Verstehen von Altsystemen4. Kosten/Nutzen der Sanierung5. CARE-Werkzeuge
Begleitliteratur: Helmut Balzert, Lehrbuch der Software-Technik
Quelle der Grafiken und Tabellen: Helmut Balzert, Lehrbuch der Software-Technik,
wenn nicht anders angegeben
Gliederung - Technik
Prof. Dr. K.-P. Fähnrich / Thomas Riechert 12
Institut für InformatikBetriebliche Informationssysteme
21.06.2011
SWM. SanierungVerfahren der Sanierung
• Kategorien von Verfahren zur Realisierung der verschiedenen Konzepte der Sanierung:
Verpacken (wrapping),
Verstehen und
Verbessern von Altsystemen.
• Hat man mittels Reverse Engineering ein ausreichendes Verständnis und eine angemessene Dokumentation der jeweiligen Abstraktionsebene erreicht, dann kann auf dieser Grundlage das Altsystem verbessert werden.
• Eine Konvertierung eines Altsystem in eine neue Programmiersprache ohne Veränderung der Systemarchitektur erfordert nur die Transformierung des Codes in eine neue Programmiersprache
Prof. Dr. K.-P. Fähnrich / Thomas Riechert 13
Institut für InformatikBetriebliche Informationssysteme
21.06.2011
SWM. SanierungVerpacken von Altsystemen - Wrapping
OO-Programm Object Wrapper
Operation 1Operation 2 …
OO-Programm
Operation 1Operation 2 …
Procedural Wrapper
entry point
Altsystem
AltsystemAufruf
Aufruf Aufruf
Aufruf OO-Wrapper
Prozeduraler Wrapper
Wrapping
• Entstanden im Rahmen der objektorientierten Entwicklung.
• Ist sowohl für die Sanierung als auch für die Migration von Altsoftware geeignet.
• Grundidee: Verpacken der Altsoftware oder ihrer Teilsysteme durch eine Software-Schicht nach außen hin, so dass eine OO-Benutzung möglich wird.
Prof. Dr. K.-P. Fähnrich / Thomas Riechert 14
Institut für InformatikBetriebliche Informationssysteme
21.06.2011
SWM. Sanierung
Dateiebene
• Zugriff auf das Altsystem über eine spezielle Schicht
Verpackungsebenen konventionaler Altsysteme
Ebenen
Prozessebene
•Start eines Stapel- programms auf einem Großrechner nach der Bereitstellung der Bewegungsdateien.
Prozedurebene
•Aufruf einer ab- geschlossenen internen Prozedur innerhalb eines Moduls des Altsystems
Transaktionsebene
•Start einer Online-CICS
oder IMS-Transaktion.
•Datenströme statt Eingabemasken
Modulebene
• Aufruf des Unter- programms mit den benötigten Eingabe-
parametern
Programmebene
•Start eines einzelnen Stapel- oder Online- Programms und Bereitstellung seiner Eingabedaten
Prof. Dr. K.-P. Fähnrich / Thomas Riechert 15
Institut für InformatikBetriebliche Informationssysteme
21.06.2011
SWM. SanierungVerstehen von Altsystemen
Möglichkeiten
• Prinzipiell gibt es 3 Möglichkeiten:
Verstehen des Systems als Black box,
Verstehen des Systems als White box,
Mischformen der ersten beiden Möglichkeiten.
• Das Verstehen des Systems als Blackbox ist in vielen Fällen ausreichend. Dazu werden 3 Engineering-Formen verwendet:
Reverse Engineering: Erstellen eines OOA-Modells des Altsystems
Reengineering: Überarneitung, Verbesserung und Erweiterung des entstandenen OOA-Modells.
Forward Engineering: Entwicklung eines neuen Systems ausgehend vom OOA-Modell.
Prof. Dr. K.-P. Fähnrich / Thomas Riechert 16
Institut für InformatikBetriebliche Informationssysteme
21.06.2011
SWM. Sanierung
1. Zur Problematik2. Konzepte und ihre Terminologie3. Technik
Verpacken von Altsystemen
Verstehen von Altsystemen4. Kosten/Nutzen der Sanierung5. CARE-Werkzeuge
Begleitliteratur: Helmut Balzert, Lehrbuch der Software-Technik
Quelle der Grafiken und Tabellen: Helmut Balzert, Lehrbuch der Software-Technik,
wenn nicht anders angegeben
Gliederung - Kosten/Nutzen
Prof. Dr. K.-P. Fähnrich / Thomas Riechert 17
Institut für InformatikBetriebliche Informationssysteme
21.06.2011
SWM. Sanierung4. Kosten/Nutzen der Sanierung
Möglichkeiten
• Folgende Möglichkeiten der Kosten/Nutzenbetrachtung stehen zur Auswahl:
Weiterführung der korrektiven und adaptiven Wartung,
Sanierung,
Neuentwicklung,
Einsatz einer Standardsoftware.
• Einen ersten Anhaltspunkt für eine mögliche Sanierung gibt eine Portfolioanalyse.
• Alte Systeme werden nach 2 Kategorien bewertet:
der technischen Qualität und
der Benutzerzufriedenheit oder der betriebswirtschaftlichen Bedeutung.
Prof. Dr. K.-P. Fähnrich / Thomas Riechert 18
Institut für InformatikBetriebliche Informationssysteme
21.06.2011
SWM. Sanierung4. Kosten/Nutzen der Sanierung
Portfolioanalyse der Altsysteme (nach [Sneed 92a, 95])II
Keine Änderung (eventuell Funktionserweiterung)
I
Keine Änderung (eventuell Nachdokumentation)
IV
Neuentwicklung
III
Sanierung
Tec
hnis
che
Qual
ität
Betriebswirtschaftliche Bedeutung
Benutzerzufriedenheit
Nie
dri
g
Hoch
Niedrig Hoch
Prof. Dr. K.-P. Fähnrich / Thomas Riechert 19
Institut für InformatikBetriebliche Informationssysteme
21.06.2011
SWM. Sanierung4. Kosten/Nutzen der Sanierung
Portfolioanalyse der Altsysteme (nach [Jacobson, Lindström 91])
II
Wartung
I
Weiterentwicklung
IV
Aufgabe
III
Sanierung
Änder
ba r
keit
Betriebswirtschaftliche Bedeutung
Nie
drig
H
och
Niedrig Hoch
Prof. Dr. K.-P. Fähnrich / Thomas Riechert 20
Institut für InformatikBetriebliche Informationssysteme
21.06.2011
SWM. Sanierung4. Kosten/Nutzen der Sanierung
Kosten/Nutzen-Analysen
• 3 Ursachen der Sanierung (nach [Sneed 92a]):
Das Altsystem ist technisch überholt und muss ersetzt werden.Sani-Nutzen = (Alt-Wert – [Sani-Nutzen * Sani-Risiken]) – (Neu-Wert – [Entw-Kosten * Entw-Risiken])
Das Altsystem hat schwerwiegende technische Mängel, die die Wartung erschweren und die Leistung beeinträchtigen. Sani-Nutzen = (Alte-Wart-Kosten – Sani-Wart-Kosten)
+ (Alt-Wert – [Sani-Nutzen * Sani-Risiken]) - (Neu-Wert – [Entw-Kosten * Entw-Risiken])
Das Altsystem sollte überarbeitet werden, um die Wartungskosten zu reduzieren und die technische Qualität zu verbessern.Sani-Nutzen = (Jährliche Kostenersparnis durch Sanierung) - (Sani-Kosten * Sani-Risiken)
Prof. Dr. K.-P. Fähnrich / Thomas Riechert 21
Institut für InformatikBetriebliche Informationssysteme
21.06.2011
SWM. SanierungKosten/Nutzen-Analysen von Sanierung und Neuentw.
12
11
10
9
8
7
6
5
4
3
2
1
1 2 3 4 5 6 7
Neu
entw
ickl
ung
Sanierung
Wartungsko
sten
Original-Ve
rsion
Neue Version
Sanierte Version
Punkt der Unrentabilität
Amortisations-punkt
Nutzwert des alten Systems
neuen Systems Sys
tem
-Kost
en in M
M p
ro J
ahr
System-Lebens-erwartung in Jahren
Prof. Dr. K.-P. Fähnrich / Thomas Riechert 22
Institut für InformatikBetriebliche Informationssysteme
21.06.2011
SWM. Sanierung4. Kosten/Nutzen der Sanierung
Nutzen einer Sanierung (nach [Figliolo 89])
• Niedrige Wartungskosten durch ersparten Aufwand pro Wartungs-auftrag.
• Niedrige Wartungskosten durch die Ablösung von höher qualifiziertem Personal durch jüngeres, weniger qualifiziertes Personal.
• Niedrigere Produktionskosten durch eine Reduzierung der Systemabbrüche.
• Niderige Verluste wegen „missed opportunities“ durch Freisetzung gebundener Kapazitäten für neue Aufgaben.
Prof. Dr. K.-P. Fähnrich / Thomas Riechert 23
Institut für InformatikBetriebliche Informationssysteme
21.06.2011
SWM. Sanierung4. Kosten/Nutzen der Sanierung
Risiken
• Das Risiko einer Neuentwicklung ist 2 bis 3 mal höher als das einer Sanierung unter der Vorraussetzung, dass die Datenstrukturen unverändert bleiben.
• Die Kosten einer Sanierung betragen normalerweise nur ¼ der Kosten einer Neuentwicklung.
• Die Sanierung ist immer dann eine günstige Alternative, wenn Funktionalität und Informationsstruktur der Software konstant bleiben.
• Eine günstiger Zeitpunkt für eine erfolgreiche Sanierung liegt vor, wenn
die Wartungsmitarbeiter ausscheiden oder versetzt werden,
das System in eine andere technische Umgebung konvertiert werden,
das System funktional überarbeitet wird.
Prof. Dr. K.-P. Fähnrich / Thomas Riechert 24
Institut für InformatikBetriebliche Informationssysteme
21.06.2011
SWM. Sanierung
1. Zur Problematik2. Konzepte und ihre Terminologie3. Technik
Verpacken von Altsystemen
Verstehen von Altsystemen4. Kosten/Nutzen der Sanierung5. CARE-Werkzeuge
Begleitliteratur: Helmut Balzert, Lehrbuch der Software-Technik
Quelle der Grafiken und Tabellen: Helmut Balzert, Lehrbuch der Software-Technik,
wenn nicht anders angegeben
Gliederung - CARE
Prof. Dr. K.-P. Fähnrich / Thomas Riechert 25
Institut für InformatikBetriebliche Informationssysteme
21.06.2011
SWM. Sanierung5. CARE-Werkzeuge
Beispiel einer CARE-Umgebung (nach [Witschurke 95])
Repository
Abstraktion der Anwendungs- und Entwurfsstruktur
Transformation der QuellprogrammeSprachabstraktion
Quellprogramme
Dokumentation
Aufgaben der Anwender/Benutzer
Erfahrungen der Betreuer
Wissen der Entwickler
Sprachanalyse
Komponenten-analyse
Auswahl der Komponenten
StrukturierungPräzisierung
ErfassungAuswahl
VisualisierungBearbeitung
Sanierungs-Ingenieur
Strukturierte Interviews Val
idierun
g
Prof. Dr. K.-P. Fähnrich / Thomas Riechert 26
Institut für InformatikBetriebliche Informationssysteme
21.06.2011
SWM. Sanierung5. CARE-Werkzeuge
• CARE-Werkzeuge für die Reformatierung und Nachdokumentation sind sehr umfassend und hilfreich für die Wartung.
• Der Nutzen von Werkzeugen zur Code-Restrukturierung und zur Modularisierung muss noch nachgewiesen werden.
• Eine vollautomatische Programmsanierung mit Rekonstruktion und Redefinition ist gegenwärtig nur eingeschränkt möglich.
• CARE-Werkzeuge müssen in eine CASE-Umgebung integriert oder an sie anbindbar sein.
• Mit der Unterstützung von CARE-Werkzeugen lässt sich die Lebenszeit von Altsystemen so verlängern, dass die vorzeitig nicht entsorgt werden müssen.
• Durch den gezielten Einsatz von CARE-Werkzeugen kann der Wartungsaufwand um etwa 20 bis 25% verringert werden.
Prof. Dr. K.-P. Fähnrich / Thomas Riechert 27
Institut für InformatikBetriebliche Informationssysteme
21.06.2011
SWM. Sanierung5. CARE-Werkzeuge
• Durch verbesserte CARE-Werkzeuge konnte die Anzahl der restrukturierten, redokumentierten und konvertierten Anweisungen pro Entwickler und pro Tag von 70 Anweisungen (1983) über 350 Anweisungen (1986) auf 2000 Anweisungen (1990) gesteigert werden.
• Die Verbreitung und Anwendung von CARE-Werkzeuge entsprechen nicht ihrer Leistungsfähigkeit. Gründe für die Stagnation liegen in den relativ hohen Kosten, fehlende Schnittstellen sowie einer Vorliebe für Neuentwicklung und Standorte.
• Die Weiterentwicklung der Werkzeuge bezogen auf den Funktions-umfang und den Bedienungskomfort hält sich in Grenzen.
• Das Angebot für die Sprachen C und C++ steigt.
Prof. Dr. K.-P. Fähnrich / Thomas Riechert 28
Institut für InformatikBetriebliche Informationssysteme
21.06.2011
SWM. SanierungLiteratur
• [Figliolo 89]
Figliolo R., benefits of Software Reengineering, in Proc. Of Software Maintenance Association Conference
• [Jacobson, Lindström 91]Jacobson I., Lindström F., Re-engineering of old systems to an object-oriented architecture, OOPSLA
• [Sneed 92 a]Sneed H., Softwaresanierung, Rudolf Müller Verlag
• [Sneed 95]Sneed H., Wann Softwaresanierung wirtschaftlich ist, in online 3/92
• [Witschurke 95]Witschurke R., Verständnisvoll - Interaktives Reverse Engineering, in iX 6/95
Software Management 1. GrundlagenÜbersicht der VorlesungHaus der Softwaretechnik (nach Balzert)Gliederung - ProblematikFakten IWartungsaufwandFakten IIGliederung - KonzepteTerminologie der Software-SanierungDefinitionenGliederung - Technik3. Technik3.1. Verpacken von AltsystemenVerpackungsebenen konventionaler Altsysteme3.2. Verstehen von AltsystemenGliederung - Kosten/Nutzen4. Kosten/Nutzen der SanierungPortfolioanalyse der AltsystemePortfolioanalyse der Altsysteme 2Slide 20Analyse Sanierung/ NeuentwicklungNutzen einer SanierungRisikenSlide 245. CARE-WerkzeugeCARE 1CARE 2Literatur