Software Engineering

Transkript

1 Software Engineering Prof. Adrian A. Müller, PMP Fachbereich Informatik und Mikrosystemtechnik Fachhochschule Kaiserslautern, Standort Zweibrücken Prof. A. Müller, FH KL Software Engineering Winter '12/'13 1

2 Inhalte: Klassische Vorgehensmodelle Wozu dienen Vorgehensmodelle? Welche Arten gibt es? Was sind nicht-klassische (agile) Vorgehensmodelle? Standard Vorgehensmodell Wasserfallmodell Evolutionäre Modelle Spezialfall: Prototypen Spiralmodell Übung: Vertiefung Vorgehensmodelle Komponenten-basiert V-Modell Zusammenfassung: Kostenverteilung Prof. A. Müller, FH KL Software Engineering Winter '12/'13 2

3 Phasenmodell eines Software-Projektes Planung Analyse Entwurf Implementierung Abnahme und Einführung Wartung und Pflege Produkt auswählen Anforderungen grob definieren Projekt planen Machbarkeit untersuchen Anforderungen ermitteln Fachliche Lösung modellieren Softwarearchitektur entwickeln Systemkomponenten spezifizieren Datenstrukturen u. Algorithmen entwerfen Programmcode erstel-len Testen Übergabe Installation Schulung Fehler beheben Leistung verbessern Dokumentieren Abnahmetest Inbetriebnahme Änderungen Erweiterungen Projekt kalkulieren Vgl. mit Modul 0 Grundlagen : Der Softwarelebenszyklus (standard life-cycle model) Prof. A. Müller, FH KL Software Engineering Winter '12/'13 3

4 Das Wasserfallmodell - Überblick Prof. A. Müller, FH KL Software Engineering Winter '12/'13 4

5 Das Wasserfallmodell - Beschreibung Merkmale des Wasserfallmodells: Erweiterung des Phasenmodells Rückkopplungen zwischen den (benachbarten) Phasen sind möglich Jede Aktivität ist in der richtigen Reihenfolge und in der vollen Breite durchzuführen. Am Ende jeder Aktivität: Meilensteinsitzung Ergebnisdokument Sequentieller Ablauf Optional: Wasserfallmodell mit Rücksprung Ziel: Verminderung des Risikos von unvollständigen Systemspezifikationen und Entwurfsfehlern Verringerung der Auswirkungen von Fehlentscheidungen in einzelnen Phasen Ein top-down-vorgehen, plan-orientiert Prof. A. Müller, FH KL Software Engineering Winter '12/'13 5

6 Wasserfall-Modell Vorteile: Einfach, klar strukturiert Wenig Management- Aufwand erforderlich Benutzerbeteiligung nur am Anfang erforderlich Eigenschaften Feedback (Fehler) können sich über mehrere Phasen erstrecken Kaum Berücksichtigung von Risikofaktoren Nachteile: Relativ starr Anforderungen müssen von Anfang an vollständig bekannt sein Während des Projektes notwendige Änderungen erfordern hohen Aufwand Anfällig für Fehler in frühen Phasen Erste Produktversion steht erst nach gesamter Projektlaufzeit zur Verfügung Prof. A. Müller, FH KL Software Engineering Winter '12/'13 6

7 Barry W. Boehm (2006) V-Modell 1979 COCOMO 1981 Spiralmodell 1988 Breitband-Delphi-Methode (vgl. V. Projektmanagement) Prof. A. Müller, FH KL Software Engineering Winter '12/'13 7

8 Das V-Modell, V-Modell 97, V-Modell XT V-Modell: Erweiterung des Wasserfallmodells - Hinzu kommen: Aktivitäten und Produkte des Planungsprozesses Qualitätsmanagement durch Validierung und Verifizierung der Teilprodukte Verifizierung: Erfüllt das (Teil)Produkt die spezifizierten Anforderungen Validierung: Eignet sich das Produkt für seinen Einsatzzweck Kennzeichen: einheitliche und verbindliche Vorgaben von Aktivitäten und Ergebnissen parallel zur Softwareentstehung werden die begleitenden Tätigkeiten beachtet (Qualitätsmanagement, Konfigurationsmanagement, technisches Projektmanagement) hoher Verbreitungsgrad in der Industrie, öffentlich Hand, Bund Ziele: Verbesserung und Gewährleistung der Qualität durch standardisiertes Vorgehen und definierte Zwischenergebnisse Eindämmung der Kosten durch einheitliche Standards Verbesserung der Kommunikation Erfolg ergibt sich nur, wenn Abstimmung zwischen Anwender, Aufgabensteller und Realisierer( z. B. Klärung gemeinsamer Prüfaktivitäten, Klärung von Schnittstellen) Prof. A. Müller, FH KL Software Engineering Winter '12/'13 8

9 V-Modell 97 Anforderungsdefinition Anwendung - Szenarien Abnahmetest Validierung Systementwurf Testfälle Systemtest Modul-Implementierung Modul- Test Testfälle Verifikation Prof. A. Müller, FH KL Software Engineering Winter '12/'13 9

10 V-Modell 97 Es existiert ein detailliertes Vorgehensmodell für große Projekte Kern des Systems sind immer die vier Submodelle für: Systemerstellung Qualitätssicherung Konfigurationsmanagement Projektmanagement Standard für Projekte der deutschen Bundesverwaltung und hoher Verbreitungsgrad in der Industrie Wird zunehmend ersetzt durch neue Version V-Modell XT Prof. A. Müller, FH KL Software Engineering Winter '12/'13 10

11 V-Modell 97 Vorteile: Einbeziehung von Tests, also use-case, test-cases, Systematische Verifikation und Validierung Einbeziehung von Konfigurations- und Projektmanagement Eigenschaften Lebenszyklus der Software (das Produkt ) ist nicht Teil des Modells Zusammenhang zwischen Firma (Organisationsform) und Vorgehensmodell wird nicht beachtet Nachteile: Relativ starr Hoher bürokratischer Aufwand Anfällig für Fehler in frühen Phasen Für kleinere Projekte überdimensioniert Ohne Software-Tools nicht handhabbar Erste Produktversion steht erst nach gesamter Projektlaufzeit zur Verfügung Prof. A. Müller, FH KL Software Engineering Winter '12/'13 11

12 Systematische Verifikation und Validierung Prof. A. Müller, FH KL Software Engineering Winter '12/'13 12

13 aktuelle Weiterentwicklung: V-Modell XT (1.3), V-Modell XT Bund (1.0) Stand Juni 2005: XT Release 1.01 Stand Jan. 2007: XT Release 1.2 Stand Jan. 2008: XT Release 1.3 Quelle: Quelle: Methoden/V-Modell_20XT/node.html? nnn=true the new standard for the development of public sector IT systems V-Modell XT Definiert XT steht für Extreme Tailoring Modulare Aufbau, Vorgehensbausteine Rollen, sind verantwortlich für Produkte Aktivitäten, erzeugen Produkte kompatibel zu ISO 9001, CMM und anderen definiert beide Seiten (Auftraggeber, Auftragnehmer) Prof. A. Müller, FH KL Software Engineering Winter '12/'13 13

14 Das Boehm sche Spiralmodell des Softwareprozesses (IEEE, 1988) Quelle: Sommerville, Kap , Abb. 4.5 Prof. A. Müller, FH KL Software Engineering Winter '12/'13 14

15 Bewertung des Spiralmodells Vorteile Hauptsächlich wird das Modell in großen und komplexen Projekten angewandt alle Risiken, die das Projekt bedrohen, werden identifiziert und anschließend bewertet offene Konzeption des Spiralmodells erlaubt Integration neuer Projektformen ohne Änderung seiner Struktur Eigenschaften Inkrementell, iterativ (Hinweis: diese Begriffe werden noch genauer definiert) Risiko-Steuerung erfolgt typischerweise über Prototypen Nachteile Zielvorstellungen der Beteiligten werden nicht angenähert Auf Grund des hohen Managementaufwand ist es für kleine und mittlere Projekte weniger gut geeignet. Es wird gerne als komplex kritisiert Prof. A. Müller, FH KL Software Engineering Winter '12/'13 15

16 Das evolutionäre (iterative) Modell "Nullversion" X=0 Systemspezifikation Version X Änderungen X++ Teilmodell (Produktkern) Entwurf Version X Teilarchitektur Anforderungen Änderungen Implementierung Version X Änderungen Produkt Version X Einsatz Version X Prof. A. Müller, FH KL Software Engineering Winter '12/'13 16

17 Das evolutionäre (iterative) Modell Vorteile Primäres Ziel: Die Auftraggeber erhalten in kurzen Abständen einsatzfähige Produkte; die erste Version vgl. früh! Integration der Erfahrungen der Anwender in die Entwicklung Überschaubare Projektgröße Korrigierbare Entwicklungsrichtung Keine Ausrichtung auf einen einzigen Endtermin Nachteile In späteren Versionen kann eine komplette Architektur Änderung bevorstehen. Die Nullversion ist möglicherweise nicht flexibel genug, um spätere Entwicklungen vorauszusehen. Eigenschaften Das Modell sieht eine stufenweise Entwicklung vor, gesteuert durch Erfahrungen der Benutzer. Re-Use von Komponenten ist üblich und auch erforderlich (s. komponenten-basiertes SE) Die Pflegeaktivitäten werden in den Prozess integriert Wir konzentrieren uns auf lauffähige Teilprodukte. Prof. A. Müller, FH KL Software Engineering Winter '12/'13 17

18 Komponenten-basiertes SE Quelle: Sommerville, Kap Software wird wieder verwendet, das reduziert Kosten und Risiken Kompromisse bei den Anforderungen sind unvermeidbar, mit Konsequenzen Kontrolle der Weiterentwicklung des Systems ist z.t. nicht gesichert Prof. A. Müller, FH KL Software Engineering Winter '12/'13 18

19 Inkrementelle Entwicklung Quelle: Sommerville, Kap , Abb. 4.4 Entwicklung des Produkts erfolgt stufenweise Entwicklung wird durch Erfahrungen der Entwickler und des Kunden gesteuert Wartung / Fehlerbehebung wird ebenfalls als neue Version behandelt Gut geeignet, wenn Anforderungen zu Beginn noch nicht vollständig bekannt sind Prof. A. Müller, FH KL Software Engineering Winter '12/'13 19

20 Inkrementelle Entwicklung Vorteile Es steht bereits frühzeitig ein funktionsfähiges System zur Verfügung Erfahrungen mit dem System können einbezogen werden Sich ändernde Anforderungen können berücksichtigt werden Risiko durch kleine Teilprojekte begrenzt Nachteile Identifikation geeigneter Teilsysteme schwierig Grundlegende Änderungen der Architektur aufwändig, da bereits produktives System im Einsatz Prof. A. Müller, FH KL Software Engineering Winter '12/'13 20

21 Prototyping Prototypen spezifizieren Prototypen herstellen experimentieren Prototyp akzeptiert? nein ändern und erweitern ja Ziele: Problemklärung Teil der Spezifikation: die Anforderungsanalyse kann exploratives Prototyping einsetzen Inkrementelle Entwicklung: vom Prototyp zum Produkt (evolutionäres Prototyping) Unterscheidung Art des Prototyping erforderlich: Laborprototyp (Labormuster, zeigt Machbarkeit) Pilotsystem (Kern des Systems) Vorabversion, Demonstrationsprototyp (umgangssprachlich) Prof. A. Müller, FH KL Software Engineering Winter '12/'13 21

22 Vertikale und horizontale Prototypen Horizontaler Prototyp Benutzungsoberfläche Anwendung Netz Datenbank Systemsoftware Vertikaler Prototyp Prof. A. Müller, FH KL Software Engineering Winter '12/'13 22

23 Vertikale und horizontale Prototypen In horizontalen Prototypen wird die betroffene Schicht weitestgehend realisiert, jedoch ohne echte Interaktion mit dem Gesamtsystem. Ziel ist typischerweise eine -isolierte -Erprobung des erzielten Verhaltens Ein vertikaler Prototyp implementiert ausgewählte Teile des Systems, jedoch mit deutlich eingeschränkter Funktionalität. Ziel eines vertikalen Prototyps ist in der Regel Funktionalitäts- oder Implementierungsoptionen zu klären und zu überprüfen Prof. A. Müller, FH KL Software Engineering Winter '12/'13 23

24 Vorteile und Nachteile des Prototyping Primäres Ziel: das Entwicklungsrisiko wird reduziert Prototyping kann sinnvoll in viele andere Prozessmodelle integriert werden Bei der Erprobung kann eine starke Rückkopplung zwischen Endbenutzern und Hersteller hergestellt werden Voraussetzung: geeignete Werkzeuge! Der Entwicklungsaufwand durch zusätzliche Erstellung der Prototypen ist hoch Es besteht die Gefahr, dass ein Prototyp (in Teilen) zum Endprodukt wird Vorsicht: Prototypen sind kein eigenständiger Ersatz für Dokumentation! Prof. A. Müller, FH KL Software Engineering Winter '12/'13 24

25 Verteilung der Software Engineering-Aktivitätskosten Quelle: Sommerville, Kap 1.1.7, Abb. 1.2 Prof. A. Müller, FH KL Software Engineering Winter '12/'13 25

26 Wichtige Aussagen Eigenschaften, Vor- und Nachteile klassischer Vorgehensmodell Validierung vs. Verifizierung Arten von Vorgehensmodellen Phasen-basiert Inkrementell Evolutionär (iterativ) Komponenten-basiert Formen und Ziele des Prototyping Prof. A. Müller, FH KL Software Engineering Winter '12/'13 26

27 Diskussion Lastenheft Pflichtenheft Prof. A. Müller, FH KL Software Engineering Winter '12/'13 27

28 Ausblick Moderne Vorgehensmodelle - wie RUP gehen von Anwendungsfällen (use cases) aus, basieren auf der gewählten Architektur, und kombinieren iterative und inkrementelle Vorgehensmodelle S. dazu: Übungsaufgabe, Sommerville Kap. 4.4 Agile Modelle bevorzugen eine schlanke und flexible Planung. Mehr dazu in Modul 10 Agile-Vorgehensmodelle Prof. A. Müller, FH KL Software Engineering Winter '12/'13 28