Embed Size (px)
Citation preview
Software Engineering
© Ludewig, J., H. Lichter: Software Engineering – Grundlagen, Menschen, Prozesse, Techniken. 2. Aufl., dpunkt.verlag, 2010.
22 Software-Wartung
22.1 Begriff und Taxonomie der Software-Wartung
22.2 Inhalt und Ablauf der Wartung
22.3 Risiken, Probleme und Grundsätze der Wartung
22.4 Die Wartungsorganisation
Einleitung
Wartung beansprucht von allen Tätigkeiten das größte Budget. kennzeichnet den Normalzustand einer Software.
Wartung ist die dominierende Tätigkeit der Software-Leute. ist extrem wichtig und kostspielig.
Aber leider gilt auch: Wartung ist terra incognita, ein Gebiet, über das wir wenig wissen.
Das fundamentale Problem: Wartung muss von beliebigen Situationen ausgehen.
2
22.1 Begriff und Taxonomie der Software-Wartung
Verschleiß und Wartung
Für Maschinen usw. gilt: Abnutzung ist modellierbar und prognostizierbar;
Wartung zur Kompensation der Abnutzung ist darum gut planbar. Unfälle finden mit einer gewissen statistischen Wahrscheinlichkeit
statt, sind aber nicht planbar, sondern passieren überraschend. Umstellungen (Anpassungen) können meist nicht geplant werden,
weil die Gründe kurzfristig entstehen. Sie können aber evtl. verschoben werden.
In der Software gibt es keine Abnutzung.
Auftretende Fehler können als Unfälle interpretiert werden. Anpassungen erfordern den größten Teil des Wartungsaufwands.
4
Definitionen des Wartungsbegriffs - 1
Aber: die Definition der Wartung als Phase verschleiert, dass es schon vor Auslieferung Wartung, noch nach Auslieferung Entwicklung gibt.
5
operation and maintenance phase — The period of time in the software life cycle during which a software product is employed in its operational environment, monitored for satisfactory performance, and modified as necessary to correct problems or to respond to changing requirements.
maintenance — The process of modifying a software system or component after delivery to correct faults, improve performance or other attributes, or adapt to a changed environment.
Syn: software maintenance. See also: adaptive maintenance; corrective maintenance; perfective
maintenance.IEEE Std 610.12 (1990)
Definitionen des Wartungsbegriffs - 2
Die Frage der Planbarkeit spielt eine wichtige Rolle.
Die unmittelbaren Auswirkungen auf den Benutzer der Software unterscheiden die Wartung vom Reengineering.
Komposition bestehender Komponenten ist Entwicklung, keine Wartung! Die Komponenten sind ja für diesen Zweck entwickelt worden.
6
Software-Wartung ist jede Arbeit an einem bestehenden Software-System, die nicht von Beginn der Entwicklung an geplant war oder hätte geplant werden können und die unmittelbare Auswirkungen auf den Benutzer der Software hat.
Ludewig, Opferkuch (2004)
Arten der Wartung - 1
Darin sind nur die Begriffe korrektive Wartung (= Korrektur) und adaptive Wartung (= Anpassung) klar.
7
adaptive maintenance — Software maintenance performed to make a computer program usable in a changed environment.
corrective maintenance — Maintenance performed to correct faults in software.
perfective maintenance — Software maintenance performed to improve the performance, maintainability, or other attributes of a computer program.
preventive maintenance — Maintenance performed for the purpose of preventing problems before they occur.
IEEE Std 610.12 (1990)
Arten der Wartung - 2
Auch hier halten wir teilweise andere Begriffe und Kategorien für sinnvoll.
Problem: Verbesserung und Prävention lassen sich nicht von Anpassung und Korrektur unterscheiden!
War die Spezifikation verletzt? Ja: → Korrektur Nein: → Anpassung
8
Wartung Die Software wird so verändert, dass … adaptiv sie neue oder geänderte Anforderungen erfüllt; diese können funktional
oder nichtfunktional sein. korrektiv ein beobachteter Fehler nicht mehr auftritt oder entschärft ist (z.B. durch
Anzeige einer Warnung)verbessernd bestimmte Qualitätsmerkmale (z.B. die Verarbeitungsgeschwindigkeit
oder die Benutzbarkeit) der Software verbessert werden. ??präventiv bestimmte Fehler gar nicht erst auftreten. ??
Arten der Wartung - 3
Die Erfüllung geänderter Anforderungen ist keine „Verbesserung“, sondern eine Anpassung.
Die Beseitigung eines Mangels, der noch nicht wirksam geworden ist, ist keine Prävention, sondern eine Korrektur. Das beliebteste Beispiel für präventive Wartung ist das
sogenannte Y2K-Problem, die mangelnde Vorbereitung vieler Software-Systeme für Jahreszahlen ab 2000. Es handelt sich aber durchgängig um Korrektur oder Anpassung.
Wir folgern daraus, dass der Begriff der präventiven Wartung überflüssig und irreführend ist.
Von verbessernder Wartung sprechen wir dann und nur dann, wenn es um weiche Anforderungen geht, die nach der Bearbeitung in höherem Maße erfüllt werden.
9
Die Kosten der Wartung
Nosek und Palvia (1990): Keine großen Veränderungen gegen Lientz, Swanson.
Das ist nach unserem Eindruck weiterhin gültig.
Je größer die Bedeutung der Informatik in einem Unternehmen ist, umso höher ist der Wartungsanteil bei den Kosten.
Im (durchaus üblichen) Extremfall gibt es praktisch nur noch Wartungskosten, weil keine Neuentwicklungen, sondern nur noch Verbesserungen, Anpassungen und Korrekturen stattfinden.
10
Studie Aufwand für Wartung
Zelkowitz, Shaw, Gannon (1979) 67%
Lientz, Swanson (1980) 48%
Abran, Nguyenkim (1991) 55%
Verteilung über die Arten der Wartung
Achtung, sehr unterschiedliches Verständnis von „Verbesserung“!
Folgerung: Anpassung und Erweiterung schlucken den Löwenanteil der
Wartungskosten. An zweiter Stelle steht die Korrektur.
11
Wartungsart Lientz, Swanson (1980)
Sneed (1987) van Vliet (2000)
Korrektur 17 % 25 % 21 %
Anpassung / Erweiterung
18 %20 %40 %
25 %
Verbesserung /Prävention
65 % 15 %50 %4 %
22.2 Inhalt und Ablauf der Wartung
Ein Modell der Wartung - 1
Wenn die Implementierung auf Grund eines Implementierungsfehlers nicht der Spezifikation entspricht (1), ist eine Korrektur (2) nötig. Damit sind Spezifikation und Implementierung konsistent (3).
Ändern sich die Anforderungen (4), ist also eine Anpassung oder Erweiterung notwendig, so muss durch eine Änderung der Implementierung (5) die Konsistenz (6) wieder hergestellt werden.
Wünscht der Kunde eine Verbesserung (7), so entspricht das (in den meisten Fällen) einer Änderung oder Präzisierung der Spezifikation. Entsprechend findet der gleiche Ablauf wie oben statt.
Natürlich können die Korrekturen die Konsistenz immer nur lokal herstellen; wir müssen grundsätzlich davon ausgehen, dass jedes Software-System Fehler enthält.
13
Ein Modell der Wartung - 1
Korrektur, Anpassung, Verbesserung
14
Schritte der Wartung - 1
Wartung sollte nicht auf Zuruf stattfinden, sondern geplant werden.
Um sie planen zu können, muss ein Änderungswesen etabliert sein.
Alle eingehenden Fehlermeldungen und Änderungswünsche fließen in Form von Problemmeldungen in die Planung der Wartung ein.
Der Änderungsausschuss (Change Control Board, CCB) entscheidet, welche Meldungen zur Wartung führen.
15
Schritte der Wartung - 2Die Wartung erfordert die folgenden Schritte:
1. Der Ausgangszustand wird (spätestens jetzt) präzise dokumentiert und archiviert.
2. Der zu modifizierende Teil wird identifiziert; er sollte so klein wie möglich sein. Die übrige Software vor Änderungen schützen!
3. Testfälle für die durchgeführte Änderung werden entworfen.(Prüfung der alten Testfälle, wie weit sie gültig bleiben oder zu ergänzen sind). An den Regressionstest denken (siehe Schritt 5)!
4. Die zu ändernden Komponenten werden aus der Konfigurationsverwaltung entnommen, bearbeitet und lokal geprüft. Wenn sie OK sind, zurück in die Konfig.-verwaltung.
5. Die veränderten Komponenten werden integriert und getestet.Dabei kommt vor allem der Regressionstest zum Zuge.
6. Der neue Zustand wird dokumentiert und wiederum archiviert.
7. Der benötigte Aufwand für die Wartung wird aufgezeichnet.
16
Die Verteilung der geänderten Software
Wenn die Änderungen durchgeführt sind, bekommt der Kunde eine Lieferung (Aktualisierung, Update).
Eine Aktualisierung basiert immer auf einer freigegebenen Basisversion (dem aktuellen Release). Die Installation eines Updates kann einfach sein (z.B. Expandieren einer Datei und Speichern an
definierter Stelle) oder viele Schritte umfassen, die in einer bestimmten Reihenfolge
ausgeführt werden müssen (z.B. bei der Aktualisierung einer auf vielen Rechnern verteilten Anwendung).
Bei vielen Software-Produkten ist die Verteilung automatisiert.
Die Risiken einer erheblichen Änderung müssen identifiziert und bewertet werden. Evtl. muss eine Übergangsstrategie entwickelt werden; beispielsweise mit der Möglichkeit eines Roll-Backs.
17
Update-Arten
Je nach Umfang der Änderungen, unterscheiden wir die folgenden Update-Arten: Ein Patch ist ein Update, das bereitgestellt wird, um einen
einzelnen Fehler oder einige wenige Fehler zu korrigieren. Spezialfall: Emergency Maintenance, Hot-fix. Einer solchen
Feuerwehraktion muss eine systematische Wartung folgen! Ein Service Pack ist ein Update, in dem Fehlerkorrekturen und
verbesserte oder neue Funktionalität enthalten sind. Neben den Service Packs auch kumulative (Combo-) Upgrades,
die auch vorhergehende Upgrades enthalten.
18
Dokumentation von Updates
Zu jedem Update werden bestimmte Informationen benötigt: Voraussetzungen für die Installation Installationsschritte behobene und nicht behobene Fehler
Die Liste der in einem Update umgesetzten Problemmeldungen ist die Ausgangsbasis dieser Dokumentation.
19
22.3 Risiken, Probleme und Grundsätze der Wartung
Risiken und Probleme - 1
Wartung von Software ist schwierig, und wir besitzen kaum Methoden oder Werkzeuge, die uns (speziell) dabei wirklich helfen.
In der Studie von Dekleva (1992) wurden 19 Problembereiche ermittelt. Die wichtigsten fünf sind:
1. Changing priorities.Wartungstätigkeiten werden oft unterbrochen – andere Tätigkeiten sind wichtiger oder dringender – und müssen anschließend wieder aufgenommen werden.
2. Inadequate testing methods.Der Regressionstest nach der Wartung bereitet Probleme, weil spezielles Know-how fehlt und weil die Testfälle und Testdaten nicht ausreichen.
21
Risiken und Probleme - 2
3. Performance measurement difficulties.Oft ist nicht definiert, wie Wartung durchzuführen ist, Wartung ist nicht explizit geplant, die benötigten Aufwände werden weder geschätzt noch erhoben.
4. System documentation is incomplete.Oft ist die vorhandene Dokumentation unvollständig und nicht mehr aktuell. Rückgriff auf das Wissen von Personen: „walking documentation“
5. Adapting to a rapidly changing business environment.Der Anwendungskontext und die Anforderungen an viele Systeme ändern sich so schnell, dass kaum mehr Stabilität erreicht werden kann.
22
Risiken und Probleme - 3
Wir sehen zusätzlich die folgenden Probleme:
6. Wartungstätigkeiten müssen meist unter Zeitdruck stattfinden.→ Qualität der Architektur, der Dokumentation und des Codes sinkt.
7. Durch die Wartung entstehen neue Fehler.Die neuen Fehler werden zu einem beträchtlichen Teil nicht entdeckt, sondern mit der neuen Version ausgeliefert.
8. Wartung ist eine unbeliebte Tätigkeit.Wartung ist eine analytische, die Entwicklung eine konstruktive Tätigkeit. Die meisten Entwickler arbeiten lieber konstruktiv.
23
Grundsätze der Wartung - 1
Für die Wartung gelten – prinzipiell – alle Regeln und Grundsätze der Software-Entwicklung. Diese Feststellung ist richtig, aber nutzlos!
Folgende Grundsätze sollten immer beachtet werden: Änderungen nur, wenn
1. dafür ein erheblicher, dokumentierter Bedarf besteht,
2. auch die Folgen sorgfältig geklärt sind und
3. die Effekte anschließend seriös geprüft werden.
24
Grundsätze der Wartung - 2
Jede Wartung muss geplant werden, weil:
1. Aufwand ist hoch. Ist der Nutzen höher?
2. Prozess-Einhaltung ist essentiell für die Qualität (Einhaltung der notwendigen Schritte bei der Wartung).
3. Systematische Prüfung ist zwingend erforderlich. Lieber ein bekannter Fehler als ein fehlerhafter „quick fix“.
Die integrierte und die separate Dokumentation müssen nachgeführt werden. Auch das muss geprüft werden!
Es darf keine Grauzone zwischen den Verantwortlichkeiten für Entwicklung und Wartung entstehen.
25
22.4Die Wartungsorganisation
Gründe für Änderungen
Die Verwaltung der Problemmeldungen und Änderungen ist Aufgabe der Konfigurationsverwaltung (Change Management).
Für die administrative und vor allem für die finanzielle Behandlung ist der Grund der Änderung wichtig.
Situationen:
27
Ein Fehler muss behoben werden.Während der Gewährleistungsfrist Sache des Herstellers.
Neue / veränderte Anforderungen erfordern Erweiterung oder Änderung der Software.
Kosten werden dem Kunden berechnet.
Software muss reorganisiert, strukturell verbessert und nachdokumentiert werden. → Reengineering
Kosten sollten aus Rücklage gedeckt werden (Zuschlag zu den Wartungskosten, eine Art „Reengineering-Steuer“)
Problemmeldung und Änderungsantrag
Am Anfang jeder Änderung steht eine Problemmeldung (Software Problem Report, SPR). Change Request, CR, ist ein zu enger Begriff.
Jede Problemmeldung wird als Irrtum, als Fehlermeldung oder als Änderungswunsch eingestuft: Irrtum: Klienten informieren, evtl. das Handbuch verbessern Fehler: Entscheiden, ob /wann der Fehler behoben werden soll.
Alternative: Workaround. Änderungs- oder Erweiterungswunsch: Vorteile, Kosten und
Risiken vergleichen, Finanzierung prüfen.
28
SPR - Beispiel
29
Bearbeitungsschritte eines SPRs
1. Problemmeldung registrieren
2. Problemmeldung analysieren
3. Irrtum und Fehlbedienung ausschließen
4. Entscheidung des CCBs vorbereiten und treffen
5. Absender über die Entscheidung des CCBs informieren
6. Änderung durchführen und prüfen
7. Problemmeldung schließen
30
Die Wartungsingenieure
Eine Wartung durch die Entwickler hat Vorteile: Der Einarbeitungsaufwand ist geringer. Die Mitarbeiter können in Abstimmung mit laufenden Projekten
flexibel für die Wartungen eingesetzt werden.
Diesen Vorteilen stehen als Nachteile gegenüber: Die Entwickler sind selten motiviert, die geänderten Teile
nachzudokumentieren. Der Aufwand für die Wartung ist kaum zu ermitteln. Konflikte zwischen den Verantwortlichen für Entwicklung und
Wartung. Die Entwickler sind mit der Software vertraut, haben aber sonst
keine speziellen Voraussetzungen für eine kompetente Wartung. Wartungswissen wird nicht gesammelt und in Verbesserungen
umgesetzt.
31
Der Änderungsausschuss
Wird gebraucht, sobald das erste geprüfte Dokument der Entwicklung (d.h. Projektplan oder Spezifikation) freigegeben ist.
Die Zusammensetzung des CCB (evtl. Beteiligung des Kunden) hängt von der Situation und dem Stadium der Entwicklung ab.
Wartungsvertrag: Grenzfälle (gedeckt oder nicht?) können von einem Änderungsausschuss behandelt und entschieden werden.
Speziell wichtige Rolle des CCB in EDV-Projekten!
32
configuration control board (CCB) — A group of people responsible for evaluating and approving or disapproving proposed changes to configuration items, and for ensuring implementation of approved changes.
Syn: change control board.IEEE Std 610.12 (1990)
