Vorgehensmodelle (Prozesse)

Vorgehensmodelle / Prozessmodelle

Software Life-Cycle → Vorgehensmodell

Fokus von Vorgehensmodellen der technischen Seite

Beginn : Definition von Anforderungen

Ende : Inbetriebnahme bei Kunden

Vorgehensmodelle (Softwareprozesse)

Strategien für Schritte in Life-Cycle. (Basieren auf Software Life-Cycle Prozess)

Rahmenprozess für Projektablauf

Bestimmt wann welches Produkt von wem in welchem Fertigstellungsgrad und auf welchem Qualitätsniveau vorliegen muss.

konkrete standardisierte Strategie, kann abgeändert werden (tailoring)

Entscheidungspunkte

(zb Meilensteine) = Zeitpunkt an dem eine Entscheidung getroffen wird.

An Entscheidungspunkten müssen definierte Produkte vorliegen.

Projektdurchführungsstrategie

eine definierte Abfolge von Entscheidungspunkten.

Sie definieren die Reihenfolge der im Projekt zu erreichenden Projektfortschrittsstufen.

Klassisch / Sequentiell (traditionell)

Wasserfallmodell

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.

Nachteile

Reaktion auf spätere Änderungen schwer

Software und Prototyp für Kunden steht spät zu verfügung

keine parallele Entwicklung.

Starke Auswirkung von Fehlern aus frühen Phasen.

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

V-Modell (Grundkonzept)

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.

Analytische Phasen
Immer detailiertere Spezifikation

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

Spezifikationsphase $\lrarr$ Realisierung und Testen.

Verschiedene Abstraktionslevels.

Fehlerbehandlung in frühen Phasen mit Reviews

$\cdot$ Frühe Fehlererkennung in analytischen Phasen

$\cdot$ Gute Planung

Basiskonzept für V-Modell 97 und V-Modell XT.

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

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

Systementwicklungsprojekt des Auftraggebers AG
Auftraggeber-Sicht

Systementwicklungsprojekt des Auftragnehmers AN
Auftragnehmer-Sicht

Systementwicklungsprojekt des AN mit AG in derstelben Organisation
InHouse-Projekt , keine externe Kommunikation

Einführung und Pflege eines organisationsspezifischen Vorgehensmodells
Warten und Verbessern

Kern und optionale Bausteine nach Projekttyp

Projekttypen vs. Projektgegenstand

Projekttypen eingeteilt nach:

Gegenstand: z.B. Hardwaresystem, Softwaresystem, Komplexes System

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.

Iterativ / Inkrementell (traditionell)

Schrittweises Vorgehen.

Sehr lange, sehr große, Komplexe Systeme, unklare / ändernde Anforderungen, schnell erste verwendbare Protoypen verlangt.

wenn man schnell schon etwas "greifbares" haben möchte

Integration findet kontinuierlich statt

kleine Etappen / Meilensteine die gemeinsam geplant werden, Planung einfacher

Kontinuierlich hohe Qualität

Ziel:

Rasch mit Teillösung auf den Markt kommen - dann ausbauen.

Gleichzeitig kann an darauf folgenden Versionen (von mehreren Teams) geplant / gearbeitet werden.

Architektur muss stabil sein

Prioritisierung, Anordnung nach Relevanz für Kunde.

Spiralmodell

Inkrementelles Vorgehen.

Schritte in jeder Iteration:

Definition: Ziele, Alternativen

Risiko Einschätzung

Entwicklung, Testen

Feedback zur aktuellen Lösung (Review)

Planung von nächster Iteration

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.

Inception (Beginn)
Anforderungen (Geschäftsfälle / Business Cases), Rahmenbedingungen definiert.

Elaboration (Entwurf + Design)
Spezifikation aus Anforderungen.

Construction (Implementierung)
Komponenten umgesetzt.

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

Business Modeling: Geschäftsfallmodellierung mit UML

Requirements: Anforderungen genau erheben, Verfeinerung der Use-Cases

Analysis & Design: Erstellen wichtige Dokumente / Artefakte: Architektur, Design, Test-Dokumente

Implementation

Test

Deployment: Fertigstellung, Auslieferung

Supporting Workflows

Configuration and Change Management: Dokumentenversionierung mit Version Control System

Project Management

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).

Agil

Bisher mangelhafte Flexibilität, unnötig hoher Dokumentationsaufwand, fehlende Nähe zum Kunden, Kunde nicht mit in Entwicklung einbezogen.

Agiles Manifest → 12 Agile Principles
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"
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.

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 Daily Scrums , 15 Minuten:

Was wurde seit dem letzten meeting erledigt

Welche Probleme sind aufgetreten während der Entwicklung

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

Pregame
Anforderungen → Architektur und Planung
Alle Eigenschaften und Features gemeinsam mit Kunden → Product Backlog → Prioritisieren
(alle zukünftigen Änderungen passieren im Product Backlog)

Sprint
Kleine Menge an features aus product backlog → spring backlog (machbare Menge)

Postgame
Auslieferung

Sprint

Team darf nicht gestört werden.

Wiederholung von:

Develop and Test Implementierung von neuer Software

Wrap Integration

Review Review des integrierten Produkts

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.

eXtreme Programming XP

Coding: kontinuierliche Integration, Programmieren in Paaren (der eine programmiert, der andere testet, Rollen können wechseln)

Design: einfache Dinge nur einmal tun

Dokumentation: kommentare im source code

Test: Unit-Tests

Integration: mehrmals täglich in Code-Basis einfügen und testen

Anwendung: Projekte mit schnell wechselnden oder vagen Anforderungen, mit kleinen Entwicklergruppen (bis 12 Personen), zeitkritische Projekte

Eher explorativer Ansatz

Prozess-Tailoring / Customization: Anpassung der Modelle

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

Process Customization: Organisation + Domäne

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).