© Till Hänisch, 2002 BA Heidenheim Vorgehensmodelle Wie entsteht Software ?

Präsentation zum Thema: "© Till Hänisch, 2002 BA Heidenheim Vorgehensmodelle Wie entsteht Software ?"—  Präsentation transkript:

1 © Till Hänisch, 2002 BA Heidenheim Vorgehensmodelle Wie entsteht Software ?

2 © Till Hänisch, 2002 BA Heidenheim Phasen der Softwareentwicklung Siehe “Problemlösungsstrategien” Analyse (Was soll entwickelt werden ?) Architektur (Aufteilung in Komponenten,...) Design (Wie werden Anforderungen umgesetzt ?) Implementierung Test Betrieb

3 © Till Hänisch, 2002 BA Heidenheim Formale Vorgehensmodelle Ad hoc Entwicklung Wasserfall-Modell V-Modell Prototypenmodell inkrementelles Modell objektorientiertes Modell Spiralmodell Rational Unified Process (RUP)

4 © Till Hänisch, 2002 BA Heidenheim Ad hoc Entwicklung "code and fix" Keine “Softwareentwicklung”, hinsetzen und programmieren möglich, wenn –Problemstellung einfach und klar –Lösungsweg klar –ein (oder sehr wenige) Entwickler –Projektdauer kurz (einige Tage bis Wochen) üblich bei Miniprojekten, Übungsaufgaben, Run-Once- Programmen,... Softwareentwicklung findet im Kopf statt

5 © Till Hänisch, 2002 BA Heidenheim Wasserfallmodell Definition (Analyse) Entwurf (Design) Implementierung Test Betrieb

6 © Till Hänisch, 2002 BA Heidenheim Wasserfallmodell mit Rückkopplung (Böhm) Definition (Analyse) Entwurf (Design) Implementierung Test Betrieb

7 © Till Hänisch, 2002 BA Heidenheim Wasserfall-Modell Top-Down-Methodik Einteilung in Phasen Phasen werden nacheinander und jeweils vollständig durchgeführt Ergebnis jeder Phase ist ein Dokument –Phase ist abgeschlossen, wenn das jeweilige Dokument erstellt ist Ergebnis einer Phase ist Input für die nächste eine Interation Anwender ist nur an der Definitionsphase beteiligt Rückkopplung (wenn überhaupt) nur auf die unmittelbar verhergehende Phase

8 © Till Hänisch, 2002 BA Heidenheim Wasserfallmodell: Bewertung Vorteile –einfach –verständlich –kaum Management-Aufwand –weit verbreitet Nachteile –Phasen müssen vollständig durchgeführt werden (nicht immer möglich/sinnvoll) –Phasen müssen sequentiell durchgeführt werden (nicht immer sinnvoll) –Zyklus wird nur einmal durchlaufen Was passiert bei Änderungen ? –Dokumentation überproportional repräsentiert

9 © Till Hänisch, 2002 BA Heidenheim V-Modell Anforderungs- Definition Grobentwurf Feinentwurf Modul- implementation Modultest Integrationstest Systemtest Abnahmetest Testfälle Anwendungsszenarien Validierung Verifikation

10 © Till Hänisch, 2002 BA Heidenheim V-Modell Erweiterung des Wasserfall-Modells Verifikation = Übereinstimmung des Produkts mit der Spezifikation –Wird ein korrektes Produkt entwickelt ? Validierung = Eignung des Produkts für den Einsatz –Wird das richtige Produkt entwickelt ? Erweiterung für Bundeswehr und Behörden, dort Standard (auch teilw. In Industrie) (“Vorgehensmodell”)

11 © Till Hänisch, 2002 BA Heidenheim Vorgehensmodell Ursprüngl. für Embedded Systems Submodelle –Systemerstellung (SE) z.B. SE1: Anforderungsanalyse, SE1.1: Ist-Analyse durchführen –Qualitätssicherung (QS) –Konfigurationsmanagement (KM) –Projektmanagement (PM) Aktivitäten und Produkte Rollen (Manager, Verantwortliche, Durchführende) Allgemeingültig Anpassbar (Tailoring)

12 © Till Hänisch, 2002 BA Heidenheim Vorgehensmodell: Bewertung Vorteile –Integration von Systemerstellung, Qualitätssicherung, Konfigurationsmanagement, Projektmanagement –Detailliertes, generisches Modell mit Möglichkeit zur Anpassung (Tailoring) –Geeignet für große Projekte Nachteile –Geeignet für große Projekte –konzipiert für embedded systems –komplex (ohne CASE-Unterstützung schwierig) –zu bürokratisch für kleine Projekte –Tailoring notwendig

13 © Till Hänisch, 2002 BA Heidenheim Prototypen z.B. Schichtenarchitektur User Interface Applikationslogik Datenbank Betriebssystem horizontaler Prototyp vertikaler Prototyp

14 © Till Hänisch, 2002 BA Heidenheim Prototypen contd. (Demonstrations-) Prototyp –Kommunikation zwischen Kunde und Entwickler –i.A. horizontal Labormuster –Technische Machbarkeit –horizontal/vertikal Pilotsystem –Kernstück des fertigen Produkts –vertikal “Plan to throw one away” (Brooks) Gefährlich (Wartung,...), wenn Prototyp Teil/Basis des Systems wird

15 © Till Hänisch, 2002 BA Heidenheim Inkrementelles/evolutionäres Vorgehen “I can’t tell you what I want, but I’ll know it when I see it” Zuerst wird Hauptschleife/Menü/Maske,... entwickelt (mit dummy-Funktionen) danach wird Modul für Modul bzw. Funktion für Funktion implementiert und verfeinert Immer funktionsfähiges System Z.B. Betriebssystem (siehe Windows NT), Textverarbeitung geeignet, wenn die (vielen) Funktionen orthogonal sind nicht alle Anforderungen müssen bei Beginn der Entwicklung bekannt sein

16 © Till Hänisch, 2002 BA Heidenheim Objektorientierte Modelle Bottom up Wiederverwendung, Klassenbibliotheken Patterns Komponenten (z.B. Beans,...) Kombination mit inkrementellem Modell Hohe Produktivität Technische Probleme (Kombination von Klassenbibliotheken) keine Gewähr für Erfüllung der Anforderungen, d.h. Kombination mit anderen Modellen (Prototyping, Inkrementell,...) nötig

17 © Till Hänisch, 2002 BA Heidenheim Spiralmodell aus Boehm, A spiral model for software development and enhancement, IEEE Computer, May 1988

18 © Till Hänisch, 2002 BA Heidenheim Spiralmodell Metamodell 4 Schritte, die zyklisch wiederholt werden –Ziele, Alternativen, Schnittstellen spezifizieren –Evaluierung der Alternativen, Risikoabschätzung und Minimierung (z.B. Prototypen, Simulationen,...) –Prozeßmodell (Prototyp, Wasserfall,...) Risikominimierung durch zyklische Evaluierung und Risikoabschätzungen Flexibel, mehrere Prozeßmodelle möglich Hoher Managementaufwand, eher für große Projekte

19 © Till Hänisch, 2002 BA Heidenheim RUP (Rational unified process)

20 © Till Hänisch, 2002 BA Heidenheim RUP contd. Prozess von Rational –Hersteller von (UML-) CASE Tools, beschäftigt einige SE Gurus (u.a. Booch, Jacobson, Rumbaugh) iterativ, je 4 Phasen –Inception –Elaboration –Construction –Transition Use case gesteuert 4 Elemente –Workers –Activities –Artifatcs –Workflows

21 © Till Hänisch, 2002 BA Heidenheim Vergleich der Modelle ModellZieltreibendes Moment Nutzer beteiligung ad hocminimaler AufwandCode (Fehler)? Wasserfallminimaler Management Aufwand Dokumentegering V-Modellmaximale Qualität Dokumentegering PrototypenRisiko- minimierung Codehoch Inkrementellfast-to-market Risikominimierung Codemittel SpiralmodellRisikominimierungRisikomittel RUPRisikominimierungDokumentemittel-hoch nach [Balzert96]