Lebenzyklen von Software

1. Lebenzyklen von Software • Seminar im Grundstudium, WS 2002/03,Testen und Analysieren von Software • Referenten: • Mohammed Naoufal Adraoui • Nouredine Elmarga • Betreuer: Prof. em. Dr. H.-J. Hoffmann(Folie 1 geringfügig geändert durch H.-J. Hoffmann)

2. Lebenzyklen von Software • Ziel: • Klärung des Softwareentwicklungsprozesses und seiner Endprodukte auf Lebenszyklusebene • Vorstellung der Variantenvielfallt von Lebenszyklusmodellen • Abgrenzung des ingenieurmäßigen Vorgehens von Alternativen

3. Übersicht

4. Übersicht

5. Phasen der Softwareentwicklung • Den Zeitraum eines Software-Projekts von Planung über Realisierung und Einsatz bis hin zur Ausmusterung nennt man Lebenszyklus der Software. • Die verschiedenen Phasen eines Software-Projekts können unterschiedlich organisiert und untereinander verknüpft sein. Diese Struktur bezeichnet man als Phasenmodell oder auch Vorgehensmodell. • Ein Vorgehensmodell, das den gesamten Lebenszyklus eines Software-Produkts abdeckt, nennt man Lebenszyklusmodell (Life-Cycle-Modell). • Die klassischen Lebenszyklusmodelle umfassen mehrere Phasen

6. Phasen der Softwareentwicklung • 1) Problemdefinition • Während dieser Phase gibt der Auftraggeber des Software-Produkts dem Entwickler: • allgemeine Informationen zu den Voraussetzungen des Projekts und seinen Wünschen. • Beschreibung des Einsatzfelds, in dem die Software später genutzt werden soll. • Erstellung eines Benutzerprofils. D.h. es muss abgeklärt werden, in welcher Systemumgebung die Software eingesetzt werden soll.

7. Phasen der Softwareentwicklung 2) Anforderungsanalyse Hier beginnt der eigentliche Zyklus der Software-Entwicklung. Es werden alle Anforderungen des Auftraggebers gesammelt und analysiert. Dazu gehören Forderungen, die der Auftraggeber an die Qualität der Software stellt sowie Kontrollanforderungen, welche die Durchführung der Entwicklung betreffen (Abnahmebedingungen, Garantie, Schulungen etc.). Die gesammelten Anforderungen werden im besonderen auf Realisierbarkeit, Vollständigkeit und Widerspruchsfreiheit geprüft.

8. Phasen der Softwareentwicklung Die Praxis hat gezeigt, dass gerade die Prüfung der Vollständigkeit nur sehr schwer zu realisieren ist. Weiterhin werden mißverständliche projektbezogene Begriffe definiert, so dass alle Unklarheiten beseitigt werden können. Es werden Verfahren zur Einigung über Forderungen und zur Genehmigung von Änderungen erstellt. Spätere Änderungen oder Erweiterungen der Anforderungen können nur konform zu den vorher festgelegten Verfahren zugesichert werden.

9. Phasen der Softwareentwicklung • 3) Anforderungsspezifikation • Ziel: • Eine übereinstimmende Festlegung der Kundenanforderungen. • Benennung der für die Erstellung der Anforderungen verantwortlichen Personen. • Beschreibung den funktionalen Inhalt des zu implementierenden Systems.

10. Phasen der Softwareentwicklung • Dokumentation der Anforderungen: • Dazu gehören u.a: • Schnittstellenbeschreibungen • Anforderungen an die Performance und an den Ressourcenverbrauch.

11. Phasen der Softwareentwicklung Abschluß der Phase: Der Auftraggeber muß die Anforderungsspezifikation nochmals kontrollieren, damit sichergestellt wird, daß keine Unklarheiten über den Auftragsumfang bestehen. Am Ende der Phase existiert also ein verbindliches Dokument: die Anforderungsspezifikation.

12. Phasen der Softwareentwicklung • 4) Planung der SW-Entwicklung • In dieser Phase wird der Entwicklungsprozeß geplant. • Es werden für jede Aufgabe folgende Punkte berücksichtigt: • Termine • Verantwortungen • Vorgaben • benötigte Mittel und Ressourcen • Ergebnisse • Verifizierung

13. Phasen der Softwareentwicklung 5) EntwurfIn dieser Phase, dem Design der Software, wird eine Software Entwurfsbeschreibung erstellt.Die Software-Entwurfsbeschreibung dient der Umsetzung der spezifizierten Anforderungen des Auftraggebers in den Entwurf des Software-Projekts.Es wird der interne Aufbau dargelegt und das Gesamtkonzept verdeutlicht.Die Software-Entwurfsbeschreibung dient den Entwicklern der Software während aller Entwicklungsphasen als Nachschlagewerk, falls Unklarheiten über den Aufbau der Software bestehen.

14. Phasen der Softwareentwicklung 6) Abschluss Kodierung In der Kodierungs- oder Implementierungsphase wird das Software-Produkt nach der Software-Entwurfsbeschreibung erstellt. Test Die Testphase dient der Überprüfung, ob die Anforderungen des Auftraggebers durch das implementierte Software-Produkt erfüllt werden. Betrieb Das fertige Software-Produkt wird in dieser Phase beim Auftraggeber eingesetzt. Zu dieser Phase werden die Einführung und die Schulung der Benutzer gezählt.

15. Phasen der Softwareentwicklung • 7) Wartung • Eswerden alle Arbeiten am Software-Produkt, die dessen fortgesetzte Anwendung über einen längeren Zeitpunkt gewährleisten, durchgeführt. • Alle funktionellen und qualitativen Mängel werden beseitigt, die während der Betriebsphase entdeckt wurden. • Eine mögliche neue Version (Release) des Software-Produkt wird geplant : • Neuer durchlauf des Entwicklungsprozess • Übergang in die Phase der Problemdefinition

16. Modelle der Softwareentwicklung • 1)Sequentielles Modell • Es werden alle Aktivitäten auf eine Phase beschränkt. • Es werden phasenspezifische Zwischen- und Endergebnisse definiert. • Es erfolgt aber keine Aussage darüber, wie Ergebnisse in Verbindung stehen oder wie phasen-über-greifende Maßnahmen durchzuführen sind.

18. Wasserfall - Modell 2) Wasserfall - Modell Eine Erweiterung zum rein sequentiellen Modell ist das Wasserfallmodell [Boehm]. Es lassen sich aber die Ergebnisse einzelner Phasen im nachhinein verbessern. Dazu wird die Phase, welche unzufriedenstellende Ergebnisse produziert und alle nachfolgenden Phasen nochmals durchlaufen. Mit Hilfe dieses Modells ist also eine iterative Nachbesserung möglich

19. Wasserfall - Modell • Jede Aktivität ist in der richtigen Reihenfolge und in der vollen Breite vollständig durchzuführen • Am Ende jeder Aktivität steht ein fertiggestelltes Dokument: • Dokumenten-getriebenes Modell • Der Entwicklungsablauf ist sequentiell • Jede Aktivität muß beendet sein, bevor die nächste anfängt • Orientierung am top-down-Vorgehen • Einfach, verständlich und benötigt nur wenig Managementaufwand

20. Wasserfall - Modell

21. Wasserfall - Modell

22. Wasserfall - Modell • Nachteile • Nicht immer ist es sinnvoll: • alle Entwicklungsschritte in der vollen Breite und vollständig durchzuführen • alle Entwicklungsschritte sequentiell durchzuführen • Es besteht die Gefahr,daß die Dokumentation wichtiger wird als das eigentliche System • Trotz dieser Nachteile hat das wasserfall-Modell wesentlich zu einem disziplinierten, sichtbaren und kontrollierbaren Prozeßablauf beigetragen

23. V-Modell 3)V-Modell Als Erweiterung des Wasserfall-Modells führten die V-Modelle in der Qualitätssicherung eine Trennung zwischen konstruktiven und prüfenden Aktivitäten ein . So ist jeder Phase mit hauptsächlich konstruktiven Elementen eine Phase mit den entsprechenden prüfenden Aktivitäten zugeordnet. Diese Aufteilung lässt sich bildhaft in einem „V“ darstellen.

24. V-Modell

25. V-Modell • Verifikation und Validation der Teilprodukte sind Bestandteile des V-Modells • Verifikation: • • Überprüfung der Übereinstimmung zwischen einem Software-Produkt und seiner Spezifikation • »Wird ein korrektes Produkt entwickelt?« • Validation: • • Eignung bzw. der Wert eines Produktes bezogen auf seinen • Einsatzzweck • »Wird das richtige Produkt entwickelt?«.

26. V-Modell V-Modell besteht aus den vier Submodellen: • Systemerstellung (SE) • Qualitätssicherung (QS) • Konfigurationsmanagement (KM) • Projektmanagement (PM) Grundelemente: • Aktivitäten (Arbeitsanleitung) • Produkte (Produktmuster) • Rollen (notwendigen Erfahrung,Kenntnisse und Fähigkeit, um Aktivitäten durchzuführen)

27. V-Modell Ziel der Aktivitäten: • Erstellen eines Produktes • Ändern des Zustandes eines Produktes • Ändern des Inhalts eines Produktes

28. V-Modell • Allgemeinheitsanspruch • • V-Modell ist für (alle) unterschiedlichen Produktentwicklungen einsetzbar • • Anpassung geschieht durch Tailoring • Tailoring • – in Abhängigkeit vom Vorhaben werden Aktivitäten oder Produkte gestrichen • • Ausschreibungsrelevantes Tailoring • Vor Beginn werden die projektbedingt sinnvollen Aktivitäten und Produkte bestimmt. • • Technisches Tailoring • Während der Entwicklung werden situationsbedingt Aktivitäten oder Produkte gestrichen.

29. V-Modell V-Modell: Zustände von Produkten

30. V-Modell Vorteile • Gesamtmodell (SE, QS, KM, PM) • generisches Modell mit Tailoring • ermöglicht standardisierte Abwicklung • gut geeignet für große Projekte Nachteile • Vorgehensweisen für große eingebettete Systeme werden unkritisch auf andere übertragen • bei mittleren und kleineren Projekten tendenziell zu viel Zwischenprodukte und Bürokratie • ohne Werkzeuge nicht handhabbar • V-Modell ist nicht methodenneutral (Trennung in Funktions- und Datensicht)

32. Das Prototypen-Modell • Problematik • Auftraggeber ist oft nicht in der Lage, die Anforderungen an ein neues System explizit und/oder vollständig zu formulieren. • Während der Entwicklung ist oft eine wechselseitige Koordination zwischen Entwicklern und Anwendern erforderlich. • Software-Entwicklungsabteilungen ziehen sich nach der Definitionsphase vom Auftraggeber zurück. • Manchmal gibt es unterschiedliche Lösungsmöglichkeiten • Die Realisierbarkeit läßt sich manchmal theoretisch nicht garantieren.

33. Das Prototypen-Modell • Lösung • Ansatz von Protoypen • Konzept • Ein Prototyp dient dazu, • bestimmte Aspekte vor der Realisierung des Softwaresystems zu überprüfen. • z.b: Der Prototyp der Benutzungsoberfläche zeigt die vollständige Oberfläche des zukünftigen Systems, ohne daß bereits Funktionalität realisiert ist.

34. Das Prototypen-Modell • schnell von der Anforderungsanalyse zu einer Realisierung übergegangen; um • schnell die Machbarkeit zu testen • die Risiken zu kennen und zu minimieren • die Kreativität für andere Lösungsalternativen zu erhalten

35. Das Prototypen-Modell Arten • Demonstrationsprototyp (Akquisitionsprototyp, Wegwerf-Prototyp , rapid prototyping) • Prototyp im engeren Sinne (parallel zur Analyse, Klärung spezifischer Aspekte der Benutzerschnittstelle und Funktionalität) • Labormuster (Klärung konstruktionsbezogener Fragen und Alternativen, Technik, Architektur, Funktionalität, nicht für Endnutzer) • Pilotsystem (Kern des Produktes, ev. erweitert um Wegwerf-Komponenten, muß in der Zielumgebung lauffähig sein)

36. Das Prototypen-Modell Problem Analyse Prototyp Einführung Wartung Codierung

37. Das Prototypen-Modell • Bewertung • Vorteil • Reduzierung des Entwicklungsrisikos durch frühzeitigen Einsatz von Prototypen • Prototypen können sinnvoll in andere Vorgehensmodelle • integriert werden • Prototypen können heute durch geeignete Werkzeuge schnell erstellt werden • Prototyping verbessert die Planung von Software-Entwicklungen • Starke Rückkopplung mit dem Endbenutzer und dem Auftraggeber

38. Das Prototypen-Modell • Nachteil • Gefahr, daß ein »Wegwerf«-Prototyp Teil des Endprodukts • wird • Prototypen werden oft als Ersatz für die fehlende Dokumentation angesehen • Beschränkungen und Grenzen von Prototypen sind oft Unbekannt • nicht geeignet für große oder komplexe Produkte; Weg-Werf-Prototypen sind schon „live gegangen“ und verursachen in der Folge einen enormen Wartungsaufwand

39. Das evolutionäre Modell Charakteristika: • Produkt wird allmählich, stufenweise entwickelt • Erfahrungen von Benutzern und Entwicklern können einfließen • Pflegeaktivitäten integriert, werden als Erstellung einer weiteren Version verstanden • gut geeignet, wenn der Auftraggeber die Anforderungen nicht vollständig überblickt (“I can’t tell you what I want, but I’ll know it when I see it.”) • Entwicklung code-getrieben, Konzentration auf lauffähige Teilprodukte wird auch als “versioning” bezeichnet

40. Das evolutionäre Modell Evolutionäres Modell

41. Das evolutionäre Modell Bewertung Vorteile • einsatzfähige Teillösungen in kürzeren Zeitabständen • kann gut mit Prototypenmodell kombiniert werden • ermöglicht Feedback von Anwendungserfahrung • Produkt wird in kleinen Arbeitsschritten entwickelt, dadurch Entwicklung Schritt für Schritt korrigierbar und neu definierbar

42. Das evolutionäre Modell Nachteile • Gefahr, daß in nachfolgenden Versionen, die komplette Systemarchitektur überarbeitet werden muß, weil in der Nullversion Kernanforderungen übersehen wurden • Gefahr, daß Nullversion nicht flexibel genug ist für die Anpassung an ungeplante Evolutionspfade

43. Das inkrementelle Modell Charakteristika: • Anforderungen werden vollständig erfaßt • nur ein Teil der Anforderungen wird im ersten Schritt implementiert • die Architektur berücksichtig alle Anforderungen • der Auftraggeber erhält schnell ein erstes einsatzfähiges System • die Erweiterungen passen zum Kernsystem, die Schnittstellen sind vorab bekannt

44. Das objektorientierte Modell • Charakteristika: • Es unterscheidet sich in den ersten beiden Phasen, Problemanalyse und Systemspezifikation, überhaupt nicht von den klassischen Vorgehensmodellen. • Erst auf spätere Phasen hat der Einsatz objektorientierter Techniken, bei denen ja die Implementierung entscheidend durch Zusammenfügen bereits existierender Bausteine geprägt ist, folgende Konsequenzen:

45. Das objektorientierte Modell • Integration der Wiederverwendung von: • – OOA-Modellen(Subsysteme,Klassen, Klassenhierarchien) • – technischen Entwürfen (OOD-Modelle) • – implementierten Klassen • Gestaltung der Software in allen bisherigen Modellen ausschließlich top down • im objektorientierten Modell Kombination aus top down und bottom up • Tendenz von Eigenentwicklung zu Wiederverwendung

47. Das objektorientierte Modell Bewertung Vorteile: • Verbesserung der Produktivität und Qualität • Konzentration auf eigene Stärken,Nutzung von Halbfabrikaten (Senkung der Fertigungstiefe)

48. Das objektorientierte Modell Nachteile: • voll nutzbar nur bei objektorientierten Methoden/Technik • geeignete Infrastruktur (Wiederverwendungsarchiv) notwendig • Organisatorische und organisationskulturelle Voraussetzungen für Wiederverwendung müssen gegeben sein (z.B: muß die Herstellung und Verwendung wiederverwendbarer Komponenten belohnt werden) • technische Probleme (z.B. Kompatibilitätsprobleme in Klassenbibliotheken)

49. Das nebenläufige Modell Ziel: • Verkürzung der time to market durch Parallelisierung bzw. starke Überlappung Charakteristika • Kooperation verschiedener Personen und Gruppen an gemeinsamer Problemlösung wird gefördert • Zeitverzögerung reduziert durch – Parallelisierung – Minimierung des Ausprobierens und Begrenzung der Improvisation (right the first time vs. redo until right beim Prototyping) – Reduktion von Wartezeiten zwischenarbeitsorganisatorisch verbundenen Aktivitäten

50. Das nebenläufige Modell • Erfahrung beteiligter Gruppen wird frühzeitig zusammengebracht • Ziel schnell das vollständige Produkt bereitzustellen (im Gegensatz zu evolutionär/inkrementell)