Vorgehensmodelle (Prozesse)

Planbasierte Methoden
= Systematische Prozesse. Sind plan-driven und orientieren sich eher an Abläufen mit Schwerpunkt auf Produkten und Dokumentation.
Beispiele:
Wasserfallmodell
V-Modell (XT)
RUP
Inkrementelle Modelle

Erklären und skizzieren Sie das Wasserfall Modell. Nennen Sie auch Vor- und Nachteile
Klassisch / Sequentiell (traditionell)
Umsetzung des Life-Cycles
Fokus auf Dokumentation
Strikt sequenzieller Projektablauf.
Vorherige Phase muss vollständig abgeschlossen und freigegeben (Validierung und Verifikation) sein. → Wenn nicht erreicht, zurückspringen.
Vorteile
- Backtracking zu früheren Entwicklungsphasen.
- Weite Verbreitung und hoher Bekanntheitsgrad.
- Risikominimierung durch „Abschluss“ einer Phase.
- Weite Verbreitung und hoher Bekanntheitsgrad.
- Strikte Trennung der einzelnen Phasen.
Nachteile
- Reaktion auf spätere Änderungen schwer.
- Software und Prototyp für Kunden steht spät zu verfügung.
- keine parallele Entwicklung, tasks müssen abgeschlossen werden
- Starke Auswirkung von Fehlern aus frühen Phasen.
- Anwendung bei guten Kenntnissen über die Anforderungsdomäne
- nur bei klar definierten und vollständigen Anforderungen.
Anwendung
Für vollständige, stabile Anforderungen, kleinen Projekten.
kleine Entwicklungsteams
Gute Kenntnis erforderlich (No-Surprise Software)
Alle Anforderungen / Erwartungen müssen von Anfang an komplett klar sein

Erklären und skizzieren Sie das V-Modell. Nennen Sie auch Vor- und Nachteile.
Für vollständige, stabile Anforderungen.
Im öffentlichen Bereich.
4 Submodelle: Systemerstellung, Qualitätssicherung, Konfigurationsmanagement, Projektmanagement
Ziel:
- Gesamtaufwand / Kostenreduktion
- Kürzere Einarbeitungszeiten für neue Mitarbeiter im Projekt
- Einfachere Kontrolle / vergleich des Projektfortschritts (auch für den Auftraggeber)
Teilt auf in Realisierungs und Test-Phase.
1. Analytische Phasen
  Immer detailiertere Spezifikation
1. Synthetische Phasen
  Immer weiter Implementiert und getestet
Sichten in analytischen und synthetischen Phasen
Anwendersicht Kundensicht, Geschäftsprozesse, Akzeptanz und Abnahmetests
Architektursicht Grundlegendes Architektur Design + Realisierug, Integrationstests
Implementierungssicht konkret spezifizierte Komponenten, oft Test-Driven-Developement
Qualitätssicherung
- Ist integriert nach jeder Phase
- Reviews, Inspektionen
Vorteile
- Fehlerbehandlung in frühen Phasen mit Reviews
  $\cdot$ Frühe Fehlererkennung in analytischen Phasen
  $\cdot$ Gute Planung
- Verschiedene Abstraktionslevels.
Nachteile
- Wie Wasserfallmodell
  Klare System-Anforderungen von Anfang an verlangt
  Alle Anforderungen / Erwartungen müssen von Anfang an komplett klar sein
- Viel Aufwand für Dokumentationen
Anwendungsbereich
für kleine Projekte zu detailliert, für große Projekte mit hohem Qualitätsanspruch geeignet (speziell Embedded Systems) an die man mehrere Jahre entwickelt
Große Projekte im öffentlichen Bereich

V Modell XT
V-Modell XT
Baut auf V-Modell und V-Modell 97 auf.
In DE im öffentlichen Bereich verpflichtend.
Modular, flexibel (kann angepasst werden durch Tailoring ).
Für unklare, sich ändernde Anforderungen auch geeignet.
Ziel: Projektrisiko minimieren, Anpassbarkeit, Anwendbarkeit, Skalierbarkeit und Änder- und Erweiterbarkeit des V-Modells.
21 verschiedene Elemente /Vorgehensbausteine
a) Kernelemente
b) Optionale Elemente
Kapseln mit Schnittstellen:
$\cdot$ Produkte
Ein Produkt kann aus vielen Subprodukten stehen die voneinander abhängig sein können (dependency).
$\cdot$ Produktergebnisse
$\cdot$ zugeordnete Aktivitäten
Für einen Produkt gibt es genau eine Aktivität (die widerum aus anderen Subaktivitäten bestehen kann)
$\cdot$ verantwortliche Rollen
Für einen Produkt gibt es genau einen Verantwortlichen.
Produkt und Aktivität können von anderen Produkte und Aktivitäten abhängig sein.
Es gibt Abhängigkeiten zwischen den Bausteinen (steht in der V-Modell XT Dokumentation).
Projektgegenstand
Inhalt des Projektes (bspws Hardware-Systeme, Software-Systeme, komplexe Systeme, eingebettete Systeme und Systemintegration im V-Modell XT)
Projekttypen
1. Systementwicklungsprojekt des Auftraggebers AG
  Auftraggeber-Sicht
1. Systementwicklungsprojekt des Auftragnehmers AN
  Auftragnehmer-Sicht
1. Systementwicklungsprojekt des AN mit AG in derstelben Organisation
  InHouse-Projekt , keine externe Kommunikation
1. Einführung und Pflege eines organisationsspezifischen Vorgehensmodells
  Warten und Verbessern
Kern und optionale Bausteine nach Projekttyp
Projekttypen vs. Projektgegenstand
Projekttypen eingeteilt nach:
1. Gegenstand: z.B. Hardwaresystem, Softwaresystem, Komplexes System
1. Rollen: z.B. Auftraggeber / Auftragnehmerprojekte
Gesamte Strategie inkl. Entscheidungspunkte (Projektdurchführung)
Projektdurchführungsstrategie: Aneinander-Reihung der Bausteine → Definiert Ablauf.
Unterschiedliche Arten an Strategien möglich (auch inkrementell und agil).
Beispiel:
Tools
Kann man an unterschiedliche Projektgegebenheiten mit Open Source tools anpassen:
- Auswahl von benötigten Vorgehensbausteinen
- passende Projektdurchführungsstrategie
- Ergebnis: maßgefertigte Vorgehensweise + Templates für die Projektdokumentation.

Erklären und skizzieren Sie den SCRUM Prozess. Nennen Sie auch Vor- und Nachteile
Bisher mangelhafte Flexibilität, unnötig hoher Dokumentationsaufwand, fehlende Nähe zum Kunden, Kunde nicht mit in Entwicklung einbezogen.
SCRUM
Art von agiler Entwicklung.
Ziel: kleine effiziente Teams bilden.
Gesamte Dauer meistens 2-4 Wochen
Sprint meistens 1 Tag → Keine Unterbrechungen, keine Änderungen zugelassen
Kurze tägliche Besprechungen vor Daily Scrums , 15 Minuten:
1. Was wurde seit dem letzten meeting erledigt
1. Welche Probleme sind aufgetreten während der Entwicklung
1. Was ist das Ziel bis zum nächsten Meeting
Reagiert auf andauernd ändernde Anforderungen im Projektablauf. Teil-Produkte stehen dem Kunden frühzeitig zur Verfügung.
Ein Team zuständig für Einheit / Produkt / Teilprodukt.
Begriffe
Temporal structure = daily Scrum Meeting + Review + Retrospective.
Backlog
alle Arbeitspakete, die in nächster Zeit umgesetzt werden müssen (sowohl klar definierte als auch vage Anforderungen): Produkt vs. Sprint Backlog.
Priorisierte Projektergebnisse (Backlog Items).
Daily-Scrum
Täglicher Arbeitsauftrag
Das Sprint-Team darf beim Arbeiten nicht gestört werden.
Scrum Team
Funktionsübergreifendes Team, zuständig für den Sprint Backlog.
Burndown Chart
Visuelle Darstellung des Projektfortschritts.
Phasen
1. Pregame
  Anforderungen → Architektur und Planung
  Alle Eigenschaften und Features gemeinsam mit Kunden → Product Backlog → Prioritisieren
  (alle zukünftigen Änderungen passieren im Product Backlog)
1. Sprint
  Kleine Menge an features aus product backlog → spring backlog (machbare Menge)
1. Postgame
  Auslieferung
Sprint
Team darf nicht gestört werden.
Wiederholung von:
1. Develop and Test Implementierung von neuer Software
1. Wrap Integration
1. Review Review des integrierten Produkts
1. Adjust Anpassung, Verbesserung
Methoden / Tools
$\cdot$ Burndown charts
$\cdot$ Test-Driven Developement
$\cdot$ Pair Programming
$\cdot$ Reviews
Vorteile:
• Wenige Regeln, leicht verständlich.
• Hohe Effektivität durch Selbstorganisation.
• Adaptiv/Tolerant gegenüber Anforderungsänderungen und neu Priorisierung.
• Hohe Transparenz durch regelmäßige Meetings und Backlogs.
• Geringer Administrations- und Dokumentationsaufwand.
Nachteile:
• Kein Gesamtüberblick über die komplette Projektstrecke.
• Hoher Kommunikations- und Abstimmungsaufwand.
• Erschwerte Koordination mehrerer Entwicklungsteam bei Großprojekten.
• Potentielle Verunsicherungen aufgrund fehlender Zuständigkeiten und Hierarchien.
• Potentielle Unvereinbarkeit mit bestehenden Unternehmensstrukturen.

Erklären Sie den Unterschied zwischen dem Produkt-Backlog und Sprint-Backlog.
Produkt-Backlog: Vom Kunden priorisierte Liste alle Features zum Produkt.
Sprint-Backlog: (Teilmenge von Produkt-Backlog) Alle Features die zu einem gewissen Sprint gehören. Features werden in kleinere Tasks aufgeteilt.

Was versteht man unter einem Burndown-Chart?
Visuelle Darstellung des Projektfortschrittes.
Immer neue Schätzungen des Abschlusses basierend auf aktueller Geschwindigkeit bei jedem daily scrum.

Was gehört zu den 12 Prinzipien des Agilen Manifests?
Entstand aus Kritik an „schwergewichtigen“ Ansätzen.
"Individuals and interactions over processes and tools; Working software over comprehensive documentation; Customer collaboration over contract negotiation; Responding to change over following a plan"
Englisch:
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
1. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
1. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
1. Business people and developers must work together daily throughout the project.
1. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
1. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
1. Working software is the primary measure of progress.
1. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
1. Continuous attention to technical excellence and good design enhances agility.
1. Simplicity--the art of maximizing the amount of work not done--is essential.
1. The best architectures, requirements, and designs emerge from self-organizing teams.
1. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Deutsch:
1. Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen.
1. Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.
1. Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne.
1. Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten.
1. Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen.
1. Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.
1. Funktionierende Software ist das wichtigste Fortschrittsmaß.
1. Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können.
1. Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität.
1. Einfachheit – die Kunst, die Menge nicht getaner Arbeit zu maximieren – ist essenziell.
1. Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams.
1. In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an.

Rational Unified Process, RUP
Inkrementell, iterativ, phasenorientiert.
Im kommerziellen Umfeld.
UML in jeder Phase.
Integriertes Anforderungsmanagement und Änderungsmanagement (supporting workflow).
Phasen mit Meilensteinen
Eine Phase kann mehrere Iterationen haben (Von Projektmanager festgelegt).
Aktivität + Verantwortlicher = Artifakt
Jede Phase / Aktivität von einem Verantwortlichen erzeugt ein Produkt / Artefakt → überprüft, freigegeben.
Wenn Überprüfung nicht bestanden, weitere Iteration.
1. Inception (Beginn)
  Anforderungen (Geschäftsfälle / Business Cases), Rahmenbedingungen definiert.
1. Elaboration (Entwurf + Design)
  Spezifikation aus Anforderungen.
1. Construction (Implementierung)
  Komponenten umgesetzt.
1. Transition (Auslieferung)
  Auslieferung an Kunden, Product release.
Disziplinen und Workflows
9 Disziplinen die durch alle Phasen geführt werden
6 Engineering Workflows
3 Supporting Workflows
Engineering Workflows
1. Business Modeling: Geschäftsfallmodellierung mit UML
1. Requirements: Anforderungen genau erheben, Verfeinerung der Use-Cases
1. Analysis & Design: Erstellen wichtige Dokumente / Artefakte: Architektur, Design, Test-Dokumente
1. Implementation
1. Test
1. Deployment: Fertigstellung, Auslieferung
Supporting Workflows
1. Configuration and Change Management: Dokumentenversionierung mit Version Control System
1. Project Management
1. Environment: Definiert Ressourcen, Budget und Werkzeuge für Entwickler
Vorteile
Real-world Szenarien.
Werkzeugunterstützung (Rational XDE, IBM).
Vordefinierte Liste mit erforderlichen Artefakten.
Nachteile
Komplexität, Dokumentationsaufwand
Anwendungsbereich
Grosse Projekte die einen Überblick brauchen (inkl. Deployment).

Erklären Sie die wesentlichen Konzepte des „Process Customizing“ und des „Prozess Tailoring“. Wozu und wann werden sie eingesetzt?
Modelle müssen dem Projekt angepasst werden.
Nicht alle Schritte aus dem Life-Cycle können ausgeführt werden.
$\cdot$ Schritte Zusammenlegen oder auslassen
Anpassung an
- Organisation mit eigener Domäne (= Fachgebiet)
  zb Wenn eine Organisation öfter Web Applikationen macht.
  Kann Best-Practices in der Domäne nutzen - Process Pattern
- Projekt
Reihenfolge
1. Process Customization: Organisation + Domäne
1. Process Tailoring: Projekt
Prozess Customization (Standardisierung)
Verallgemeinerte Form des „Tailorings“.
- unternehmensspezifische Standards (für eher große Unternehmen) → Domänenabhängige Anpassungen, z.B. für Produktionsautomatisierung.
- ähnliche Projekte (z.B. Webapplikationen).
Dient dann als Grundlage für Projektspezifisches Tailoring.
Prozess Tailoring (Prozess auf das jeweilige Projekt anpassen
Angepasst an konkrete Projekte (Projektgröße, Projekttyp und Anwendungsdomäne)
Braucht erfahrene Projektleiter und Toolunterstützung (z.B. V-Modell XT Projektassistent).

Auf welcher Grundannahme basiert die klassische / sequenzielle Softwareentwicklung? Zu welchen Problemen kann dies führen und wie wird damit bei der kontinuierlichen Softwareentwicklung umgegangen?
Der sequentielle Entwicklungsprozess basiert auf stabilen Anforderungen.
Anforderungen ändern sich allerdings oft, was bei sequentiellen Vorgehensmodellen in der Regel dazu führt, dass das Endprodukt nicht mehr den Anforderungen entspricht.
Beim kontinuirlichen Modell wird iterativ gearbeitet, der Funktionsumfang steigt mit jeder Iteration, gesteuert durch den Soll-Ist-Vergleich → auf Anforderungsänderungen kann besser reagiert werden.

V-Modell XT

SCRUM