02 - Vorgehensmodelle Flashcards
Definition: Vorgehensmodell
Standards für IT-Projekte definieren. Besonders für:
1) Projektphasen
2) Projektorganisation
3) Dokumente
4) Kommunikationsbeziehungen
5) Methoden
Zweck von Vorgehensmodellen
Sie fassen Erfahrungen aus vorherigen Projekten zusammen, geben eine Grundstruktur für die Projektplanung vor und helfen beim Assessment.
Wasserfallmodell Schritte (5)
1) Anforderungen
2) Design
3) Implementierung
4) Test
5) Inbetriebnahme
Wasserfallmodell Eigenschaften
- Phasen laufen sequentiell durch.
- Am Ende jeder Phase steht ein Meilenstein
- Nur eine Rückkopplung über eine Phase möglich, und auch auf dem Rückweg wird keine Phase übersprungen
Wasserfallmodell Vorteile (3)
1) Für jeden verständlich
2) Qualitätskontrolle wird durch Meilensteine sichergestellt
3) Eignet sich für kleine, überschaubare Projekte mit kurzer Laufzeit und wenigen Mitarbeitern
Wasserfallmodell Nachteile (4)
1) Unterstellt, dass nach dem Abschluss der Anforderungsanalyse alle Anforderungen im Detail bekannt sind und sich auch nicht ändern werden.
2) Keine Phase für Prototypen
3) Misverständnisse bei der Anforderungsanalyse werden spät erkannt
4) Keine Iterative Entwicklung (über mehrere Softwarereleases)
Definition: V-Modell
Sehr umfangreiches Modell des Bundes, für IT-Systeme der öffentlichen Hand in Deutschland.
Definition: Inkrementell-Iterative Methoden
Eine Vorgehensweise, wo erstmal die Kernfunktionalität unter Berücksichtigung der technischen Herausforderungen erstellt wird und danach in mehreren Schritten ergänzt wird.
Hier werden mehrere Zwischenprodukte erstellt, die als Prototyp zum Test zur Verfügung stehen.
Vorteil der Inkrementell-Iterativen Methoden
Fehler können hiermit früh erkannt werden.
Nachteil der Inkrementell-Iterativen Methoden
Technisches Design muss eigentlich immer die Endbaustufe berücksichtigen, sonst fällt ein hoher Wegwerfaufwand an.
Definition: Spiralmodell nach Barry Boehm
Ein Inkrementell-Iteratives Modell, bei dem jeder Zyklus aus 4 Quadranten besteht: Zieldefinition, RIsikoabschätzung (zum ersten Mal!), Implementierung und Test, Planung des nächsten Zyklus.
Definition: Rational Unified Process (RUP)
Ein Vorgehensmodell für Projekte der <b>Objektorientierten</b> Softwareentwicklung, das sich auf die UML Bezieht.
6 Best Practices (RUP)
1) Iterative Entwicklung
2) Anforderungsmanagement
3) Komponentenbasierte Architektur
4) Visuelle Modellierung, i.d.R. mittels der UML
5) Permanente Qualitätskontrolle
6) Management von Änderungen
RUP Vorteile (5)
1) Iterative Entwicklung ermöglicht frühe (und damit kostengünstige) Fehlererkennung
2) Einbindung aktueller softwaretechnischer Methoden
3) Geeignet für die Entwicklung objektorientierter Software mit Komponentenarchitektur
4) Kein rein sequentielles Modell, Parallelisierung von Aktivitäten
5) Verfügbarkeit unterstützender (allerdings kostenpflichtiger) Tools
RUP Nachteile (3)
1) Komplex & hoher initialer Einarbeitungsaufwand
2) Speziell vorgesehen für objektorientierte Softwareentwicklungsprojekte. Deshalb ungeeignet für Hardware oder Legacy Erweiterungen, für die Einführung von Standardsoftware.
3) Angepasst auf die Tools von Rational (sonst viel aufwendiger).
Definition: Agile Vorgehensmodelle
Sie gehen inkrementell-iterativ vor. Die Iterationen werden aber nicht zu Projektbeginn geplant, sondern nach Projektfortschritt und Kundenfeedback im Laufe des Projektes erst festgelegt.
Charakteristiken agiler Vorgehensmodelle (5)
1) So wenig Bürokratie wie möglich und sich aufs wesentliche fokussieren: Programmieren
2) Die durch Bürokratieabbau gesparte Zeit soll in die eigentliche Softwareentwicklung investiert werden.
3) Anwender sind in allen Projektphasen eng mit dem Projekt eingebunden. Vertrauen geht vor detaillierter vertraglicher Absicherung.
4) Mensch steht im Mittelpunkt, Prozesse und Werkzeuge sind weniger wichtig
5) Auf Änderungen im Projektverlauf wird flexibel reagiert. Kundenzufriedenheit geht vor Einhaltung überholter Ziele.
Definition: Extreme Programming (XP)
Dies ist die bekannteste agile Methode und basiert auf dem Prinzip das die Entwickler und Anwender in einem Raum arbeiten und auf eine 40-Stunden-Woche eingeschränkt sind.
Charakteristiken: Extreme Programming (XP) (7)
1) Refactoring
2) Standards beim Programmieren festlegen
3) Jeder ist für das Gesamtergebnis verantwortlich, jeder darf in jedem Programmteil Ergänzungen vornehmen, wenn sie zu seiner Aufgabe gehören (Weniger Trennung von Funktionalitäten während der Entwicklung des Programms).
4) Die einfachste Lösung wird immer bevorzugt
5) Pair Programming
6) Ständiges Deployment um Unverträglichkeiten sofort zu endecken.
7) Für kleinere Teams geeignet
Nachteile: Extreme Programming (2)
1) Anwender und Entwickler müssen ein großes Vertrauensverhältnis haben (z.B. Anwender und Entwickler im selben Unternehmen). Sonst ist XP schwer anzuwenden.
2) Weiterhin keine Dokumentation
Vorteile: Extreme Programming (2)
1) Einige Bestandteile haben sich auch für herkömmliche Projekte bewiesen: Code Review, Refactoring, Pair Programming.
2) XP besteht aus wenigen Grundregeln und wird viel weniger detailliert vorgegeben.
Definition: Scrum
Ein Agiles Vorgehensmodell, das die Prozesse eines Softwareprojektes nur mit einem groben Rahmen vorgibt. In diesem Rahmen können Projekte gestaltet werden, indem das Projektteam selbst sich Richtlinien gibt. Dennoch trägt das Projektteam die gemeinsame Verantwortung für das Ergebnis.
Scrum Phasen (3)
1) Pre-Game
2) Game
3) Post-Game
Ablauf: Pre-Game Scrum Phase (4)
1) Projektteam zusammenstellen und es wird sich auf Standards und Werkzeuge geeinigt.
2) Product Owner erstellt Product Backlog
3) Alternative Vorschläge zu, Systemdesign werden diskutiert. Dabei wird noch nicht detailliert, sondern die Architektur bestimmt.
4) Design Review Meeting findet statt, wo ein Grobdesign vorgeschlagen wird.
Definition: Product Backlog
Hier sind alle bisher bekannten Anforderungen enthalten. Er gilt nicht als abgeschlossen, sonder wird ständig weiterentwickelt.
Ablauf: Game Scrum Phase (6)
1) Projektphasen werden in Sprints aufgeteilt
Pro Sprint:
2) Im Sprint Planning Meeting wird zunächst vom Product Owner und dem Projektteam festgelegt, was das Ziel des nächsten Sprints sein soll und wie es zu erreichen ist.
3) Das Sprint Backlog wird angelegt und gepflegt. Es enthält eines Auswahl jener Ziele des Product Backlog, die für diesen Sprint vorgesehen sind. Sie sind natürlich detaillierter als im Product Backlog beschrieben.
4) Daily Scrum meetings werden durchgeführt
5) Zum Abschluss des Sprint stellt in einem Sprint Review Meeting das Projektteam dem Product Owner und den Stakeholders seine Ergebnisse vor.
6) Zu guter letzt wird entschieden, ob das Product Backlog angepasst und ein neuer Sprint beginnen muss, oder ob in die Post-Game-Phase übergangen werden muss.
Fragen beim Daily Scrum (3)
1) Was habe ich gestern erreicht?
2) Was will ich morgen erreichen?
3) Was blockiert meine Arbeit?
Ablauf: Post-Game Scrum Phase (3)
1) Erstellung der Dokumentation
2) Systemtest. Im Falle von Fehlern wird das Product Backlog angepasst und ein neuer Sprint gestartet
3) User Acceptance Test
Rolle: Scrum Master (6)
1) Überwacht die Einhaltung der Scrum-Regeln
2) Ist kein Teammitglied
3) Kein Teamleiter. Das Team organisiert sich ja selbst.
4) Bei Schwierigkeiten der Ansprechpartner für die Teammitglieder
5) Trägt die Blockaden von Daily Scrums in den Backlog ein und ist verantwortlich diese auch zu beseitigen.
6) Kann einen Sprint abbrechen, sobald die Ziele unerreichbar sind oder Hindernisse unüberwindbar sind.
Rolle: Product Owner (Scrum) (4)
1) kommuniziert mit dem Kunden und gibt die Erkenntnisse an das Team weiter.
2) definiert die Projektziele anhand von User Stories
3) priorisiert die Einträge im Product Backlog
4) Kommuniziert direkt mit dem Team
Rolle: Das Projektteam (Scrum) (2)
1) schätzt die Aufwände für die Einträge im Product Backlog
2) wählt anhand der Prioritäten des Product Owners aus dem Product Backlog-Einträgen die ziele für den nächsten Sprint.
Rolle: Stakeholders (Scrum) (2)
1) Finanzierung
2) Teilnahme am Sprint Review Meeting
Rolle: Die Manager (Scrum) (2)
1) Sind die Vorgesetzten des Teams
2) Stellen die Arbeitsumgebung zur Verfügung
Definition: Continuous Integration
Ein Bestandteil vieler Agilen Methode, wo neue, verbesserte Prototypen für Tester sowie verbesserte Produktversionen für Endbenutzer bereitgestellt werden.
Vorteil: Continuous Integration
Fehler werden sofort erkannt.
Nachteil: Continuous Integration
Wenn laufend neue Commits in die Queue gestellt werden, wird es schwierig, immer letzte stabile Versionen zu definieren.
Ziel: DevOps
Gemeinsame Ziele, Abläufe und Werkzeuge der Entwicklung und dem Systembetrieb schaffen.
Definition: DevOps
Ein Vorgehensmodell das Teams aus Entwicklern/Testern und Operatoren/Admins zusammenstellt. Es ergibt bei agilen Projekten viel Sinn und das Team ist fortlaufend zuständig für die Entwicklung neuen Codes und Systembetrieb.
DevOps Toolchain (7)
1) Create
2) Verify
3) Package
4) Release
5) Configure
6) Monitor
7) Plan
