ALLG. METHODEN DES SOFTWAREEINGINEERING

Transkript

1 Vorgehens- und Prozessmodelle ALLG. METHODEN DES SOFTWAREEINGINEERING

2 Ziel der Veranstaltung Evolution der Modelle des Software Engineering Übersicht der Modelle Vorgehensmodelle Prozessmodelle Aufbau eines Modells am Beispiel von V-Modell XT 2

3 Was sind Modelle? Modelle dienen zur Vereinfachung Strukturierung Dokumentation der Realität Ein Modell beschreibt die Realität aus einer Perspektive Verringerung der Komplexität durch Abstraktion Verallgemeinerung, Theoretisierung Typisierung relevanter Sachverhalte 3

4 Wozu werden die Modelle eingesetzt? Strukturierung und Visualisierung des Systems und aber auch der Vorgehensweise durch Abstraktion Dadurch Berücksichtigung aller System/Prozess-Aspekte Validierung des Kurses (aus der Sicht der Projektleitung) Orientierung (aus der Sicht des Mitarbeiters) 4

5 Übersicht der Modelle Auszug 5

6 Weshalb sind so viele Modelle vorhanden? Wandlung des Komplexität in der Software-Entwicklung Algorithmen betriebliche/ verteilte Systeme Anpassung an moderne Entwicklungskonzepte und Paradigmen (z.b. OOP) Anpassung an Vorschriften und andere Regularien Anpassung an die Wandlung der allgemeinen Kommunikationsund Arbeitstechniken 6

7 Welche Modelle betrachten wir? Vorgehensmodelle Code an Fix Sequentielles Phasenmodell Das Wasserfallmodell Prototyping Prozessmodelle V-Modell XT Unified Process / RUP 7

8 Vorgehensmodelle vs. Prozessmodelle Vorgehensmodelle beschreiben die Entwicklungsstrategien beschreiben das WAS = Teilen des Entwicklungsprozesses in überschaubare, zeitlich und inhaltlich begrenzte Phasen Prozessmodelle dienen zur Benennung und Ordnung von Tätigkeiten im Rahmen der Softwareentwicklung sind (meist) generische Modelle betrachten die Software-Entwicklung als eine organisatorische Herausforderung versuchen das WIE zu beschreiben 8

9 Code and Fix Anwendungsentwicklung ohne feste Vorgaben und Ziele Ziel: Ausführbare und schnell produzierte Ergebnisse durch try and error A-hoc-Tests validieren die Entwicklungsergebnisse Meist genutzte Vorgehensweise (unbewusst) 9

10 Code and Fix Vorteile Schnelle und sichtbare Ergebnisse lauffähiges Programm Codieren nach Wissen und Gewissen Wenige bis keine administrativen Rand- und QS-Aktivitäten 10

11 Code and Fix Nachteile Keine Projektplanung möglich, da keine Anforderungen und somit Ziele vorhanden Subjektive Wahrnehmung des Problems > subjektive Lösung des Problems Kein Soll/Ist-Vergleich möglich Fehlende Konzeption verhindert Entwicklung in Arbeitsgruppen Starke Abhängigkeit vom Programmierer/Wissensträger 11

12 Sequentielles Phasenmodell Synonym für software life cycle (gepr. Rosove, 1967) Teilt den Lebenslauf eines Software-Produktes in Phasen Eine Phase basiert auf den Ergebnissen der vorgelagerten Phase Eine Phase darf erst dann begonnen werden, wenn die Vorgängerphase vollständig abgeschlossen ist 12

13 Software-Lebenszyklus 13

14 Sequentielles Phasenmodell Phase Problemanalyse und Grobplanung Ziele Ermittlung der Anforderungen Festlegung der erforderlichen Aktivitäten Identifikation von Wechselwirkungen und Abhängigkeiten Abschätzung des zeitlichen und finanziellen Aufwands Aktivitäten Aufnahme des IST-Zustandes Abgrenzung des Problembereichs Grobe Skizzierung der Systemstruktur Erstellung eines Projektplans 14

15 Sequentielles Phasenmodell Phase Systemspezifikation und Planung Ziele Klare Festlegung der externen Funktionalität Zustimmung des Auftraggebers Endgültige Festlegung von Zeitbedarf und Kosten Aktivitäten Festlegung der Systemarchitektur Beschreibung des logischen Datenmodells Ergebnisse: Spezifikation 15

16 Sequentielles Phasenmodell Phase Systementwurf Ziele Festlegung der internen Struktur Zahl und Funktionalität aller Komponenten Aktivitäten Definition der einzelnen Komponenten Definition aller internen Schnittstellen Beschreibung der erforderlichen Algorithmen Ergebnisse Interne Spezifikation 16

17 Sequentielles Phasenmodell Phase Implementierung und Komponententest Ziele Ablauffähiges Softwaresystem Funktionsfähige Komponenten Aktivitäten Verfeinerung aller Algorithmen und Modelle Codierung aller Komponenten Austesten aller Einzel-Komponenten Ergebnisse Quellcode Testberichte 17

18 Sequentielles Phasenmodell Phase Systemtest und Integration Ziele Einsatzfähiges Softwaresystem Systemabnahme Aktivitäten Intensive funktionale Systemtests Belastungstests Abnahmetest Ergebnisse Kompiliertes System Abnahme-Protokoll 18

19 Sequentielles Phasenmodell Phase Betrieb und Wartung Ziele Langfristig stabiler Betrieb Erweiterbarkeit Aktivtäten Laufende Fehlerbehebung Realisierung neuer Anforderungen Aktualisierung der Dokumentation Ergebnisse: Fehlerbehebungen Releases und Versionen 19

20 Sequentielles Phasenmodell Vorteile Sequentielles Phasenmodell liefert einen klaren Rahmen Definiert die wichtigsten Tätigkeiten des Entwicklungsprozesses Unabhängig vom Anwendungsgebiet, von der Projektgröße und von der Komplexität Ermöglicht einen arbeitsteiligen Entwicklungsprozess Immer wieder aktuell und modern (z.b. sicherheits-kritische Systeme) 20

21 Sequentielles Phasenmodell Nachteile Das Modell basiert auf einer streng sequentiellen Vorgehensweise Starke Trennung zwischen den einzelnen Stadien, keine Überlappung dieser möglich Iteration unklar definiert bzw. nicht vorhanden Greifbare Ergebnisse/Halbfabrikate liegen sehr spät vor 21

22 Das Wasserfallmodell Basiert auf dem Software-Lebenszyklus (gepr. von Royce, 1970) Top/Down-Vorgehen und sequentielle Vorgehensweise Besteht aus Aktivitäten, die sequentiell abgearbeitet werden Abgeschlossene Dokumentation am Ende jeder Aktivität Iteration nur zwischen zwei aufeinander folgenden Stufen 22

23 Das Wasserfallmodell nach Boehm Rückkopplung Phasen aus dem Software-Lebenszyklus 23

24 Das Wasserfallmodell Aktivitäten Beschreiben Ziele Können Teilaktivitäten enthalten Definieren Ergebnisse Weise Rollen und Verantwortlichkeiten zu 24

25 Das Wasserfallmodell Beispiel: Aktivität Systemtest Ziele Teilaktivitäten Ergebnisse Beteiligte Systematische Prüfung des Systems auf der Basis der Testspezifikation 1. Herstellen der Testumgebung 2. Installation des Prüflings in der Testumgebung gemäß Installationsbeschreibung 3. Durchführung der Tests gemäß Testspezifikation 4. Notieren aller entdeckten Fehler mit Hilfe des Problemlösungsformulars 5. Prüfen, ob durchgeführte Korrekturen erfolgreich waren 6. Schreiben des Testberichts 1. Beta-Release des Systems 2. Testbericht 3. Liste der entdeckten Fehlern Test-Ingenieur 25

26 Das Wasserfallmodell Vorteile Einfaches Modell, klare Abgrenzungen Disziplinierter, kontrollierbarer und sichtbarer Prozessablauf Sehr breiter Bekanntheitsgrad 26

27 Das Wasserfallmodell Nachteile Keine Unterstützung von parallelen Aufgaben Gefahr durch starke Gewichtung der Dokumentation Beschreibt hauptsächlich Programmerstellung, weniger den Managementprozess Im Wasserfallmodell werden keine Verantwortlichen definiert 27

28 Das Wasserfallmodell Nachteile Anforderungen oft zu Beginn nicht vollständig klar bzw. nicht stabil Keine iterative Entwicklung Ergebnisse sind erst nach dem Ende einer Phase einsehbar Lauffähige Version erst sehr spät verfügbar 28

29 Prototyping Was wird unter einem Prototyp verstanden? Schnell und mit einem geringen Aufwand erstellte Software- Halbfabrikate Simulieren das Endprodukt Einfach zu ändernde Modelle des geplanten Software-Produkts Sind größtenteils ausführbar 29

30 Prototyping Wozu werden Prototypen eingesetzt? Klärung von offenen Anforderungen des Klienten Findung eines besten Lösungsansatzes durch die Erfahrung bei der Realisierung Vervollständigung der Spezifikation Achtung: Ein Prototyp ersetzt keine Spezifikation! 30

31 Prototyping Beispiele von Prototypen (I) Demonstrations-Prototyp Vorführung von Einsatzmöglichkeiten Propagieren der Vision > Vermitteln von ersten Eindrucken Vereinfachung der Entscheidungsfindung in der Start- / Aquisitionsphase Labormuster Modellierung des Zielsystems Aufbau eines Experementalsystems 31

32 Prototyping Beispiele von Prototypen (II) Funktionale Prototypen Modellieren (i.d.r.) der Bedienungsoberfläche Vereinfachen die konzeptionellen Entscheidungen auf der operativen Ebene Pilotsysteme Realisieren einen abgeschlossenen Teil des Zielsystems Ermöglichen ersten Betrieb Schrittweiser Ausbau 32

33 Prototyping Exploratives Prototyping Ziel: Möglichst vollständige Spezifikation Zweck: Einblicke in den Anwendungsbereich für die Entwickler Unterstützung der Analyse involvieren des Klienten in die Gestaltungs- und Entscheidungsprozesse Einsatz: Demonstrations-Prototyp, Funktionaler Prototyp 33

34 Prototyping Experimentelles Prototyping Ziel: Vollständige Spezifikation von Teilsystemen Zweck: Prüfung der Tauglichkeit von Teilspezifikationen Prüfung der Machbarkeit von technischen Lösungsansätzen Unterstützung bei System- und Komponentendesign Konkretisierung von Anforderungen (Technik, Ergonomie) Einsatz: Funktionaler Prototyp, Labormuster 34

35 Prototyping Evolutionäres Prototyping Ziel: Inkrementelle Systementwicklung Zweck: Nutzung des stabilen Produkts als Grundlage für neue Anforderungen Ausbau des Produktes um neue Funktionalitäten ->Frage: Unterschied zum normalen Customizing? Einsatz: Pilotsysteme 35

36 Prototyping Prototyping-orientiertes Modell 36

37 Prototyping Vorteile Die Anforderungen der Anwender können laufend präzisiert und verifiziert werden Höhere Überstimmung mit Benutzererwartungen Risiko der Fehlentwicklung sinkt, die Qualitätssicherung kann frühzeitig eingebunden werden Frühzeitige Validierung auf der technischen Ebene 37

38 Prototyping Nachteile Verführung, Anforderungen weder korrekt zu erheben noch sauber zu dokumentieren Never-ending-story, weil Anforderungen laufend definiert werden Interimslösung wird zum Produkt -> Nichts hält länger als Provisorium Es entstehen während der Entwicklung zusätzliche Kosten 38

39 39

40 Das V-Modell Entstanden für die Realisierung von IT-Projekten der öffentlichen Hand (Boehm, 1979, 1986) V steht für Vorgehen und symbolisiert das Modell Ziele Minimierung der Projektrisiken Verbesserung und Gewährleistung der Qualität Verbesserung der Kommunikation zwischen allen Beteiligten Frei verfügbar unter: 40

41 Das V-Modell Der Kern QS und Validierung auf jeder Ebene Anwendungsszenarien Systemtest Integrationstests Modultest Projektfortschritt 41

42 Das V-Modell Modulübersicht Projektfortschritt 42

43 Das V-Modell XT Ausbau zum vollständigen Prozessmodell Modernisierung und Erweiterung des V-Modells (2005) Aktivitätsorientiertes Prozessmodell, logisch verknüpftes Netz von Aktivitäten und Produkten Zusammenfassung von Aktivitäten in Phasen, die mit einem Entscheidungspunkt/Meilenstein abgeschlossen werden Definiert was gemacht werden muss, aber nicht wie, Anpassung an die Projekttypen > Tailoring 43

44 Das V-Modell XT Elemente des Modells (I) Aktivitäten Erstellen Produkte Werden in Aktivitätsgruppen zusammengefasst Können Teilaktivitäten unterteilt werden Produkte Ergebnisse und Zwischenergebnisse Werden in Produktgruppen/Themen zusammengefasst Zu jeder Aktivitätsgruppe wird eine korrespondierende Produktgruppe definiert 44

45 Das V-Modell XT Beispiel: Aktivitäten und Produkten Die Reihenfolge beschreibt die Abhängigkeit der Aktivitäten voneinander Jede Aktivität endet mit einem Produkt 45

46 Das V-Modell XT Elemente des Modells (II) Rollen Beschreiben zusammengehörende Aufgaben und Verantwortlichkeiten Produkten werden zu Rollen zugeordnet Vorgehensbausteine Zusammenfassung aller Rollen, Produkte und Aktivitäten Obligatorische Vorgehensbausteine Optionale Vorgehensbausteine 46

47 Das V-Modell XT Beispiel: Rollen 47

48 48

49 Das V-Modell XT Elemente des Modells (III) Entscheidungspunkte Entsprechen den Meilensteinen Teilen das Projekt in Teilabschnitte Definition der Produkte, die erstellt werden müssen Projektdurchführungsstrategien Ordnung einer Menge von zusammengehörenden Entscheidungspunkte Vergabe der zeitlichen Reihenfolge Unterstützung durch einen Assistenten (Demo) 49

50 Das V-Modell XT Dokumentation 50

51 Das V-Modell XT Vorteile Sehr detaillierte Darstellung Anpassung an projektspezifische Anforderungen Integration vieler Aspekte des Entwicklungsprozesses Standardisierung der Abwicklung von Systemerstellungsprojekten Hilfreich in Organisationen mit wenig/ohne SW-Entw-Know-how Kostenlos verfügbar 51

52 Das V-Modell XT Nachteile Zu allgemein für kleine und mittlere Software-Projekte Sehr bürokratisch, da große Dokumentenflut, viele Entscheidungsvorgänge Sehr viel Raum für Interpretationen offen 52

53 Unified Process-Modell Entstanden mit dem OOP-Paradigma (Jacobson, 1987) UP ist ein Phasenmodell Vier Phasen => ein Zyklus Definierte Arbeitsabläufe in jeder Phase Das Ergebnis eines Zyklus ist ein Release (lauffähiges Produkt) UP ist iterativ, ein Release entsteht inkrementell UP basiert auf der Verwendung von Use Cases 53

54 Rational Unified Process-Modell (RUP) Ausbau des Unified Process-Modells (UP) zu einem vollwertigen Prozessmodell durch RUP Grundkonzepte des UP werden erweitert und konkretisiert Beschreibung und Visualisierung von Arbeitsabläufen in UML- Aktivitätsdiagrammen 54

55 Unified Process-Modell Elemente des Modells Rolle/Worker Zusammenfassung von Aufgaben, Verantwortlichkeiten und Fähigkeiten Worker kann unterschiedliche Rollen annehmen Aktivität Eine Tätigkeit, die von Rolle in einem Arbeitsablauf durchgeführt wird Aktivität liefert ein definiertes Ergebnis Artefakte Formulierte Information Dokumente Modelle 55

56 Unified Process-Modell Phasen (I) Inception / Konzeption Ziel: Ausarbeitung (Identifikation und Modellierung) eines Geschäftsfalls Evtl. Aufbau eines ersten Prototypen Elaboration / Entwurf Aufdeckung aller fehlenden Anforderungen Festlegung der Architektur > Prototyp Projektplan und Risikenbeurteilung 56

57 Unified Process-Modell Phasen (II) Construction / Konstruktion Implementierung, Integration und Test des Systems Ausrollen einer Beta-Version des Zielsystems Verteilung erster Benutzerdokumentation Transmission / Übergabe Stabilisierung des Betriebs (anhand der Rückmeldungen) Vervollständigung der Betriebs- und Benutzerdokumentation Endabnahme durch Klienten 57

58 Unified Process-Modell Iterationen Eine Iteration 58

59 Rational Unified Process Vorteile Risikofaktoren können schnell erkannt werden Abstimmung der Komponenten zur Entwicklungszeit Use Cases und UML als Basis Gewährleistung der Aktualität und des Supports durch Rational Software Ausgezeichnete Dokumentation und hoher Detaillierungsgrad 59

60 Rational Unified Process Nachteile Schwierige Anpassung, da RUP spezielle Gegebenheiten einer Entwicklungsorganisation adressiert RUP ist ein komplexes und dynamisches Vorgehensmodell Keine Qualitätssicherung im RUP integriert Setzt starkes Änderungsmanagement voraus Für Software-Häuser vorteilhaft Kommerzielles Produkt / setzt oft Werkzeuge voraus 60

61 Zusammenfassung Verfahrensmodelle Code an Fix Software-Lebenszyklus Das Wasserfallmodell Prototyping Prozessmodelle V-Modell XT Unified Process / RUP 61

62 Literaturquellen Pomberger, G., Blasckek, G.: Software Engineering. Prototyping und objektorientierte Software-Entwicklung Sommerville, I.: Software Engineering Ludewig, J., Lichter, H.: Software Engineering. Grundlagen, Menschen, Prozesse, Techniken o.v.: Das V-Modell, IABG Industrieanlagen-Betriebsgesellschaft mbh, Verfügbar im Internet unter abgerufen am