Vorgehensmodelle Flashcards
1
Q
Aufgaben von Vorgehensmodellen
A
Definieren von Standards für IT-Projekte
- Projektphasen (z.B. Entwicklung und Test)
- Projektorganisation (z.B. Rollen und Aktivitäten)
- Dokumente (z.B. Requirement Spec, Change Request)
- Kommunikation zwischen Beteiligten
- Methoden (z.B. für Aufwandschätzung)
2
Q
Zweck von Vorgehensmodellen
A
- Erfahrungen aus vergangenen Projekten zusammenfassen
- Grundstruktur für Projektplanung vorgeben
- Assessment (Was lief gut/schlecht?)
3
Q
Wasserfallmodell
A
- Reihenfolge: Anforderungen, Design, Implementierung, Test, Inbetriebnahme
- sequentielle Abarbeitung der Phasen
- am Ende jeder Phase ein Meilenstein
4
Q
Vor- / Nachteile Wasserfallmodell
A
Vorteile: schnell für jedermann verständlich, Qualitätskontrolle nach jeder Phase
Nachteile: nicht iterativ, keine Prototypen, Test erst am Ende, Missverständnisse erst spät erkannt
5
Q
Anwendungsfälle Wasserfallmodell
A
- klare Anforderungen und keine Änderungen an diesen
- kleine, kurze Projekte mit wenigen Mitarbeitern
- IT-interne Anwendung (Anwender sind IT-Experten)
6
Q
Inkrementell-iterative Methoden
A
- initiale Erstellung der Kernfunktionalität unter Berücksichtigung der techn. Herausforderungen
- Ergänzung in Iterationen
- Zwischenprodukte als Prototyp zum Testen
7
Q
Vor- / Nachteile inkrementell-iterativer Methoden
A
Vorteil: frühzeitige Fehlererkennung
Nachteil: technisches Design muss Endausbaustufe berücksichtigen, ansonsten Wegwerfaufwand (z.B. Web-Frontend)
8
Q
Spiralmodell (inkrementell-iterativ)
A
- 4 Quadranten: Zieldefinition, Risikoabschätzung, Implementierung und Test, Planung des nächsten Zyklus
9
Q
Rational Unified Process (RUP)
A
- Vorgehensmodell für Projekte der objektorientierten Softwareentwicklung, das sich auf UML bezieht
- Rational macht Vorgehensmodell frei verfügbar
- RUP sieht aber an vielen Stellen den Einsatz bestimmter Werkzeuge vor
10
Q
Best Practices RUP
A
- Iterative Entwicklung
- Anforderungsmanagement
- Komponentenbasierte Architektur
- Visuelle Modellierung mittels UML
- Permanente Qualitätskontrolle
- Management von Änderungen
11
Q
Vorteile RUP
A
- frühe und kostengünstige Fehlererkennung
- Einbindung aktueller softwaretechnischer Methoden
- geeignet für Entwicklung objektorientierter Software mit Komponentenarchitektur
- Parallelisierung von Aktivitäten
12
Q
Nachteile RUP
A
- komplex, hoher initialer Einarbeitungsaufwand
- ungeeignet für Hardware und für nicht-objektorientierte Legacy-Erweiterungen und für Standardsoftware
- angepasst auf Tools von Rational
13
Q
Agiles Manifest (4 Prinzipien)
A
- Individuen und Interaktionen mehr als Prozesse und Werkzeuge
- Funktionierende Software mehr als umfassende Dokumentation
- Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
- Reagieren auf Veränderung mehr als das Befolgen eines Plans
14
Q
Grundsätze agiler Vorgehensmodelle
A
- Strukturierung, Formalisierung, Dokumentation: So wenig wie möglich, so viel wie nötig
- Vertrauen vor vertraglicher Absicherung
- kein: allgemeingültigen Regeln: Mensch im Mittelpunkt vor Werkzeugen und Prozessen
- Flexibles Reagieren auf Änderungen, Kundenzufriedenheit > Einhaltung überholter Ziele
15
Q
Extreme Programming (XP)
A
- bekannteste agile Methode
- Entwickler und Anwender in einem Raum
- 40-Stunden-Woche, mehr Arbeit mindert die Produktivität
16
Q
XP: Planning Game
A
Anwender definieren Anforderungen in “Stories”, Entwickler schätzen den Aufwand, beide verhandeln die Reihenfolge der Entwicklung
17
Q
XP: Zyklus
A
- Anforderung, Design, Entwicklung, Test
- kurze Zeitabstände zwischen Zyklen
- ständige Verbesserung mit sofortiger Rückmeldung der Anwender
18
Q
XP: Refactoring
A
Codeverbesserungen ohne zusätzliche Funktionalität
19
Q
XP: Entwicklungsstandards
A
keine persönlichen Vorlieben bei der Codegestaltung
-> jeder ist für Gesamtergebnis verantwortlich, man darf Ergänzungen in Programmteilen der anderen vornehmen, wenn sie zur eigenen Aufgabe gehören, aber woanders implementiert werden
20
Q
XP: Arbeitsvorgehen
A
- zwei Programmierer teilen sich einen Arbeitsplatz (einer entwickelt, der andere achtet auf Fehler)
- ständiges Deployment (Zusammenführen der Arbeitsergebnisse der 2er-Gruppen) um Unverträglichkeiten sofort zu entdecken
21
Q
Würdigung des XP
A
- für kleinere Projekte
- setzt großes Vertrauensverhältnis voraus
- Dokumentation fehlt (Entwickler für spätere Pflege)
- wenige Grundregeln, Projektdurchführung wenig detailliert
- Elemente aus XP lassen sich in anderen Projekten einsetzen (z.B. Refactoring)
22
Q
Scrum
A
- Idee: Prozesse eines Softwareprojektes eh zu komplex, um sie detailliert zu beschreiben
- gibt groben Rahmen für Projektmanagement vor
- Projektteam gibt sich Richtlinien selbst und trägt Verantwortung gemeinsam
23
Q
Scrum: Pre-Game-Phase
A
- Zusammenstellen des Projektteams
- Einigen auf Standards und Werkzeuge
- Diskutieren von Vorschlägen für Systemdesign und Bestimmen der Architektur
24
Q
Scrum: Product Owner und Product Backlog
A
- Product Owner erstellt Product Backlog (enthält alle bisher bekannten Anforderungen und wird ständig weiterentwickelt)
25
Scrum: Game-Phase
Produkt wird mehreren Abschnitten (Sprints) erstellt, die ein nachprüfbares Ergebnis haben (Dauer: ca. 1 Monat)
26
Scrum: Sprint Planning Meeting
Ziel und dessen Erreichung für nächsten Sprint wird von Product Owner und Projektteam festgelegt
27
Scrum: Sprint Backlog
- wird in jedem Sprint angelegt und gepflegt
- enthält Ziele für laufenden Sprint aus Product Backlog und ist bezüglich dieser detaillierter
- Product Owner kann Sprint Backlog nicht ändern (Änderungen kommen erst im nächsten Sprint zu tragen)
- Team entscheidet selbst, wer welche Punkte aus Sprint Backlog als nächstes bearbeitet
28
Scrum: Daily Scrum
Jedes Teammitglied beantwortet in täglichem, kurzen Face-to-Face-Meeting folgende Fragen:
- Was habe ich seit gestern erreicht?
- Was will ich bis morgen erreichen?
- Was blockiert meine Arbeit?
29
Scrum: Burndown Chart
Wird täglich gezeichnet und bezieht Restaufwand auf verstrichene Zeit
30
Scrum: Sprint Review Meeting
- Zum Abschluss des Sprints stellt Projektteam dem Product Owner und den Stakeholders seine Ergebnisse vor
- Entscheidung für Anpassung des Product Backlog und neuer Sprint oder Übergang in Post-Game-Phase
31
Scrum: Post-Game-Phase
- Erstellung der Dokumentation
- Systemtest (bei Fehlern: Anpassen des Product Backlog und neuer Sprint)
- User Acceptance Test
32
Scrum: Scrum Master
- überwacht Einhaltung der Scrum-Regeln
- ist weder Teammitglied noch Teamleiter (Team organisiert sich selbst)
- Ansprechpartner bei Schwierigkeiten
- trägt Blockaden aus Daily Scrum in Impediment Backlog ein und beseitigt diese
- kann Sprint abbrechen, wenn er Ziele für unerreichbar oder Hindernisse für unüberwindbar hält
33
Scrum: Product Owner
- Product Owner kann Product Backlog ändern und priorisiert Einträge
- kommuniziert mit Kunden und vertritt diese gegenüber dem Team
- definiert Projektziele anhand von User Stories
- kommuniziert direkt mit Team
34
Scrum: Projektteam
- schätzt Aufwände für Einträge im Product Backlog
| - wählt anhand der Prioritäten des Product Owner aus den Product Backlog-Einträgen die Ziele für nächsten Sprint aus
35
Scrum: Kunden/Stakeholder
- finanzieren das Projekt
| - bekommen im Sprint Review Meeting die Ergebnisse des letzten Sprint präsentiert
36
Scrum: Manager
- sind die Vorgesetzten des Teams
| - stellen Arbeitsumgebung zur Verfügung
37
Würdigung von Scrum
- strukturiert, aber nicht komplex
- es gelten Vor- und Nachteile agiler Methoden
- mildert einige Nachteile agiler Methoden (z.B. Product Owner darf Ziele während des Sprints nicht ändern)
- mittlerweile sehr verbreitet
38
Continuous Integration
- Extremfall von häufigem Release von Versionen
- mehrfach täglich neue Versionen
- Automatisierter Build und Test mittels geeigneter Werkzeuge
- tägliche neuer Code (commits) zur Integration
- alle neuen Commits werden in einem Build integriert
39
Vor- / Nachteile Continuous Integration
Vorteil: Fehler werden sofort erkannt
Nachteil: durch ständig neue Commits werden stabile letzte Versionen erschwert
40
DevOps: Zielkonflikt
agile Projekte wollen häufiges Deployment, Systembetrieb sieht Änderung als Störungsursache (wenige Deployments und müssen getestet werden
41
DevOps: Idee
gemeinsame Ziele, Abläufe und Werkzeuge (Goals, Processes, Tools) für Entwicklungsprojekte und Systembetrieb
42
DevOps
- Entwicklungsprojekt und Systembetrieb oft voneinander getrennt
- DevOps stellt Team für Applikation aus Entwicklern/Testern und Operatoren/Administratoren zusammen
- unabhängig vom Vorgehensmodell
- Team ist laufend zuständig für neuen Code und Systembetrieb
43
DevOps: Toolchain
- dauerhafte, permanente Verbindung von Dev und Ops
- Create, Verify, Package (Graphiken, JAR), Release (Doc und RfC)
- Configure (Infrastruktur), Monitor, Plan
44
Crystal Family
- farbige Bezeichnung von agilen Softwareentwicklungsmethoden
- Farbe hängt von Teamgröße und Risikoklasse ab
- Risiken: Gefährdung Kundenzufriedenheit, Imageschaden, Geldverlust
45
Crystal Family: Prinzipien
- fokussiertes Arbeiten, häufige Releases und Integration, laufende Kritik und Verbesserung, passiver Wissentransfer
46
Crystal Clear
- einfachste Form aus Crystal Family
- Teamgröße: 2 bis 6 Personen
- Meilensteine und inkrementelle Auslieferung von Software
- kein Pair-Programming
47
Software Kanban
Methode in der Softwareentwicklung, bei der die Anzahl paralleler Arbeiten, der Work in Progress, begrenzt und somit kürzere Durchlaufzeiten erreicht und Probleme – insbesondere Engpässe – schnell sichtbar gemacht werden sollen
48
Feature-driven development (FDD)
- Sammlung von Arbeitstechniken, Strukturen, Rollen und Methoden für das Projektmanagement im Rahmen agiler Softwareentwicklung
- 5 Prozesse: Gesamtmodell entwickeln, Feature-Liste erstellen, Planung je Feature, Entwurf und Programmierung je Feature
49
Test-driven development (TDD)
bei der agilen Entwicklung von Software werden Softwaretests konsequent vor den zu testenden Komponenten erstellt
-> qualitative Entwicklung in kurzer Zeit auf Kosten von komplizierten Codeänderungen
50
Rapid Application Development (RAD)
- Softwareentwicklung mit prototypischem Vorgehensmodell (Requirements planning -> User Design/Construction -> Cutover)
- user-centered und Risikokontrolle, aber schwer skalierbar, komplex, Benutzeranforderungen und modularisierbares System erforderlich
51
Lean Software Development (LSD)
- ähnlich zu agilem Manifest
- Müll vermeiden, spät entscheiden, früh liefern, das Ganze sehen, Integrität, Verantwortung ans Team, Lernen unterstützen
- Stärken: Test, Implementierung, Systemdesign
- Schwächen: Wartung, Requirement- und Projektmanagement
52
Skalierungsmöglichkeiten Scrum
- Large Scale Scrum
- Nexus
- Scrum at Scale
- Safe
53
Disciplined Agile Delivery (DAD)
- Process Decision Framework, das leane und agile Methoden kombiniert
- Inception Phase, Construction Phase, Transition Phase
- Ansätze aus Softwareentwicklung (XP, Kanban), Datenmodellierung (Agile Business Intelligence) und Produktentwicklung (SCRUM) werden verbunden
