Vorgehensmodelle hydrated
This commit is contained in:
parent
cd79c0f4bd
commit
c2dd3751e8
Binary file not shown.
@ -1780,36 +1780,12 @@
|
||||
|
||||
\newpage
|
||||
\section{Vorgehensmodelle}
|
||||
\subsection{Einführung}
|
||||
Wie läuft Softwareerstellung ab?
|
||||
\begin{itemize*}
|
||||
\item (oder besser, wie sollte sie ablaufen?)
|
||||
\item Aufgaben und Phasen siehe vorangegangene Kapitel
|
||||
\item Wann wird was getan? Abhängigkeiten?
|
||||
\begin{itemize*}
|
||||
\item Sequentiell / nebenläufig,
|
||||
\end{itemize*}
|
||||
\item Prozessmodelle der Softwareentwicklung
|
||||
\begin{itemize*}
|
||||
\item Regelwerke, Erfahrungen, best practices für große Projekte
|
||||
\item Aktives Entwicklungsgebiet
|
||||
\end{itemize*}
|
||||
\item Erweiterbar zum Software-Lebenszyklus mit Inbetriebnahme, Wartung, Außerdienststellung usw.
|
||||
\end{itemize*}
|
||||
|
||||
Softwareentwicklungsprozess/Vorgehensmodell
|
||||
\begin{itemize*}
|
||||
\item Methode zur Erstellung von Softwaresystemen
|
||||
\item Systematisch, rational und schrittweise erfolgender Weg vom Problem zur Lösung
|
||||
\item Ziel: Softwareentwicklungsprozess übersichtlich, plan- und strukturierbar
|
||||
\item Zerlegung des Softwareentwicklungsprozesses in überschaubare Einheiten
|
||||
\item Systematisch, rational und schrittweise zur Lösung
|
||||
\item Softwareentwicklungsprozess übersichtlich, plan- und strukturierbar
|
||||
\item Zerlegung des Softwareentwicklungsprozesses in Einheiten
|
||||
\item Unternehmensspezifisch, anpassbar, erweiterbar
|
||||
\begin{itemize*}
|
||||
\item Eigene Varianten, evtl. projektabhängig
|
||||
\item An spezielle Bedürfnisse des Informationsbereichs angepasst
|
||||
\item Kein allgemeingültiges Vorgehen
|
||||
\item Einsetzbar in verschiedenartigen Projekten
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
|
||||
Phasen
|
||||
@ -1818,12 +1794,6 @@
|
||||
\item Zeitlich begrenzte Phasen
|
||||
\item Auch inhaltlich und organisatorisch begrenzte Phasen möglich
|
||||
\item Teilprozesse / Aktivitäten
|
||||
\begin{itemize*}
|
||||
\item Inhaltliche Zerlegung
|
||||
\item Satz von Aufgaben
|
||||
\item Verteilung der Teilprozesse / Aktivitäten auf verschiedene Phasen
|
||||
\item Begleitet von unterstützenden, übergreifenden Aktivitäten
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
|
||||
Aufgabe
|
||||
@ -1834,7 +1804,7 @@
|
||||
|
||||
Arbeitsergebnis (oder Artefakt)
|
||||
\begin{itemize*}
|
||||
\item Dokument, Modell, System, Programmcode Lastenheft, Spezifikation, Glossar, Handbuch usw.
|
||||
\item Dokument, Modell, System, Programmcode, Lastenheft,...
|
||||
\item Intern zu lieferndes Ergebnis
|
||||
\end{itemize*}
|
||||
|
||||
@ -1845,28 +1815,13 @@
|
||||
\end{itemize*}
|
||||
|
||||
Unterstützungsprozesse / -Aktivitäten
|
||||
\begin{itemize*}
|
||||
\item Projektmanagement
|
||||
\begin{itemize*}
|
||||
\item Projektplanung, -verfolgung und -steuerung
|
||||
\item Risikomanagement
|
||||
\end{itemize*}
|
||||
\item Anforderungsmanagement
|
||||
\begin{itemize*}
|
||||
\item Im Gegensatz zur Anforderungsaufnahme und -analyse
|
||||
\end{itemize*}
|
||||
\item Qualitätsmanagement
|
||||
\begin{itemize*}
|
||||
\item Problem Management
|
||||
\item Softwaremetriken (Messung von Softwareeigenschaften)
|
||||
\item Statische + dynamische Analyse (Bestimmung von Schwachstellen)
|
||||
\end{itemize*}
|
||||
\item Konfigurationsmanagement
|
||||
\begin{itemize*}
|
||||
\item Versionsverwaltung, Änderungsmanagement
|
||||
\end{itemize*}
|
||||
\item Dokumentation
|
||||
\end{itemize*}
|
||||
\begin{description*}
|
||||
\item[Projektmanagement] Projektplanung, -verfolgung und -steuerung, Risikomanagement
|
||||
\item[Anforderungsmanagement] Im Gegensatz zur Anforderungsaufnahme und -analyse
|
||||
\item[Qualitätsmanagement] Softwaremetriken, Statische + dynamische Analyse (Bestimmung von Schwachstellen)
|
||||
\item[Konfigurationsmanagement] Versionsverwaltung, Änderungsmanagement
|
||||
\item[Dokumentation]
|
||||
\end{description*}
|
||||
|
||||
\subsection{Sequenzielle Modelle}
|
||||
\begin{itemize*}
|
||||
@ -1874,127 +1829,70 @@
|
||||
\begin{itemize*}
|
||||
\item Abhängigkeiten zwischen Teilergebnissen
|
||||
\item Ursprung in System- Hardwareentwicklung
|
||||
\begin{itemize*}
|
||||
\item Wurde für die SW-Entwicklung übernommen
|
||||
\item Auch heute verbreitetes Vorgehen bei HW-Entwicklung
|
||||
\end{itemize*}
|
||||
\item Sequenzielles Phasenmodell (Abschluss der Phasen)
|
||||
\item Stark Dokumentengetrieben (Ergebnisse der Phasen)
|
||||
\item Unterteilung in abgeschlossene Phasen:
|
||||
\begin{itemize*}
|
||||
\item Analyse
|
||||
\item Analyse (Planung)
|
||||
\item Design/Entwurf
|
||||
\item Implementierung
|
||||
\item Test \& Integration
|
||||
\item Einführung, Betrieb \& Wartung
|
||||
\end{itemize*}
|
||||
\item Alternativ:
|
||||
\begin{itemize*}
|
||||
\item Planung
|
||||
\item Definition
|
||||
\item Entwurf
|
||||
\item Implementierung
|
||||
\item Test \& Integration
|
||||
\item Einsatz und Wartung
|
||||
\end{itemize*}
|
||||
\item Vorteile
|
||||
\begin{itemize*}
|
||||
\item Einfach und verständlich, bekannt und verbreitet
|
||||
\item Erleichterte Planung und Steuerung
|
||||
\end{itemize*}
|
||||
\item Nachteile
|
||||
\begin{itemize*}
|
||||
\item Idealisierte Annahme rein sequentiellen Ablaufs
|
||||
\item Starke Abhängigkeiten zwischen Teilergebnissen
|
||||
\item Ungeeignet, falls Anforderungen zu Beginn unklar
|
||||
\item Unflexibel gegenüber Änderungen
|
||||
\item Erst sehr spät greifbare Ergebnisse
|
||||
\end{itemize*}
|
||||
\item Einfach und verständlich, bekannt und verbreitet
|
||||
\item Starke Abhängigkeiten zwischen Teilergebnissen
|
||||
\item Ungeeignet, falls Anforderungen zu Beginn unklar
|
||||
\item Unflexibel gegenüber Änderungen
|
||||
\end{itemize*}
|
||||
\item Erweitertes Wasserfallmodell
|
||||
\item Sequenziell
|
||||
\begin{itemize*}
|
||||
\item Verbesserung für Änderungen und Fehler - Rückschritte
|
||||
\item Phasen strikt nacheinander, Dokumenten-orientiert
|
||||
\item Keine Änderungen abgeschlossener Artefakte
|
||||
\end{itemize*}
|
||||
\item Alternative Arten von Phasenmodellen
|
||||
\item Nebenläufig
|
||||
\begin{itemize*}
|
||||
\item Sequenziell
|
||||
\begin{itemize*}
|
||||
\item Phasen strikt nacheinander, Dokumenten-orientiert
|
||||
\item Keine Änderungen abgeschlossener Artefakte
|
||||
\end{itemize*}
|
||||
\item Nebenläufig
|
||||
\begin{itemize*}
|
||||
\item Phasen laufen teilweise parallel für bessere Zeitnutzung
|
||||
\item Weiterhin keine Änderungen fertiger Dokumente
|
||||
\end{itemize*}
|
||||
\item Inkrementell
|
||||
\begin{itemize*}
|
||||
\item Unterteilung des Produkts in Teile
|
||||
\item Schnellere Auslieferung von Teilfunktionalität nach vollständiger Aufnahme der Anforderungen
|
||||
\end{itemize*}
|
||||
\item Alternative: Evolutionär
|
||||
\begin{itemize*}
|
||||
\item Anforderungen entwickeln sich im Projekt
|
||||
\item Ausgelieferte Versionen ergeben neue Anforderungen
|
||||
\end{itemize*}
|
||||
\item V-Modell [Boehm]
|
||||
\begin{itemize*}
|
||||
\item Explizite Adressierung der Qualitätssicherung
|
||||
%\item %
|
||||
\item Entwicklung des V-Modells in Deutschland
|
||||
\begin{itemize*}
|
||||
\item Leitfaden, in Bundesbehörden ab 1990er verbindlich
|
||||
\item Version V-Modell 97 erweitert um Werkzeuganforderungen, Rollen und Submodelle der Beteiligten
|
||||
\item Kritik: schlecht skalier\item und anpassbar, zu unflexibel,
|
||||
\item bürokratisch, nicht an moderner OO-SWEntw. orientiert
|
||||
\end{itemize*}
|
||||
\item V-Modell XT (extreme tailoring)
|
||||
\begin{itemize*}
|
||||
\item Aktuelle Version ab 2004/05
|
||||
\item Einfache projektspezifische Anpassbarkeit
|
||||
\item Assistent www.v-modell-xt.de (kleines Projekt ~40 Dok.!)
|
||||
\item Überprüfbarer Projektfortschritt
|
||||
\item AG/AN-Sichten und Schnittstellen, Ausschreibungen
|
||||
\item Gesamter SW-Lebenszyklus
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
\item Phasen laufen teilweise parallel für bessere Zeitnutzung
|
||||
\item Weiterhin keine Änderungen fertiger Dokumente
|
||||
\end{itemize*}
|
||||
\item Inkrementell
|
||||
\begin{itemize*}
|
||||
\item Unterteilung des Produkts in Teile
|
||||
\item Schnellere Auslieferung von Teilfunktionalität nach vollständiger Aufnahme der Anforderungen
|
||||
\end{itemize*}
|
||||
\item Evolutionär
|
||||
\begin{itemize*}
|
||||
\item Anforderungen entwickeln sich im Projekt
|
||||
\item Ausgelieferte Versionen ergeben neue Anforderungen
|
||||
\end{itemize*}
|
||||
\item V-Modell [Boehm]
|
||||
\begin{itemize*}
|
||||
\item Explizite Adressierung der Qualitätssicherung
|
||||
\item Entwicklung des V-Modells in Deutschland
|
||||
\item V-Modell XT (extreme tailoring)
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
|
||||
|
||||
\subsection{Iterative Modelle}
|
||||
Iterativer Entwicklungsprozess
|
||||
\begin{itemize*}
|
||||
\item Spezifikation, Entwurf und Implementierung müssen immer wieder verändert und angepasst werden
|
||||
\item Häufiges Integrieren, Validieren und Testen
|
||||
\item "You should use iterative development only on projects that you want to succeed." [Fowler]
|
||||
\end{itemize*}
|
||||
|
||||
Inkrementelle Entwicklung
|
||||
\begin{itemize*}
|
||||
\item Wenn möglich, sollte es immer einen lauffähigen (unvollständigen) Prototypen geben
|
||||
\item Neue Funktionen sofort integrieren
|
||||
\item Neue Versionen gegenüber Anforderungen Validieren
|
||||
\end{itemize*}
|
||||
|
||||
%
|
||||
Spiralmodell
|
||||
\begin{itemize*}
|
||||
\item Risikogetrieben: Größte Projektrisiken identifizieren und als erstes bearbeiten (Prototyp?)
|
||||
\item Risikogetrieben: Größte Projektrisiken identifizieren und als erstes bearbeiten
|
||||
\item Spirale = iterativer Zyklus durch dieselben Schritte
|
||||
\item Ziele jedes Durchlaufs aus alten Ergebnissen ableiten
|
||||
\item Kosten/Nutzen abwägen
|
||||
\item Regelmäßige Überprüfung des Prozessmodells
|
||||
\item Anpassbar
|
||||
\item Hoher Management-Overhead, große Projekte
|
||||
\end{itemize*}
|
||||
|
||||
Unified Process
|
||||
\begin{itemize*}
|
||||
\item Vorgehensmodelle zur objektorientierten Softwareentwicklung
|
||||
\begin{itemize*}
|
||||
\item Ivar Jacobson, Grady Booch and James Rumbaugh: The Unified Software Development Process, (Rational/IBM), 1999
|
||||
\end{itemize*}
|
||||
\item Phasen der Entwicklung
|
||||
\begin{itemize*}
|
||||
\item Anfang, Ausarbeitung, Erstellung, Überleitung
|
||||
@ -2006,75 +1904,30 @@
|
||||
\item Geschäftsprozessmodellierung, Anforderungsanalyse, Analyse \& Design, Implementierung, Test, Auslieferung
|
||||
\item In unterschiedlichen Anteilen parallel ablaufend!
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
|
||||
Prinzipieller Ablauf des Unified Process
|
||||
%
|
||||
\begin{itemize*}
|
||||
\item Haupteigenschaften des UP
|
||||
\item Variation
|
||||
\begin{itemize*}
|
||||
\item Inkrementell, iterativ, evolutionär
|
||||
\item Anwendungsgetrieben
|
||||
\item Architekturzentriert
|
||||
\item Risikoorientiert
|
||||
\item Ereignisorientiert
|
||||
\item Nutzt die UML als Notationssprache
|
||||
\item Erweiterbar / Anpassbar
|
||||
\end{itemize*}
|
||||
\item Verbreitete Vertreter
|
||||
\begin{itemize*}
|
||||
\item Rational Unified Process - RUP (Rational / IBM)
|
||||
\item Open Unified Process - OpenUP (Eclipse Foundation)
|
||||
\item Object Engineering Process - OEP (oose GmbH)
|
||||
\end{itemize*}
|
||||
\item Vorteile
|
||||
\begin{itemize*}
|
||||
\item Vorteile der Eigenschaften (iterativ, inkrementell, anpassbar, ...)
|
||||
\item Berücksichtigung des Risikos
|
||||
\item Passend für objektorientiertes Paradigmas und UML
|
||||
\item Tool-Unterstützung
|
||||
\item Reaktion auf Änderungen möglich
|
||||
\item Industriestandard
|
||||
\end{itemize*}
|
||||
\item Nachteile
|
||||
\begin{itemize*}
|
||||
\item Hoher Bürokratischer Aufwand $\rightarrow$ Tailoring notwendig!
|
||||
\item Relativ hohe „Lernkurve“ aller Beteiligten
|
||||
\item Keine schnelle Reaktion auf Änderungen
|
||||
\item Keine integrierte Qualitätssicherung
|
||||
\end{itemize*}
|
||||
\item Passend für objektorientiertes Paradigmas und UML
|
||||
\item Tool-Unterstützung
|
||||
\item Reaktion auf Änderungen möglich
|
||||
\item Hoher Bürokratischer Aufwand $\rightarrow$ Tailoring notwendig!
|
||||
\item Relativ hohe „Lernkurve“ aller Beteiligten
|
||||
\item Keine schnelle Reaktion auf Änderungen
|
||||
\item Keine integrierte Qualitätssicherung
|
||||
\end{itemize*}
|
||||
|
||||
\subsection{Agile Methoden}
|
||||
\begin{itemize*}
|
||||
\item Ausgangspunkt
|
||||
\begin{itemize*}
|
||||
\item Ziv's Unsicherheitsprinzip des Software Engineering: "Unsicherheit ist im Software-Entwicklungsprozess und den Produkten inhärent und unvermeidlich." (Ziv, 1996)
|
||||
\item Humphrey's Prinzip der Anforderungsunsicherheit: "In einem neuen Software System werden die Anforderungen solange nicht komplett bekannt sein, bis die Anwender damit arbeiten." (Humphrey, 1995)
|
||||
\item Wegner's Lemma: "Es ist unmöglich, ein interaktives System komplett zu spezifizieren." (Wegner, 1995)
|
||||
\end{itemize*}
|
||||
\item Ziele
|
||||
\begin{itemize*}
|
||||
\item geringer bürokratischer Aufwand
|
||||
\item Hauptziel ist die Softwareentwicklung
|
||||
\item nur wenige Regeln bzw. Verhalten definiert
|
||||
\item sehr flexibel gehaltenes Vorgehen
|
||||
\item stark Anwendungs- und Ereignisorientiert
|
||||
\item iterativ / inkrementell / evolutionär
|
||||
\item sehr schnelle Entwicklungsiterationen
|
||||
\item meist Architekturzentriert
|
||||
\item auch testgetriebenes Vorgehen möglich
|
||||
\item Berücksichtigung sozialer Aspekte
|
||||
\item Softwareentwicklung: Kreative Arbeit von Kreativen
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
|
||||
Das Agile Manifest (2001)
|
||||
\begin{itemize*}
|
||||
\item Individuen und Interaktionen bedeutender als Prozesse und Tools
|
||||
\item Funktionierende Software bedeutender als übermäßige Dokumentation
|
||||
\item Stetige Zusammenarbeit mit dem Kunden bedeutender als Vertragsverhandlung
|
||||
\item Mut und Offenheit für Änderungen bedeutender als Befolgen eines Plans
|
||||
\item Individuen und Interaktionen $>$ als Prozesse und Tools
|
||||
\item Funktionierende Software $>$ als übermäßige Dokumentation
|
||||
\item Stetige Zusammenarbeit mit Kunden $>$ als Vertragsverhandlung
|
||||
\item Mut und Offenheit für Änderungen $>$ als Befolgen eines Plans
|
||||
\end{itemize*}
|
||||
|
||||
Eigenschaften agiler Vorgehensmodelle
|
||||
@ -2082,31 +1935,6 @@
|
||||
\item Team ist für Ergebnis verantwortlich und organisiert sich selbst
|
||||
\item Kleine Teams 5-8 Personen
|
||||
\item Definition von Richtlinien, Werten und Prinzipien
|
||||
\item Beispiele für Werte
|
||||
\begin{itemize*}
|
||||
\item Kommunikation (Kommunikation statt Dokumentation)
|
||||
\item Einfachheit (KISS „Keep it small and simple“)
|
||||
\item Feedback
|
||||
\item Mut
|
||||
\item Respekt
|
||||
\end{itemize*}
|
||||
\item Beispiele für Prinzipien
|
||||
\begin{itemize*}
|
||||
\item Beidseitiger Vorteil
|
||||
\item Fehlschläge hinnehmen
|
||||
\item Ständige Verbesserungen
|
||||
\item Ständige Lauffähigkeit des Codes
|
||||
\item Kleine Schritte
|
||||
\item Wiederverwendung bestehender / bewährter Lösungen
|
||||
\end{itemize*}
|
||||
\item Beispiele für Praktiken
|
||||
\begin{itemize*}
|
||||
\item Pair-Programing, Coding Rules
|
||||
\item Kollektives Eigentum / Gemeinsamer Codebesitz
|
||||
\item Testgetriebene Entwicklung
|
||||
\item Ständiges Refactoring
|
||||
\item Keine Überstunden
|
||||
\end{itemize*}
|
||||
\item Vorteile agiler Methoden
|
||||
\begin{itemize*}
|
||||
\item Geringer bürokratischer Aufwand
|
||||
@ -2119,10 +1947,8 @@
|
||||
\item Nachteile
|
||||
\begin{itemize*}
|
||||
\item Schwierigeres Projektmanagement
|
||||
\begin{itemize*}
|
||||
\item Chaotische Vorgehen
|
||||
\item Schwere Planbarkeit des Ergebnisses
|
||||
\end{itemize*}
|
||||
\item Chaotische Vorgehen
|
||||
\item Schwere Planbarkeit des Ergebnisses
|
||||
\item Notwendige Beteiligung des Kunden
|
||||
\item Ergebnis ist schwer vorherzusagen
|
||||
\end{itemize*}
|
||||
@ -2130,238 +1956,59 @@
|
||||
|
||||
\paragraph{eXtreme Programming (XP)}
|
||||
\begin{itemize*}
|
||||
\item Beck 1999, aus Kritik an „monumentalen Modellen“
|
||||
\item Evolutionäre Entwicklung in kleinen Schritten
|
||||
\begin{itemize*}
|
||||
\item Möglichst einfaches Design
|
||||
\end{itemize*}
|
||||
\item Konzentration auf Programmcode als Analyseergebnis, Entwurfsdokument und Dokumentation
|
||||
\item Weglassen von explizitem Design, ausführlicher Dokumentation und Reviews
|
||||
\item Code wird permanent lauffähig gehalten (täglich)
|
||||
\item Schnell und flexibel
|
||||
\item Erfordert Disziplin der Teilnehmer
|
||||
\item Rollen: Projektleiter, Kunde (verfügbar), Entwickler
|
||||
\begin{itemize*}
|
||||
\item Max. 5-10 Entwickler
|
||||
\end{itemize*}
|
||||
\item Kunde bestimmt Anforderung und Prioritäten
|
||||
\begin{itemize*}
|
||||
\item planning game; story cards (use cases)
|
||||
\end{itemize*}
|
||||
\item Implementierung in kleinen Schritten
|
||||
\begin{itemize*}
|
||||
\item pair programming, collective code ownership
|
||||
\item Häufige Releases inkl. Integration
|
||||
\item Refactoring bei Designänderungen
|
||||
\item Programmier-Konventionen
|
||||
\end{itemize*}
|
||||
\item Regelmäßiges automatisiertes Testen
|
||||
\begin{itemize*}
|
||||
\item test-first Ansatz
|
||||
\end{itemize*}
|
||||
\item Morgendliches Meeting im Stehen ohne Diskussionen
|
||||
\item 40h-Woche
|
||||
\item XP
|
||||
\begin{itemize*}
|
||||
\item Sammlung von 12 "best practices"
|
||||
\item Test-getrieben
|
||||
\item Flexibel, effizient
|
||||
\item Kleine Teams
|
||||
\item Erfordert Disziplin der Teilnehmer
|
||||
%\item %
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
|
||||
\paragraph{Scrum}
|
||||
\begin{itemize*}
|
||||
\item [Ken Schwaber, Jeff Sutherland und Mike Beedle]
|
||||
\item Haupteigenschaften
|
||||
\item Iterativ / Inkrementell, Evolutionär
|
||||
\item stark Anwendungs- und Ereignisorientiert
|
||||
\item schnelle Entwicklungsiterationen
|
||||
\item Sprint: eine schnelle Iteration/Umsetzung Features (30 Tage)
|
||||
\item Product Backlog: Liste der gewünschten Features des Produkts
|
||||
\begin{itemize*}
|
||||
\item Iterativ / Inkrementell, Evolutionär
|
||||
\item stark Anwendungs- und Ereignisorientiert
|
||||
\item schnelle Entwicklungsiterationen
|
||||
\end{itemize*}
|
||||
\item Sprint
|
||||
\begin{itemize*}
|
||||
\item eine schnelle Iteration: Dauer ca. 30 Tage
|
||||
\item Festlegung welche Features umgesetzt werden
|
||||
\end{itemize*}
|
||||
\item Product Backlog
|
||||
\begin{itemize*}
|
||||
\item Liste der gewünschten Features des Produkts
|
||||
\item Vom Produkt-Owner priorisiert / Aufwand vom Team geschätzt
|
||||
\item Jeder kann Einträge beisteuern
|
||||
\end{itemize*}
|
||||
\item Rollen
|
||||
\begin{description*}
|
||||
\item[Product Owner] Erfasst Bedürfnisse der Kunden und Stakeholder, Pflegt Backlog, definiert, priorisiert Features pro Sprint
|
||||
\item[Scrum Master] Berät das Team, Überprüft Einhaltung von Werten und Techniken, moderiert die Meetings, Schützt das Team vor äußeren Störungen, Repräsentiert Team gegenüber Management
|
||||
\item[Scrum Team] Team organisiert sich und die Aufgaben selbst, gemeinsames Ziel verfolgen, selbstloses Handeln, Teamentscheidungen vertreten
|
||||
\end{description*}
|
||||
\item Sprint Backlog
|
||||
\begin{itemize*}
|
||||
\item Product Owner
|
||||
\begin{itemize*}
|
||||
\item Erfasst Bedürfnisse der Kunden und Stakeholder
|
||||
\item Pflegt Backlog, definiert, priorisiert Features pro Sprint
|
||||
\end{itemize*}
|
||||
\item Scrum Master
|
||||
\begin{itemize*}
|
||||
\item Berät das Team, Überprüft Einhaltung von Werten und Techniken, moderiert die Meetings
|
||||
\item Schützt das Team vor äußeren Störungen
|
||||
\item Repräsentiert Team gegenüber Management
|
||||
\end{itemize*}
|
||||
\item Scrum Team (ca. 5-9 Personen)
|
||||
\begin{itemize*}
|
||||
\item Team organisiert sich und die Aufgaben selbst
|
||||
\item Team bedeutet: Zielgerichtet und funktionsübergreifend arbeiten, gemeinsames Ziel verfolgen, selbstloses Handeln, Teamentscheidungen vertreten
|
||||
\end{itemize*}
|
||||
\item Für die aktuelle Iteration ausgewählte Aufgaben ($\leq$ 2 Tage)
|
||||
\item Team-Mitglieder wählen Tasks aus - keine Zuweisung
|
||||
\item Restaufwand wird täglich aktualisiert - Burndown Chart
|
||||
\item Team-Mitglied kann Tasks hinzufügen, löschen, ändern
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
|
||||
Sprint Backlog
|
||||
\begin{itemize*}
|
||||
\item Für die aktuelle Iteration ausgewählte Aufgaben
|
||||
\item Daily Meeting (15 Minuten)
|
||||
\begin{itemize*}
|
||||
\item Aufgabe nicht länger als 2 Tage Aufwand
|
||||
\item Was wurde geschafft? Was ist zu tun? Was behindert den Fortschritt?
|
||||
\item Weiterführende Diskussionen erst im Anschluss
|
||||
\end{itemize*}
|
||||
\item Team-Mitglieder wählen Tasks aus - keine Zuweisung
|
||||
\item Restaufwand wird täglich aktualisiert - Burndown Chart
|
||||
\item Team-Mitglied kann Tasks hinzufügen, löschen, ändern
|
||||
\item Darstellung an prominenter Stelle
|
||||
\end{itemize*}
|
||||
|
||||
Daily Meeting
|
||||
\begin{itemize*}
|
||||
\item ca. 15 Minuten
|
||||
\item Kurze Statusmeldung, Was wurde geschafft? Was ist zu tun? Was behindert den Fortschritt?
|
||||
\item Weiterführende Diskussionen erst im Anschluss
|
||||
\end{itemize*}
|
||||
|
||||
%
|
||||
|
||||
Sprint Review-Meeting
|
||||
\begin{itemize*}
|
||||
\item Präsentation des Erreichten (Feature Demo)
|
||||
\item Product Owner, Kunde usw. geben Feedback
|
||||
\item Sprint Review-Meeting
|
||||
\begin{itemize*}
|
||||
\item Präsentation des Erreichten (Feature Demo)
|
||||
\item Product Owner, Kunde usw. geben Feedback
|
||||
\item Neue Anforderungen hinzufügen / Neu priorisieren
|
||||
\item Qualitätsansprüche ändern
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
|
||||
Sprint-Retrospektive
|
||||
\begin{itemize*}
|
||||
\item Rückkopplungsschleife
|
||||
\item Sprint-Retrospektive
|
||||
\begin{itemize*}
|
||||
\item Was war gut und was hat nicht funktioniert?
|
||||
\item Was kann verbessert werden?
|
||||
\end{itemize*}
|
||||
\item Nach jedem Sprint
|
||||
\item Diskussion der identifizierten Probleme
|
||||
\item Identifikation von wenigen „Action Items“
|
||||
\end{itemize*}
|
||||
|
||||
Burndown Chart
|
||||
\begin{itemize*}
|
||||
\item Darstellung der offenen und erledigten Aufwände / Tasks
|
||||
%\item %
|
||||
\end{itemize*}
|
||||
|
||||
\subsection{Zusammenfassung}
|
||||
\begin{itemize*}
|
||||
\item Software-Entwicklungsmethode
|
||||
\begin{itemize*}
|
||||
\item Elemente
|
||||
\begin{itemize*}
|
||||
\item Darstellung - Notation und Semantik für Modelle, Diagrammtypen, Dokumentvorlagen (Artefakte)
|
||||
\item Vorgehensmodell - Phasen, Arbeitsschritte
|
||||
\item Verfahren - Regeln, Anweisungen, Aktivitäten (+Rollen)
|
||||
\item Werkzeuge
|
||||
\end{itemize*}
|
||||
\item Industriestandards: RUP + UML
|
||||
\item Öffentliche Auftraggeber: V-Modell
|
||||
\item Firmenintern: eigene Varianten, evtl. projektabhängig
|
||||
\item Weitere Themen
|
||||
\begin{itemize*}
|
||||
\item Reifegradbeurteilung CMMI, SPICE, ISO 9000
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
\item Charakterisierung von Vorgehensmodellen
|
||||
\begin{itemize*}
|
||||
\item Sequenziell
|
||||
\begin{itemize*}
|
||||
\item Teilprozesse strikt nacheinander
|
||||
\item Keine Änderungen abgeschlossener Artefakte
|
||||
\end{itemize*}
|
||||
\item Nebenläufig
|
||||
\begin{itemize*}
|
||||
\item Teilprozesse laufen teilweise parallel für bessere Zeitnutzung
|
||||
\end{itemize*}
|
||||
\item Dokumentgetrieben
|
||||
\begin{itemize*}
|
||||
\item Erstellung von Dokumenten (Artefakte) im Vordergrund
|
||||
\item Festlegung der Dokumente pro Phase
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
\item Charakterisierung von Vorgehensmodellen
|
||||
\begin{itemize*}
|
||||
\item Iterativ
|
||||
\begin{itemize*}
|
||||
\item Definition einer sich wiederholenden Abfolge von Teil-Prozessen bzw. Aktivitäten
|
||||
\item Schnelles Wiederholen dieser Abfolgen
|
||||
\end{itemize*}
|
||||
\item Inkrementell
|
||||
\begin{itemize*}
|
||||
\item Definition und Kontrolle des Fortschritts pro Iteration
|
||||
\item Kleine Erweiterungen
|
||||
\end{itemize*}
|
||||
\item Evolutionäres Vorgehen
|
||||
\begin{itemize*}
|
||||
\item Schnelle Prototypen
|
||||
\item Lauffähiger Prototyp jederzeit vorhanden
|
||||
\item Toolunterstützung (Versionierung)
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
\item Charakterisierung von Vorgehensmodellen
|
||||
\begin{itemize*}
|
||||
\item Ereignisorientiert
|
||||
\begin{itemize*}
|
||||
\item Schnelle Reaktion auf Anforderungsänderungen
|
||||
\item Keine starre Abfolge von Tätigkeiten / Prozessen
|
||||
\item Voraussetzung: Prozesse laufen parallel ab
|
||||
\end{itemize*}
|
||||
\item Architekturzentriert
|
||||
\begin{itemize*}
|
||||
\item Starke Gewichtung der Architektur
|
||||
\item Verwendung von Modellen, Mustern und vorhandenem Wissen
|
||||
\end{itemize*}
|
||||
\item Anwendungsgetrieben
|
||||
\begin{itemize*}
|
||||
\item Orientierung an den Anwendungsfällen
|
||||
\item Umsetzen, was einem Anwendungsfall zugeordnet werden kann
|
||||
\item Anwender steht im Mittelpunkt (User Stories)
|
||||
\end{itemize*}
|
||||
\item Risikoorientiert
|
||||
\begin{itemize*}
|
||||
\item Risiko der Entwicklung wird in Planung berücksichtigt
|
||||
\item Risiko- / Nutzen-Analyse
|
||||
\end{itemize*}
|
||||
\item Test- / Qualitätsgetrieben
|
||||
\begin{itemize*}
|
||||
\item Qualität steht im Vordergrund
|
||||
\item Test wird während oder sogar vor der Implementierungs-phase erstellt
|
||||
\end{itemize*}
|
||||
\item Erweiterbar / Anpassbar (tailoring)
|
||||
\begin{itemize*}
|
||||
\item Nur Rahmen des Vorgehens festgelegt
|
||||
\item Konkretes Vorgehen wird an die Bedürfnisse angepasst
|
||||
\item Grundlegende Eigenschaft von Vorgehensmodellen
|
||||
\end{itemize*}
|
||||
\end{itemize*}
|
||||
\item Softwareprojekt im Sommersemester
|
||||
\begin{itemize*}
|
||||
\item Auswahl aus 3 Vorgehensmodellen
|
||||
\begin{itemize*}
|
||||
\item Klassisches Vorgehen
|
||||
\item Unified Process
|
||||
\item Agiles Vorgehen
|
||||
\end{itemize*}
|
||||
\item Rückkopplungsschleife: Was war gut und was hat nicht funktioniert?
|
||||
\item Nach jedem Sprint
|
||||
\item Diskussion der identifizierten Probleme
|
||||
\item Identifikation von wenigen „Action Items“
|
||||
\end{itemize*}
|
||||
\item Burndown Chart: Darstellung der offenen und erledigten Aufwände / Tasks
|
||||
\end{itemize*}
|
||||
|
||||
\newpage
|
||||
|
||||
Loading…
Reference in New Issue
Block a user