4. Organisation: Prozess-Modelle

Transkript

1 Software Management 4. Organisation: Prozess-Modelle 1

2 Übersicht der Vorlesung Grundlagen Planung Organisation: Gestaltung Organisation: Prozess-Modelle Personal Leitung Innovationsmanagement Kontrolle: Metriken, Konfigurations- und Änderungsmanagement 9. CASE 10. Wiederverwendung 11. Sanierung 2

3 Gliederung 1. Einführung 2. Das Wasserfall-Modell 3. Das V-Modell 4. V-Modell XT 5. Das Prototypen-Modell 6. Das evolutionäre/inkrementelle Modell 7. Das objektorientierte Modell 8. Das nebenläufige Modell 9. Das Spiralmodell Begleitliteratur: Helmut Balzert, Lehrbuch der Software-Technik Quelle der Grafiken und Tabellen: Helmut Balzert, Lehrbuch der Software-Technik, wenn nicht anders angegeben 3

4 Prozessmodell Prozessmodell legt den Organisationsrahmen fest, in dem eine Software-Erstellung erfolgt. Grundmodell der Anfangstagen der Software-Technik: code & fix [Boehm 88]. Reihenfolge des Arbeitsablaufs. Jeweils durchzuführende Aktivitäten. Definition der Teilprodukte einschließlich Layout und Inhalt. Fertigstellungskriterien. Notwendige Mitarbeiterqualifikation. Verantwortlichkeiten und Kompetenzen. Prozess-Modell legt fest... Anzuwendende Standards, Richtlinien, Methoden und Werkzeuge. 4

5 Das Wasserfall-Modell Wasserfallmodell: Weiterentwicklung des stagewise models [Benington 56]. Wasserfallmodell von [Royce 70] erweitert das stagewise model um Rückkopplungsschleifen zwischen den Stufen. SystemAnforderungen SoftwareAnforderungen Analyse Entwurf Codierung Testen Betrieb Wasserfall mit ursprünglichen Phasen 5

6 Wasserfall-Modell normierte Darstellung Iterationszyklen Definieren Änderungen Benutzerbeteiligung Produktmodell Entwerfen Änderungen Produktarchitektur Implementieren Produkt 6

7 Wasserfall-Modell - Zusammenfassung 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. Der Entwicklungsablauf ist sequentiell. Es orientiert sich am top-down Vorgehen. Es ist einfach, verständlich und benötigt nur wenig Managementaufwand. Merkmale Eine Benutzerbeteiligung ist in der Definitionsphase vorgesehen. Vollständige Durchführung aller Entwicklungsschritte nicht immer sinnvoll. Sequentielle Durchführung aller Entwicklungsschritte nicht immer sinnvoll. Gefahr einer falschen Prioritätsverteilung (Dokumente-System). Nachteile Keine Berücksichtigung der Risikofaktoren. 7

8 V-Modell nach Boehm Erweiterung des Wasserfall-Modells durch Integration einer expliziten Qualitätssicherung 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? Anwendungsszenarien AnforderungsDefinition Abnahmetest Testfälle Grobentwurf Validierung Systemtest Verifikation Testfälle Feinentwurf Modulimplementazion Testfälle Integrationstest Modultest Quelle: Balzert, H.; Lehrbuch der Software-Technik 8

9 V-Modell normierte Darstellung Definieren Änderungen Anwendungs szenarien Produktmodell Entwerfen Änderungen Änderungen Änderungen Änderungen Produltarchitektur Integrations testfälle Module implementieren Modul x Module testen Testfall y Integration testen Getest. Modul x Integriertes Sys. System testen Produkt 9

10 V-Modell - Submodelle Legt die Aktivitäten und Produkte des Entwicklungs- und Pflegeprozesses fest. Produktzustände und logische Abhängigkeiten zwischen Aktivitäten und Produkten werden dargestellt. Vier Submodelle: Systemerstellung (SE), Qualitätssicherung (QS), Konfigurationsmanagement (KM), Projektmanagement (PM). Erzeugnisstruktur des V-Modells 10

11 V-Modell IT System IT-System Segment mit IT-Anteil Kann entfallen Segment mit IT-Anteil Kann entfallen SegmentEbene SW-Einheit/ HW-EinheitEbene HW-Einheit SW-Komponente Können entfallen SW-Komponente Segment ohne IT-Anteil Segment ohne IT-Anteil SW-Einheit SW-Modul System-Ebene Datenbank HW-Komponente KomponentenEbene HW-Komponente Modul/Datenbank-Ebene HW-Modul 11

12 V-Modell Aktivitäten und Produkte Grundelemente des V-Modells sind Aktivitäten und Produkte. Aktivität: Tätigkeit, die bezogen auf ihr Ergebnis und ihre Durchführung genau beschrieben werden kann. Produkt: Ergebnis bzw. Bearbeitungsgegenstand einer Aktivität. Ziel einer Aktivität: Erstellung eines Produkts, Änderung des Zustands eines Produkts, Änderung des Inhalts eines Produkts. 12

13 V-Modell Aktivitäten und Produkte Zulässige Zustandsübergänge von Produkten geplant In Bearbeitung vorgelegt Akzeptiert *) *) Wird durch das Konfigurationsmanagement verursacht und führt zu einer neuen Produktversion 13

14 V-Modell Produkte des Submodells: Systemerstellung SW-Einheit Technische Anforderungen SW-Architektur Betriebsinformationen Implementierungsdokumente Integrationsplan IT-System/Segment Anwenderanforderungen Systemarchitektur Technische Anforderungen Schnittstellenübersicht Schnittstellenbeschreibung Integrationsplan SWPÄ-Konzept Betriebsinformationen SW-Komponente SW-Entwurf Datenkatalog Implementierungsdokumente HW-Einheit Technische Anforderungen SW-Architektur Zeichnungssatz Realisierungsdokumente Analysebericht SW-Modul SW-Entwurf Datenkatalog Implementierungsdokumente Datenbank SW-Entwurf Datenkatalog Implementierungsdokumente 14

15 V-Modell Zusammenwirken der 4 Submodelle Projekt planen und kontrollieren QS-Ergebnis IstPlanDaten daten Voraussetzungen schaffen und Softwareentwicklungsumgebung bereitstellen Projektmanagement Ist-Daten SEU QS-Anforderungen vorgeben Produkte prüfen Qualitätssicherung SEU IstPlanDaten daten SEU IstPlanDaten daten Systemerstellung SEU Produktstruktur planen Produkt entwickeln QS-Anforderung Plandaten Konfig. Strukt. Rechte Produkt Produkt Produkte/Rechte verwalten Konfigurationsmanagement 15

16 V-Modell - Rollen Rollen im V-Modell Beschreiben die notwendigen Erfahrungen, Kenntnisse und Fähigkeiten, um Aktivitäten durchzuführen. In jedem Submodell gibt es: einen (Projekt)Manager, einen Verantwortlichen (Projektleiter), einen oder mehrere Durchführende (Projektadministrator,..., KM-Administrator). 16

17 V-Modell Rollen Manager Verantwortliche Durchführende PM Projektmanager Projektleiter Rechtsverantwortlicher Controller Projektleiter Projektadministrator SE Projektmanager IT-Beauftragter Anwender Projektleiter Systemanalytiker Systemdesigner SW-Entwickler HW-Entwickler Technischer Büro SEU-Betreuer Datenadministrator IT-Sicherheitsbeauftragter Datenschutzbeauftragter Systembetreuer QS Q-Manager QS-Verantwortlicher Prüfer KM KM-Manager KM-Verantwortlicher KM-Administrator Rollen im V-Modell 17

18 V-Modell - Organisationsanalyse Organisationsanalyse Folgende Aspekte sind zu berücksichtigen: Organisationsanalyse vorbereiten, Geschäfteprozesse aufnehmen, Geschäftsprozesse analysieren, Analyseergebnisse auswerten. Ergebnisse dienen als Ausgangspunkt für die Definition von Anforderungen Basis für eine nachfolgende Geschäftsprozessmodellierung. 18

19 V-Modell - Tailoring Tailoring Tailoring =Maßschneidern Zwei Stufen: Ausschreibungsrelevante Tailoring Technisches Tailoring Ziel: Vermeiden einer übermäßigen Papierflut sowie sinnloser Dokumentation, Vermeiden vom Fehlen wichtigen Dokumente. 19

20 V-Modell - Zusammenfassung Bewertung Integrierte, detaillierte Darstellung von Systemerstellung, QS, KM und PM. Generisches Vorgehensmodell mit definierten Möglichkeiten der Anpassung. Standardisierte Abwicklung von Systemerstellungsprojekten. Vorteile Gut geeignet für große Projekte, insbesondere für eingebettete Systeme. Die für eingebettete Systeme sinnvolle Vorgehenskonzepte unkritisch übertragbar Unnötige Produktvielfalt und Software-Bürokratie (kleine und mittlere Software-Entwicklungen) Nicht handhabbar ohne geeignete CASE-Unterstützung. Unrealistische Rollendefinition (außer für Großprojekte). Es fehlen in der Dokumentation vollständige Beispiele. Gefahr, dass bestimmte Software-Methoden festgeschrieben werden Nachteile 20

21 V-Modell XT - Überblick V-Modell XT - das Vorgehensmodell für IT-Projekte Nachfolger des V-Modells 92 und 97 XT Standard in der Bundesverwaltung Für Auftraggeber, Auftragnehmer und Bundesrepublik Deutschland, 2004, Alle Rechte vorbehalten Projektorganisationen nutzbar Ca. 700 Seiten Umfang, liegt als HTML und PDF vor Quelle: Thomas Klingenberg, microtool GmbH 21

22 V-Modell XT - Historie Das V-Modell XT - ein modulares Vorgehensmodell XT= extreme Tailoring WEIT-Projekt KBSt/IT-AmtBw TU München / TU Kaiserslautern und Partner XT Bundesrepublik Deutschland, 2004, Alle Rechte vorbehalten Kosten ca. 4 Mio., ca. 30 beteiligte Personen Nach WEIT geht s immer WEITER... Version 1.2 seit dem 1. Februar 2006 Quelle: Thomas Klingenberg, microtool GmbH 22

23 V-Modell XT - Grundlagen Vorgehensbausteine Kapseln Aktivitäten, Produkte und Rollen sind die modularen Einheiten für das Tailoring können von anderen Vorgehensbausteinen abhängen XT Bundesrepublik Deutschland, 2004, Alle Rechte vorbehalten Quelle: Thomas Klingenberg, microtool GmbH 23

24 V-Modell XT - Vorgehensbausteinkarte Quelle: Thomas Klingenberg, microtool GmbH 24

25 Was ist neu am V-Modell XT 1.2? Multiprojektmanagement für Auftraggeber Veränderte Projektdurchführungsstrategien: Iterationen und Parallelitäten in der Planung XT Bundesrepublik Deutschland, 2004, Alle Rechte vorbehalten Neuer Projekttyp Systementwicklung AG/AN Quelle: Thomas Klingenberg, microtool GmbH 25

26 Multiprojektmanagement für Auftraggeber Vergabe und Durchführung eines Systementwicklungsprojektes (AG) Quelle: Thomas Klingenberg, microtool GmbH 26

27 Multiprojektmanagement für Auftraggeber Gemeinsames Planen der Iterationen Quelle: Thomas Klingenberg, microtool GmbH 27

28 Multiprojektmanagement für Auftraggeber Vergabe und Durchführung mehrerer Systementwicklungsprojektes (AG) Quelle: Thomas Klingenberg, microtool GmbH 28

29 Was ist neu am V-Modell XT 1.2? Multiprojektmanagement für Auftraggeber Veränderte Projektdurchführungsstrategien: Iterationen und Parallelitäten in der Planung XT Bundesrepublik Deutschland, 2004, Alle Rechte vorbehalten Neuer Projekttyp Systementwicklung AG/AN Quelle: Thomas Klingenberg, microtool GmbH 29

30 Projektdurchführungsstrategien Inkrementelle Systementwicklung (AN) Quelle: Thomas Klingenberg, microtool GmbH 30

31 Projektdurchführungsstrategien Inkrementelle Systementwicklung (AN) mit Unteraufträgen Quelle: Thomas Klingenberg, microtool GmbH 31

32 Projektdurchführungsstrategien Komponentenbasierte Systementwicklung (AN) Quelle: Thomas Klingenberg, microtool GmbH 32

33 Projektdurchführungsstrategien Agile Systementwicklung (AN) Quelle: Thomas Klingenberg, microtool GmbH 33

34 4. Projektdurchführungsstrategien Wartung und Pflege von Systemen (AN) Quelle: Thomas Klingenberg, microtool GmbH 34

35 Was ist neu am V-Modell XT 1.2? Multiprojektmanagement für Auftraggeber Veränderte Projektdurchführungsstrategien: Iterationen und Parallelitäten in der Planung XT Bundesrepublik Deutschland, 2004, Alle Rechte vorbehalten Neuer Projekttyp Systementwicklung AG/AN Quelle: Thomas Klingenberg, microtool GmbH 35

36 Systementwicklung AG/AN Die Trennung in Auftraggeber und Auftragnehmer passt nicht immer! Quelle: Thomas Klingenberg, microtool GmbH 36

37 Systementwicklung AG/AN Neuer Projekttyp Systementwicklung AG/AN Für Projekte innerhalb einer Organisation oder in zwei eng kooperierenden Organisationen wo es nur 1 Projektleiter gibt. Trotzdem erfolgt die Trennung in die fachliche fachliche und technische Sicht technische Sicht, daher AG/AN Quelle: Thomas Klingenberg, microtool GmbH 37

38 4. Systementwicklung AG/AN Die Projektdurchführungsstrategien des Projekttyps Systementwicklung (AG/AN) als Kombinationslösung Quelle: Thomas Klingenberg, microtool GmbH 38

39 Systementwicklung AG/AN Inkrementelle Systementwicklung (AG/AN) Quelle: Thomas Klingenberg, microtool GmbH 39

40 Systementwicklung AG/AN Komponentenbasierte Systementwicklung (AG/AN) Quelle: Thomas Klingenberg, microtool GmbH 40

41 Systementwicklung AG/AN Agile Systementwicklung (AG/AN) Quelle: Thomas Klingenberg, microtool GmbH 41

42 Systementwicklung AG/AN Wartung und Pflege von Systemen (AG/AN) Quelle: Thomas Klingenberg, microtool GmbH 42

43 Das Prototypen-Modell Unterschiede zwischen einem Software-Prototypen und einem Prototypen in anderen Ingenieursdisziplinen. Ein SoftwarePrototyp: ist nicht das erste Muster einer großen Serie von Produkten (da Vervielfältigung kein Ingenieursproblem). zeigt ausgewählte Eigenschaften des Zeilproduktes im praktischen Einsatz. Ähnlichkeiten in der Anwendung der Prototypen: Sie werden verwendet, um relevante Anforderungen oder Entwicklungsprobleme zu klären. Sie dienen als Diskussionsbasis und helfen bei Entscheidungen. Sie werden für experimentelle Zwecke verwendet und um praktische Erfahrungen zu sammeln. Prototypen-Modell unterstützt die Erstellung ablauffähiger Modelle des zukünftigen Produkts. 43

44 Das Prototypen-Modell Vier Arten von Prototypen: Demonstrationsprototyp, Prototyp im engeren Sinne (für Analyse im Anwendungsbereich), Labormuster, Pilotsystem. Klassifikation aus der Sicht des fertigen Software-Produkts: Horizontaler Prototyp, Vertikaler Prototyp. Beziehungen zwischen Prototypen und Software-Systemen: Prototypen dienen zur Klärung von Problemen. Ein Prototyp ist Teil der Produktdefinition. Prototypen werden inkrementell weiterentwickelt, um ein marktfähiges Produkt zu erhalten. 44

45 5. Das Prototypen-Modell Horizontaler und vertikaler Prototyp Benutzungsoberfläche Horizontaler Prototyp Anwendung Horizontaler Prototyp Netzanbindung Datenhaltung Benutzungsoberfläche Vertikaler Prototyp Vertikaler Prototyp 45

46 Das Prototypen-Modell Planen Änderungen Demo-PT Akquirieren Durchführbarkeitsstudie Definieren PT i.e.s. Produktmodell Entwerfen Änderungen Labormuster Erweiterung des Benutzers Produktarch. Implementieren Produkt Pilotsystem 46

47 Prototypen-Modell - Zusammenfassung Bewertung Reduzierung des Entwicklungsrisikos. Kann sinnvoll in andere Prozessmodelle integriert werden. Prototypen können durch Werkzeuge erstellt werden. Verbessert die Planung der Software-Entwicklung. Vorteile Labormuster fordern die Kreativität für Lösungsalternativen. Starke Rückkopplung mit dem Endbenutzer und dem Auftraggeber. Höherer Entwicklungsaufwand. Gefahr der Integration eines Wegwerf-Prototyps im Produkt. Verträge für die Software-Erstellung berücksichtigen noch nicht das Prototypen-Modell. Prototypen werden oft als Ersatz für die fehlende Dokumentation gesehen. Die Beschränkungen und Grenzen von Prototypen sind oft nicht bekannt. Nachteile 47

48 Evolutionäre Modell Das evolutionäre Modell Ausgangspunkt: Kernanforderungen des Auftraggebers Stufenweise Entwicklung des Produkts. Pflegeaktivitäten gelten als Erstellung einer neuen Version. Charakteristika Gut geeignet, wenn der Auftraggeber seine Anforderungen noch nicht vollständig überblickt. Code-getriebene Entwicklung. 48

49 Evolutionäre Modell normierte Darstellung Nullversion X:=0 Änderungen Definieren Version X X:=X+1 Partielles Modell Entwerfen Version X Änderungen Wünsche Partielle Architektur Implementieren Version X Produkt Version X Das evolutionäre Modell Einsetzen Version X 49

50 Evolutionäre Modell - Zusammenfassung Bewertung Auftraggeber erhält in kurzen Zeitabständen einsatzfähige Produkte. Kann mit dem Prototypen-Modell kombiniert werden. Auswirkungen des Produkteinsatzes gut in die folgende Version einzubringen. Vorteile Richtung der Entwicklung korrigierbar durch schrittweise Entwicklung. Entwicklung nicht nur auf ein einzigen Endabgabetermin ausgerichtet. Gefahr, dass im nachfolgenden Modell die gesamte Architektur überarbeitet werden muss. Gefahr, dass die Nullversion nicht flexibel genug ist, um sich an geplante Evolutionspfade anzupassen. Nachteile 50

51 Inkrementelles Modell Das inkrementelle Modell Nachteile des evolutionären Modells werden bei dem inkrementellen Modell vermieden. Alle Anforderungen an das zu modellierende Produkt werden möglichst vollständig erfasst und modelliert. Es wird aber nur ein Teil der Anforderungen entworfen und implementiert (analog zum evolutionären Modell). Wegen dem vollständigen Analysemodell ist sichergestellt, dass die Erweiterungen zu dem bisherigen System passen. 51

52 Inkrementelles Modell normierte Darstellung Definieren Änderungen If X=0 Vollständiges Produktmodell Mod. Modell Entwerfen Version X X:=X+1 Definiere Änderungen If X>0 Änderungen Partielle Architektur Änderungen Implementieren Version X Wünsche Produkt Version X Das inkrementelle Modell Einsetzen Version X 52

53 7. Das objektorientierte Modell Wiederverwendung Wesentlicher Vorteil einer OO-Entwicklung: Wiederverwendung Wiederverwendungsebenen: Ebene der OOA-Modelle, Ebene der technischen Entwürfe, Ebene der implementierten Klassen und Klassenbibliotheken Wiederverwendungsgebiete: Anwendungs- bzw. branchenspezifische Klassen und Subsysteme, Klassen, die die Anbindung einer Anwendung an die Umgebung ermöglichen, Klassen, die die Anbindung an die Systemsoftware ermöglichen Herkunft der Klassen: frühere Entwürfe, auf dem Markt eingekaufte Klassenbibliotheken 53

54 7. Das objektorientierte Modell Wiederverwendung - Charakteristika Mögliche Zeitpunkte des Einsatzes von wiederverwendbaren Klassen: während der laufenden Entwicklung, am Ende der laufenden Entwicklung, nach einer nachträglichen Analyse abgeschlossener Entwicklungen Starker bottom-up-aspekt aufgrund der Wiederverwendbarkeit Tendenz zur Entwicklung in voller Breite. Charakteristika Fokus auf Wiederverwendung. Gut kombinierbar mit dem evolutionären, dem inkrementellen und dem Prototypen-Modell. 54

55 7. Das objektorientierte Modell Quader der Wiederverwendbarkeits-Klassifikation t ge OOA-Modelle z.b. GUIModelle OOD-Modelle OOD-Modelle OOA-Modelle ge ei n t ge OOD-Modelle ge ei Anwendung Anwendungsanbindung BasisKlassenBibliotheken ge ei uf a k n ge OOP-Klassen- z.b. GUIKlassenBibliotheken Bibliotheken uf a k u ka ft n Systemanbindung 55

56 7. Das objektorientierte Modell 56

57 7. Das evolutionäre/inkrementelle Modell Bewertung Verbesserung der Produktivität und Qualität; Vorteile Konzentration auf die eigenen Stärken, Rest zukaufen. Null voll nutzbar, wenn OO-Methoden eingesetzt werden. Geeignete Infrastruktur (Widerverwendungsarchiv) muss vorhanden sein. Firmenkultur der Wiederverwendung muss aufgebaut sein. Nachteile Technische Probleme müssen überwunden werden. 57

58 8. Das nebenläufige Modell Das nebenläufige Prozess-Modell stellt einen Ansatz dar, um eine termingerechte Fertigstellung zu erreichen [Spectrum 91]. Stammt aus der Fertigungsindustrie. Alle betroffenen Entwicklungsabteilungen sind in einem Team vereint. Es soll ein möglichst hoher Parallelisierungsgrad erreicht werden. Risiken der Parallelisierung: Verwendung unreifer Entwürfe führt zu Verschrottung der Werkzeuge. Erfordert ein ständiges Abwägen zwischen finanziellen Risiken und vorzeitiger Parallelisierung von Arbeitsfolgen. 58

59 8. Das nebenläufige Modell Definieren Kernsystem Partielles Modell Änderungen Entwerfen Kernsystem erweitertes Modell Partielle Architektur Implementieren Kernsystem Kernsystem Definieren Ausbaustufe 1 Änderungen Änderungen.. Entwerfen Ausbaustufe 2 erweiterte Archi. Implementieren Ausbaustufe 1 Änderungen.... Erweitertes Kernsys. Produkt 59

60 8. Das nebenläufige Modell Versuch einer Parallelisierung des prinzipiell sequentiellen Entwicklungsprozess. Förderung des auf Problemlösung gerichteten Zusammenarbeiten der betreffenden Personengruppen. Reduzierung von Zeitverzögerungen durch: Teilweise Parallelisierung vorwiegend sequentiell organisierter Arbeiten. Minimierung des Ausprobierens und Begrenzung des Improvisierens. Charakteristika Reduktion der Wartezeiten. Frühzeitiges Zusammenbringen aller Erfahrungen der betroffenen Personengruppen. Auslieferung des vollständigen Produkts ist das Ziel. 60

61 8. Das nebenläufige Modell Bewertung Vorteile Frühes Erkennen und Eliminieren von Problemen durch Beteiligung aller betroffenen Personengruppen. Optimale Zeitausnutzung. Es ist fraglich,ob es wegen der speziellen Charakteristika der Software möglich ist, das Ziel right the first time zu erreichen. Risiko, dass die grundlegenden und kritischen Entscheidungen zu spät getroffen werden und dadurch Iterationen nötig werden. Nachteile Hoher Planungs- und Personalaufwand. 61

62 8. Das nebenläufige Modell Bewertung Überprüfung in periodischen Intervallen und u. U. erneute Festlegung des Prozessablaufs in Abhängigkeit von den Risiken. Prozess-Modell nicht für die gesamte Entwicklung festgelegt. Integration anderer Prozess-Modelle als Spezialfälle. Vorteile Fehler und ungeeignete Alternativen werden frühzeitig eliminiert. Flexibles Modell. Leichtere Neudefinition der Entwicklungsziele wenn nötig. Unterstützung der Wiederverwendung von Software. Hoher Managementaufwand. Ungeeignet für kleine und mittlere Projekte. Identifizieren und Managen von Risiken schwierig. Nachteile 62

63 9. Das Spiral-Modell Spiralmodell von [Boehm 86,88] ist Metamodell. Für jedes Produkt und jede Verfeinerungsebene sind 4 Schritte zu durchlaufen. Schritt 1 Identifikation des Teilprodukts. Alternative Möglichkeiten, um das Teilprodukt zu realisieren. Randbedingungen bei den verschiedenen Alternativen. Evaluierung der Alternativen unter Berücksichtigung der Ziele und Randbedingungen. Entwicklung einer kosteneffektiven Strategie im Falle von Risiken. Schritt 2 Festlegung des Prozessmodells für diesen Schritt. Schritt 3 Die Kombination verschiedener Modelle kann vorgenommen werden. Planung des nächsten Zyklus. Überprüfung (re-view) der Schritte 1 bis 3. Einverständnis über den nächsten Zyklus herstellen. Schritt 4 63

64 9. Das Spiral-Modell Das Spiralmodell 64

65 9. Das Spiral-Modell Für Teilprodukte identifizieren: Ziele Alternativen Randbedingungen Ziele Alternativen Randbedingungen Evaluierung der Alternativen Risikobeseitigungsstragie entwickeln Evaluationsergebnisse Risikobeseitigungsstrategie Auswahl eines geeigneten Prozessmodells Anwendung des Prozessmodells Teilprodukt Planung des nächsten Zyklus Überprüfung des Teilproduktes und der Planung Entscheidung 65

66 9. Das Spiral-Modell Risikogetriebenes Modell, bei dem oberstes Ziel die Minimierung des Risikos ist. Jede Spirale stellt einen iterativen Zyklus durch dieselben Schritte dar. Die Ziele für jeden Zyklus werden aus den Ergebnisse des letzten Zyklus abgeleitet. Separate Spiralzyklen können für verschiedene SoftwareKomponenten durchgeführt werden. Keine Trennung in Entwicklung und Wartung. Ziel: Beginne im kleinen, halte die Spirale eng und erreiche die Entwicklungsziele mit minimalen Kosten. Charakteristika Bei der Zielbestimmung werden auch Qualitätsziele aufgeführt. Für jede Aktivität und jeden Ressourcenverbrauch wird gefragt wieviel ist genug?. 66

67 Zusammenfassung Prozessmodell Primäres Ziel Antreibendes Moment Benutzerbeteiligung Charakteristika WasserfallModell min. Managementaufwand Dokumente Gering Sequentiell, volle Breite V-Modell max. Qualität Dokumente Gering Sequentiell, volle Breite, Validation, Verifikation PrototypenModell Risikominimierung Code Hoch Nur Teilsysteme Evolutionäres Modell min. Entwicklungszeit Code Mittel Sofort: nur Kernsystem Inkrementelles min. EntModell wicklungszeit und Risiko Code Mittel Volle Definition dann zunächst nur Kernsystem 67

68 Zusammenfassung Prozessmodell Primäres Ziel Antreibendes Moment Benutzerbeteiligung Charakteristika OO-Modell Zeit und Kostenminimierung Wiederverwendbare Komponenten? Volle Breite in Abh. Von WVKomponenten Nebenläufiges Modell min. Entwicklungszeit Hoch Volle Breite, nebenläufig Spiralmodell Risikominimierung Mittel Entscheidung pro Zyklus über weiteres Vorgehen 68

69 Literatur [Benington 56] Benington H.D., Production of large computer programs [Boehm 81] Boehm B.W., Software Engineering Economics, Prentice Hall [Boehm 84] Boehm B.W., Verifying and validating Software Requirements and Design Specification, IEEE Software [Boehm 86] Boehm B.W., A Spiral Model of Software Development and Enhancement, ACM SIGSOFT [Boehm 88] Boehm B.W., A Spiral Model of Software Development and Enhancement, IEEE [Royce 70] Royce W.W., Managing the development of large software systems, IEEE [Spectrum 91] Special Report: Concurrent Engineering, IEEE Spectrum 69