Upload
others
View
4
Download
0
Embed Size (px)
Citation preview
Prof. Dr. K.-P. Fähnrich / Thomas Riechert 1
Institut für InformatikBetriebliche Informationssysteme
15.06.2010
Software Management
SanierungProf. Dr. K.-P. Fähnrich / Thomas Riechert
Prof. Dr. K.-P. Fähnrich / Thomas Riechert 2
Institut für InformatikBetriebliche Informationssysteme
15.06.2010
Organisatorisches
• Lehrveranstaltungsevaluation
Modulkennung: 10-202-2319_SS10 Passwort: L59wnztm URL: https://www.umfragen.uni-bonn.de/leipzig/module
https://www.umfragen.uni-bonn.de/leipzig/module
Prof. Dr. K.-P. Fähnrich / Thomas Riechert 3
Institut für InformatikBetriebliche Informationssysteme
15.06.2010
Übersicht der Vorlesung
1. Grundlagen 2. Planung3. Organisation: Gestaltung4. Organisation: Prozess-Modelle5. Personal6. Leitung7. Innovationsmanagement8. Kontrolle: Metriken, Konfigurations- und
Änderungsmanagement9. CASE10. Wiederverwendung11. Sanierung
Prof. Dr. K.-P. Fähnrich / Thomas Riechert 4
Institut für InformatikBetriebliche Informationssysteme
15.06.2010
Gliederung
1. Zur Problematik
2. Konzepte und ihre Terminologie
3. Technik
3.1. Verpacken von Altsystemen
3.2. Verstehen von Altsystemen
4. Kosten/Nutzen der Sanierung
5. CARE-Werkzeuge
Begleitliteratur: Helmut Balzert, Lehrbuch der Software-Technik
Quelle der Grafiken und Tabellen: Helmut Balzert, Lehrbuch der Software-Technik,
wenn nicht anders angegeben
Prof. Dr. K.-P. Fähnrich / Thomas Riechert 5
Institut für InformatikBetriebliche Informationssysteme
15.06.2010
1. Zur Problematik
Fakten (nach [Sneed 92a])
• 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
15.06.2010
1. Zur Problematik
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
15.06.2010
1. Zur Problematik
Fakten (nach [Sneed 92a]) (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
15.06.2010
Gliederung
1. Zur Problematik
2. Konzepte und ihre Terminologie
3. Technik
3.1. Verpacken von Altsystemen
3.2. Verstehen von Altsystemen
4. Kosten/Nutzen der Sanierung
5. CARE-Werkzeuge
Prof. Dr. K.-P. Fähnrich / Thomas Riechert 9
Institut für InformatikBetriebliche Informationssysteme
15.06.2010
2. Konzepte und ihre Terminologie
Terminologie der Software-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
Prof. Dr. K.-P. Fähnrich / Thomas Riechert 10
Institut für InformatikBetriebliche Informationssysteme
15.06.2010
2. Konzepte und ihre Terminologie
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
15.06.2010
Gliederung
1. Zur Problematik
2. Konzepte und ihre Terminologie
3. Technik
3.1. Verpacken von Altsystemen
3.2. Verstehen von Altsystemen
4. Kosten/Nutzen der Sanierung
5. CARE-Werkzeuge
Begleitliteratur: Helmut Balzert, Lehrbuch der Software-Technik
Quelle der Grafiken und Tabellen: Helmut Balzert, Lehrbuch der Software-Technik,
wenn nicht anders angegeben
Prof. Dr. K.-P. Fähnrich / Thomas Riechert 12
Institut für InformatikBetriebliche Informationssysteme
15.06.2010
3. Technik
Verfahren 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
15.06.2010
3.1. Verpacken von Altsystemen
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.
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
Prof. Dr. K.-P. Fähnrich / Thomas Riechert 14
Institut für InformatikBetriebliche Informationssysteme
15.06.2010
Dateiebene
• Zugriff auf das Altsystem über eine spezielle Schicht
3.1. Verpacken von Altsystemen
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
15.06.2010
3.2. Verstehen 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
15.06.2010
Gliederung
1. Zur Problematik
2. Konzepte und ihre Terminologie
3. Technik
3.1. Verpacken von Altsystemen
3.2. Verstehen von Altsystemen
4. Kosten/Nutzen der Sanierung
5. CARE-Werkzeuge
Prof. Dr. K.-P. Fähnrich / Thomas Riechert 17
Institut für InformatikBetriebliche Informationssysteme
15.06.2010
4. 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
15.06.2010
4. 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
15.06.2010
4. 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
15.06.2010
4. 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
15.06.2010
4. Kosten/Nutzen der Sanierung
Kosten/Nutzen-Analysen von Sanierung und Neuentwicklung
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
15.06.2010
4. 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
15.06.2010
4. 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
15.06.2010
Gliederung
1. Zur Problematik
2. Konzepte und ihre Terminologie
3. Technik
3.1. Verpacken von Altsystemen
3.2. Verstehen von Altsystemen
4. Kosten/Nutzen der Sanierung
5. CARE-Werkzeuge
Begleitliteratur: Helmut Balzert, Lehrbuch der Software-Technik
Quelle der Grafiken und Tabellen: Helmut Balzert, Lehrbuch der Software-Technik,
wenn nicht anders angegeben
Prof. Dr. K.-P. Fähnrich / Thomas Riechert 25
Institut für InformatikBetriebliche Informationssysteme
15.06.2010
5. 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
15.06.2010
5. CARE-Werkzeuge
Aussagen
• 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
15.06.2010
5. CARE-Werkzeuge
Aussagen (2)
• 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
15.06.2010
Literatur
• [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 11. SanierungSlide 2Übersicht der VorlesungGliederung1. Zur ProblematikSlide 6Slide 7Slide 82. Konzepte und ihre TerminologieSlide 10Slide 113. Technik3.1. Verpacken von AltsystemenSlide 143.2. Verstehen von AltsystemenSlide 164. Kosten/Nutzen der SanierungSlide 18Slide 19Slide 20Slide 21Slide 22Slide 23Slide 245. CARE-WerkzeugeSlide 26Slide 27Literatur