Software Management -...
Transcript of Software Management -...
-
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