3. SE - 2. Vorgehensmodelle Flashcards
Was machen Vorgehensmodelle?
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)
Was bedeutet Tailoring? (Vorgehensmodelle)
Wenn Vorgehensmodelle ausdrücklich vorsehen, dass spezielle Anforderungen angepasst werden, nennt man das Tailoring.
Zweck von Vorgehensmodellen?
- fassen Erfahrungen aus vergangenen Projekten zusammen
- geben Grundstruktur für Projektplanung vor (Wie sollen wir vorgehen?)
- helfen beim Assessment (Was war gut, was schlecht?)
Wasserfallmodell Reihenfolge
Anforderungen (System requirements, Software requirements) Design (Analysis, Program design) Implementierung (Coding) Test (Testing) Inbetriebnahme (Operations)
Was variiert beim Wasserfallmodell?
Anzahl und Benennung der einzelnen Phasen
Was ist zu beachten beim Wasserfallmodell?
- 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
(2) Vorteile Wasserfallmodell
- unmittelbar für jedermann verständlich
- Qualitätskontrolle durch Meilensteine am Ende jeder Phase
Nachteile Wasserfallmodell
- 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)
Was sagen Experten zum Wasserfallmodell?
Viele Experten raten grundsätzlich vom Wasserfallmodell ab, dennoch wird Modell bis heute häufig angewandt
Wann ist Wasserfallmodell sinnvoll?
Anforderungen klar und unmissverständlich formuliert
keine Änderungen der Anforderung zu erwarten
Bsp für sinnvollen Einsatz des Wasserfallmodells und warum ist es hier sinnvoll?
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)
Was ist das “V-Modell des Bundes” und von wem gepflegt und weiterentwickelt?
Vorgehensmodell für IT-Systeme der öffentlichen Hand in Deutschland
- gepflegt und weiterentwickelt von Beauftragten der Bundesregierung für Informationstechnik
Vorteil Inkrementell-iterative Methoden
Fehler können früh erkannt werden
Nachteil Inkrementell-iterative (wird besser nach jeder Wiederholung) Methoden
“Endausbaustufe” muss bei technischen Design berücksichtigt werden, sonst fällt Wegwerfaufwand an (Bsp. Web-Frontend einer Applikation als letzte Iteration)
Wie wird die Kernfunktionalität einer Inkrementell-iterativen Methode erstellt?
Die Kernfunktionalität wird initial unter Berücksichtigung der technischen Herausforderungen erstellt
In mehreren Iterationen wird sie ergänzt
Wie stehen Zwischenprodukte zum Test zur Verfügung? (inkrementell iterative methoden)
zumindest als Prototyp
Wie heißt das Inkrementell-iteratives Modell bei dem jeder Zyklus aus 4 Quadranten besteht?
Spiralmodell nach Barry Boehm
Wie heißen die 4 Quadranten des Spiralmodell nach Barry Boehm?
- Zieldefinition
- Risikoabschätzung
- Implementierung und Test
- Planung des nächsten Zyklus
Was bedeutet RUP und was ist es?
Rational Unified Process
Ein Vorgehensmodell für Projekte der objektorientierten Softwareentwicklung, welches sich auf die UML bezieht
Enthält die UML ein Vorgehensmodell?
NEIN, es enthält kein Vorgehensmodell
Was macht Rational? (RUP)
Das Vorgehensmodell frei verfügbar
verkauft bestimmte Werkzeuge die an vielen Stellen benutzt werden müssen
Was sind die Dreh- und Angelpunkte des RUP
sogenannten 6 BEST PRACTICES, die von Rational-Werkzeugen unterstützt werden
Nenne die RUP Best Practices (6)
- Iterative Entwicklung
- Anforderungsmanagement
- Komponentenbasierte Architektur
- Visuelle Modellierung, i.d.R. mittels der UML
- Permanente Qualitätskontrolle
- Management von Änderungen
Vorteile des RUP
- 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
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)
Wie gehen Agile Modelle vor?
Gehen Inkrementell-iterativ vor
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
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
Wie werden die Anwender bei agiler Vorgehensmodelle einbezogen?
Anwender werden in alle Projektphasen eng eingebunden. vertrauen geht vor detaillierter vertraglicher Absicherung
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
Wie wird auf Änderungen im Projektverlauf reagiert?
FLEXIBEL
Kundenzufriedenheit ist wichtiger als das Einhalten überholter Ziele
Was ist die bekannteste agile Methode?
Extreme Programming (XP)
Arbeiten Entwickler und Anwender bei XP zusammen?
Ja, Entwickler und Anwender arbeiten zusammen in einem Raum
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.
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.
Refactoring bei XP
Codeverbesserung ohne zusätzlichen Funktionalitäten
Was sind die Entwicklungsstandards bei XP
Keine persönliche Vorlieben bei Codegestaltung
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
Wird bei XP die einfachste oder die raffinierteste Lösung bevorzugt
Die einfachste!
Wie viele Programmierer teilen sich einen Arbeitsplatz bei XP und was machen sie?
Zwei Programmierer. Einer Entwickelt, der andere achtet dass keine Fehler passieren
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
Für was für Projekte eignet sich XP am besten?
Kleinere Projekte
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
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)
Welche Vorschläge des Extreme Programing lassen sich gewinnbringend auch in herkömmlichen Projekten umsetzten?
Refactoring (Code review) und verbindliche Codierungsstandards
Grundregeln XP
wenige Grundregeln
Projektdurchführung wird viel detaillierter vorgegeben als zB bei RUP und V-Modell XT
Welches Vorgehensmodell wurde von Ken Schwaber entwickelt?
Scrum
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.
Schwerpunkt von Scrum
Projektmanagement
Warum ist es gut das Scrum nur einen groben Rahmen vorgibt?
Projekte können gestaltet werden, indem sich das Projektteam selbst Richtlinien gibt
Wer trägt die Verantwortung bei Scrum?
Das Team trägt gemeinsame Verantwortung für das Ergebnis
Wie viele Phasen gibt es bei Scrum? Nenne diese.
3
Pre-Game, Game, Post-Game
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
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
Was passiert im Design Review Meeting bei Scrum?
Im Design Review Meeting wird ein Grobdesign beschlossen
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
Was ist ein “Sprint” in einem Wort?
Intensivephase
Wie läuft ein Sprint ab?
- “Sprint Planning Meeting”
- Product Owner und Projektteam legen Ziel des nächsten Sprints fest und wie es erreicht werden soll - 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 - 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
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.
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
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?
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
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
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
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
Was macht die Scrum Rolle “KUNDEN/STAKEHOLDERS”?
- finanzieren Projekt
- bekommen im Sprint Review Meeting die Ergenisse des letzten Sprint präsentiert
Was macht die Scrum Rolle “MANAGER”?
- Vorgesetzten des Teams
- stellen Arbeitsumgebung zur Verfügung
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
Scrum mindert einige Nachteile agiler Methoden ab - nenne ein Bsp
Product Owner darf während eines Sprint die Ziele nicht ändern
Nenne das Konzept von Agilen Methoden
- möglichst oft neue, verbesserte Prototypen für Tester
- möglichst oft verbesserte Produktversionen für Endbenutzer bereitzustellen
Extreme Fall von AGILE METHODE
Continuous Integration
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
Was ist ein “commit”?
Wenn Entwickler mindestens täglich neuen Code zur Integration liefern
(Continuos Integration)
Vorteile Continuous Integration
Fehler werden sofort erkannt
Nachteile Continuous Integration
- da laufend neue Commits in die Queue gestellt werden, wird es schwierig, immer letzte stabile Versionen zu definieren
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
Idee von DevOps
Gemeinsame Ziele, Abläufe und Werkzeuge (Goals, Process, Tools) für Entwicklungsprojekte und Systembetriebe
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
Nenne die DevOps Toolchain
Create > Verify > Package > Release > Configure > Monitor > Plan > REPEAT (with create)
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
