SW-Lebenslauf (Prozessmodelle Klasse 2)

• Aufbauorganisation, Verantwortlichkeiten, Rollenmodell und -verteilung

• Struktur und Eigenschaften von Dokumenten

• einzusetzende Verfahren

• auszuführende Aktivitäten der Entwicklung inkl. Kontrollfluss (=Prozessmodell Klasse I)

• Explizite Projektphasen, Meilensteine, Prüfkriterien

• einzusetzende Notationen und Sprachen (z.B. UML, Java)

• einzusetzende Werkzeuge (z.B. Eclipse, JUnit, Git)

Prozessmodelle der Klasse I machen lediglich Aussagen über den Projektablauf.

Klasse 2 auch über Organisation, Dokumentation, Verantwortlichkeiten.

Ergänzung eines generischen (Prozess-)Modells durch Projekttyp-spezifische Elemente.

Ziel: Gezielte Prozessausprägung.

Das Phasenmodell untergliedert den Gesamtablauf eines Projekts in einzelne

• aufeinander folgende,

• parallel verlaufende und/oder sich überlappende,

• sachlich voneinander getrennte

zeitliche Abschnitte (Projektphasen).

Eine Phase ist ein Zeitraum zwischen zwei

Meilensteinen.

Ein Meilenstein ist ein zeitlich geplantes Ereignis, das den Abschluss einer oder mehrerer Aufgaben markiert.

—> An einem Meilenstein ist eine zuvor definierte Menge von Ergebnissen in einer festgelegten Qualität abzuliefern.

—> Hierdurch wird der Software-Prozess einer Bewertung/Erfolgsmessung zugänglich gemacht.

—> Achtung: Die Erreichung eines Meilensteins ist durch die angestrebten Ziele/Ergebnisse definiert und nicht durch den geplanten Erreichungstermin. Dieser kann sich ändern.

• Welche Ergebnisse müssen vorliegen?

• Welche Gütekriterien werden bei deren Prüfung zugrunde gelegt?

• Wer entscheidet, ob der Meilenstein erreicht ist?

Großer Aufwand für die Vorbereitung und Durchführung der Prüfungen zum Erreichen der Meilensteine.

• Präzise Planung durch Meilensteine

• Termindrift leicht erkennbar

• Personalbedarf je Phase gut ableitbar

• Qualitätssicherung durch Prüfung der Teilprodukte

• Prüfungen geben Sicherheit, dass sich das Projekt „in die richtige Richtung“ entwickelt und sich Teilprodukte nicht übermäßig verspäten.

• Überwinden des „90%-fertig Syndroms“

  
  

• basiert auf Phasenmodell

• eigenes Vokabular, z.B.

  • Meilensteine —> Entscheidungspunkte

  • Phasen —> Projektabschnitte

• Urform von 1992 nur für Software

• seit 1997 für Soft-, Hardware und Kombinationen

• Qualitätsmanagement

• Konfigurationsmanagement

• Projektmanagement

• Systemerstellung (SE)

• Qualitätssicherung (QS)

• Konfigurationsmanagement (KM)„

• Projektmanagement (PM)

• Vorgehensbausteine

• Projekttypvarianten/Projektdurchführungsstrategien

• Entscheidungspunkte

• Aktivitäten

• Produkte

• Rollen

• Systementwicklungsstrategien

• wesentliches Gestaltungsmerkmal

• Dient der Erfüllung einer Aufgabe

• organisiert Rollen, Produkte & Aktivitäten

• Vorgehensbausteine

  • Projektmanagement

  • Qualitätssicherung

  • Problem- und Änderungsmanagement

  • Konfigurationsmanagement

Das V-Modell XT kennt 21 Entscheidungspunkte, z.B.

• inkrementell (schließt Wasserfallmodell ein)

• komponentenbasiert

• agil

• 4 obligatorische Vorgehensbausteine betonen deren Gleichberechtigung zu konstruktiven Tätigkeiten wie Spezifizieren und Kodieren

• freie Verfügbarkeit

• umfangreich, generisch, anpassbar

• “Es ist an alles Wichtige gedacht”

• Es ist sehr komplex

  —> Fokus auf Großprojekte d.h. Für kleine und mittlere

  Projekte weniger geeignet

• Ohne Anpassung sind sehr viele

  Produkte/Dokumente abzuliefern

  (selbst nach Tailoring noch ca. 40

  Stück), deren Nutzen fraglich ist

• Projektassistent macht relativ starre

  Vorgaben

• UP ist ein Phasenmodell

• uP ist iterativ

• Releases entstehen inkrementell

• Produkte entstehen ggf. inkrementell

• UP basiert auf Use Cases

• UP ist architekturzentriert

• Worker (statt Rolle)

• Workflows

• Aktivitäten

• Artefakte

• Verstehen der grundlegenden Idee sowie der Anforderungen an das Zielsystem

• Verstehen der wirtschaftlichen Seite als Voraussetzung für Start des Entwicklungsprojekts

• Identifikation grundlegender Anwendungsfälle

• Risikoanalyse und ggf. Prototypen zur Absicherung

• Erster Architekturentwurf, Projektplan

• Anforderungen werden komplettiert

• Architekturentscheidung

• Erster Prototyp für Demonstration des Architekturkerns

• Identifikation der größten Risiken und Erarbeitung von Maßnahmeplänen

• Planung der Folgephasen

• Implementation, Integration und Test

• Komplettierung der Dokumentation

Ziel: Eine einsetzbare Beta-Version

• Überführung/Übergang des Systems inkl. Dokumentation in einen stabilen Zustand

• Anwender-Feedback

Ziel: Auslieferbare, uneingeschränkt nutzbare & vom AG akzeptierte Produkte (System & Dokumentation)

• RUP hat einen höheren Detaillierungs-/ Konkretisierungsgrad

• RUP ist ein kommerzielles Produkt von IBM/Rational

• RUP hat Änderung des Vokabulars, z.B. wird aus dem Workflow die Discipline

• RUP definiert Disciplines durch UML-Aktivitätsdiagramme

• in RUP werden einzelne Aktivitäten eingehend textuell beschrieben

• Gute Konfigurations- & Änderungsverwaltung nötig wegen iterativer & inkrementeller Vorgehensweise

• Hohe Anforderungen an Projektmanagement wegen Planung der Iterationen (wie viele?, jew. wie lang?)

• OO-Kenntnisse erforderlich, insbesondere zu Anwendungsfällen

• Projektspezifisches Tailoring kaum möglich wg. hohem Kopplungsgrad der Aktivitäten

• Vendor-Lock-in bzgl. Tools & Methode, kommerzielle Weiterentwicklung des Prozessmodells

• Der Detaillierungsgrad erweckt den (falschen!) Eindruck, dass man durch stupides Befolgen der Workflows/ Disciplines automatisch zu guten Produkten gelangt

• Umfangreiche elektronische Dokumentation

• Detaillierte Dokumentation des RUP inkl. Anleitungen &

  Musterdokumenten

Fähigkeit schnelle Bewegungen durchzuführen

Die Fähigket schnell auf Ereignisse, die das Projekt beeinflussen reagieren zu können.

Beispiele von Ereignissen:

• Anforderungen ändern sich

• Personal wird (temporär) abgezogen

• Budgetkürzungen

• Veränderte Marktsituation

Erkenntnis:

• Am beweglichsten bin, ich wenn ich (jeden?/unnötigen?) Ballast abwerfe

• Training fördert meine Beweglichkeit

• iterativer Ansatz;

  Zykluslänge: wenige Wochen, max. 3 Monate

• Arbeit in kleinen Gruppen zu 6-8 Pers., die zudem in einem

  gemeinsamen Labor arbeiten

• umfangreiche Dokumentation wird total oder partiell abgelehnt

• Kundenfokus/-bedeutung & seine Beteiligung im Projekt empfehlen oder fordern

• Selbstorganisation (oft)

• dogmatisches Vorgehen ablehnen