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.

Präsentation zum Thema: "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."—  Präsentation transkript:

1 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

2 Einleitung Wartung beansprucht von allen Tätigkeiten das größte Budget. kennzeichnet den Normalzustand einer Software. 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.

3 22.1 Begriff und Taxonomie der Software-Wartung

4 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.

5 Definitionen des Wartungsbegriffs - 1
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 (1990) Aber: die Definition der Wartung als Phase verschleiert, dass es schon vor Auslieferung Wartung, noch nach Auslieferung Entwicklung gibt.

6 Definitionen des Wartungsbegriffs - 2
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) 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.

7 Arten der Wartung - 1 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 (1990) Darin sind nur die Begriffe korrektive Wartung (= Korrektur) und adaptive Wartung (= Anpassung) klar.

8 Arten der Wartung - 2 Auch hier halten wir teilweise andere Begriffe und Kategorien für sinnvoll. 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. ?? Problem: Verbesserung und Prävention lassen sich nicht von Anpassung und Korrektur unterscheiden! War die Spezifikation verletzt? Ja: → Korrektur Nein: → Anpassung

9 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 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.

10 Die Kosten der Wartung Studie Aufwand für Wartung Zelkowitz, Shaw, Gannon (1979) 67% Lientz, Swanson (1980) 48% Abran, Nguyenkim (1991) 55% 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.

11 Verteilung über die Arten der Wartung
Wartungsart Lientz, Swanson (1980) Sneed (1987) van Vliet (2000) Korrektur 17  % 25  % 21  % Anpassung / Erweiterung 18  % 20  % 40  % Verbesserung / Prävention 65  % 15  % 50  % 4  % Achtung, sehr unterschiedliches Verständnis von „Verbesserung“! Folgerung: Anpassung und Erweiterung schlucken den Löwenanteil der Wartungskosten. An zweiter Stelle steht die Korrektur.

12 22.2 Inhalt und Ablauf der Wartung

13 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.

14 Ein Modell der Wartung - 1
Korrektur, Anpassung, Verbesserung

15 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.

16 Schritte der Wartung - 2 Die Wartung erfordert die folgenden Schritte:
Der Ausgangszustand wird (spätestens jetzt) präzise dokumentiert und archiviert. Der zu modifizierende Teil wird identifiziert; er sollte so klein wie möglich sein. Die übrige Software vor Änderungen schützen! 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)! Die zu ändernden Komponenten werden aus der Konfigurationsverwaltung entnommen, bearbeitet und lokal geprüft. Wenn sie OK sind, zurück in die Konfig.-verwaltung. Die veränderten Komponenten werden integriert und getestet. Dabei kommt vor allem der Regressionstest zum Zuge. Der neue Zustand wird dokumentiert und wiederum archiviert. Der benötigte Aufwand für die Wartung wird aufgezeichnet.

17 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.

18 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.

19 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.

20 22.3 Risiken, Probleme und Grundsätze der Wartung

21 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: Changing priorities. Wartungstätigkeiten werden oft unterbrochen – andere Tätigkeiten sind wichtiger oder dringender – und müssen anschließend wieder aufgenommen werden. Inadequate testing methods. Der Regressionstest nach der Wartung bereitet Probleme, weil spezielles Know-how fehlt und weil die Testfälle und Testdaten nicht ausreichen.

22 Risiken und Probleme - 2 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. System documentation is incomplete. Oft ist die vorhandene Dokumentation unvollständig und nicht mehr aktuell. Rückgriff auf das Wissen von Personen: „walking documentation“ 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.

23 Risiken und Probleme - 3 Wir sehen zusätzlich die folgenden Probleme:
Wartungstätigkeiten müssen meist unter Zeitdruck stattfinden. → Qualität der Architektur, der Dokumentation und des Codes sinkt. Durch die Wartung entstehen neue Fehler. Die neuen Fehler werden zu einem beträchtlichen Teil nicht entdeckt, sondern mit der neuen Version ausgeliefert. Wartung ist eine unbeliebte Tätigkeit. Wartung ist eine analytische, die Entwicklung eine konstruktive Tätigkeit. Die meisten Entwickler arbeiten lieber konstruktiv.

24 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 dafür ein erheblicher, dokumentierter Bedarf besteht, auch die Folgen sorgfältig geklärt sind und die Effekte anschließend seriös geprüft werden.

25 Grundsätze der Wartung - 2
Jede Wartung muss geplant werden, weil: Aufwand ist hoch. Ist der Nutzen höher? Prozess-Einhaltung ist essentiell für die Qualität (Einhaltung der notwendigen Schritte bei der Wartung). 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.

26 22.4 Die Wartungsorganisation

27 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: 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“)

28 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.

29 SPR - Beispiel

30 Bearbeitungsschritte eines SPRs
Problemmeldung registrieren Problemmeldung analysieren Irrtum und Fehlbedienung ausschließen Entscheidung des CCBs vorbereiten und treffen Absender über die Entscheidung des CCBs informieren Änderung durchführen und prüfen Problemmeldung schließen

31 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.

32 Der Änderungsausschuss
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 (1990) 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!