3 Softwareentwicklungsprozesse und Vorgehensmodelle

Transkript

1 Softwaretechnik I 3 Softwareentwicklungsprozesse und Vorgehensmodelle Lernziele Verstehen, was ein Softwareentwicklungsprozess ist Erklären können, warum man Vorgehensmodelle braucht Wissen, welche Vorgehensmodelle es gibt Vor- und Nachteile von Vorgehensmodellen verstehen Erklären können, was Softwareentwicklungsprozessverbesserung bedeutet 2013 IAS, Universität Stuttgart 117

2 Softwaretechnik I 3 Softwareentwicklungsprozesse und Vorgehensmodelle 3.1 Softwareentwicklungsprozess 3.2 Vorgehensmodelle 3.3 Standardisierte Vorgehensweise 3.4 Verbesserung des Softwareentwicklungsprozesses 3.5 Zusammenfassung 2013 IAS, Universität Stuttgart 118

3 3.1 Softwareentwicklungsprozess Softwareentwicklungsprozess (1) Definition Softwareentwicklungsprozess: Menge von Tätigkeiten, deren Ziel die Entwicklung oder die Weiterentwicklung von Software ist. [Ian Sommerville] Sehr große Vielfalt an unterschiedlichen Softwareentwicklungsprozessen Es gibt keinen idealen Softwareentwicklungsprozess Trotz vieler unterschiedlicher Softwareentwicklungsprozesse, gibt es 5 grundlegende Aktivitäten, die alle Softwareentwicklungsprozesse gemeinsam haben. Requirements Engineering Softwaresystemanalyse Softwareentwurf Softwareimplementierung Softwaretest 2013 IAS, Universität Stuttgart 119

4 3.1 Softwareentwicklungsprozess Softwareentwicklungsprozess (2) Live-Mitschrieb Standards, Normen Personen Anforderungen Softwareentwicklungsprozess Produkt Kosten, Ressourcen, Werkzeuge Zeitdauer, Aufwand 2013 IAS, Universität Stuttgart 120

5 Fragen zur Vorlesung Frage zu 3.1 Welche Aktivitäten finden üblicherweise im Softwareentwicklungsprozess statt? f f Entwicklung von Updates Verpackungsdesign Gespräche mit dem Kunden Softwareverkauf Programmierung 2013 IAS, Universität Stuttgart 121

6 Softwaretechnik I 3 Softwareentwicklungsprozesse und Vorgehensmodelle 3.1 Softwareentwicklungsprozess 3.2 Vorgehensmodelle 3.3 Standardisierte Vorgehensweise 3.4 Verbesserung des Softwareentwicklungsprozesses 3.5 Zusammenfassung 2013 IAS, Universität Stuttgart 122

7 3.2 Vorgehensmodelle Vorgehensmodell (engl. Process Model) Definition Vorgehensmodell: Vereinfachte Beschreibung eines Softwareentwicklungsprozesses, der von einer bestimmten Perspektive aus dargestellt wird. [Ian Sommerville] Vorgehensmodelle umfassen: Tätigkeiten des Softwareentwicklungsprozesses Softwareprodukte, die während des Softwareentwicklungsprozesses entstehen Rollen von Personen 2013 IAS, Universität Stuttgart 123

8 3.2 Vorgehensmodelle Wozu Vorgehensmodelle? Softwareentwicklungsprozess wird transparenter und somit planbar nachvollziehbar kontrollierbar lehrbar für das Softwareprodukt bedeutet das höhere Qualität effizientere Produktion bessere Wartbarkeit und somit schnellere Fehlerbehebung erhöhte Änderungsfreundlichkeit 2013 IAS, Universität Stuttgart 124

9 3.2 Vorgehensmodelle Allgemeine Vorgehensmodelle Phasenmodell "Wasserfall"-Modell Evolutionäres Modell Wiederverwendungsorientierte Entwicklung Inkrementelle Entwicklung Extreme Programming Spiralmodell Unified Process 2013 IAS, Universität Stuttgart 125

10 3.2 Vorgehensmodelle Phasenmodell Verschiedene Modelle Anzahl, Dauer und Bezeichnung der Phasen ist nicht fest vorgegeben Konzeptphase Angebotsphase Entwicklungsphase Testphase und Inbetriebnahme Analyse der Anforderungen Erstellung Pflichtenheft Entwurfsphase Implementierung Aufgabendefinition Test Grobentwurf Feinentwurf Implementierung Inbetriebnahme Streng sequenziell, keine Iterationen Zeit Zeitanteil der einzelnen Phasen fest Phasenmodelle entsprechen nicht der Realität 2013 IAS, Universität Stuttgart 126

11 3.2 Vorgehensmodelle "Wasserfall"-Modell Anforderungsdefinition Anzahl und Bezeichnung der Phasen ist nicht fest vorgegeben System- und Softwareentwurf Implementierung und Komponententest Integration und Systemtest Betrieb und Wartung 2013 IAS, Universität Stuttgart 127

12 3.2 Vorgehensmodelle "Wasserfall"-Modell - Eigenschaften Weiterentwicklung des sogenannten Phasenmodells [Royce, 1970 / Boehm, 1981]. Weit verbreitetes Vorgehensmodell. Jede Phase muss vollständig durchlaufen werden. Das ursprüngliche Modell ist streng sequentiell. Nächste Phase beginnt erst nach Abschluss der vorigen Phase. Iterationen sind nur zwischen zwei aufeinanderfolgenden Phasen erlaubt. Modell ist dokumentengetrieben. Aus jeder Phase entstehen Dokumente, die abgenommen werden. In der Praxis sind Überlappungen der Phasen notwendig 2013 IAS, Universität Stuttgart 128

13 3.2 Vorgehensmodelle Vorteile des "Wasserfall"-Modells Einfach verständlich, kein großer Schulungsaufwand notwendig Begrenzter Managementaufwand Sehr strukturierter und kontrollierbarer Prozessablauf Nachteile des "Wasserfall"-Modells Annahme, dass zu Beginn eine abgeschlossene und korrekte Anforderungsdefinition existiert, entspricht nicht der Realität. Lauffähige Version des Systems liegt erst am Ende der Entwicklung vor. Auftraggeber ist nur in der ersten Phase (Anforderungsdefinition) mit eingebunden. Nichteinhalten der Projektdauer führt zu Abstrichen in den späten Phasen (z. B. beim Testen). Testen wird nur am Ende des Entwicklungszyklus vorgesehen IAS, Universität Stuttgart 129

14 3.2 Vorgehensmodelle Evolutionäres Modell Anforderungsdefinition Modifikation der Anforderung Entwicklung Kunde Zeit Validierung Ja Neuer Zyklus erforderlich? Nein Endprodukt 2013 IAS, Universität Stuttgart 130

15 3.2 Vorgehensmodelle Evolutionäres Modell - Eigenschaften Softwareentwicklungsprozess wird nicht als linearer Prozess betrachtet, sondern als Folge von Entwicklungszyklen Entwicklung verläuft über viele Versionen, bis ein angemessenes Produkt entstanden ist Entwicklung beginnt typischerweise mit einem Prototyp Evolutionäres Prototyping Zusammenarbeit mit dem Kunden, um Anforderungen zu bestimmen Entwicklung beginnt bei den eindeutigen Teilen des Systems "Wegwerf"-Prototyping (Throw-Away) Anforderungen des Kunden sollen verstanden werden Entwicklung beginnt bei den unklaren Anforderungen 2013 IAS, Universität Stuttgart 131

16 3.2 Vorgehensmodelle Vorteile des Evolutionären Modells Nähe zum Kunden während des gesamten Entwicklungsprozesses Akzeptanz des Kunden wird durch fortlaufende Berücksichtigung der Wünsche verbessert Nachteile des Evolutionären Modells Prozess ist nicht sichtbar Keine regelmäßigen Zwischenversionen für die Messung des Projektfortschritts Keine kosteneffiziente Dokumentation möglich Systeme sind schlecht strukturiert Stetige Veränderungen führen zu schlecht strukturierten Systemen Schlechte Eignung für große Systeme mit langer Lebensdauer 2013 IAS, Universität Stuttgart 132

17 3.2 Vorgehensmodelle Wiederverwendungsorientierte Entwicklung Basiert auf der systematischen Wiederverwendung, in der Systeme aus existierenden Komponenten zusammengebaut werden. Dieser Ansatz wird immer wichtiger, bisher jedoch nur geringe Erfahrungen. Anforderungsdefinition Auswahl der Komponenten Anpassung der Anforderungen Komponentenbibliothek Systementwurf mit Wiederverwendung Entwicklung und Integration Zeit Systemvalidierung 2013 IAS, Universität Stuttgart 133

18 3.2 Vorgehensmodelle Vorteile der Wiederverwendungsorientierten Entwicklung Menge der zu entwickelnden Software wird verringert. Kosten und Risiken werden reduziert. Nachteile der Wiederverwendungsorientierten Entwicklung Kompromisse bei den Anforderungen sind unvermeidbar. Kann zu Systemen führen, die den Benutzerwünschen nicht gerecht werden. Einfluss auf Teile der Software geht verloren, da Komponenten von Fremdfirma entwickelt werden IAS, Universität Stuttgart 134

19 3.2 Vorgehensmodelle Inkrementelle Entwicklung (1) Inkrement 1 Analyse Entwurf Code Test Auslieferung des 1. Inkrements Inkrement 2 Analyse Entwurf Code Test Auslieferung des 2. Inkrements Inkrement 3 Analyse Entwurf Code Test Auslieferung des 3. Inkrements Inkrement 4 Analyse Entwurf Code Test Auslieferung des 4. Inkrements Zeit 2013 IAS, Universität Stuttgart 135

20 3.2 Vorgehensmodelle Inkrementelle Entwicklung (2) Die Systementwicklung wird in Schritte (= Inkremente) unterteilt. Jeder Schritt realisiert einen Teil der geforderten Funktionalität. Kundenanforderungen werden priorisiert und die höchstprioren Anforderungen in die frühen Schritte integriert. Die Anforderungen eines Inkrements werden zu Beginn der Entwicklung dieses Inkrements eingefroren. Anforderungen können somit kontinuierlich weiterentwickelt werden IAS, Universität Stuttgart 136

21 3.2 Vorgehensmodelle Vorteile der Inkrementellen Entwicklung Kundenwünsche können in jedem Inkrement erfüllt und ausgeliefert werden, somit ist die Systemfunktionalität früher verfügbar. Frühe Inkremente agieren als Prototyp und helfen Anforderungen für spätere Inkremente zu eruieren. Geringeres Risiko für Scheitern des Gesamtprojekts Die höchstprioren Funktionen werden am intensivsten getestet. Nachteile der Inkrementellen Entwicklung Abbildung der Kundenbedürfnisse (Anforderungen) auf einzelne Inkremente ist schwierig Ermittlung der Grundfunktionen für das erste Inkrement ist schwierig Grundfunktionen = Funktionen, die später von Teilsystemen gebraucht werden 2013 IAS, Universität Stuttgart 137

22 3.2 Vorgehensmodelle extreme Programming (XP) Leichtgewichtiges und flexibles Vorgehensmodell Weiterentwicklung der inkrementellen Entwicklung Basiert auf der Entwicklung und Auslieferung sehr kleiner Inkremente (Teilsysteme) Zwei Forderungen motivierten die Entwicklung von XP Develop for today Konzentration auf aktuelle Probleme Do the simplest thing that could possible work Verwendung des einfachsten Entwurfs (Simple Design), d.h. Erfüllung der Anforderungen Redundanzfreiheit 2013 IAS, Universität Stuttgart 138

23 3.2 Vorgehensmodelle Spiralmodell Zielbestimmung, Beurteilung von Alternativen Risikoanalyse Planung der nächsten Phase Entwicklungsplan P1 P2 Anforderungen Anforderungsvalidierung Entwurf V & V Abnahme Test P3 Grobentwurf P4 Feinentwurf Implementierung Integration Prototypen Produkt der nächsten Ebene entwickeln und verifizieren Anzahl und Bezeichnung der Sektoren und Teilschritte nicht fest vorgegeben 2013 IAS, Universität Stuttgart 139

24 3.2 Vorgehensmodelle Spiralmodell - Eigenschaften Vorgeschlagen von [Boehm 1998] Risikogetriebenes Vorgehensmodell Oberstes Ziel: Minimierung des Risikos Ähnlichkeiten zu evolutionärem Modell Softwareprozess wird als iterativer Prozess verstanden und als Spirale dargestellt, statt einer Sequenz aus Aktivitäten mit Rückkopplung Jede Windung repräsentiert eine Projektphase Jede Windung ist in Segmente aufgeteilt: Festlegung von Zielen, Alternativen und Randbedingungen Evaluierung der Alternativen, Erkennen und Reduzieren der Risiken Realisierung und Überprüfung des Zwischenprodukts Planung der Projektfortsetzung 2013 IAS, Universität Stuttgart 140

25 3.2 Vorgehensmodelle Vorteile des Spiralmodells Flexibles Modell Periodische Überprüfung und ggf. erneute Festlegung des Ablaufs in Abhängigkeit von Risiken Integrierte Risikoabwägung Integration anderer Vorgehensmodelle Betrachtung von Alternativen z. B. Kauf, Out-Sourcing oder Wiederverwendung von SW Nachteile des Spiralmodells Hoher Managementaufwand Risikomanagement ist nicht weit verbreitet Schlechte Eignung für kleine und mittlere Projekte 2013 IAS, Universität Stuttgart 141

26 3.2 Vorgehensmodelle Unified Process (1) Vorgehensmodell passend zur Unified Modeling Language (UML) Sehr mächtiges Prozessframework Baut auf den "Best Practices" der Softwareentwicklung auf: Iterative Softwareentwicklung Anforderungsmanagement Verwendung komponentenbasierter Architekturen Visuelle Software-Modellierung (Standardnotation: UML) Prüfung der Softwarequalität Kontrolliertes Änderungsmanagement Unterstützung dieser "Best Practices" durch vordefiniertes Framework von Methoden, Templates und Tools 2013 IAS, Universität Stuttgart 142

27 3.2 Vorgehensmodelle Unified Process (2) Unterscheidung zwischen Projektphasen und Arbeitsschritten (Workflows) Projektphasen werden zusätzlich in Iterationen unterteilt aus [Sommerville, Software Engineering] 2013 IAS, Universität Stuttgart 143

28 3.2 Vorgehensmodelle Phasen des Unified Process Beginn ("Inception") Entwicklung der Vision des Endprodukts Entwicklung einer Architekturidee Abschätzung von Risiken Ausarbeitung ("Elaboration") Festlegung der späteren Nutzung im Detail Festlegung der Systemarchitektur Realisierung der wichtigsten Funktionalitäten Genaue Planung der Kosten Konstruktion ("Construction") Realisierung des Systems Alpha-Release Umsetzung ("Transition") Übergang zu Beta-Release Schulung von Benutzern Fehler und Unzulänglichkeiten nachbessern 2013 IAS, Universität Stuttgart 144

29 Fragen zur Vorlesung Frage zu 3.2 Was definiert ein Vorgehensmodell? Welche Aktivitäten in welcher Reihenfolge ausgeführt werden f Welche Softwareentwicklungsumgebung eingesetzt werden soll f Welche Aktivität durch welche Personen durchgeführt wird Es legt fest, ob iterativ oder linear vorgegangen wird f Es legt Ergonomiestandards fest 2013 IAS, Universität Stuttgart 145

30 Fragen zur Vorlesung Frage zu 3.2 Welchen Aussagen stimmen Sie zu? f f Das "Wasserfall"-Modell ist für die Entwicklung von hoch komplexer Software geeignet Das Evolutionäre Modell stellt einen linearen Softwareentwicklungsprozess dar Die wiederverwendungsorientierte Entwicklung reduziert die Kosten der Softwareentwicklung Bei der inkrementellen Entwicklung werden Kundenwünsche explizit berücksichtigt f Das Spiralmodell wird stets in 4 Sektoren unterteilt 2013 IAS, Universität Stuttgart 146

31 Softwaretechnik I 3 Softwareentwicklungsprozesse und Vorgehensmodelle 3.1 Softwareentwicklungsprozess 3.2 Vorgehensmodelle 3.3 Standardisierte Vorgehensweise 3.4 Verbesserung des Softwareentwicklungsprozesses 3.5 Zusammenfassung 2013 IAS, Universität Stuttgart 147

32 3.3 Standardisierte Vorgehensweise Vorteile und Nutzen von Standards Standards sind eine notwendige Voraussetzung für eine einheitliche Verwendung. Durch standardisiertes Vorgehen wird die Vollständigkeit der zu liefernden Ergebnisse am ehesten gewährleistet. Definierte Zwischenergebnisse ermöglichen frühzeitige Validierung und Verifikation. Standardisierter Einsatz von Notationen erleichtert die Lesbarkeit, Wartbarkeit sowie die Codegenerierung. Das standardisierte Vorgehen macht die Kalkulation des Aufwands transparenter. Standards erlauben eine globale Entwicklung. Sie helfen beim Outsourcing und bei der Sub -Auftragsbearbeitung IAS, Universität Stuttgart 148

33 3.3 Standardisierte Vorgehensweise V-Modell (1) Entwicklungsmodell für ein Gesamtsystem Einheitlicher Standard für den gesamten öffentlichen Bereich ISO-Standard: Militär- und Bundesbehörden Anspruch auf Allgemeingültigkeit Definiert 25 Rollen für Managementaufgaben Zurechtschneiden auf konkrete Anforderungen (Tailoring) 2013 IAS, Universität Stuttgart 149

34 3.3 Standardisierte Vorgehensweise V-Modell (2) Aufteilung in 4 Submodelle System-Erstellung (SE) Qualitätssicherung (QS) Konfigurationsmanagement (KM) Projektmanagement (PM) Projekt planen und kontrollieren PM Voraussetzung schaffen und Softwareentwicklungsumgebung (SEU) bereitstellen QS-Anforderungen vorgeben System entwickeln Produktstruktur planen Produkte prüfen QS SE Produkte/Rechte verwalten KM 2013 IAS, Universität Stuttgart 150

35 3.3 Standardisierte Vorgehensweise V-Modell - Submodell System-Erstellung Ähnlichkeit zum Wasserfallmodell Integration von Validierung/Verifikation Formale Kriterien zur Abnahme von Teilprodukten Kundenerwartungen Abnahmetest Abnahme Anforderungsdefinition Grobentwurf Systemtest Integrationstest Modulintegration Systemintegration Feinentwurf Modultest Modulimplementierung 2013 IAS, Universität Stuttgart 151

36 3.3 Standardisierte Vorgehensweise Vorteile des V-Modells Umfassendes Modell Integriert viele Aspekte des Entwicklungsprozesses Erweiterbar und anpassbar Nachteile des V-Modells Zu allgemein und generisch Nicht für kleine Projekte geeignet Benötigt unbedingt gute CASE-Tools Neue Version des V-Modells: V-Modell XT Release 1.4 (2012) Stärkere Modularisierung Integration agiler und inkrementeller Ansätze 2013 IAS, Universität Stuttgart 152

37 3.3 Standardisierte Vorgehensweise Dreistufiges Standardisierungskonzept 1. Vorgehensweise Was ist zu tun Tätigkeiten in der Softwareentwicklung Ergebnisse Inhalte der Ergebnisse 2. Methoden Wie ist etwas zu tun Methodenunterstützung der Tätigkeiten Darstellungsmittel für Ergebnisse 3. Werkzeuganforderungen Womit ist etwas zu tun Funktionale Eigenschaften von Softwarewerkzeugen Video: IAS-Vorgehensmodell 2013 IAS, Universität Stuttgart 153

38 Fragen zur Vorlesung Frage zu 3.3 Welchen Aussagen stimmen Sie zu? Die Wiederverwendbarkeit wird verbessert, wenn Standards eingesetzt werden Das V-Modell ist ein standardisiertes Vorgehensmodell Das V-Modell beinhaltet im Wesentlichen die Softwareerstellung f 2013 IAS, Universität Stuttgart 154

39 Softwaretechnik I 3 Softwareentwicklungsprozesse und Vorgehensmodelle 3.1 Softwarerentwicklungsprozess 3.2 Vorgehensmodelle 3.3 Standardisierte Vorgehensweise 3.4 Verbesserung des Softwareentwicklungsprozesses 3.5 Zusammenfassung 2013 IAS, Universität Stuttgart 155

40 3.4 Verbesserung des Softwareentwicklungsprozesses Softwareentwicklungsprozess-Verbesserung Prozessverbesserung bedeutet: bestehende Prozesse zu verstehen und diese Prozesse zu verändern, um die Produktqualität zu verbessern die Kosten zu senken die Entwicklungszeit zu reduzieren Ablauf der Prozessverbesserung Verbesserung erkennen Prozessänderungen einführen Prozess analysieren Prozessänderungen anpassen 2013 IAS, Universität Stuttgart 156

41 3.4 Verbesserung des Softwareentwicklungsprozesses (Software-) Entwicklungprozess-Reife ist... The extent to which a specific process is explicitly defined, managed, measured, and effective. Maturity implies a potential for growth in capability and indicates both the richness [...] and consistency with which software processes are applied across the organization. Capability Maturity Model Integration (CMMI-DEV) 2013 IAS, Universität Stuttgart 157

42 3.4 Verbesserung des Softwareentwicklungsprozesses Capability Maturity Model Integration (CMMI) Prozessmodell zur Beurteilung und Verbesserung der Qualität ( Reife ) von Prozessen für die Produktentwicklung Nachfolger des Capability Maturity Model (CMM) CMM seit 1997 nicht weiterentwickelt Seit 2005 keine CMM-Assessments mehr SVC CMMI ist in 3 Gruppen ( Constellations ) unterteilt CMMI-DEV (Entwicklungsprozesse) CMMI-SVC (Dienstleistungsprozesse) CMMI-ACQ (Beschaffungsprozesse) DEV ACQ CMMI-DEV integriert verschiedene Modelle für unterschiedliche Entwicklungsdisziplinen Softwareentwicklung Systementwicklung Aktuelle Version: CMMI 1.3 (November 2010) 2013 IAS, Universität Stuttgart 158

43 3.4 Verbesserung des Softwareentwicklungsprozesses Die 6 Reifegrade des CMMI-Modells (1) kontinuierliche Verbesserung Reifegrad 5 Optimizing Prozessmessung Reifegrad 4 Quantitatively Managed Prozessdefinition Reifegrad 3 Defined Basismanagement Reifegrad 2 Managed Basisziele erreicht Reifegrad 1 Performed Reifegrad 0 Incomplete 2013 IAS, Universität Stuttgart 159

44 3.4 Verbesserung des Softwareentwicklungsprozesses Die 6 Reifegrade des CMMI-Modells (2) Incomplete (Anfangszustand) Keine definierte Vorgehensweise bei der Softwareerstellung Keine Kostenschätzung und Projektpläne Änderungen werden nicht dokumentiert Performed (Bestehende Prozesse) Eingangs- und Ausgangsprodukte sind identifizierbar Kernprobleme im Entwicklungsprozess werden erkannt und erfasst Es werden bestehende firmeninterne Standardprozesse verwendet Mechanismen für Prozessmessungen, Risikomanagement, Validierung und Verifikation wurden vorbereitet Existierende Lösungen werden in die Planung mit einbezogen Managed (Wiederholbare Prozesse) Erzielter Erfolg ist wiederholbar Definierter Entwicklungsprozess Zeit- und Kostenpläne werden eingehalten Anfälligkeit gegen Änderungen und Störungen 2013 IAS, Universität Stuttgart 160

45 3.4 Verbesserung des Softwareentwicklungsprozesses Die 6 Reifegrade des CMMI-Modells (3) Defined (Definierte Prozesse) Softwareprozess ist standardisiert und konsistent Aktivitäten von Softwareentwicklung und Management sind stabil und reproduzierbar Kosten, Zeitpläne, Funktionalität unter Kontrolle Zielqualität wird eingehalten Bewährte Vorgehensweise wird auch bei Krisen beibehalten Quantitatively Managed (Gesteuerte Prozesse) Messungen am Prozess Produktivität und Qualität werden projektübergreifend erfasst Qualität von Softwareprodukten ist hoch und vorhersagbar Prozess- und Produktmetriken werden gesammelt Optimizing (Optimierung der Prozesse) Kontinuierliche Prozessverbesserung Kosten-Nutzen-Analyse über die Wirksamkeit der Prozesse Empfehlungen von Prozessverbesserungen 2013 IAS, Universität Stuttgart 161

46 % der Organisationen 3.4 Verbesserung des Softwareentwicklungsprozesses Weltweite CMMI-Bestandsaufnahme 50% 45% 40% 35% 33,9% 49,0% Bestandsaufnahme Stand Organisationen 30% 25% 20% 15% 10% 10,9% 5% 3,1% 0% 0,0% Keine Angabe: 3,1% Reifegrad Quelle: SEI, IAS, Universität Stuttgart 162

47 3.4 Verbesserung des Softwareentwicklungsprozesses Ergebnisse der Softwareentwicklungsprozessverbesserung Kategorie Bereich Mittelwert Jährliche Kosten für SPI-Tätigkeiten $ $ $ Jahre der Befassung mit SPI 1-9 3,5 Kosten der SPI pro Softwareingenieur $490 - $2004 $1375 Produktivitätssteigerung pro Jahr 9% - 67% 35% Zuwachs an Entwurfsfehlererkennung 6% - 25% 22% Jährliche Reduzierung in Time-to-Market 15% - 23% 19% Rendite (Return-of-Investment) 4,0% - 8,8% 5% Firmen der Studie : Alcatel, Bellcore, BULL, GTE, Hewlett Packard, Hughes Aircraft, IBM Federal, Systems, Lockheed, Motorola, NASA GSFC, Northrop, Philips, Schlumberger, Siemens, Texas Instruments, US Air Force, US Navy Quelle: SEI IAS, Universität Stuttgart 163

48 Fragen zur Vorlesung Frage zu 3.4 Welchen Aussagen stimmen Sie zu? f Die Prozessverbesserung wird einmal jährlich durchgeführt f Durch Prozessverbesserung wird Softwarequalität verbessert Das CMMI definiert 6 Reifegrade Der Reifegrad 4 (Quantitatively Managed) wird sehr häufig von Firmen erreicht 2013 IAS, Universität Stuttgart 164

49 Softwaretechnik I 3 Softwareentwicklungsprozesse und Vorgehensmodelle 3.1 Softwareentwicklungsprozess 3.2 Vorgehensmodelle 3.3 Standardisierte Vorgehensweise 3.4 Verbesserung des Softwareentwicklungsprozesses 3.5 Zusammenfassung 2013 IAS, Universität Stuttgart 165

50 3.5 Zusammenfassung Zusammenfassung Softwareentwicklungsprozesse sind Aktivitäten, die bei Produktion und Entwicklung von Softwaresystemen vorkommen. Diese können in einem Vorgehensmodell dargestellt werden. Allgemeine Aktivitäten sind Anforderungsspezifikation, Entwurf und Implementierung, Validierung und Weiterentwicklung Iterative Vorgehensmodell beschreiben den Softwareentwicklungsprozess als Kreislauf von Aktivitäten Standards ermöglichen Wiederverwendung und Kooperation Das Capability Maturity Model Integration (CMMI) ist ein de-facto Standard zur erfolgreichen Prozessverbesserung 2013 IAS, Universität Stuttgart 166

51 3.5 Zusammenfassung Vorbereitungsfragen zu 3 Frage 1: Vorgehensmodelle (SS 06) Bei einem geplanten Softwareentwicklungsprojekt sind die Anforderungen nicht detailliert verfügbar. Diese sollen während der Entwicklung verfeinert werden. Ihr Kunde verlangt darüber hinaus, dass seine Wünsche zeitnah in die Systemfunktionalität einfließen und somit verfügbar sind. a) Welches Vorgehensmodell empfehlen Sie zur Durchführung des Projekts? Welches Vorgehensmodell würden Sie auf keinen Fall vorschlagen? Begründen Sie Ihre Antworten. b) Welches Vorgehensmodell würden Sie auf keinen Fall vorschlagen? Begründen Sie Ihre Antwort. Frage 2: Welche Aussagen zu Vorgehensmodellen sind richtig? (WS 05/06) Beim Einsatz des evolutionären Modells sollte die Anzahl der Iterationen im Vertrag zwischen Entwickler und Kunde festgelegt werden. Das oberste Ziel des Spiralmodells ist die Minimierung des Risikos durch wiederkehrendes Durchlaufen der einzelnen Phasen. Bei der inkrementellen Entwicklung werden Kundenwünsche explizit berücksichtigt IAS, Universität Stuttgart 167