Prof. Dr. Gerhard Schmidt pres. by H.-J. Steffens Software Engineering SS 2009Folie 1 Weitere Vorgehensmodelle Der Rational Unified Process RUP –bei IBM.

Präsentation zum Thema: "Prof. Dr. Gerhard Schmidt pres. by H.-J. Steffens Software Engineering SS 2009Folie 1 Weitere Vorgehensmodelle Der Rational Unified Process RUP –bei IBM."—  Präsentation transkript:

1 Prof. Dr. Gerhard Schmidt pres. by H.-J. Steffens Software Engineering SS 2009Folie 1 Weitere Vorgehensmodelle Der Rational Unified Process RUP –bei IBM entwickelt –4 zeitliche Phasen: Vorbereitung (Inception) Software-Strukturierung (Elaboration) Software-Erstellung (Construction) Software-Übergabe (Transition

2 Prof. Dr. Gerhard Schmidt pres. by H.-J. Steffens Software Engineering SS 2009Folie 2 Weitere Vorgehensmodelle –Projektdurchführung ist in Arbeitsprozesse (Workflows) gegliedert: Geschäftsmodellierung (Businessmodeling) Requirementsengineering Analyse und Entwurf (Analysis and Design) Implementierung ( Implementation) Tests Einsatz und Verteilung (Deployment) Konfigurations- und Änderungsmanagement Projektmanagement Entwicklungsumgebung (Environment)

3 Prof. Dr. Gerhard Schmidt pres. by H.-J. Steffens Software Engineering SS 2009Folie 3 Weitere Vorgehensmodelle –Charakteristisch: sechs Best Praktices der Softwareentwicklung Iterative Entwicklung Anforderungsmanagement Architekturzentrierte Entwicklung Visuelle Modellierung (UML) Qualitätssicherung Änderungsmanagement Vorteile: –Möglichkeit, Änderungen während der Projektdurchführung zu verarbeiten –Risiko, die Kundenanforderungen nicht zu erfüllen, werden minimiert Nachteile: –hoher Aufwand –Tool erforderlich ( IBM)

4 Prof. Dr. Gerhard Schmidt pres. by H.-J. Steffens Software Engineering SS 2009Folie 4 Weitere Vorgehensmodelle Das Prototypen-orientierte Lebenszyklusmodell –Im Grundsatz: Phasenmodell –nicht linear sondern als iteratives Modell zu verstehen –Unterschied: Vorgehensweise und Ergebnisse der Phasen d.h. die Problemanalyse und die Spezifikation laufen zeitlich überlappend ab. –Auch die Phasen Entwurf, Implementierung und Test überlappen sich. –Der Begriff Phase wird durch den Begriff Aktivität ersetzt, um Verwechslungen mit dem Spiralmodell auszuschließen –keine Trennung von Teilaufgaben –Ablauf: 1.Erstellung von Prototyp 2.Test unter Realbedingungen 3.Änderungen 4.Überprüfung der Anforderungen

5 Prof. Dr. Gerhard Schmidt pres. by H.-J. Steffens Software Engineering SS 2009Folie 5 Weitere Vorgehensmodelle Prototypen –Explorative Prototypen: Unterstützung der Anforderungsanalyse. Klärung von Anforderungen hinsichtlich –Funktionsabläufen, –Benutzerschnittstellen, –Qualitätsanforderungen wird nicht zu einem Produkt weiterentwickelt Beispiele für explorative Prototypen –Dialogentwürfe –Druckmuster –Formularentwürfe

6 Prof. Dr. Gerhard Schmidt pres. by H.-J. Steffens Software Engineering SS 2009Folie 6 Weitere Vorgehensmodelle –Experimentelle Prototypen dienen zum Nachweis der Machbarkeit Unterstützung bei Lösungsstudien, System- und Detailentwurf eingesetzt –Evolutionäre Prototypen werden in der Regel nicht verworfen, sondern sukzessive zum Produkt weiterentwickelt Vorteile: –Minimierung des Risikos einer falschen Spezifikation –Produkt steht früh zur Verfügung

7 Prof. Dr. Gerhard Schmidt pres. by H.-J. Steffens Software Engineering SS 2009Folie 7 Weitere Vorgehensmodelle Das Objektorientierte Lebenszyklusmodell –Ausnutzung der objektorientierten Eigenheiten, wie z.B. Klassen Hirarchie, Vererbung, Polymorphie –Verschmelzung von Entwurf und Implementierung (Zusammensetzen von bereits existierenden Bausteinen) –Wartung der vorhandenen Klassenbibilotheken –Vorteile: Wiederverwendbarkeit Kombination mit anderen Modellen möglich –Nachteile: Wartung und Pflege der Bibilotheken (hoher Aufwand) zu spezielle Bibilotheken => geringe Wiederverwendbarkeit zu abstrakte Bibilotheken => hoher Aufwand zur Anpassung

8 Prof. Dr. Gerhard Schmidt pres. by H.-J. Steffens Software Engineering SS 2009Folie 8 Auswahl eines Vorgehensmodells Kriterien –Größe und Komplexität eines Projektes –Neuartigkeit von Risiken –Klarheit der Ziele und Anforderungen –die (zu erwartende) Änderungshäufigkeit –zeitliche Vorgabe für erstes Ergebnis –Zuverlässigkeit der Software –Externe Anforderungen –Kundenvorgaben –gesetzliche Vorgaben Fazit: Es gibt kein Idealmodell