Please enable JavaScript.
Coggle requires JavaScript to display documents.
Softwareprozessrahmenwerke - Coggle Diagram
Softwareprozessrahmenwerke
V-Modell XT
Allgemein
verbindlich für öffentliche Projekte vorgeschrieben, z.B. Bundesverwaltung
Hauptelemente
Projekttypen
Systementwicklungsprojekt eines Auftraggebers
Systementwicklungsprojekt eines Auftragnehmers
Systementwicklungsprojekt eines Auftraggebers mit Auftragnehmer in gleicher Organisation
Einführung und Pflege eines organnisationsspezifischen Vorgehensmodellss
Entscheidungspunkte und Projektdurchführungsstragien
Entscheidungspunkte: Entscheidung, ob gewisse Projektfortschrittstufe erreicht wird
zu jedem Entscheidungspunkt sind Ergebnisse bzw. Produkte definiert, die fertiggestellt werden
Reihenfolge in Projektdurchführungsstrattegie festgelegt
konkrete Durchführungsstrategie: von Prjekttyp und spezifischen Projektmerkmalen abhängig
Beispiele: Projekt genehmigt, Projekt definiert, Anforderungen festgelegt, Projekt ausgeschrieben, Projekt beauftragt, Abnahme erfolgt, Projekt abgeschlossen, …
Vorgehensbausteine
konkrete Aufgaben, Aktivitäten, Ergebnisse und beteiligte Rollen werden dort festgelegt
konkreter Projekttyp entscheidet, ob Vorgehensbausteine zur Anwendung kommen müssen oder nicht
es gibt vor WAS von WEM in einem Projekt zu tun ist
Referenzen
Vorgaben und Anhaltspunkte für
Tailoring (Zuschneiden) für eigene Softwareprozessmodelle
Rollen im Softwareprozess. 30 verschiedene mit Beschreibung, Zuständigkeiten und Kategorie der Rolle
Produkte im Softwareprozess, detaillierte Beschreibung zur Erstellung, Verwendung und zu Abhängigkeiten von 110 Produkt- bzw. Ergebnistypen
Aktivitäten, 102 verschiedene; Ablauf der einzelnen Schritte und detaillierte Anleitung zur Erstellung und Bearbeitung der Ergebnisse
Konventionsabbildungen, internationale und nationale Konventionen in Beziehungen zu Elementen des V-Modells XT
Rational Unified Process (RUP)
Allgemein
industriell geprägt
von IBM entwickelt
Phasen im RUP
Inception (Konzeption)
Vorbereitungsphase: Fokus auf RE, Erarbeitung der Projektvision, erste Risikoanalyse, Erstellen des Projektplans, Aufstellen des Projektbudges
Elaboration (Entwurf)
Verfeinerung und Detaillierung der Anforderungen, Entwicklung und Beschreibung eines Konzepts für System-Architektur, ggfs. Bau von ersten Prototypen
Ergebnis dieser Phase: Architekturbeschreibung ⇨ Vorgabe und Rahmen für nächste Phase
Construction
Großteil der Implementierungsaktivitäten: Erzeugung des Programmcodes, Durchführung und Behebung von Softwaretests
Transition (Übergabe)
Aktivitäten nach Abshcluss der Entwicklungsarbeiten bis zur Inbetriebnahme: Nutzerschulung, Systemtest, Integration in Ausführungsumgebung, Dokumentation
Organisation der Software Engineering Kernaktivitäten
Disciplines
Business Modelling
Requirements
Analysis & Design
Implementation
Test
Deployment
Configuration & Change Mgmt.
Project Mgmt.
Environment
zu jeder Disziplin gibt es spezifische Rollen, Artefakte, Aktivitäten und Workflows (Reihenfolge von Aktivitöten in Verbindung mit Artefakten und Rollen)
Kernaktivitäten nicht streng separiert, teilweise parallel oder eng verzahnt
Anteil bzw. Intensität mit der Aktivitäten durchgeführt werden unterscheiden sich
einzelne Phasen können auch mehrfach hintereinander durchgeführt werden ⇨ mehrere Zyklen
Scrum
Allgemein
stark evolutionär
konsequente Organistion in kurze Zyklen und sich selbst organisiertes Team
keine Rollen oder Aktivitäten, die für Software Engineering typisch sind
kein spezifisches Softwareprozessmodell-Rahmenwerk sondern für ganz verschiedene Aufgaben anwendbar
definiert verschiedene Rollen, strenge Vorgabe für Aktivitäten und deren Reihenfolge
Scrum-spezifische Elemente zur Verwaltung des Projekts
Rollen
Product Owner
repräsentiert Bedürfnisse des Kunden bzw. des Anwenders
für Erfolg als auch für RE verantwortlich
Brücke zwischen Projekt und Außenwelt ⇨ einzige Schnittstelle zwischen Stakeholdern und Entwicklern
trifft wichtige fachliche Enscheidungen
erstellt Releaseplan, priorisiert Anfprderungen und nimmt in einem Zyklus erstelltes Ergebnis ab
Scrum Master
vergleichbar mit organisatorischem Projektleiter
moderiert und begleitet Aktivitäten
sorgt für Einhaltung von zeitlichen und organisatorischen Vorgaben
sorgt für möglichst ideale Arbeitsumgebung von Product Owner und Team ⇨ Hindernisse aus dem Weg räumen
keine Weisungsbefugnis
Managen des Scrumprozesses
Team
technische Konzeption, Konstruktion und Qualitätssicherung
arbeitet selbstorganisiert und autonom
bestimmt in Abstimmung mit Product Owner, wievielle Funktionen wann in einem Zyklus umgesetzt werden
frei in Wahl der technischen Umsetzung (abgesehen: organisatorische Vorgaben und Konventionen)
alle benötigten Rollen arbeiten in einem Team eng zusammen
insgesamt 3 bis 9 Personen
am Ende des Zyklus: Ergebnispräsentation
Elemente zur Verwaltung und Steuerung des Projekts
Product Backlog
Liste aller Anforderungen an das System
Detaillierung; von ersten Idee bis zur vollständig spezifizierten Funktion
zu Beginn: nur wenige, grob umrissene Anforderungen und Wünsche an System
im Verlauf verfeinert, ergänzt und priorisiert
nur Product Ownder dar Product Backlog verändern
Sprint Backlog
Liste von Anforderungen für einen Sprint (Zyklus)
Teilmenge des Product Backlog
Anforderungen werden von Product Owner und Team miteinander vereinbart
Menge der Anforderungen von Velocity des Teams abhängig
während Bearbeitungszeit eines Zyklus wird Sprint Backlog nicht verändert
Velocity
teamspezifische Kennzahl, die sich aus Menge und Umfang der in einem Zyklus umgesetzten Funktionen ergibt
Velocity stabilisiert sich nach den ersten 5 - 7 durchgeführten Zyklen
Anhaltspunkt, wie viele und welche Anforderunen ein Team für einen Zyklus aus Product Backlog in Sprint Backlog laden kann
Aktivitäten im Scrum
aus Product Backlog wird Sprint Backlog für einen Sprinbt erstellt
Team setzt während eines Sprints die Anforderungen aus dem Sprint Backlog um
Daily Scrum: tägliche Statusbesprechungen, max. 15 Minuten ⇨ was wurde und was wird in den nächsten 24 h bearbeitet, Probleme
Ende des Sprints: erweiterte Software wird vorgestellt und Liste der Anforderungen für nächsten Zyklus wird bestimmt
Ablauf eines Sprints
Planning
Product Owner stellt Anforderungen vor
Team schätzt Umsetzungsaufwand ein
Sprint Backlog wird befüllt
Team plant intern die Umsetzung und die Verantwortlichkeiten
Durchführung
Anforderungen werden umgesetzt
Product Owner für Fragen zur Verfügung
Product Owner spezifiziert Anforderungen für nächsten Sprint
Scrum Master beseitigt Hindernisse und sorgt für ordnungsgemäße Durchführung des Daily Scrum
Review
Team präsentiert Ergebnis den Stakeholdern
Stakeholder geben Feedback
Product Owner nimmt Sprintergebnis offiziell ab und dokumentiert Änderungen und noch nicht umgesetzte Anforderungen
Retrospektive
Product Owner, Team und Scrum Master reflektieren gemeinsam den Arbeitsprozess