3. SE - 2. Vorgehensmodelle Flashcards
1
Q
Was machen Vorgehensmodelle?
A
definieren Standards für IT-Projekte
vor allem für:
- Projektphasen (zB Entwicklung und Test)
- Projektorganisation (zB Rollen und Aktivitäten)
- Dokumente (zB Requirement Spec, Change Request)
- Kommunikationsbeziehungen zwischen den Beteiligten
- Methoden (zB für die Aufwandsschätzung)
2
Q
Was bedeutet Tailoring? (Vorgehensmodelle)
A
Wenn Vorgehensmodelle ausdrücklich vorsehen, dass spezielle Anforderungen angepasst werden, nennt man das Tailoring.
3
Q
Zweck von Vorgehensmodellen?
A
- fassen Erfahrungen aus vergangenen Projekten zusammen
- geben Grundstruktur für Projektplanung vor (Wie sollen wir vorgehen?)
- helfen beim Assessment (Was war gut, was schlecht?)
4
Q
Wasserfallmodell Reihenfolge
A
Anforderungen (System requirements, Software requirements) Design (Analysis, Program design) Implementierung (Coding) Test (Testing) Inbetriebnahme (Operations)
5
Q
Was variiert beim Wasserfallmodell?
A
Anzahl und Benennung der einzelnen Phasen
6
Q
Was ist zu beachten beim Wasserfallmodell?
A
- Reihenfolge (Anforderungen, Design, Implementierung, Test, Inbetriebnahme)
- Phasen sequentiell durchlaufen
- Am Ende jeder Phase steht ein Meilenstein
- Rückkopplung im Falle von offensichtlichen Fehlern ist nur über eine Phase möglich, auf dem Rückweg wird keine Phase übersprungen
7
Q
(2) Vorteile Wasserfallmodell
A
- unmittelbar für jedermann verständlich
- Qualitätskontrolle durch Meilensteine am Ende jeder Phase
8
Q
Nachteile Wasserfallmodell
A
- Keine Prototypen (erst fertige Softwareprodukte stehen nach Abschluss der Entwicklung zum Testen zur Verfügung UND erst fertig getestete System wird Anwendern vorgestellt)
- Missverständnisse bei Anforderungsanalyse werden spät erkannt
- Keine Iterative Entwicklung (über mehrere Softwarerelease)
9
Q
Was sagen Experten zum Wasserfallmodell?
A
Viele Experten raten grundsätzlich vom Wasserfallmodell ab, dennoch wird Modell bis heute häufig angewandt
10
Q
Wann ist Wasserfallmodell sinnvoll?
A
Anforderungen klar und unmissverständlich formuliert
keine Änderungen der Anforderung zu erwarten
11
Q
Bsp für sinnvollen Einsatz des Wasserfallmodells und warum ist es hier sinnvoll?
A
Erstellung einer Datenbank für Sicherheitszwischenfälle in der Unternehmens-IT
- da kleines, überschaubares Projekt mit kurzer Laufzeit und weniger Mitarbeitern. IT-interne Anwendung (Anwender selbst sind IT Experten. Missverständnisse über Anforderungen sind deshalb unwahrscheinlich)
12
Q
Was ist das “V-Modell des Bundes” und von wem gepflegt und weiterentwickelt?
A
Vorgehensmodell für IT-Systeme der öffentlichen Hand in Deutschland
- gepflegt und weiterentwickelt von Beauftragten der Bundesregierung für Informationstechnik
13
Q
Vorteil Inkrementell-iterative Methoden
A
Fehler können früh erkannt werden
14
Q
Nachteil Inkrementell-iterative (wird besser nach jeder Wiederholung) Methoden
A
“Endausbaustufe” muss bei technischen Design berücksichtigt werden, sonst fällt Wegwerfaufwand an (Bsp. Web-Frontend einer Applikation als letzte Iteration)
15
Q
Wie wird die Kernfunktionalität einer Inkrementell-iterativen Methode erstellt?
A
Die Kernfunktionalität wird initial unter Berücksichtigung der technischen Herausforderungen erstellt
In mehreren Iterationen wird sie ergänzt
16
Q
Wie stehen Zwischenprodukte zum Test zur Verfügung? (inkrementell iterative methoden)
A
zumindest als Prototyp
17
Q
Wie heißt das Inkrementell-iteratives Modell bei dem jeder Zyklus aus 4 Quadranten besteht?
A
Spiralmodell nach Barry Boehm
18
Q
Wie heißen die 4 Quadranten des Spiralmodell nach Barry Boehm?
A
- Zieldefinition
- Risikoabschätzung
- Implementierung und Test
- Planung des nächsten Zyklus
19
Q
Was bedeutet RUP und was ist es?
A
Rational Unified Process
Ein Vorgehensmodell für Projekte der objektorientierten Softwareentwicklung, welches sich auf die UML bezieht
20
Q
Enthält die UML ein Vorgehensmodell?
A
NEIN, es enthält kein Vorgehensmodell
21
Q
Was macht Rational? (RUP)
A
Das Vorgehensmodell frei verfügbar
verkauft bestimmte Werkzeuge die an vielen Stellen benutzt werden müssen
22
Q
Was sind die Dreh- und Angelpunkte des RUP
A
sogenannten 6 BEST PRACTICES, die von Rational-Werkzeugen unterstützt werden
23
Q
Nenne die RUP Best Practices (6)
A
- Iterative Entwicklung
- Anforderungsmanagement
- Komponentenbasierte Architektur
- Visuelle Modellierung, i.d.R. mittels der UML
- Permanente Qualitätskontrolle
- Management von Änderungen
24
Q
Vorteile des RUP
A
- Iterative (Wiederholende) Entwicklung ermöglicht frühe (und somit Kostengünstige) Fehlererkennung
- Einbindung aktueller softwaretechnischer Methoden
- geeignet für Entwicklung objektorientierter Software mit Komponentenarchitektur
- kein rein sequentielles Modell, Parallelisierung von Aktivitäten
- Verfügbarkeit unterstützender (allerdings kostenpflichtiger) Tools
25
Nachteile des RUP
- komplex. hoher initialer Einarbeitungsaufwand
- speziell vorgesehen für objektorientierte Softwareentwicklungsprojekte - deshalb ungeeignet für Hardware, für nicht-objektorientierte Legacy-Erweiterungen, für Einführung von Standardsoftware
- angepasst auf die Tools von Rational (mit anderen Werkzeugen erhöhter Aufwand, ohne entsprechende Werkzeuge nicht einsetzbar)
26
Wie gehen Agile Modelle vor?
Gehen Inkrementell-iterativ vor
27
Wie sind die Iterationen bei Agilen Vorgehensmodellen geplant?
Iterationen werden nicht zu Projektbeginn geplant, sondern nach Projektfortschritt und Kundenfeedback im Laufe des Projektes erst festgelegt
28
Wie werden Struktur des Projektes, Formalisierung, Dokumentation bei agiler Vorgehensmodelle empfunden?
Als übertriebene Bürokratie. Die gesparte Zeit durch Bürokratieabbau soll in eigentliche Softwareentwicklung investiert werden
So wenig wie möglich, so viel wie nötig
29
Wie werden die Anwender bei agiler Vorgehensmodelle einbezogen?
Anwender werden in alle Projektphasen eng eingebunden. vertrauen geht vor detaillierter vertraglicher Absicherung
30
Welche allgemeingültige Regeln gibt es zu beachten bei agiler Vorgehensmodelle?
KEINE
Jedes Projekt ist anders deswegen kann es keine allgemein gültige Regeln geben. Der Mensch steht im Mittelpunkt, Prozesse und Werkzeuge sind weniger wichtig
31
Wie wird auf Änderungen im Projektverlauf reagiert?
FLEXIBEL
| Kundenzufriedenheit ist wichtiger als das Einhalten überholter Ziele
32
Was ist die bekannteste agile Methode?
Extreme Programming (XP)
33
Arbeiten Entwickler und Anwender bei XP zusammen?
Ja, Entwickler und Anwender arbeiten zusammen in einem Raum
34
Was ist das sogenannte "Planning Game" bei XP?
Die Anwender definieren die Anforderungen in "Stories", die Entwickler schätzen den Aufwand, beide verhandeln die Reihenfolge der Entwicklung.
35
Was ist das Prinzip des Extremen Programming?
Ständige Wiederholung des kompletten Zyklus (Anforderung, Design, Entwicklung, Test) in kurzen Zeitabständen bei ständiger Verbesserung und mit sofortiger Rückmeldung der Anwender.
36
Refactoring bei XP
Codeverbesserung ohne zusätzlichen Funktionalitäten
37
Was sind die Entwicklungsstandards bei XP
Keine persönliche Vorlieben bei Codegestaltung
38
Wie läuft es mit der Verantwortung bei Extreme Coding
Jeder ist verantwortlich für das Gesamtergebnis, deswegen darf auch jeder in den Programmteilen der anderen Ergänzungen vornehmen, wenn sie zu einer Aufgabe gehören, aber aus architektonischen Gründen in den Programmteilen der anderen implementiert werden soll
39
Wird bei XP die einfachste oder die raffinierteste Lösung bevorzugt
Die einfachste!
40
Wie viele Programmierer teilen sich einen Arbeitsplatz bei XP und was machen sie?
Zwei Programmierer. Einer Entwickelt, der andere achtet dass keine Fehler passieren
41
Was macht man bei XP um Unverträglichkeiten zu entdecken
Um Unverträglichkeiten sofort zu entdecken, findet ein ständiges Deployment statt - Zusammenführung der Arbeitsergebnisse der Zweiergruppen
42
Für was für Projekte eignet sich XP am besten?
Kleinere Projekte
43
Wie sieht es mit der Dokumentation des XP aus
Dokumentation fehlt völlig. Wenn das System später bearbeitet oder gepflegt werden soll, sollte immer ein Entwickler aus dem ursprünglichen Team verfügbar sein
44
Wie sieht es mit dem Vertrauensverhältnis aus beim XP?
XP setzt großes Vertrauensverhältnis voraus und ist daher eher anwendbar, wenn Entwickler und Anwender zu einem Unternehmen gehören (interne IT-Abteilung)
45
Welche Vorschläge des Extreme Programing lassen sich gewinnbringend auch in herkömmlichen Projekten umsetzten?
Refactoring (Code review) und verbindliche Codierungsstandards
46
Grundregeln XP
wenige Grundregeln
| Projektdurchführung wird viel detaillierter vorgegeben als zB bei RUP und V-Modell XT
47
Welches Vorgehensmodell wurde von Ken Schwaber entwickelt?
Scrum
48
Was ist die Idee von Scrum?
Prozesse eines Softwareprojektes sind ohnehin zu komplex, um sie detailliert beschreiben zu können
Scrum gibt deshalb nur einen groben Rahmen vor. Schwerpunkte sind nicht konkrete Praktiken wie bei XP, sondern das Projektmanagement.
49
Schwerpunkt von Scrum
Projektmanagement
50
Warum ist es gut das Scrum nur einen groben Rahmen vorgibt?
Projekte können gestaltet werden, indem sich das Projektteam selbst Richtlinien gibt
51
Wer trägt die Verantwortung bei Scrum?
Das Team trägt gemeinsame Verantwortung für das Ergebnis
52
Wie viele Phasen gibt es bei Scrum? Nenne diese.
3
Pre-Game, Game, Post-Game
53
Was passiert in der Pre-Game-Phase bei Scrum?
- Projektteam zusammengestellt
- Einigung auf Standards und Werkzeuge
- Product Owner erstellt Product Backlog
- Alternative Vorschläge zum Systemdesign werden diskutiert (nicht detailliert, sondern Architektur bestimmt)
- Design Review Meeting
54
Was ist das "Product Backlog" bei Scrum?
Dokument das alle bisher bekannten Anforderungen enthält
Es ist nicht abgeschlossen, sondern wird ständig weiterentwickelt
Einträge sind priorisiert und geordnet
55
Was passiert im Design Review Meeting bei Scrum?
Im Design Review Meeting wird ein Grobdesign beschlossen
56
Was passiert in der Game-Phase bei Scrum?
- Produkt wird in mehreren Abschnitten erstellt, die nachprüfbares Ergebnis haben, etwa einen Monat Dauer und SPRINT heißen
57
Was ist ein "Sprint" in einem Wort?
Intensivephase
58
Wie läuft ein Sprint ab?
1. "Sprint Planning Meeting"
- Product Owner und Projektteam legen Ziel des nächsten Sprints fest und wie es erreicht werden soll
2. Sprint Backlog anlegen und pflegen
- Enthält Ziele des laufenden Sprint
- Enthält Auswahl jener Ziele des Produkt Backlog
- detaillierter als Product Backlog.
- Product Backlog kann vom Prodct Owner geändert werden, nicht aber der Sprint Backlog.
- Team entscheidet wer welche Punkte aus Sprint Backlog als nächstes bearbeitet
3. Daily Scrum
- 3 Fragen jedes Teammitglied
- täglich "Burndown Chart" fortgezeichnet, das den Restaufwand auf die verstrichene Zeit bezieht
Ende einen Sprint:
- Sprint Review Meeting:
- Projektteam stellt Ergebnisse Product Owner und Stakeholders vor
- Dann entschieden ob Product Backlog angepasst und ein neuer Sprint begonnen wird ODER Post-Game-Phase gestartet
59
Warum ist der Sprint Backlog detaillierter als der Product Backlog?
Sprint Backlog enthält Ziele des laufenden Sprints. Enthält Auswahl jener Ziele des Produkt Backlog, die für diesen Sprint vorgesehen sind. Bezüglich dieser Ziele ist es detaillierter als der Product Backlog.
60
Was bedeutet es, dass der Product Owner den Product Backlog ändern kann aber nicht den Sprint Backlog?
Änderungen von außen kommen frühestens im nächsten Sprint zum tragen
61
Welche Fragen werden jedem Teammitglied im kurzem Daily Scrum gestellt?
Was habe ich seit gestern erreicht?
Was will ich bis morgen erreichen?
Was blockiert meine Arbeit?
62
Wie läuft eine "Post-Game-Phase" in Scrum ab?
- Erstellung der Dokumentation
- Systemtest (Im Fall von Fehlern wird das Product Backlog angepasst und ein neuer Sprint gestartet)
- User Acceptance Test
63
Was macht die Scrum Rolle "SCRUM MASTER"?
- überwacht Einhaltung der Scrum-Regeln
- kein Teammitglied
- kein Teamleiter (Team organisiert sich selbst)
- Ansprechpartner für alle Teammitglieder wenn Schwierigkeiten auftreten
- trägt Blockaden die im Daily Scrum von Teammitgliedern genannt werden in Impediment Backlog ein und ist dafür verantwortlich sie zu beseitigen
- Kann Sprint abbrechen. wenn Ziel für unerreichbar gehalten wird oder Hindernisse für unüberwindbar zählen
64
Was macht die Scrum Rolle "PRODUCT OWNER"?
- kommuniziert mit Kunden und vertritt diese gegenüber Team
- definiert Projektziele anhand User Stories
- priorisiert die Einträge im Product Backlog
- kommuniziert direkt mit Team
65
Was macht die Scrum Rolle "PROJEKTTEAM"?
- schätzt Aufwände für Einträge im Product Backlog
| - wählt anhand von Prioritäten des Prodcut Owners aus Product backlog-Einträgen die Ziele für nächsten Sprint
66
Was macht die Scrum Rolle "KUNDEN/STAKEHOLDERS"?
- finanzieren Projekt
| - bekommen im Sprint Review Meeting die Ergenisse des letzten Sprint präsentiert
67
Was macht die Scrum Rolle "MANAGER"?
- Vorgesetzten des Teams
| - stellen Arbeitsumgebung zur Verfügung
68
Würdigund von Scrum
- strukturiert, nicht komplex
- generelle Vor und Nachteile agiler Methoden
- sehr große Verbreitung in Softwareentwicklung
- Scrum mindert einige Nachteile agiler Methoden ab
69
Scrum mindert einige Nachteile agiler Methoden ab - nenne ein Bsp
Product Owner darf während eines Sprint die Ziele nicht ändern
70
Nenne das Konzept von Agilen Methoden
- möglichst oft neue, verbesserte Prototypen für Tester
| - möglichst oft verbesserte Produktversionen für Endbenutzer bereitzustellen
71
Extreme Fall von AGILE METHODE
Continuous Integration
72
Was beinhaltet die Continuous Integration
- AUTOMATISIERTE Test mittels geeigneter Werkzeuge
- alle Entwickler liefern täglich neuen Code zu Integration (commit)
- Alle neuen Commits werden in einem Build integriert
- automatisierte "Build" mittels geeigneter Werkzeuge
- mehrfach täglich neue Versionen
73
Was ist ein "commit"?
Wenn Entwickler mindestens täglich neuen Code zur Integration liefern
(Continuos Integration)
74
Vorteile Continuous Integration
Fehler werden sofort erkannt
75
Nachteile Continuous Integration
- da laufend neue Commits in die Queue gestellt werden, wird es schwierig, immer letzte stabile Versionen zu definieren
76
Zielkonflikt DevOps
- Aus Sicht agiler Projekte ist häufiges Deployment wünschenswert, ggf. Continuous Integration
- Aus Sicht des Systembetriebs ist später nach dem Go-Live jede Änderung eine potentielle Störungsursache, deshalb sollte nicht zu viele gegeben werden und wenn sollten diese ausgiebig getestet werden
77
Idee von DevOps
Gemeinsame Ziele, Abläufe und Werkzeuge (Goals, Process, Tools) für Entwicklungsprojekte und Systembetriebe
78
Idee DevOps
- In vielen IT-Organisationen sind Entwicklungsprojekte und Systembetrieb traditionell voneinander getrennt
- Nach DevOps werden Teams für eine Applikation aus Entwickler/Testern und Operatoren/Administratoren zusammengestellt
- DevOp im Grunde unabhängig vom Vorgehensmodell, ergibt aber besonders mit agiler Methoden und CI Sinn
- Team fortlaufend zuständig für Entwicklung neuen Codes und Systembetrieb
79
Nenne die DevOps Toolchain
Create > Verify > Package > Release > Configure > Monitor > Plan > REPEAT (with create)
80
Nenne die DevOps Toolchain und was im jeweiligen Schritt passiert
Create
- Entwicklung und Build
Verify
- Verifikation und Vaildierung
Package
- Einbinden von zB Graphiken, Multimedia,...
- Erstellen von zB JAR
Release
- Stellen und dokumentieren von RfC nach den Richtlinien der IT-Organisationen
Configure
- Einrichten und Betreiben der Applikationen und ihrer Infrastruktur
Monitor
- Automatisiert und nach Anwender-Feedback (Events und Incidents)
Plan
- Entwurf der nächsten Verbesserung von Produkt und Betriebsprozess
