Kapitel 8 Qualitäts und Vorgehensmodelle Literatur Wolf Zimmermann Softwaretechnik VDI-Norm 2221: Methodik zum Entwickeln und Konstruieren technischer Systeme und Produkte, VDI-Handbuch Konstruktion, Beuth-Verlag, 1993 Reinhard Höhn, Stephan Höppner: Das V-Modell-XT. Springer 2008. Wolf Zimmermann 640 Wolf Zimmermann 641 Inhalt 8.1 Qualitätssicherung Ziele Ziele Verständnis für Softwareentwicklung im Großen Kennenlernen der wichtigsten Qualitätsmodelle Kennenlernen und beurteilen verschiedener Vorgehensmodelle 1 Qualitätssicherung 2 Vorgehensmodelle Vermeidung von Fehlern und Defiziten in Softwareprodukten Einhaltung gesetzlicher Vorgaben Minimierung des Produkthaftungsrisikos Schutz vor Angriffen auf das Softwareprodukt Auch Minimierung des eigenen Haftungsrisikos? Maßnahmen Einführung und Zertifizierung nach ISO 9000 für Qualitätssicherungsmaßnahmen Qualitätssicherungsstufen nach CMMI (Capability Matury Model Integration) oder ISO 15504 Wolf Zimmermann 642 Einführung und Zertifizierung nach ISO 27000 für Schutzmaßnahmen Wolf Zimmermann 643
SOx Der Sarbanes-Oxley Act von 2002 Motivation Haftungsgesetz in USA für Manager als Reaktion auf den Enron-Skandal Gilt für alle Unternehmen, die in USA wirtschaftlich tätig sind. Wichtig für Software? Section 302: That the CEO and CFO are responsible for the maintenance and regular evaluation of disclosure controls and procedures designed to ensure that information required in SEC filings is timely, accurat and complete. This requires the certification is evidenced by signatures of the CEO and CFO Section 404: That the company s annual report includes an internal control report containing an assessment of the company s internal control system that must in turn be reported on by the external auditors. Implikationen Keine Aussage nach meinem besten Wissen Persönliche Haftung des CEO, auch wenn er nichts für Fehler und Defizite kann Prozesse für Evaluation und Berichtspflicht über die Effektivität interner Maßnahmen Eingeführte IT-Systeme müssen korrekt funktionieren und ständig kontrolliert werden Qualitätssicherung: Die ISO-9000 Norm Ziele von ISO-9000 Qualitätskontrolle des Produktes Qualitätskontrolle des Herstellungsprozesses Auch für Zulieferer von Teilprodukten ISO-9000 ist allgemeiner übergeordneter, organisatorischer Rahmen zur Qualitätssicherung materieller und immaterieller Produkte ISO-9000 legt keine spezifischen Qualitätssicherungsmaßnahmen fest Was muss gemacht werden? Festlegung der Qualitätsziele Verpflichtung aller Ebenen zur Qualitätssicherung Festlegung der konkreten Qualitätssicherungsmaßnahmen Festlegung des Auftraggeber-Lieferanten-Verhältnis Darlegung gegenüber der internen Maßnahmen gegenüber Dritten Systemzertifizierung nach ISO 9001 Audit durch unabhängige Zertifizierungsstelle (nach DIN EN 45 012) Jährliche Überwachungsaudits Nach drei Jahren: Wiederholungsaudit Wolf Zimmermann 644 Wolf Zimmermann 645 Struktur der ISO-9000 Norm ISO 9000-1 Allgemeine Einführung, Leitfaden zur Auswahl und Anwendung ISO 9000-2 Allgemeiner Leitfaden zur Anwendung von 9001, 9002 und 9003 ISO 9000-3 Leitfaden zur Anwendung von 9001 auf Software ISO 9000-4 Leitfaden zum Management von Zuverlässigkeitsprogrammen ISO 9001 beschreibt Modelle zur Qualitätssicherung in allen Phasen ISO 9002 definiert Modelle zur Qualitätssicherung in Produktion und Installation ISO 9003 Qualitätssicherung in Endprüfung ISO 9004 Erläuterung der Qualitätssicherungselemente Wolf Zimmermann 646 Maßnahmen nach ISO 9000-3 Einmalige Maßnahmen Geschäftsleitung: Verpflichtung zur Qualitätspolitik Beauftragter zur Überwachung der Einhaltung der Norm regelmäßige Überprüfung Mitarbeiter: Festlegung der Verantwortlichkeiten und Kompetenzen Beauftragte für Qualitätskontrolle (unabhängig von Entwickler) Einrichtung, Aufrechterhaltung und Dokumentation von Qualitätsmanagement Integration in gesamten Lebenszyklus Maßnahmen pro Projekt Softwareentwicklung in Phasen Festlegung der Vorgaben für jede Phase Festlegung der zu erzielende Ergebnisse für jede Phase Festlegung des Verifizierungsverfahrens für jede Phase keine Festlegung auf bestimmtes Verfahren Wolf Zimmermann 647
Dokumente nach ISO 9000-3 Vertrag Auftraggeber-Lieferant Spezifikation Entwicklungsplan Qualitätssicherungsplan Qualitätsaufzeichnungen Festlegung von Regeln, Praktiken Nutzung von Werkzeugen Unterauftragsmanagement: von beschafften Produkten Testplan Wartungsplan Konfigurationsmanagementplan Wolf Zimmermann 648 Vorteile von ISO 9000 Aufmerksamkeit und Bewusstsein für Qualitätssicherung Zwang zur Beibehaltung der Qualitätssicherung Festlegung der Anforderungen, Freiheit bei deren Realisierung Erleichtert Aquisitation von Aufträgen Geeignet für Werbung Reduktion des Produkthaftungsrisikos Nachteile von ISO 9000 Unsystematischer Aufbau Keine saubere Trennung zwischen Fach-, Management- und Qualitätssicherungsaufgaben Software-Bürokratie Einsatz von nicht vorhandenen CASE-Werkzeugen noch keine standardisierten Verfahrensabläufe und Dokumente Qualifikation der Auditoren Mittlerer Bildungsabschluss mit spezieller Schulung genügt Schlechte Übersetzung deutscher Fassung Wolf Zimmermann 649 Das Capability Maturity Model Integration Ziel Modell zur Verbesserung und Bewertung von Software und Systementwicklungsprozessen Eingeführt vom Software Engineering Institute (SEI) der Carnegie-Mellon-University für Projekte des amerikanischen Verteidigungsministeriums Nachfolger von CMM ISO 15504 ist ähnlich Methodik Einführung von Reifegraden (maturity levels) mit konkret verbundenen Zielen zur Qualitätsverbesserung Jede dieser Stufe umfasst weitere Prozesse, Anforderungen und Maßnahmen Softwareunternehmen können sich gezielt verbessern Stufenförmige Darstellung des CMMI Reifegrad 0: Mindestens ein Ziel des Entwicklungsprozesses wird nicht erreicht Reifegrad 1: Die Prozesse sind noch ad hoc und der Erfolg hängt in erster Linie vom Einsatz und der Kompetenz einzelner Mitarbeiter ab. Reifegrad 2: Etabliert Managementprozesse zur Kosten, Zeit und Funktionalitätsplanung. Reifegrad 3: Verlagerung des Schwerpunkts vom einzelnen Projekt auf das Unternehmen/die Organisation Einheitliche Entwicklungsprozesse Reifegrad 4: Nutzung von Metriken und Kennzahlen als Entscheidungsgrundlage für Verbesserungsaktivitäten Reifegrad 5: Einführung einer Systematik zu kontinuierlichen Verbesserungen Stufe 1: Initial unvorhersehbar wenig Steuerung Stufe 2: Gemanagt frühere Erfolge sind wiederholbar Stufe 5: Optimierend Entwicklungsprozess verbesserung Stufe 4: Quant. geman. Entwicklungsprozess gemessen und gesteuert Stufe 3: Definiert Entwicklungsprozess dokumentiert und ver standen Wolf Zimmermann 650 Wolf Zimmermann 651
Prozessgebiete der Stufe 2 Prozessgebiete der Stufe 3 Anforderungsmanagement Projektplanung Projektverfolgung und steuerung Management von Lieferantenvereinbarungen Messung und Analyse Qualitätssicherung von Prozessen und Produkten Konfigurationsmanagement Anforderungsentwicklung Technische Umsetzung Produktintegration und Verifikation Organisationsweite(r) Prozessfokus, definition Organisationsweites Prozesstraining Integriertes Projektmanagement Risikomanagement Entscheidungsanalyse und findung Wolf Zimmermann 652 Wolf Zimmermann 653 Zusammenfassung Qualitätssicherung wird zunehmend eine der zentralen Aufgaben der Softwareentwicklung Minimierung des Produkthaftungsrisikos sowie ggf. des persönlichen Haftungsrisikos ISO 9000 Norm beeinhaltet Verpflichtung zur Qualitätssicherung CMMI sieht Reifegrade der Qualität samt konkreten Prozessen und Maßnahmen vor ISO 15504 implementiert CMMI konform zu ISO 9000 für Softwareentwicklung ISO 27000 berücksichtigt auch Schutz (Datenschutz, Schutz vor Angriffen etc.) 8.2 Vorgehensmodelle Aufgaben eines Vorgehensmodell (auch Prozessmodell) Definition der Reihenfolge des Arbeitsablaufs Durchzuführende Aktivitäten bei Softwareentwicklung Definition der Teilprodukte einschließlich Form und Inhalt Festlegung der Fertigstellungskriterien Festlegung notwendiger Mitarbeiterqualifikationen Festlegung der Verantwortlichkeiten und Kompentenzen Definition von Standards, Richtlinien, Methoden und Werkzeuge Programmieren durch Probieren Vorgehen: 1 Schreibe Programm 2 Finde und behebe Fehler im Programm Wolf Zimmermann 654 Wolf Zimmermann 655
Wasserfallmodell Vorteil Schnelle Entwicklung(???) Nachteile Gefahr von Spaghetti- und Ravioli-Code Mangelhafte Aufgabenerfüllung Teure Wartung und Pflege, keine Dokumentation ungeeignet für Teamarbeit Anforderungs analyse Entwurf Lastenheft, Pflichtenheft, Projektplan vorläufiges Benutzerhandbuch, Verifikationsplan Systemarchitektur,Benutzer handbuch, Verifikationsplan Test Module, Testdaten Dokumentation funktionsfähiges System, Rückblick Betrieb und Wartung Wolf Zimmermann 656 Revalidierung Wolf Zimmermann 657 Prototypenmodell Vorteile des Wasserfallmodells Dokumentengetriebenes Modell Aktivitäten enden mit fertiggestellten Dokumenten Orientiert an top-down-vorgehen Einfach, verständlich, wenig Managementaufwand Einfache Anpassung an projektspezifische Anforderungen Benutzerbeteiligung nur in Definitionsphase Nachteile des Wasserfallmodells Anforderungs analyse Prototyp, Entwurf Vorführung Anforderungs analyse Prototyp Klärung wichtiger Fragen und Unsicherheiten Systembeschreibung, Pflichtenheft, Projektplan vorläufiges Benutzerhandbuch, Verifikationsplan Sequentielle Reihenfolge der Entwicklungsschritte nicht immer sinnvoll Vollständige Durchführung der Entwicklungsschritte nicht immer sinnvoll Gefahr der Bürokratisierung Dokumente wichtiger als eigentliches System Zu geringe Berücksichtigung der Risikofaktoren Benutzerbeteiligung nur in Definitionsphase Entwurf Systemarchitektur,Benutzer handbuch, Verifikationsplan Test Module, Testdaten Dokumentation funktionsfähiges System, Rückblick Wolf Zimmermann 658 Betrieb und Wartung Revalidierung Wolf Zimmermann 659
Verschiedene Prototypen Demonstrationsprototyp Vermittelt Eindruck über zu erstellendes Produkt Auftragsaquisitation Vernachlässigung softwaretechnischer Standards Prototyp im engeren Sinn Provisorisches ablauffähiges System Parallel zur Systemanalyse (Modellierung) Dient der Analyse des Anwendungsbereichs Labormuster Demonstration der technischen Umsetzbarkeit Konstruktionsbezogene Fragen und Alternativen Pilotsystem Kern des Produkts Weiterentwicklung in Zyklen Erhöhung des Reifegrads Vorteile des Prototypenmodells Erleichtert Aquisitation von Aufträgen Unterstützt Auftraggeber und Entwickler bei Anforderungs und Systemanalyse Leicht in andere Prozessmodelle integrierbar Erleichtert Planung von Softwareprojekten Werkzeugunterstützung für schnelle Erstellung von Prototypen rapid prototyping Nachteile des Prototypenmodells Höherer Entwicklungsaufwand Gefahr, dass Wegwerfprototyp doch Bestandteil des Produkts wird Verträge zur Softwareerstellung berücksichtigen keine Prototypen Prototypen als Ersatz für fehlende Dokumentation Unbekannte Grenzen und Beschränkungen des Prototyps Wolf Zimmermann 660 Wolf Zimmermann 661 Modellbasierte Entwicklung Anforderungs analyse Formalisierung Entwurf formale Spezifikation Konsistenz Vollständigkeit Änderungswünsche Metamodell, Modell und Modelltransformationen Metamodell 1 Metamodell 2 beschreibt Quelle Ziel beschreibt Modell 1 Modell transformationen Modell 2 Modell: Modell des zu entwickelnden (Teil )systems Modell 2: von Modell 1 Metamodell: Definiert Sprache zur Beschreibung von Modellen Modelltransformationen: Definiert Transformationsregeln von Modellen im Metamodell 1 zu Modellen im Metamodell 2 (halb) automat. Generieren praktischer Einsatz Wolf Zimmermann 662 Wolf Zimmermann 663
Beispiel: Übersetzer Spezifikation reguläre Ausdrücke konkrete Syntax (Grammatik) abstrakte Syntax (Grammatik) attributierte Grammatik Abbildung abstrakt > Zwischensprache Zwischensprache (Grammatik) Generator LEX REX yacc LALR ELL AST AG Puma AST Modul lexikalische Analyse syntaktische Analyse Syntaxbaum semantische Analyse Transformation Zwischen sprache Vorteile Fokus auf Modellierung Wartung auf Spezifikation Automatisierung der Werkzeuge zur Konsistenz- und Vollständigkeitsprüfung Nachteile Nur in wenigen Bereichen anwendbar (z.b. Automobil, Flugzeugbau) Oft nur auf kleine Programme anwendbar Ungeschulte Mitarbeiter Testen auf Modellebene (aktives Forschungsthema) Abbildung Zwischensprache > Assembler BEG Codegenerator Wolf Zimmermann 665 Wolf Zimmermann 664 Objektorientierte Entwicklung OO Produkt 1 OO Produkt 2 Anforderungs analyse Wiederverwendung OOA Modell Entwurf Wiederverwendung OOD Modell Wiederverwendung OO Produkt Analysieren Überarbeiten Verallgemeinern OOA Modell Auswählen OOD Modell Auswählen Klassen Auswählen Suchen Subsystem klassen Suchen OOD Modell Klassen Suchen Komponenten Ablegen Ablegen Ablegen Ablegen w i e d e r v e r w e n d b a r e K o m p o n e n t e n Vorteile Höhere Produktivität und Qualität Offshoring leicht möglich Einsatz und Produktion von Standardsoftware Gut kombinierbar mit Versionsmodell und Prototypenmodell Schult Blick über den Tellerrand Nachteile Bindung an objektorientierte Technologie Vorhandene Wiederverwendungsinfrastruktur? Zusätzliche Kosten für Erweiterung firmeninterner Wiederverwendungsinfrastruktur Aufbau einer Firmenphilosophie zur Wiederverwendung Technische Probleme, z.b. Inkompatibilitäten in und zwischen Klassenbibliotheken Wolf Zimmermann 666 Wolf Zimmermann 667
Versionsmodell partielles Modell Nullversion n :=0 n := n Definition der Version n partielle Architektur + 1 Entwurf der Version n der Versionn Einbetten der Version n auch inkrementelles oder evolutionäres Modell Wünsche Vorteile des Versionsmodells Auftraggeber erhält in kürzeren Zeitabständen einsatzfähige Produkte Einfache Kombination mit Prototypenmodell (Pilotsystem) Unterstützt Studium der Auswirkungen des Produkts auf Arbeitsabläufe Leichtere Korrekturen der Entwicklungsschritte Keine einseitige Ausrichtung auf Endabnahmetermin Nachteile des Versionsmodells Teuer Gefahr der Komplettüberarbeitung Unflexible Nullversion Wolf Zimmermann 668 Wolf Zimmermann 669 Verbesserung des Versionsmodells Der Rational Unified Process (RUP) von IBM als Versionsmodell geänderte Anforderungen Wünsche zeitliche Organisation Phasen vollständiges Modell Anforderungs analyse Nullversion n :=0 modifiziertes Modell n := n + 1 falls n >0 Entwurf der Version n Grundprinzip Anfang Anfang Elaboration Elab 1 Elab 2 Konstruktion Kons 1 Kons Kons Tran Tran 2 N 1 2 Vier Phasen: Anfang, Elaboration, Konstruktion und Transition Transition partielle Architektur der Versionn Einbetten der Version n Abschluss einer Phase durch Meilenstein: Zeitpunkt, zu dem gewisse Tätigkeiten vollzogen sind. Falls nicht alle Aufgaben abgeschlossen sind, findet weitere Iteration statt. Arbeitsablauf durch Organisation der Aktivitäten, Rollen und deren Artefakte Wolf Zimmermann 670 Wolf Zimmermann 671
Aktivitäten und Artefakte Rollen Aktivitäten Arbeitseinheiten, die innerhalb weniger Stunden oder Tage zu erledigen sind Beispiele Eine Aktivität erfolgt ein klar definiertes Ziel Iteration planen Überarbeiten der Softwarearchitektur Durchführen der Performancetests Artefakte Artefakte sind Resultate von Aktivitäten Nicht formal als Dokumente definiert Nur in Werkzeugen als Modell Beispiel Analysemodell smodell Architekturmodell Wolf Zimmermann 672 Rollen Eine Rolle wird vom einem Teammitglied übernommen Personen können mehrere Rollen einnehmen Jeder Rolle werden Aktivitäten zugeordnet Rollen im RUP Analytiker erheben primär Anforderungen Entwickler sind bei der Erstellung von Software involviert Projektmanager leiten und konfigurieren den Softwareprozess Tester beschäftigen sich mit dem Testen der Software Produktion und Support (z.b. Systemadministratoren) Weitere Rollen (z.b. Versions und Konfigurationsmanagement): meist Aktivitäten, die jedes Teammitglied ausführen muss Wolf Zimmermann 673 Workflows Workflow Einheiten, die Aktivitäten der einzelnen Rollen in Gruppen kategorisieren Workflows im RUP Geschäftsmodellierung: Korrespondenz von Business Engineering und Software-Engineering Gemeinsame Darstellung der Anforderungen für Kunden und Entwickler Anforderungen: Definition der Abläufe des zu entwickelnden Systems Gemeinsame Überprüfung mit Kunden in regelmäßigen Abständen Grundlage von Kostenschätzung und Zeitaufwandsschätzung Analyse und Entwurf: Erstellen einer Softwarearchitektur, die die Anforderungen erfüllt : der Software Zusammensetzen der Klassen zu Komponenten der Softwarearchitektur Integration Testen: auf allen Ebenen mit dem Ziel Fehler zu entdecken Auslieferung: Auslieferungsplan, Installationsartefakte, gefertigtes Produkt Konfigurations und Versionsmanagement: Verwaltung der verschiedenen Versionen und Varianten innerhalb eines Projekts Projektmanagement: Koordinieren und Planen des Softwareprojekts Risikomanagement Planung und Überwachen der Iterationen sowie des Gesamtprozesses Umgebung: Versorgung mit Werkzeugen, Programmierumgebungen, Prozessen Wolf Zimmermann 674 Phasen und Iterationen Anfang: Legt Grundstein für Projekt Wichtigste Eckpunkte Geschäftsvision Risikoanalyse Entscheidung über Durchführung des Projekts Elaboration: Identifikation der Problemstellung und Erstellung einer initialen Architektur Modellierung der Funktionalität Berücksichtigung nicht-funktionaler Anforderungen Ggf. Prototyp Konstruktion: Entwurf und des Systems Ressourcenmanagement, Kontroll und Prozessoptimierung Komponentenentwicklung und Test Einschätzung, ob Produkt freigegeben werden kann Transition: Bereitstellen und Ausliefern der Software an Kunden Feinabstimmung Produktrelease herstellen Supportunterlagen fertigstellen Wolf Zimmermann 675
Agile Methoden Motivation Traditionelle Vorgehensmodelle sind zu bürokratisch Andere Gewichtung Einzelpersonen und Interaktionen sind wichtiger als Prozesse und Werkzeuge Laufende Systeme sind wichtiger als Dokumentation Zusammenarbeit mit Kunden ist wichtiger als Vertragsverhandlungen Reaktionen auf Veränderungen sind wichtiger als das Einhalten eines Plans Entgegengesetzter Ansatz zur traditionellen Vorgehensmodellen. Wichtige Ansätze Extreme Programming Scrum Feature Driven Development Wolf Zimmermann 676 Extreme Programming Auswahl von User Stories für das aktuelle Release Auswertung des Systems Herunterbrechen der Stories auf einzelne Aufgaben Freigabe der Software Planung des nächsten Release Entwicklung, Integration und Test der Software Vorgehen Anforderungen werden als Stories ausgedrückt Der Kunde priorisiert die Stories, die vom Entwicklerteam in Aufgaben samt Kostenschätzung zerlegt werden Der Kunde priorisiert die Aufgaben und entscheidet damit welche in der aktuellen Iteration erledigt werden. Die nicht-implementierten Stories sind zukünftigen Iterationen vorbehalten Beispiel: Story Downloading and Printing an Article(Ausschnitt) Zuerst wählen Sie den gewünschte Artikel aus einer angezeigten Artikelliste. Dann müssen sie dem System mitteilen, wie Sie den Artikel bezahlen (Abonnement, Überweisung oder Kreditkarte). Danach bekommen Sie ein Copyright-Formular vom System, das Sie ausfüllen müssen. Sobald Sie diese eingereicht haben, können Sie den gewünschten Artikel auf Ihren Computer runterladen. Anschließend wählen Sie den Drucker, um den Artikel auszudrucken. Falls der Artikel nur gedruckt werden darf, muss die PDF-Version sofort nach erfolgreichem Drucken wieder gelöscht werden. Wolf Zimmermann 677 Umsetzung von Extreme Programming Scrum Grundprinzipien Tests für jede Aufgabe werden vor der entwickelt Vor der Integration in das neue System müssen alle Tests erfolgreich sein Sehr kleine Iterationszyklen (wenige Stunden bis maximal einen Tag) Kunde ist als Vollzeit in das Projekt integriert System ist praktisch immer lauffähig Wichtige Praktiken (Ausschnitt) Kleine Releases: Minimale, um neues lauffähiges System zu erhalten Refactoring: Verbesserung durch systematische Codetransformation Paarprogrammierung: Entwickler arbeiten als Paar, um die Arbeit des Partners zu überprüfen und zu unterstützen Der Code gehört allen: Niemand der Entwickler hat einen einzelnen Anspruch auf den Code bzw. Teile davon Kunde als Mitglied des Entwicklungsteams: Erlaubt sehr schnelles Eingehen auf Kundenwünsche. Er kann insbesondere beim Testen integriert werden Scrum Meeting (tägl., 15 Min) Anforderungen (product backlog) Auswahl von Anforderungen Anforderungen für nächsten Sprint Auftraggeber Produkt manager Realisierung dieser Anforderungen Entwickler Scrum Master Neue ausführbare Version (Prototyp, Test, Produkt) Post Sprint Demo Review alle Product Backlog: Sammlung aller Anforderungen Priorisierung durch Auftraggeber Sprint: Iteration von 30 Tagen Auswahl von Anforderungen durch Produktmanager (ergibt Sprint Backlog) Keine Überschreitung des Endtermins Ggf. Reduktion der Funktionalität durch das Team Scrum Master: verantwortlich für ungestörtes Arbeiten Scrum Meeting: tägliches, zeitgleiches 15-minütiges Treffen. Jedes Teammitglied muss informieren was seit es seit der letzten Besprechung getan hat, welche Schwierigkeiten überwunden werden mussten, was es bis zur nächsten Besprechung tun möchte Probleme werden nur durch die Betroffenen gelöst. Kontrolle des Projektfortschritts: Protokollierung des geschätzten Restaufwands durch jedes Teammitglied Akkumulation ergibt Überblick Wolf Zimmermann 678 Wolf Zimmermann 679
agiler Methoden Nebenläufiges Modell Vorteile Hohe Kundenbeteiligung Sehr schnelle Iterationszyklen Wenig Dokumentations /Managementaufwand hohe Kommunikation und Transparenz im Team Definition Kernsystem partielles Modell Definition Ausbaustufe 1 Nachteile Gefahr des Wiederholens von Fehlern wegen mangelnder Dokumentation Gefahr des Vernachlässigens softwaretechnischer Standards Gefahr, dass Iterationen nur noch dem Beseitigen von Fehlern dienen Erfahrungen in der Praxis Gut geeignetes Vorgehensmodell für Webportale und GUIs Eher schlecht geeignet für sicherheitskritische Anwendungen Iterationszyklen nähern sich dem klassischen inkrementellen Modell an Kundenbeteiligung erfordert oft Überzeugungsarbeit Qualitätssicherungsmaßnahmen müssen explizit eingefordert werden. Längerfristige Planung durch übergeordnetes Team notwendig Entwurf Kernsystem partielle Architektur Kernsystem Kernsystem erweitertes Modell Entwurf Aufbaustufe 1 erweiterte Architektur Aufbaustufe 1 erweitertes Kernsystem Definition Ausbaustufe 2 erweitertes Produktmodell Entwurf Aufbaustufe 2 erweiterte Produktarchitektur Aufbaustufe 2 erweitertes Produkt Produkt Wolf Zimmermann 680 Wolf Zimmermann 681 Charakteristika des nebenläufigen Modells Parallelisieren des Entwicklungsprozesses Förderung der zielgerichteten Zusammenarbeit der Personengruppen Reduktion von Zeitverzögerungen Parallelisierung von Aktivitäten Minimierung des Ausprobierens Reduktion von Wartezeiten zwischen organisatorisch verbundenen Aktivitäten Frühe Integration der Erfahrungen der betroffenen Arbeitsgruppen Vorteile Frühes Erkennen und Beseitigen von Problemen Optimale Zeitausnutzung Nachteile Realisierbarkeit bei Softwareprojekten? Risiko, kritische Entscheidungen zu spät zu treffen Hoher Planungs- und Personalaufwand Wolf Zimmermann 683 Wolf Zimmermann 682
Spiralmodell Spiralmodell Grundsätzliche Struktur Bestimme Ziele, Alternativen Beschränkungen Evaluiere Alternativen Bestimme und behebe Risiken Bestimme Ziele, Alternativen Beschränkungen Risikoanalyse (RA) Risikoanalyse (RA) Evaluiere Alternativen Bestimme und behebe Risiken Risikoanalyse (RA) Verpflichtung nächste Runde Überprüfung Plane nächste Runde Erstelle und verifiziere Produkt Plane nächste Runde R Prototyp Anforderungen A 1 Lebenszyklus Vorgehens plan konzept Entwicklungs plan Integrations und Testplan Prototyp 2 Prototyp 3 Pilotsystem Software anforderungen der Anforderungen Simulationen, Modelle, Vergleiche Software produkt entwurf und Verifikation des Entwurfs Abnahmetest Integration und Test Detailentwurf Codierung und Modultest Erstelle und verifiziere Produkt Wolf Zimmermann 684 Wolf Zimmermann 685 Merkmale des Spiralmodells Alle bisherigen Modelle sind Spezialfälle des Spiralmodells Risikogetriebenes Modell Risikominimierung Jede Spirale ist iterativer Zyklus durch dieselben Schritte Ziele für Zyklus aus vorhergehendem Zyklus Separate Spiralzyklen für verschiedene Softwarekomponenten möglich Keine Trennung von Entwicklung und Wartung Erreiche Entwicklungsziele mit minimalen Kosten Berücksichtigt Qualitätsziele Pro Aktivität und Ressourcenverbrauch wird gefragt: Wieviel ist genug? Vorteile Nachteile Festlegung und Änderung des Prozessablaufs risikoabhängig Prozessmodell nicht für gesamte Entwicklung festgelegt Frühe Erkennung und Beseitigung von Fehlern Frühzeitige Erkennung und Auswahl von Alternativen Flexibel gegenüber in Anforderungen, Entwicklung Unterstützt Wiederverwendung Hoher Managementaufwand Ungeeignet für kleinere und mittlere Projekte Wissen über Identifizieren und Beherrschen von Risiken noch nicht weit verbreitet Wolf Zimmermann 686 Wolf Zimmermann 687
Das V-Modell XT Projekttypen des V-Modells XT basiert auf Höhn/Höppner: V-Modell XT, Springer 2008 Ziele Minimierung der Projektrisiken Verbesserung und Gewährleistung der Qualität Eindämmung der Projekt und Systemlebenszykluszeiten Kontinuierliche Verbesserung der Projektfähigkeit Verbesserung der Kommunikation zwischen allen Beteiligten Grundprinzipien Vorgabe standardisierter Vorgehensweisen Beschreibung der zugehörigen Ergebnisse und verantwortlichen Rollen Verbesserung der Planbarkeit Leichtere Überprüfung der Ergebnisse und des Projektfortschritts Verringerung der Abhängigkeit des Auftraggebers vom Auftragnehmer Anpassung des Vorgehensmodells an die Organisation Fazit V-Modell XT liefert einen generischen Rahmen für die Konstruktion von Vorgehensmodellen mit den gewünschten Eigenschaften Ziel Orientierung für unterschiedliche Projektkonstellationen Systementwicklungsprojekt eines Auftraggebers Beschreibung einer Erstellung einer Ausschreibung im Projektverlauf an Unterauftragnehmer Beschreibung des Auswahlprozesses Festlegung der Abnahmekriterien Systementwicklungsprojekt eines Auftragnehmers Erstellung eins Angebots Systemauslieferung Einführung und Pflege eines organisationsspezifischen Vorgehensmodells Einführung und Verbesserung eines einheitlichen Vorgehensmodells Analyse und Erfassung von Verbesserungsmöglichkeiten Beobachtung In einem Projekt wird eine Auftraggeber/Auftragnehmerschnittstelle festgelegt Wolf Zimmermann 688 Wolf Zimmermann 689 Tailoring Anpassung des generischen Vorgehensmodells Schritte Festlegung der Vorgehensbausteine Festlegung der Entscheidungspunkte Festlegung Projektdurchführungsstrategie Vorgehensbausteine, Entscheidungspunkte Vorgehensbaustein: Satz von Produkten, Aktivitäten und Rollen zur Erfüllung einer bestimmten Aufgabe Entscheidungspunkt: Zeitpunkt oder Meilenstein im Projektverlauf, zu dem der erfolgreiche Abschluss eines Projektabschnitts überprüft werden kann. Projektdurchführungsstrategie: Zeitlich geordnete Folge der Entscheidungspunkte Lenkungsausschuss Leiter ist der Projektmanager Überprüft Erfolg einer Projektfortschrittsstufe Gibt nächsten Projektabschnitt frei Festhalten der Entscheidungen in einem Bericht Wolf Zimmermann 690 Orientierungshilfen für Tailoring Grundprinzip Das V-Modell XT legt für jeden Projekttyp die relevanten Vorgehensbausteine und Projektdurchführungsstrategien fest V-Modell XT-Kern enthält verpflichtende Vorgehensbausteine für alle Projekttypen Optionale Vorgehensbausteine für alle Projekttypen Projekttypspezifische Vorgehensbausteine Beispiele von Vorgehensbausteinen des V-Modell XT V-Modell XT-Kern: Projektmanagement, Qualitätssicherung, Konfigurationsmanagement, Problem und Änderungsmanagement Optionale Vorgehensbausteine: Kaufmännisches Projektmanagement: Verfahren und Hilfe für Integration des Projektmanagement in das kaufmännische Management Messung und Analyse Vorgehensbausteine Systementwicklungsprojekt eines Auftraggebers: Anforderungsfestlegung, Systemsicherheit, Vertragsschluss, Lieferung und Abnahme Vorgehensbausteine Systementwicklungsprojekt eines Auftragnehmers: Systemerstellung, Hard bzw. Softwareentwicklung, Weiterentwicklung und Migration von Altsystemen etc. Wolf Zimmermann 691
Entscheidungspunkte und Projektdurchführungsstrategien im V-Modell XT Vorgehen bei der Systementwicklung im V-Modell (XT) Gesamtprojekt aufgeteilt Gesamtprojektfortschritt überprüft Projektfortschritt überprüft Anforderungs definition Anwendungsszenarien Abnahme test Projekt genehmigt Projekt definiert Anforderungen festgelegt Projekt ausgeschrieben Angebot abgegeben Projekt beauftragt System spezifiziert Iteration geplant Abnahme erfolgt Lieferung durchgeführt Projekt abgeschlossen Grobentwurf Testfälle, Verifikation System test Vorgehensmodell analysisert Verbesserung Vorgehensmodell konzipiert System entworfen Feinentwurf abgeschlossen System integriert Systemelemente realisiert Verbesserung Vorgehensmodell realisiert Feinentwurf Testfälle, Verifikation Integrations test Alle V Modell Projekte Organisationsspezifisches Vorgehensmodell Systementwicklung Auftraggeber/ Auftragnehmerschnittstelle Testfälle Verifikation Modultest Wolf Zimmermann 692 Wolf Zimmermann 693 Vorteile des V-Modells XT Integration der Qualitätssicherung in Wasserfall und iterative Modelle Zuschneidung auf organisations und projektspezifische Anforderungen Einfache Anpassung an projektspezifische Anforderungen Standardisierte Abwicklung von Systemerstellungsprojekten Gut geeignet für große Projekte, insbesondere eingebettete Systeme von ISO 9000, CMMI-Stufen 2 und 3 Nachteile des V-Modells XT Hohe Produktvielfalt und Bürokratie Ohne CASE-Werkzeuge praktisch nicht handhabbar Wolf Zimmermann 694 Zusammenfassung Primäres Ziel antreibendes Benutzer Prozessmodell Moment beteiligung Merkmale minimaler Dokumente gering Wasserfallmodell Managementaufwand sequentiell, volle Breite V-Modell maximale Qualität Dokumente gering sequentiell, volle Breite, Verifikation, Validation Prototypenmodell Risikominimierung Code hoch nur Teilsysteme minimale Entwicklungszeit Code mittel Versionsmodell Risikominimierung hoch (agil) volle Definition, dann zunächst Kernsystem Modellbasierte maximale Qualität Spezifikation gering Entwicklung Automatisierung Kostenminimierung Wiederverwendbare unklar OO-Modell Komponenten volle Breite abhängig von Bibliothek nebenläufiges minimale Entwicklungszeit Zeit hoch Modell volle Breite, nebenläufig Spiralmodell Risikominimierung Risiko mittel Entscheidung pro Zyklus über weiteres Vorgehen Wolf Zimmermann 695