Wartung und (Re-) Engineering

Die Entwicklung, Pflege und Einsatz qualitativ hochwertiger Software unter Einstz von:

• wissenschaftlichen Methoden,

• wirtschaftl. Prinzipien,

• geplanten Vorgehensmodellen,

• Werkzeugen und

• quantifizierbaren Zielen.

Qualität ist der Grad, in dem ein System, eine Komponente oder ein Prozess die Kundenerwartungen und Kundenbedürfnisse erfüllt.

Softwarequalität ist die Gesamtheit der Funktionalitäten und Merkmale eines Softwareprodukts, die sich auf dessen Eignung beziehen, festgelegte oder vorausgesetzte Erfordernisse zu erfüllen.

• Zuverlässigkeit (Reliability)

• Benutzbarkeit (Usability)

• Effizienz (Efficiency)

• Änderbarkeit (Maintainability)

• Übertragbarkeit (Portability)

• Qualitätszielbestimmung

• quantitative Qualitätssicherung

• konstruktive Qualitätssicherung

• integrierte, frühzeitige analytische Qualitätssicherung

• unabhängige Qualitätssicherung

• analysierende Verfahren (Review, statische Analysen, (formale) Verifikation) -> Prüfen der Eigenschaften

• testende Verfahren (dynamische Tests, symbolische Tests) -> Ausführen mit konkreter Eigabe

• Machbarkeitsstudie

• Anforderungsanalyse

• Systementwurf

• Codieren und Modultest

• Integrations- und Systemtests

• Auslieferung und Installation

• Wartung

• Problem informell und abstrahiert beschreiben

• Verschiedene Lösungsansätze erarbeiten

• Kostenschätzung durchführen

• Angebotserstellung

• Lastenheft = (sehr) grobes Pflichtenheft

• Projektkalkulation

• Projektplan

• Angebot an Auftraggeber

• Genaue Festlegung der Systemeigenschaften wie Funktionalität, Leistung, Benutzungsschnittstelle, Portierbarkeit, … im Pflichtenheft

• Bestimmen von Testfällen

• Festlegung erforderlicher Dokumentationsdokumente

• Pflichtenheft = Anforderungsanalysedokument

• Akzeptanztestplan

• Benutzungshandbuch (1-te Version)

• Programmieren-im-Großen = Entwicklung eines Bauplans

• Grobentwurf, der System in Teilsysteme/Module zerlegt

• Auswahl bereits existierender Software-Bibliotheken, Rahmenwerke, …

• Feinentwurf, der Modulschnittstellen und Algorithmen vorgib

• Entwurfsdokument mit Software-Bauplan

• detailierte(re) Testpläne

• Programmieren-im-Kleinen = Implementierung einzelner Module

• Einhaltung von Programmierrichtlinien

• Code-Inspektionen kritischer Modulteile (Walkthroughs)

• Test der erstellten Module

• Menge realisierter Module

• Implementierungsberichte (Abweichungen vom Entwurf, Zeitplan, … )

• technische Dokumentation einzelner Module

• Testprotokolle

• Systemintegration = Zusammenbau der Modul

• Gesamtsystemtest in Entwicklungsorganisation durch Kunden (alpha-Test)

• Fertigstellung der Dokumentation

• fertiges System

• Benutzerhandbuch

• technische Dokumentation

• Testprotokolle

• Auslieferung an ausgewählte (Pilot-)Benutzer (beta-Test)

• Auslieferung an alle Benutzer

• Schulung der Benutzer

• fertiges System

• Akzeptanztestdokument

• ca. 20% Fehler beheben (corrective maintenance)

• ca. 20% Anpassungen durchführen (adaptive maintenance)

• ca. 50% Verbesserungen vornehmen (perfective maintenance)

• Software-Problemberichte (bug reports)

• Software-Änderungsvorschläge

• neue Software-Versionen

• zu Projektbeginn nur ungenaue Kosten- u. Ressourcenschätzungen möglich

• Pflichtenheft kann nie Umgang mit fertigem System ersetzen, das erste sehr spät entsteht (Risikomaximierung)

• Es gibt Fälle, in denen zu Projektbeginn kein vollständiges Pflichtenheft erstellt werden kann (weil Anforderungen nicht klar)

• Anforderungen werden früh eingefroren, notwendiger Wandel (aufgrund organisatorischer, politischer, technischer, … Änderungen) nicht eingeplant

• strikte Phaseneinteilung ist unrealistisch (Rückgriffe sind notwendig)

• Wartung mit ca. 60% des Gesamtaufwandes ist eine Phase

• Systemanforderungsanalyse: Gesamtsystem einschließlich aller Nicht-DV-Komponenten wird beschrieben (fachliche Anforderungen und Risikoanalyse)

• Systementwurf: System wird in technische Komponenten (Subsysteme) zerlegt, also die Grobarchitektur des Systems definiert

• Softwareanforderungsanalyse: technischen Anforderungen an die bereits identifizierten Komponenten werden definiert

• Softwaregrobentwurf: Softwarearchitektur wird bis auf Modulebene festgelegt

• Softwarefeinentwurf: Details einzelner Module werden festgelegt

• Softwareimplementierung: wie beim Wasserfallmodell (inklusive Modultest)

• Software-/Systemintegration: schrittweise Integration und Test der verschiedenen Systemanteile

• Überleitung in die Nutzung: entspricht Auslieferung bei Wasserfallmodell

Das fertige Softwaresystem ist Ergebnis des Entwicklungsprozesses. Ausgehend von Anforderungsanalyse (Machbarkeitsstudie) wird ein neues Softwaresystem entwickel:

Anforderungen -> Design -> Code

Das vorhandene Software-System ist Ausgangspunkt der Analyse. Ausgehend von existierender Implementierung wird meist „nur“ das Design rekonstruiert und dokumentiert. Es wird (noch) nicht das betrachtete System modifiziert.

Anforderung <- Design <- Code

Sanierung eines vorhandenen Software-Systems bzw. seiner Neuimplementierung. Dabei werden die Ergebnisse des Reverse Engineerings als Ausgangspunkt genommen.

Anforderungen <- Design -> Code