Software-Lebenszyklus Inhalt Vorgehensmodell/Phasenplan Wasserfallmodell WAS-Beschreibung WIE-Beschreibung Weitere Phasenmodelle: Spiral-Modell, V-Modell, RUP Extreme Programming SW-Qualitätssicherung (SW-QS) Qualitätskosten (aus Projektsicht) Konstruktive/analytische QS Qualitätsmodell / Qualitätsmerkmale Review Beispiel: Qualitätsmodell für Pflegbarkeit Christoph Riewerts Seite 1
Wie heißt dieses Vorgehensmodell? Phasenmodell 2 Entwicklungsphasen zur Beschreibung, was realisiert werden soll. Studie Analyse 2 Entwicklungsphasen zur Beschreibung, wie das Produkt realisiert werden soll Entwurf Implementierung Betrieb Seite 2
Phasenmodell Tätigkeiten in der Phase Studie (Projekt-Vorphase): Definition der Projektziele Situationsanalyse (grobe Darstellung) Darstellung des SOLL-Ablaufs Gegenüberstellung der SOLL/IST- Abläufe Vorstellung der Projektfinanzierung Terminvorstellungen für den Projektablauf Tätigkeiten in der Phase Analyse : Systemabgrenzung Zielsetzung Zustandsanalyse (fein) Analyse der Datenflüsse und Funktionen (funktionsorientierter Ansatz) Analyse der Kontrollflüsse und Ablaufbedingungen (ablauforientierter Ansatz) Analyse der Daten und Datenbeziehungen (datenorientierter Ansatz) Qualitätsziele Verifikation der Analyseergebnisse (mittels eines CASE-Tools) Seite 3
Phasenmodell Tätigkeiten in der Phase Entwurf : Festlegen der Software-Architektur (Client-Server, Kommunikation, Schnittstellen, ) Festlegen der Hardware- Konfiguration Festlegen der modularen Software- Struktur Entwurf der Benutzeroberfläche (Layout, Navigation) ggfs. Datenbankentwurf Entwurf des Testplans Tätigkeiten in der Phase Implementierung : Übersetzen der Module und Komponenten Modul- und Komponententest Integrationstest Erstellen der Benutzerdokumentation: Systembeschreibung (für die Weiterentwicklung) Bedienungsanleitung (für die Benutzung) Betriebsanleitung (für das Rechenzentrum) Tätigkeiten in der Phase Betrieb : Inbetriebnahme, Abnahme, Störungs- und Fehlerbeseitigung, Schulung der Benutzer, Weiterentwicklung Seite 4
Weitere Phasenmodelle: Spiral-Modell iterativer Entwicklungsprozess Definition von Prototypen V-Modell: Phasenmodell seit 1986 in Deutschland entwickelt (von mehreren Hochschulen) vorgesehen für IT-Projekte der öffentlichen Hand, jedoch auch in der Privatwirtschaft eingesetzt. keine strikte zeitliche Abfolge der Aktivitäten RUP (Rational Unified Process) von der IBM entwickelt objektorientiertes Vorgehensmodell benutzt UML (Unified Modeling Language) Seite 5
Spiral-Modell Seite 6
V-Modell (1von2) Anforderungsdefinition Anwendungsszenarien Abnahmetest Validierung Grobentwurf Testfälle Systemtest Verifikation Feinentwurf Testfälle Integrationstest Modulimplementation Testfälle Modultest Seite 7
V-Modell (2von2) Projekt planen und kontrollieren PM Voraussetzungen schaffen und Softwareentwicklungsumgebung (SEU) bereitstellen Plandaten Istdaten SEU Istdaten SEU SEU Plandaten Plandaten Plandaten Istdaten Istdaten SEU QS- Anforderungen vorgeben SE Produkt entwickeln Produktstruktur planen Konfigurationsstruktur QS- Ergebnis Produkte prüfen QS QS- Anforderung Produkt Rechte Produkt Produkte/ Rechte verwalten KM Seite 8
RUP Process Workflows Inception Elaboration Construction Transition Business Modeling Requirements Analysis & Design Implementation Test Deployment Supporting Workflows Configuration Mgmt Management Environment Preliminary Iteration(s) #1 #2 #n #n+1 Iterationen umfassen jeweils alle Workflows einer Phase #n+2 #m #m+1 Seite 9
Übung: Begriffe einordnen in die WAS- oder WIE-Phase Seite 10
Extreme Programming (XP) XP ist gedacht für kleinere Projekte mit unklaren und sich immer wieder ändernden Anforderungen Das Team besteht aus 2-12 Mitgliedern (Kunde(!), Programmierer, Manager, Trainer, Verfolger) Der Kunde ist fester Bestandteil des Teams. Er definiert, priorisiert und entwickelt die Testfälle für die User Stories Die Programmierung (incl. Test) erfolgt in Paaren (pair-programming) mit Rotation der Partner Gemeinsame Verantwortung der Gruppe für den Code: Jeder kann Änderungen am Code vornehmen Test Driven Development (TDD): Alle Tests sollten möglichst automatisch ablaufen Entwickler schreiben Unit Tests, Kunden schreiben funktionale Tests Zuerst Testfall entwerfen, dann Funktionalitäten solange implementieren, bis Testfall erfolgreich Testfall als Spezifikation der Anforderungen Test als Kriterium für Anforderungserfüllung Seite 11
Extreme Programming Der Prozess ist in monatliche Releases gegliedert, die wiederum in wöchentliche Iterationen von mehreren Tasks Die sequentielle Integration garantiert zu jeder Zeit ein lauffähiges System Die Entscheidungskompetenz liegt bei den Entwicklern und beim Kunden. Das Management zeigt lediglich zu lösende Probleme und Fortschritte des Teams auf Strenge Einhaltung von Richtlinien: simple design, develop for today, refactoring Die Teammitglieder müssen erfahren und kommunikativ sein XP geht von einer 40 Stunden Woche aus. Überstunden sollten überflüssig sein Seite 12
Extreme Programming Vorteile von XP Vollständige Erfüllung der Anforderungen wegen der engen Kopplung von Auftraggeber und Auftragnehmer Gute Termineinhaltung wegen des strengen Zeitrasters Hohe Qualität wegen der umfangreichen Tests und der Richtlinien Große Motivation des Teams wegen Entscheidungskompetenz und Verantwortungsübernahme Nachteile von XP Das Fehlen einer expliziten Spezifikation und einer Entwurfsdokumentation wird häufig kritisiert spätere Änderungen sind nur unvollständig berücksichtigt Das gemeinsame Code-Eigentum kann zu Problemen führen Es gibt keine empirische Untersuchung, die belegt, dass XP anderen Vorgehensweisen überlegen ist Seite 13