Prozess- .2. Einführung • Prozess-Modelle legen den organisatorischen Rahmen einer Software-Entwicklung

  • View
    212

  • Download
    0

Embed Size (px)

Text of Prozess- .2. Einführung • Prozess-Modelle legen den organisatorischen Rahmen einer...

  • Prozess-Modelle

    Modelle Wasserfallmodell V-Modell Prototypenmodell Evolutionres/inkrementelles Modell Objektorientiertes Modell Nebenlufiges Modell Spiralmodell

    Einfhrung in UML Klassendiagramme Anwendungsfalldiagramme

  • 2

    Einfhrung

    Prozess-Modelle legen den organisatorischen Rahmen einer Software-Entwicklung fest

    Prozess-Modelle legen folgendes fest: Reihenfolge des Arbeitsablaufs (Entwicklungsstufen, Phasenkonzepte) Durchzufhrende Aktivitten Definition der Teilprodukte (einschlielich Layout und Inhalt) Fertigungskriterien (Wann ist ein Teilprodukt fertiggestellt) Notwendige Mitarbeiterqualifikation Einzuhaltende Standards, Richtlinien und Werkzeuge

  • 3

    Prozess-Modelle

    Wasserfallmodell V-Modell Prototypenmodell Evolutionre/inkrementelle Modell Objektorientierte Modell Nebenlufige Modell Spiralmodell

  • 4

    Das Wasserfall-Modell (1)System-

    Anforderungen

    Software-Anforderungen

    Analyse

    Entwurf

    Codierung

    Testen

    Betrieb

  • 5

    Das Wasserfall-Modell (2)

    Jede Aktivitt ist in der richtigen Reihenfolge und in voller Breite durchzufhren

    Am Ende jeder Aktivitt steht ein fertiggestelltes Dokument (Dokumentengetriebenes Modell)

    Sequentielle Abfolge der Aktivitten (Keine berlappung von Aktivitten)

    Iterationen sind nur zwischen zwei aufeinanderfolgenden Stufen erlaubt

  • 6

    Das Wasserfall-Modell: Bewertung

    Vorteile Einfach, verstndlich Geringer Management-Aufwand Disziplinierter, kontrollierbarer und sichtbarer Prozessablauf

    Nachteile Die Sequentialitt und volle Breite der Entwicklungsschritte

    oft nicht sinnvoll Gefahr einer berbewertung der Dokumentation Risiken werden zu wenig bercksichtigt Benutzerbeteiligung nur bei Anforderungen und im Betrieb Mglichkeit von Feedback kaum gegeben

  • 7

    Das V-Modell (1)

    Anforderungs-Definition

    Validierung

    AbnahmetestAnwendungsszenarien

    Integrationstest

    Modul-Implementation

    Systemtest

    Feinentwurf

    TestflleGrobentwurf

    Verifikation

    Testflle

    TestflleModultest

  • 8

    Das V-Modell (2)

    Erweiterung des Wasserfall-Modells Bercksichtigung der Qualittssicherung

    Verifikation: berprfung der bereinstimmung zwischen Software-Produkt und Spezifikation

    Validierung: berprfung der Eignung eines Produktes bezogen auf Einsatzzweck

    Submodelle im V-Modell: PM: Projektmanagement SE: Systemerstellung QS: Qualittssicherung KM: Konfigurationsmanagement

  • 9

    Das V-Modell: Submodelle

    Konfigurations-struktur

    PM

    SE

    QS KM

    Plandaten Istdaten SEU

    SEU

    QS-Ergebnis

    Ist-daten

    QS-Anforderung

    Produkt

    Produktentwickeln

    QS-Anforderungen

    vorgeben

    Produkteprfen

    Produkte/Rechte

    verwalten

    Produktstrukturplanen

    Plan-daten SEU SEU

    Plan-daten

    Plan-daten

    Ist-daten

    Produkt

    Rechte

    Ist-daten

    Voraussetzungen schaffen und SEU bereitstellen

    Projekt planen und kontrollieren

  • 10

    Das V-Modell: Rollen

    Manager Verantwortliche DurchfhrendeSubmodell

    PM Projektmanager ProjektleiterRechtsverantwortlicherController

    Projektadministrator

    SE ProjektmanagerIT-BeauftragterAnwender

    Projektleiter SystemanalytikerSystemdesignerSW-EntwicklerHW-EntwicklerTechnischer AutorSEU-BetreuerDatenadministratorIT-SicherheitsbeauftragterDatenschutzbeauftragterSystembetreuer

    QS Q-Manager QS-Verantwortlicher Prfer

    KM KM-Manager KM-Verantwortlicher KM-Administrator

  • 11

    Das V-Modell: Bewertung

    Vorteile Integrierte, detaillierte Darstellung von SE, QS, KM und PM Generisches Vorgehensmodell mit definierten Mglichkeiten

    zur Anpassung an projektspezifischen Anforderungen Gut geeignet fr groe ProjekteNachteile Die Vorgehenskonzepte, die fr groe Projekte geeignet sind

    werden unreflektiert auf andere Projekte bertragen Fr kleine und mittlere Softwareentwicklungen fhrt das V-

    Modell zu einer unntigen Brokratie Die im V-Modell definierten Rollen (bis zu 25) sind fr

    gngige Softwareentwicklungen nicht realistisch Ohne geeignete Werkzeug-Untersttzung ist das V-Modell

    nicht handhabbar

  • 12

    Das Prototypen-Modell

    Probleme bei der Verwendung des Wasserfall- und V-Modells Auftraggeber und Endbenutzer knnen ihre Anforderungen an ein

    Software-Produkt oft nicht explizit und vollstndig formulieren In der Entwicklungsphase ist ein Austausch zwischen Anwendern und

    Software-Entwicklern notwendig Fr manche Anforderungen gibt es unterschiedliche Lsungen, die mit

    dem Auftraggeber diskutiert werden mssen Die Realisierbarkeit mancher Anforderungen kann theoretisch nicht

    garantiert werden und muss durch Experimente ermittelt werden Fr die Projektakquisition muss der (potentielle) Auftraggeber von der

    Software-Lsung berzeugt werdenLsung: Prototypen-Modell Prototypen dienen dazu, relevante Anforderungen oder

    Entwicklungsprobleme zu klren Prototypen stellen Diskussionsbasis dar und helfen bei der

    Entscheidungsfindung Prototypen dienen dazu, Experimente durchzufhren und damit erste

    Erfahrungen mit der Anwendung zu sammeln

  • 13

    Das Prototypen-Modell

    Prototyping Untersttzt die frhzeitige Erstellung ablauffhiger Modelle (Prototypen) des

    zuknftigen Systems Dient zur Ermittlung der Realisierbarkeit von Anforderungen

    Arten von Prototypen Demonstrationsprototyp:

    Stellt ein mgliches Aussehen einer geplanten Software-Lsung dar Dient zur Auftragsakquisition(Wird i.A. nach Erfllung der Aufgabe weggeworfen)

    Prototyp im engeren Sinne: Realisiert Teile der Funktionalitt (z.B. Benutzerschnittstelle) Dient zur Analyse des Anwendungsbereichs

    Labormuster: Demonstriert technische Umsetzbarkeit der Anforderungen Dient zur Beantwortung konstruktionsbezogener Fragen und Alternativen

    Pilotsystem: Ist Kern des Produktes Wird in Zyklen zum Endprodukt weiterentwickelt

  • 14

    Das Prototypen-Modell: horizontale vs. Vertikale Prototypen

    HorinzontalePrototypen

    Benutzeroberflche

    Anwendung

    Systemsoftware

    Netzanbindung Datenhaltung

    Vertikale Prototypen

    Horizontale Prototypen: Realisierung spezifischer Ebenen des SystemsVertikale Prototypen: Realisierung ausgewhlter Teile des Zielsystems durch alle Ebenen hindurch

  • 15

    Das Prototypen-Modell: Bewertung

    Vorteile Reduzierung von Entwicklungsrisiken durch frhzeitige

    Verwendung von Prototypen Verbesserung der Planung von Software-Entwicklungen Starke Rckkopplung mit dem Endbenutzer bzw.

    Auftraggeber Frderung der Kreativitt bei der Ermittlung von Alternativen

    fr die ProblemlsungNachteile Aufwand fr die Entwicklung von Prototypen Aufwand fr Prototypentwicklung oft vertraglich schwer zu

    fassen Gefahr der Weiterverwendung von (Wegwerf-)Prototypen

  • 16

    Das evolutionre Modell

    Wnsche

    Definieren Version X

    EinsetzenVersion X

    Implement. Version X

    Entwerfen Version X

    PartiellesModell

    Produkt Version X

    partielle Architektur

    Nullversion X:=0

    X:=X+1

    nderungen

    nderungen

  • 17

    Das evolutionre Modell

    Kern bzw. Mussanforderungen des Auftraggebers definieren Produktkern

    Produktkern wird als erstes entworfen und entwickelt (Nullversion)

    Erfahrungen mit Nullversion fhren zu neuen Anforderungen aus denen eine neue Version entwickelt wird

    Merkmale des evolutionren Modells Stufenweise Entwicklung des Produkts, gesteuert durch Erfahrung

    von Endbenutzern Gut geeignet, wenn der Auftraggeber seine Anforderungen noch nicht

    vollstndig berblickt Die Entwicklung im evolutionren Modell ist Code-

    getrieben: Der Fokus liegt jeweils auf lauffhigen Teilprodukten

  • 18

    Das evolutionre Modell: Bewertung

    Vorteile Einsatzfhige Produkte in kurzen Zeitabstnden Lsst sich mit dem Prototypen-Modell kombinieren Auswirkungen des Produkteinsatzes lassen sich untersuchen

    und die gewonnene Erfahrungen werden in der folgenden Version bercksichtigt

    Die Richtung der Entwicklung ist leichter steuerbar: statt einem Ergebnis gibt es mehrere Zwischenergebnisse

    Nachteile Falls in der Nullversion Kernanforderungen bersehen

    wurden muss die Systemarchitektur u.U. vollstndig berarbeitet werden

    Die Nullversion kann sich als zu unflexibel fr sptere Anpassungen erweisen

  • 19

    Das Inkrementelle Modell

    Definieren

    EntwerfenVersion X

    EinsatzVersion X

    Implement.Version X

    Definierennderungen

    Wnsche

    nderungen

    modifiz.Modellnderungen

    nderungen

    VollstndigesProduktmodell

    ProduktVersion X

    partielle Architektur

    If X>0

    X:=X+1Nullversion

    X:=0If X=0

    Variation des evolutionren Modells: Die Anforderungen werden zunchst vollstndig erfasst Teile der Anforderungen werden inkrementell umgesetztZiel: Sicherstellen, dass inkrementelle Entwicklungen zu bisherigen Zwischenergebnissen passen

  • 20

    Das nebenlufige ModellDefinieren Kernsystem

    partiellesModell Definieren

    Ausbaustufe 1

    DefinierenAusbaustufe 2

    Implement. Kernsystem

    nderungen

    EntwerfenKernsystem

    erweitertesModell

    ImplementierenAusbaustufe 1

    EntwerfenAusbaustufe 2

    ImplementierenAusbaustufe 2

    EntwerfenAusbaustufe 1

    nderungen

    ErweitertesProduktmodell

    nderungenErw. Produkt-

    architektur ...

    erweitertesKernsystem

    erweiterteArchitektur

    nderungen

    Kernsystem

    partielleArchitektur