L5-Softwareprozessmodell-Rahmenwerke

Ein Rahmenwerk für SW Prozessmodelle, dass verbindlich für öffentliche IT-Projekte ist.

Hauptelemente, die beliebige SW Prozessmodelle gestalten, sind:

1. Projekttypen (Beschreibt ausserdem welche Vorgehensbausteine eingesetzt werden müssen und welche optional sind)

   1. Systementwicklungsprojekt eines Auftraggebers

   2. Systementwicklungsprojekt eines Auftragnehmers

   3. Systementwicklungsprojekt eines Auftraggebers mit Auftragnehmer in der gleichen Organisation

   4. Einführung und Pflege eines organisationsspezifischen Vorgehensmodells

2. Entscheidungspunkte und Projektdurchführungsstrategien

   1. Entscheidungspunkte legen fest, ob eine bestimmte Projektfortschrittsstufe erreicht wird oder nicht. Es wird definiert welche Ergebnisse bzw. Produkte fertiggestellt werden.

   2. Die Projektdurchführungsstrategie legt die Reihenfolge der Entscheidungspunkte fest.

   3. Die konkrete Durchführungsstrategie leitet sich aus Projekttyp und spezifischen Projektmerkmalen ab.

3. Vorgehensbausteine

   1. Besteht aus konkreten Aufgaben, Aktivitäten, Ergebnissen und Rollen des SW Projekts

   2. Die Entscheidungspunkte legen fest, was Angewendet wird.

   3. Was von Wem im Projekt gefordert wird.

4. Referenzen (Dient als Nachschlagewerk)

   1. Vorgaben und ANhaltspunkte für:

      1. Tailoring (Zuschneiden) eigener SW Prozessmodelle

      2. Rollen im SW Prozess mit Beschreibung, Zuständigkeit und Kategorie.

      3. Produkte im SW Prozess, deren Erstellung, Verwendung und Abhängigkeit

      4. Aktivitäten mit detaillierter Anleitung zur Erstellung und Bearbeitung der Ergebnisse.

      5. Konventionsabbildungen, die nationale und internationale Konventionen in Beziehung zu Elementen des V Modell XT setzen.

Rational Unified Process (RUP)

Industrielles Rahmenwerk für SW Prozessmodelle von IBM.

Phasen:

1. Inception (Konzeption) ist die Vorbereitungsphase, Fokus auf:

   1. Requirements Engeneering,

   2. Erarbeitung der Projektvision,

   3. erste Risikoanalyse,

   4. Erstellen des Projektplans und

   5. aufstellen des Projektbudgets.

2. Elaboration (Entwurf)

   1. Anforderungen werden verfeinert und detailliert.

   2. Entwicklung eines Konzepts der Systemarchitektur

   3. Bau erster Prototypen

   4. Architekturbeschreibung, die Vorgaben und Rahmen für die Construction Phase macht

3. Construction (Konstruktion)

   1. Großteil der Implementierungsaktivitäten findet statt.

   2. Es wird hauptsächlich der Programmcode des SW Systems erzeugt.

   3. SW Tests werden dgf und Fehler behoben.

4. Transition (Übergabe)

   1. Alle Aktivitäten, die nach Abschluss der Entwiklungsarbeiten bis hin zur abgeschlossenen Inbetriebnahme dgf werden müssen.

   2. Nutzerschulung, Systemtest, Integration der Ausführungsumgebung, Dokumentation.

Organisation der SW-Engeneering Kernaktivitäten

1. RUP etnhält Disziplinen, die aus spezifischen Rollen, Artefakten, Aktivitäten und WOrkflows bestehen.

2. Die Kernaktivitäten sind in jeder Phase nicht streng separiert, sondern finden teilweise parallel oder eng verzahnt statt. Unterschiede bestehen in der Intensität der einzelnen Phasen.

3. RUP unterstützt die evolutionäre Entwicklung, indem einzelne Phasen teilweise mehrfach intereinander ausgeführt werden.

Stark evolutionäres SW Prozessmodell-Rahmenwerk, das durch die konsequente Organisation in kurze Zyklen und einem sich selbst organisierten Team auszeichnet.

Scrum definiert keine SW Engeneering spezifischen Rollen und Aktivitäten. Genau genommen ist Scrum kein spezifisches SW Prozessmodell-Rahmenwerk. Es ist ein Rahmenwerk für Prozessmodelle verschiedenster Arten.

Scrum definiert verschiedene Rollen und gibt strenge Vorgaben für Aktivitäten und deren Reihenfolge. Es gibt Scrum-spezifische Elemente zur Verwaltung des Projekts.

Rollen:

1. Product Owner

   1. Repräsentiert die Bedürfnisse des Kunden/Anwenders und ist für den Erfolg des Projekts und das Requirements Engeneering verantwortlich.

   2. Ist die Brücke zwischen Projekt und Außenwelt, zwischen Stakeholder und Systementwicklern.

   3. Trifft wichtige fachliche Entscheidungen. Erstellt den Releaseplan, priorisiert Anforderungen, nimmt Zyklusergebnisse ab.

2. Scrum Master

   1. Moderiert und begleitet Aktivitäten in Scrum ähnlich wie ein organisatorischen Projektleiter, um zeitliche Vorgaben des Scrum Zykluses enzuhalten.

   2. Sorgt für eine ideale Arbeitsumgebung von Product Owner und Team durch einen reibungslosen Ablauf.

   3. Hat keine Weisungsbefugnis und soll den Scrum Prozess managen und Störungen bzw. äußere Einflüsse zu verhindern.

3. Team

   1. Verantwortlich für die technische Konzeption, Konstruktion und Qualitätssicherung.

   2. Arbeitet selbstorganisiert und autonom.

   3. Abstimmungen werden mit dem Product Owner getroffen. Abgesehen von organisatorischen Vorgaben und Konventionen ist das Team frei in der Wahl der technischen Umsetzung.

   4. Besteht aus 3-9 Personen, welche die Rollen Architekt, Entwickler und Tester übernehmen.

   5. Das Ergebnis wird am Zyklusende präsentiert.

Elemente zur Verwaltung und Steuerung

1. Product Backlog

   1. Liste von Anforderungen an das System. Detaillierungsgrad reicht von einer Idee bis zur vollständigen spezifizierten Funktion.

   2. Anfangs sind die Anforderungen noch sehr grobe Systemwünsche. Im Verlauf werden diese Wünsche vom Product Owner verfeinert, ergänzt und priorisiert.

   3. Nur der Product Owner darf Änderungen a Product Backlog vornehmen.

2. Sprint Backlog

   1. Liste von Anforderungen, die im Sprint (Scrum-Zyklus) umgesetzt werden sollen. Ist also eine Teilmenge des Product Backlogs.

   2. Der Inhalt des Sprint Backlg vereinbaren Productowner und Team.

   3. Die Anforderungsmenge ist von der velocity des Teams abhängig.

   4. Während der Bearbeitungszeit eines Zykluses wird der Sprint Backlog nicht verändert.

3. Velocity

   1. Ist eine teamspezifische Kennzahl. Setzt sich aus Menge und Umfang der Zyklusfunktionen zusammen. Die Geschwindigkeit stabilisiert sich nach ca 5-7 Zyklen.

   2. Anhaltspunkt, wie viele Anforderungen aus dem Product Backlog in den Sprint Backlog übertragen lassen.

Aktivitäten im Scrum

1. Für jeden Sprint wird aus dem Product Backlog ein Sprint Backlog erstellt.

2. Ein Sprint dauert typischerweise 2 Wochen und setzt dabei die Anforderungen um.

3. Daily Scrum - Jeden Tag findet eine kurze Statusbesprechung statt. Jedes Teammitglied stellt kurz vor, was es gemaht hat. Dauer=Max 15min.

4. Am Ende eines Sprints werden die erweiterten Funktionen vorgestellt und Liste der Anforderungen an den nächsten Zyklus mit dem Product Owner besprochen.

Ablauf eines Sprints

1. Scrum legt genau fest, aus welchen Phasen ein zyklus besteht und welche Rollen und Aktivitäten darin durchgeführt werden.

2. Phasen des Sprints:

   1. Sprint Planing

      1. Product Owner stellt vorgesehene Anforderungen vor.

      2. Aufwandsabschätzung des Teams mit der Priorisierung des Product Oweners Befüllung anschließend das Sprint Backlog.

      3. Danach plant das Team die Umsetzung und Verteilung der Aufgaben.

   2. Sprint Durchführung

      1. Umsetzung der Anforderungen aus dem Sprint Backlog.

      2. Product Owner ist für Fragen da und spezifiziert während der Durchführung die Anforderungen für den nähsten Sprint.

      3. Die Menge der Anforderungen im SPrint Backlog wird während des Sprints nicht verändert.

      4. Scrum Master beseitigt Störnisse, die den reibungslosen Ablauf verhindern.

   3. Sprint Review

      1. Ergebnispräsentation an die Stakeholder.

      2. Stakeholder geben Feedback ab.

      3. Product Owner nimmt das Sprintergebnis ab und dokumentiert Änderungen und noch nicht umgesetzte Anforderungen im Product Backlog.

   4. Sprint Retrospektive

      1. Product Owner, Team und Scrum Master reflektieren gemeinsam den eigenen Arbeitsprozess des Sprints unter den Gesichtspunkten “Was lief gut?” und “Was sollte verbessert werden?”