wieerwill/Informatik
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Vorgehensmodelle hydrated

Browse Source
This commit is contained in:
WieErWill 2021-03-16 10:39:44 +01:00
parent cd79c0f4bd
commit c2dd3751e8
2 changed files with 80 additions and 433 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

BIN
Softwaretechnik - Cheatsheet.pdf
View File

Binary file not shown.

421
Softwaretechnik - Cheatsheet.tex
View File

@ -1780,36 +1780,12 @@
\newpage \newpage
\section{Vorgehensmodelle} \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*} \begin{itemize*}
\item Methode zur Erstellung von Softwaresystemen \item Methode zur Erstellung von Softwaresystemen
\item Systematisch, rational und schrittweise erfolgender Weg vom Problem zur Lösung \item Systematisch, rational und schrittweise zur Lösung
\item Ziel: Softwareentwicklungsprozess übersichtlich, plan- und strukturierbar \item Softwareentwicklungsprozess übersichtlich, plan- und strukturierbar
\item Zerlegung des Softwareentwicklungsprozesses in überschaubare Einheiten \item Zerlegung des Softwareentwicklungsprozesses in Einheiten
\item Unternehmensspezifisch, anpassbar, erweiterbar \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*} \end{itemize*}
Phasen Phasen
@ -1818,12 +1794,6 @@
\item Zeitlich begrenzte Phasen \item Zeitlich begrenzte Phasen
\item Auch inhaltlich und organisatorisch begrenzte Phasen möglich \item Auch inhaltlich und organisatorisch begrenzte Phasen möglich
\item Teilprozesse / Aktivitäten \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*} \end{itemize*}
Aufgabe Aufgabe
@ -1834,7 +1804,7 @@
Arbeitsergebnis (oder Artefakt) Arbeitsergebnis (oder Artefakt)
\begin{itemize*} \begin{itemize*}
\item Dokument, Modell, System, Programmcode Lastenheft, Spezifikation, Glossar, Handbuch usw. \item Dokument, Modell, System, Programmcode, Lastenheft,...
\item Intern zu lieferndes Ergebnis \item Intern zu lieferndes Ergebnis
\end{itemize*} \end{itemize*}
@ -1845,28 +1815,13 @@
\end{itemize*} \end{itemize*}
Unterstützungsprozesse / -Aktivitäten Unterstützungsprozesse / -Aktivitäten
\begin{itemize*} \begin{description*}
\item Projektmanagement \item[Projektmanagement] Projektplanung, -verfolgung und -steuerung, Risikomanagement
\begin{itemize*} \item[Anforderungsmanagement] Im Gegensatz zur Anforderungsaufnahme und -analyse
\item Projektplanung, -verfolgung und -steuerung \item[Qualitätsmanagement] Softwaremetriken, Statische + dynamische Analyse (Bestimmung von Schwachstellen)
\item Risikomanagement \item[Konfigurationsmanagement] Versionsverwaltung, Änderungsmanagement
\end{itemize*} \item[Dokumentation]
\item Anforderungsmanagement \end{description*}
\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*}
\subsection{Sequenzielle Modelle} \subsection{Sequenzielle Modelle}
\begin{itemize*} \begin{itemize*}
@ -1874,49 +1829,21 @@
\begin{itemize*} \begin{itemize*}
\item Abhängigkeiten zwischen Teilergebnissen \item Abhängigkeiten zwischen Teilergebnissen
\item Ursprung in System- Hardwareentwicklung \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 Sequenzielles Phasenmodell (Abschluss der Phasen)
\item Stark Dokumentengetrieben (Ergebnisse der Phasen) \item Stark Dokumentengetrieben (Ergebnisse der Phasen)
\item Unterteilung in abgeschlossene Phasen: \item Unterteilung in abgeschlossene Phasen:
\begin{itemize*} \begin{itemize*}
\item Analyse \item Analyse (Planung)
\item Design/Entwurf \item Design/Entwurf
\item Implementierung \item Implementierung
\item Test \& Integration \item Test \& Integration
\item Einführung, Betrieb \& Wartung \item Einführung, Betrieb \& Wartung
\end{itemize*} \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 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 Starke Abhängigkeiten zwischen Teilergebnissen
\item Ungeeignet, falls Anforderungen zu Beginn unklar \item Ungeeignet, falls Anforderungen zu Beginn unklar
\item Unflexibel gegenüber Änderungen \item Unflexibel gegenüber Änderungen
\item Erst sehr spät greifbare Ergebnisse
\end{itemize*} \end{itemize*}
\end{itemize*}
\item Erweitertes Wasserfallmodell
\begin{itemize*}
\item Verbesserung für Änderungen und Fehler - Rückschritte
\end{itemize*}
\item Alternative Arten von Phasenmodellen
\begin{itemize*}
\item Sequenziell \item Sequenziell
\begin{itemize*} \begin{itemize*}
\item Phasen strikt nacheinander, Dokumenten-orientiert \item Phasen strikt nacheinander, Dokumenten-orientiert
@ -1932,7 +1859,7 @@
\item Unterteilung des Produkts in Teile \item Unterteilung des Produkts in Teile
\item Schnellere Auslieferung von Teilfunktionalität nach vollständiger Aufnahme der Anforderungen \item Schnellere Auslieferung von Teilfunktionalität nach vollständiger Aufnahme der Anforderungen
\end{itemize*} \end{itemize*}
\item Alternative: Evolutionär \item Evolutionär
\begin{itemize*} \begin{itemize*}
\item Anforderungen entwickeln sich im Projekt \item Anforderungen entwickeln sich im Projekt
\item Ausgelieferte Versionen ergeben neue Anforderungen \item Ausgelieferte Versionen ergeben neue Anforderungen
@ -1940,61 +1867,32 @@
\item V-Modell [Boehm] \item V-Modell [Boehm]
\begin{itemize*} \begin{itemize*}
\item Explizite Adressierung der Qualitätssicherung \item Explizite Adressierung der Qualitätssicherung
%\item %![VModell](Assets/Softwaretechnik1_VModell.png)
\item Entwicklung des V-Modells in Deutschland \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) \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*}
\end{itemize*} \end{itemize*}
\end{itemize*}
\end{itemize*}
\subsection{Iterative Modelle} \subsection{Iterative Modelle}
Iterativer Entwicklungsprozess
\begin{itemize*} \begin{itemize*}
\item Spezifikation, Entwurf und Implementierung müssen immer wieder verändert und angepasst werden \item Spezifikation, Entwurf und Implementierung müssen immer wieder verändert und angepasst werden
\item Häufiges Integrieren, Validieren und Testen \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 Wenn möglich, sollte es immer einen lauffähigen (unvollständigen) Prototypen geben
\item Neue Funktionen sofort integrieren \item Neue Funktionen sofort integrieren
\item Neue Versionen gegenüber Anforderungen Validieren \item Neue Versionen gegenüber Anforderungen Validieren
\end{itemize*} \end{itemize*}
%![Spiralmodell](Assets/Softwaretechnik1_Spiralmodell.png)
Spiralmodell Spiralmodell
\begin{itemize*} \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 Spirale = iterativer Zyklus durch dieselben Schritte
\item Ziele jedes Durchlaufs aus alten Ergebnissen ableiten \item Ziele jedes Durchlaufs aus alten Ergebnissen ableiten
\item Kosten/Nutzen abwägen
\item Regelmäßige Überprüfung des Prozessmodells \item Regelmäßige Überprüfung des Prozessmodells
\item Anpassbar
\item Hoher Management-Overhead, große Projekte \item Hoher Management-Overhead, große Projekte
\end{itemize*} \end{itemize*}
Unified Process Unified Process
\begin{itemize*} \begin{itemize*}
\item Vorgehensmodelle zur objektorientierten Softwareentwicklung \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 \item Phasen der Entwicklung
\begin{itemize*} \begin{itemize*}
\item Anfang, Ausarbeitung, Erstellung, Überleitung \item Anfang, Ausarbeitung, Erstellung, Überleitung
@ -2006,75 +1904,30 @@
\item Geschäftsprozessmodellierung, Anforderungsanalyse, Analyse \& Design, Implementierung, Test, Auslieferung \item Geschäftsprozessmodellierung, Anforderungsanalyse, Analyse \& Design, Implementierung, Test, Auslieferung
\item In unterschiedlichen Anteilen parallel ablaufend! \item In unterschiedlichen Anteilen parallel ablaufend!
\end{itemize*} \end{itemize*}
\end{itemize*} \item Variation
Prinzipieller Ablauf des Unified Process
%![Unified Process](Assets/Softwaretechnik1_UnifiedProcess.png)
\begin{itemize*}
\item Haupteigenschaften des UP
\begin{itemize*} \begin{itemize*}
\item Inkrementell, iterativ, evolutionär \item Inkrementell, iterativ, evolutionär
\item Anwendungsgetrieben \item Anwendungsgetrieben
\item Architekturzentriert \item Architekturzentriert
\item Risikoorientiert \item Risikoorientiert
\item Ereignisorientiert \item Ereignisorientiert
\item Nutzt die UML als Notationssprache
\item Erweiterbar / Anpassbar
\end{itemize*} \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 Passend für objektorientiertes Paradigmas und UML
\item Tool-Unterstützung \item Tool-Unterstützung
\item Reaktion auf Änderungen möglich \item Reaktion auf Änderungen möglich
\item Industriestandard
\end{itemize*}
\item Nachteile
\begin{itemize*}
\item Hoher Bürokratischer Aufwand $\rightarrow$ Tailoring notwendig! \item Hoher Bürokratischer Aufwand $\rightarrow$ Tailoring notwendig!
\item Relativ hohe „Lernkurve“ aller Beteiligten \item Relativ hohe „Lernkurve“ aller Beteiligten
\item Keine schnelle Reaktion auf Änderungen \item Keine schnelle Reaktion auf Änderungen
\item Keine integrierte Qualitätssicherung \item Keine integrierte Qualitätssicherung
\end{itemize*} \end{itemize*}
\end{itemize*}
\subsection{Agile Methoden} \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) Das Agile Manifest (2001)
\begin{itemize*} \begin{itemize*}
\item Individuen und Interaktionen bedeutender als Prozesse und Tools \item Individuen und Interaktionen $>$ als Prozesse und Tools
\item Funktionierende Software bedeutender als übermäßige Dokumentation \item Funktionierende Software $>$ als übermäßige Dokumentation
\item Stetige Zusammenarbeit mit dem Kunden bedeutender als Vertragsverhandlung \item Stetige Zusammenarbeit mit Kunden $>$ als Vertragsverhandlung
\item Mut und Offenheit für Änderungen bedeutender als Befolgen eines Plans \item Mut und Offenheit für Änderungen $>$ als Befolgen eines Plans
\end{itemize*} \end{itemize*}
Eigenschaften agiler Vorgehensmodelle Eigenschaften agiler Vorgehensmodelle
@ -2082,31 +1935,6 @@
\item Team ist für Ergebnis verantwortlich und organisiert sich selbst \item Team ist für Ergebnis verantwortlich und organisiert sich selbst
\item Kleine Teams 5-8 Personen \item Kleine Teams 5-8 Personen
\item Definition von Richtlinien, Werten und Prinzipien \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 \item Vorteile agiler Methoden
\begin{itemize*} \begin{itemize*}
\item Geringer bürokratischer Aufwand \item Geringer bürokratischer Aufwand
@ -2119,10 +1947,8 @@
\item Nachteile \item Nachteile
\begin{itemize*} \begin{itemize*}
\item Schwierigeres Projektmanagement \item Schwierigeres Projektmanagement
\begin{itemize*}
\item Chaotische Vorgehen \item Chaotische Vorgehen
\item Schwere Planbarkeit des Ergebnisses \item Schwere Planbarkeit des Ergebnisses
\end{itemize*}
\item Notwendige Beteiligung des Kunden \item Notwendige Beteiligung des Kunden
\item Ergebnis ist schwer vorherzusagen \item Ergebnis ist schwer vorherzusagen
\end{itemize*} \end{itemize*}
@ -2130,238 +1956,59 @@
\paragraph{eXtreme Programming (XP)} \paragraph{eXtreme Programming (XP)}
\begin{itemize*} \begin{itemize*}
\item Beck 1999, aus Kritik an „monumentalen Modellen“
\item Evolutionäre Entwicklung in kleinen Schritten \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 Konzentration auf Programmcode als Analyseergebnis, Entwurfsdokument und Dokumentation
\item Weglassen von explizitem Design, ausführlicher Dokumentation und Reviews \item Weglassen von explizitem Design, ausführlicher Dokumentation und Reviews
\item Code wird permanent lauffähig gehalten (täglich) \item Code wird permanent lauffähig gehalten (täglich)
\item Schnell und flexibel \item Schnell und flexibel
\item Erfordert Disziplin der Teilnehmer \item Erfordert Disziplin der Teilnehmer
\item Rollen: Projektleiter, Kunde (verfügbar), Entwickler \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 %![XP](Assets/Softwaretechnik1_XP.png)
\end{itemize*}
\end{itemize*} \end{itemize*}
\paragraph{Scrum} \paragraph{Scrum}
\begin{itemize*}
\item [Ken Schwaber, Jeff Sutherland und Mike Beedle]
\item Haupteigenschaften
\begin{itemize*} \begin{itemize*}
\item Iterativ / Inkrementell, Evolutionär \item Iterativ / Inkrementell, Evolutionär
\item stark Anwendungs- und Ereignisorientiert \item stark Anwendungs- und Ereignisorientiert
\item schnelle Entwicklungsiterationen \item schnelle Entwicklungsiterationen
\end{itemize*} \item Sprint: eine schnelle Iteration/Umsetzung Features (30 Tage)
\item Sprint \item Product Backlog: Liste der gewünschten Features des Produkts
\begin{itemize*} \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 Vom Produkt-Owner priorisiert / Aufwand vom Team geschätzt
\item Jeder kann Einträge beisteuern \item Jeder kann Einträge beisteuern
\end{itemize*} \end{itemize*}
\item Rollen \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*} \begin{itemize*}
\item Product Owner \item Für die aktuelle Iteration ausgewählte Aufgaben ($\leq$ 2 Tage)
\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*}
\end{itemize*}
\end{itemize*}
Sprint Backlog
\begin{itemize*}
\item Für die aktuelle Iteration ausgewählte Aufgaben
\begin{itemize*}
\item Aufgabe nicht länger als 2 Tage Aufwand
\end{itemize*}
\item Team-Mitglieder wählen Tasks aus - keine Zuweisung \item Team-Mitglieder wählen Tasks aus - keine Zuweisung
\item Restaufwand wird täglich aktualisiert - Burndown Chart \item Restaufwand wird täglich aktualisiert - Burndown Chart
\item Team-Mitglied kann Tasks hinzufügen, löschen, ändern \item Team-Mitglied kann Tasks hinzufügen, löschen, ändern
\item Darstellung an prominenter Stelle
\end{itemize*} \end{itemize*}
\item Daily Meeting (15 Minuten)
Daily Meeting
\begin{itemize*} \begin{itemize*}
\item ca. 15 Minuten \item Was wurde geschafft? Was ist zu tun? Was behindert den Fortschritt?
\item Kurze Statusmeldung, Was wurde geschafft? Was ist zu tun? Was behindert den Fortschritt?
\item Weiterführende Diskussionen erst im Anschluss \item Weiterführende Diskussionen erst im Anschluss
\end{itemize*} \end{itemize*}
\item Sprint Review-Meeting
%![Scrum Vorgehen](Assets/Softwaretechnik1_ScrumVorgehen.png)
Sprint Review-Meeting
\begin{itemize*} \begin{itemize*}
\item Präsentation des Erreichten (Feature Demo) \item Präsentation des Erreichten (Feature Demo)
\item Product Owner, Kunde usw. geben Feedback \item Product Owner, Kunde usw. geben Feedback
\begin{itemize*}
\item Neue Anforderungen hinzufügen / Neu priorisieren \item Neue Anforderungen hinzufügen / Neu priorisieren
\item Qualitätsansprüche ändern \item Qualitätsansprüche ändern
\end{itemize*} \end{itemize*}
\end{itemize*} \item Sprint-Retrospektive
Sprint-Retrospektive
\begin{itemize*} \begin{itemize*}
\item Rückkopplungsschleife \item Rückkopplungsschleife: Was war gut und was hat nicht funktioniert?
\begin{itemize*}
\item Was war gut und was hat nicht funktioniert?
\item Was kann verbessert werden?
\end{itemize*}
\item Nach jedem Sprint \item Nach jedem Sprint
\item Diskussion der identifizierten Probleme \item Diskussion der identifizierten Probleme
\item Identifikation von wenigen „Action Items“ \item Identifikation von wenigen „Action Items“
\end{itemize*} \end{itemize*}
\item Burndown Chart: Darstellung der offenen und erledigten Aufwände / Tasks
Burndown Chart
\begin{itemize*}
\item Darstellung der offenen und erledigten Aufwände / Tasks
%\item %![Burndown Chart](Assets/Softwaretechnik1_Burndownchart.png)
\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*}
\end{itemize*}
\end{itemize*} \end{itemize*}
\newpage \newpage