V-Modell XT - Motivation

1. V-Modell XT - Motivation • CHAOS-Report: „Erfolgsstatistik“ von Software-Projekten Software Engineering WS 2006 / 2007

2. V-Modell XT - Motivation • Negativbeispiele: • Mautdebakel mit Toll-Collect • FISCUS droht nach 14! Jahren zu scheitern • Online Jobsuche des Arbeitsamtes • Absturz einer Ariane 5 Trägerrakete 1996 • Absturz einer Marssonde wegen Umrechnung von Fuß in m • Softwarefehler in C65-Mobiltelefonen von Siemens (Personenschäden) • . . . • Fazit: Notwendigkeit der Anwendung von Vorgehensmodellen (Widerspruch zur Realität!!!) Software Engineering WS 2006 / 2007

3. V-Modell XT - Historie • V-Modell 92: • 1986 vom Bundesamt für Wehrtechnik und Beschaffung (BWB) auf Auftrag des Bundesverteidigungsministeriums initiiert • Ziele: • Verbesserung der Qualität von Software • Verbesserung der Steuerbarkeit des Entwicklungsprozesses • Erhöhung der Transparenz des Entwicklungsprozesses • Nachvollziehbarkeit der zu erzeugenden Produkte • Entwicklung eines neuen Standards, da bestehende Lösungsansätze nur Teilaspekte der Softwareentwicklung abdeckten • 1992 V-Modell 92 vom Bundesinnenministerium als Entwicklungsstandard für IT-Systeme des Bundes für alle Behörden erlassen Software Engineering WS 2006 / 2007

4. V-Modell XT - Historie • V-Modell 97 • Beginn: 1994 aufgrund der zweijährigen Erfahrungen und der erkannten Probleme: • bisher keine dynamische Gestaltung von Prozessen • V-Modell war bisher nur für SW-Projekte geeignet • bisher streng technisch orientierte Systemsicht •  V-Modell 97 • Einsatz auch in großen, mittleren und kleinen Unternehmen Software Engineering WS 2006 / 2007

5. V-Modell XT - Historie • V-Modell XT • Beginn 2002: Weiterentwicklung (WEIT) durch TU München, TU Kaiserslautern + Industriepartner (Siemens, 4Soft, EADS,...) • Präsentation der Version 1.0 am 4. Februar 2005 • Änderung der Namenskonvention: Anstelle der Jahreszahl: „XT“ (eXtreme Tailoring) • stetiger Weiterentwicklungsprozess, um aktuelle Innovationen der IT-Branche berücksichtigen zu können • Pflege erfolgt in zweistufigem Modell: („Anwender des Entwicklungsstandards der öffentlichen Verwaltung“ ANSSTAND e.V) • nicht Strukturbetreffende Änderungen: Änderungsvorschläge werden gesammelt; Änderungskonferenz (ÄKO) entscheidet, ob Änderungen übernommen werden. • Strukturelle Änderungen: gesonderter Fortschreibungsprozess wird gestartet Software Engineering WS 2006 / 2007

6. V-Modell XT - Ziele • neuester Stand: technologische und methodische Weiterentwicklung • Erweiterung des Anwendungsbereiches und Ausweitung zum allgemeinen Standard • Bessere Unterstützung der Anwendbarkeit, Skalierbarkeit sowie Änder- und Erweiterbarkeit • Anpassung an aktuelle Vorschriften und Normen • Effizienzsteigerung und Akzeptanzerhöhung durch Verringerung der Komplexität Software Engineering WS 2006 / 2007

7. V-Modell XT - Grundstruktur • Gesamtstruktur • Änderung der bisher starren Struktur zu einer modularen, bausteinbasierten Struktur • Festlegung der Aufgaben der Projektbeteiligten: Welches Projekt wird von wem zu welchem Zeitpunkt erstellt? • Anpassung: benötigte Komponenten können ausgewählt oder weggelassen werden Dezimierung des Aufwandes • . . . Software Engineering WS 2006 / 2007

8. V-Modell XT - Grundstruktur • . . . • Ziel- und Ergebnisorientiertes vorgehen: • Produkte als zentrale Projektergebnisse stehen im Mittelpunkt • Projektdurchführungsstrategien und Entscheidungspunkte bestimmen die Reihenfolge der Produktfertigstellung und damit die grundlegende Struktur des Projektverlaufes • Projektplanung und –steuerung erfolgt auf Basis der Bearbeitung und Fertigstellung von Produkten • Für jedes Produkt gibt es eine verantwortliche Rolle, der im konkreten Fall eine Person (Organisationseinheit) zugeordnet wird. • Produktqualität ist durch definierte Anforderungen an das Produkt und explizite Beschreibungen der Abhängigkeiten zu anderen Produkten überprüfbar Software Engineering WS 2006 / 2007

9. V-Modell XT - Grundstruktur • erreichte Ziele und Grenzen • Minimierung der Projektrisiken durch Standardisierung • Steuerung der Qualität des Produktes und der Zwischenergebnisse • Kooperation zwischen Auftraggeber und –nehmer • Auswahlmöglichkeit zwischen verschiedenen Modulen und Strategien verringert die Komplexität und erhöht die Verwendbarkeit • Unterstützung der frühen Planungs- und Vorbereitungsphasen • Unterstützung des kompletten Systemlebenszyklusses (von Planung bis Außerbetriebnhame) • „make or buy“-Diskussion wird nicht behandelt • Vergabe von Unteraufträgen und der Betrieb und die Instandhaltung von Systemen werden noch nicht vollständig abgedeckt. Software Engineering WS 2006 / 2007

10. V-Modell XT - Grundstruktur • Rollenkonzept • Aufgabe im Projekt werden von abstrakten Rollen übernommen • bisher 20 Rollen definiert (z. B. Projektleiter, Systemarchitekt) und beschrieben Erleichtert Zuordnung • Rollen müssen mit Personen bzw. Organisationseinheiten besetzt werden • Unterscheidung in „verantwortlich“ und „mitwirkend“ Software Engineering WS 2006 / 2007

11. V-Modell XT - Grundstruktur • Projektspezifische Anpassung (Tailoring) • Tailoring: maßschneidern • hier: Anpassung an das konkrete Projekt • V-Modell XT ist „generischer“ Entwicklungsstandard • Tailoring erfolgt zu Beginn • nur noch die wichtigen Bestandteile bleiben übrig • Unterstützung durch Open Source Tool: „V-Modell XT-Projektassistent“ • Abfrage von Merkmalen liefert inhaltlich an das spezifische Projekt angepasste Dokumentation Software Engineering WS 2006 / 2007

12. V-Modell XT • erste Anpassungsmaßnahme: Auswahl des Projekttyps aus drei Möglichkeiten • Systementwicklungsprojekt eines Auftraggebers • Systementwicklungsprojekt eines Auftragnehmers • Einführung und Pflege eines organisationsspezifischen Vorgehensmodells Software Engineering WS 2006 / 2007

13. V-Modell XT • zweite Maßnahme: Anwendungsprofil bestimmen durch Festlegen der Projektmerkmale: • Projektgegenstand (z. B. SW-Projekt) • Projektrolle (z.B. Auftragnehmer) • Systemlebenszyklusabschnitt (z.B. Wartung und Pflege eines Systems) • kaufmännisches Projektmanagement (+ Kostenplanung) • quantitative Projektkennzahlen (+ Metriken und Messung von Kennzahlen) • Fertigprodukte (+ Evaluierung und Benutzung von Fertigprodukten) • Benutzerschnittstelle (wenn erfolgsrelevant) • Safety und Security (für sicherheitsrelevante Projekte) • hohe Realisierungsrisiken (für Sonderrisiken) Software Engineering WS 2006 / 2007

14. V-Modell XT • Vorgehensbausteine • modularer Aufbau durch Vorgehensbausteine realisiert • Vorgehensbaustein = konkrete inhaltlich zusammengehörende Aufgabenstellung im Projekt (z.B. Qualitätssicherung, Systemerstellung) • inhaltlich stark verwandte Aktivitäten und Produkte werden gruppiert (Farbe!) • “Landkarte“ Software Engineering WS 2006 / 2007

15. V-Modell XT - Welt • V-Modell XT Landkarte Software Engineering WS 2006 / 2007

16. V-Modell XT • V-Modell-Kern: obligatorische Bausteine (dick umrandet): • Projektmanagement • Konfigurationsmanagement • Problem- und Änderungsmanagement • Qualitätssicherung • Pfeile definieren Beziehungen zwischen den Bausteinen • gefüllte Pfeilspitze markiert einen obligatorische Baustein • nicht gefüllte Pfeilspitzen markiert eine Auswahlmöglichkeit (z.B. „Benutzbarkeit und Ergonomie“ erfordert Modul • HW-Entwicklung, oder • Systemerstellung, oder • SW-Entwicklung Software Engineering WS 2006 / 2007

17. V-Modell XT • dritte Maßnahme: Projektdurchführungsstrategien • Festlegung des inhaltlichen und zeitlichen Verlaufs Software Engineering WS 2006 / 2007

18. V-Modell XT • Durchführungsstrategie wird festgelegt durch: • Projekttyp • Systemlebenszyklusausschnitt (Projektmerkmale) • Durchführungsstrategie • Vergabe und Durchführung von Systementwicklungsprojekten (AG) • inkrementelle Systementwicklung (AN) • komponentenbasierte Systementwicklung (AN) • agile Systementwicklung (AN) • Wartung und Pflege (AN) • Weiterentwicklung und Migration von Altsystemen (AN) • Einführung und Pflege eines organisationsspezifischen Vorgehensmodells Software Engineering WS 2006 / 2007

19. V-Modell XT • vierte Maßnahme: Entscheidungspunkte und Projektfortschrittsstufen • Durchführungsstrategie gibt Reihenfolge für die Projektfortschrittsstufen an • Stufe entspricht Teilabschnitt im Projektverlauf • Entscheidungspunkte (vgl. Meilenstein): Entscheidung über den Projektverlauf • Evaluierung des Projektschrittes • Freigabe für den nächsten Schritt • Verbesserungsprozess (KVP ): • Entscheidungspunkt wird neu evaluiert • vorherige Stufe wird neu durchlaufen • Projekt wird komplett neu konzipiert • Projekt wird abgebrochen Software Engineering WS 2006 / 2007

20. V-Modell XT - Entscheidungspunkte • Entscheidungspunkte der Projektdurchführungsstrategien Software Engineering WS 2006 / 2007

21. V-Modell XT Software Engineering WS 2006 / 2007

22. V-Modell XT - Assistent • Der Projektassistent Software Engineering WS 2006 / 2007