Hybride und spezielle Vorgehensmodelle
In dieser Lerneinheit tauchst du in hybride und spezielle Vorgehensmodelle wie den Rational Unified Process (RUP) ein. Du lernst die charakteristischen Merkmale und Einsatzgebiete dieser Modelle kennen, die Elemente aus klassischen und agilen Ansätzen kombinieren. Durch das Verständnis dieser flexiblen Vorgehensweisen kannst du später fundiert entscheiden, welche Methoden-Kombination sich für deine konkreten Projektanforderungen am besten eignet.
Einführung
In der Softwareentwicklung stehst du oft vor einem Dilemma: Klassische Vorgehensmodelle wie das Wasserfallmodell bieten Struktur und Planbarkeit, sind aber zu starr für sich ändernde Anforderungen. Agile Methoden wie Scrum sind flexibel, bieten aber manchmal zu wenig Orientierung für komplexe Großprojekte.
Was wäre, wenn du das Beste aus beiden Welten kombinieren könntest?
Genau hier setzen hybride und spezielle Vorgehensmodelle an. Sie verbinden die Planungssicherheit klassischer Ansätze mit der Anpassungsfähigkeit agiler Methoden.
In dieser Lerneinheit lernst du fünf wichtige Ansätze kennen: RUP, FDD, DDD, MDSD und DevOps/CD.
Lernziele
Nach dieser Lerneinheit kannst du:
- Die vier Phasen des Rational Unified Process (RUP) benennen und seine sechs Best Practices erklären
- Die fünf Kernaktivitäten von Feature Driven Development (FDD) beschreiben
- Zentrale DDD-Konzepte wie Bounded Context, Aggregates und Domain Events unterscheiden
- Den Prozess der modellgetriebenen Softwareentwicklung (MDSD) erläutern
- Die Schlüsselelemente von DevOps und Continuous Delivery anwenden
Überleitung
Um zu verstehen, wie hybride Vorgehensmodelle klassische Struktur mit agiler Flexibilität verbinden, beginnen wir mit einem der bekanntesten Vertreter: dem Rational Unified Process.
RUP zeigt, wie iterative Entwicklung mit klar definierten Phasen kombiniert werden kann.
Was ist der Rational Unified Process?
Der Rational Unified Process (RUP) ist ein kommerzielles Produkt für Softwareentwicklung, das eine strukturierte Vorgehensweise bietet.
Entwickelt von: Rational Software (heute IBM)
Notationssprache: Unified Modeling Language (UML)
RUP kombiniert iterative Entwicklung mit klar definierten Phasen und Meilensteinen. Anders als beim klassischen Wasserfallmodell durchläuft jede Iteration einen vollständigen Entwicklungszyklus:
- Analyse
- Design
- Implementierung
- Test
Die vier Grundsätze des RUP
RUP basiert auf vier grundlegenden Prinzipien:
1. Iterativ und inkrementell
Der Entwicklungsprozess ist in mehrere Iterationen unterteilt. Jede Iteration liefert ein erweiterbares, funktionsfähiges Produkt.
2. Anforderungsgetrieben
Die Softwareentwicklung wird durch Anwenderanforderungen gesteuert. Diese werden kontinuierlich aktualisiert und angepasst.
3. Architekturzentriert
Eine robuste und flexible Architektur ist die Grundlage für den Projekterfolg. Sie wird früh definiert und schrittweise verfeinert.
4. Visuell
UML ermöglicht eine visuelle Darstellung von Anforderungen, Architekturen und Designelementen.
Die vier Phasen des RUP
RUP unterteilt den Entwicklungsprozess in vier Hauptphasen:
| Phase | Ziel | Hauptaktivitäten |
|---|---|---|
| Inception (Konzeption) | Projektumfang definieren | Anforderungssammlung, Machbarkeitsstudie, Risikobewertung |
| Elaboration (Ausarbeitung) | Architektur spezifizieren | Detaillierte Analyse, Architektur-Definition, Entwicklungsplan |
| Construction (Konstruktion) | Produkt entwickeln | Codierung, Testen, Integration der Komponenten |
| Transition (Übergang) | Produkt übergeben | Beta-Tests, Benutzerschulung, Fehlerbehebung |
Jede Phase endet mit einem Meilenstein, der die Zielerreichung überprüft.
RUP Best Practices: Iterative Entwicklung und Anforderungsmanagement
RUP empfiehlt sechs Best Practices für erfolgreiche Softwareentwicklung. Die ersten drei sind:
Iterative Entwicklung
Anstatt das gesamte System auf einmal zu entwickeln, wird es in mehreren Iterationen aufgebaut. Jede Iteration liefert ein funktionsfähiges Inkrement, das getestet und bewertet werden kann. Das reduziert Risiken und ermöglicht frühes Feedback.
Management von Anforderungen
Anforderungen werden systematisch erfasst, priorisiert und verwaltet. Änderungen werden kontrolliert eingeführt, um den Projektumfang nicht unkontrolliert wachsen zu lassen (“Scope Creep”).
Komponenten-basierte Architektur
Die Software wird aus wiederverwendbaren Komponenten aufgebaut. Das fördert Modularität, erleichtert die Wartung und ermöglicht parallele Entwicklung durch verschiedene Teams.
RUP Best Practices: Modellierung, Qualität und Änderungskontrolle
Die drei weiteren Best Practices des RUP sind:
Visuelle Modellierung
Durch die Verwendung von UML werden Anforderungen, Architekturen und Designelemente visuell dargestellt. Das vereinfacht das Verständnis und verbessert die Kommunikation im Team und mit Stakeholdern.
Verifizierung der Softwarequalität
Kontinuierliche Tests und Quality Assurance sind in jede Iteration integriert. Durch Code-Reviews, automatisierte Tests und Qualitätsmetriken wird sichergestellt, dass die Software den Anforderungen entspricht.
Kontrolle von Änderungen
Ein strukturiertes Change Management verfolgt alle Änderungen am Code, an Requirements und an der Architektur. Das gewährleistet Nachvollziehbarkeit und reduziert Risiken bei Änderungen.
RUP in hybriden Ansätzen
In der modernen Softwareentwicklung wird RUP häufig nicht isoliert, sondern in Kombination mit agilen Praktiken eingesetzt:
Typische hybride Vorgehensweise:
- Inception/Elaboration mit RUP: Strukturierte Architektur- und Anforderungsanalyse in den frühen Phasen
- Construction mit Scrum/Kanban: Agile Entwicklung in kurzen Sprints während der Konstruktionsphase
- Transition mit DevOps: Automatisierte Deployment-Pipelines für die Auslieferung
Dieser Ansatz vereint die Planungssicherheit von RUP mit der Flexibilität agiler Methoden. Besonders bei großen, komplexen Projekten mit regulatorischen Anforderungen ist diese Kombination verbreitet.
Was ist Feature Driven Development?
Feature Driven Development (FDD) ist ein agiles Vorgehensmodell, das sich auf die Lieferung von funktionalen Merkmalen (Features) innerhalb kurzer Iterationen konzentriert.
Entwickelt von: Jeff De Luca (Ende der 1990er Jahre)
Erster Einsatz: Bankprojekt in Singapur
Ziel: Effiziente, wiederholbare Prozesse für schnelle Entwicklung und hochwertige Software
Im Gegensatz zu Scrum fokussiert FDD stärker auf Dokumentation und eignet sich besonders für große Teams und langfristige Projekte.
Die fünf Kernaktivitäten von FDD
FDD setzt sich aus fünf aufeinander aufbauenden Kernaktivitäten zusammen:
1. Entwicklung eines Gesamtmodells
Ein High-Level-Modell, das die Schlüsselaspekte und den Umfang des Projekts abbildet.
2. Erstellung der Merkmalsliste
Eine umfassende Liste aller erforderlichen Features wird erstellt und priorisiert.
3. Planung nach Merkmalen
Die Features werden Entwicklern zugewiesen und zeitlich eingeplant.
4. Design und Build nach Merkmalen
Jedes Feature wird individuell entworfen, entwickelt und getestet.
5. Regelmäßige Fortschrittsüberprüfung
Kontinuierliche Integration und Testing stellen Qualität und Fortschritt sicher.
Iterationen in FDD
FDD betont kurze, konzentrierte Iterationen von 2 bis 10 Tagen pro Feature. Features, die länger als 10 Tage benötigen, sollten in kleinere Features aufgeteilt werden.
Die kurzen Zyklen ermöglichen schnelles Feedback und rasche Anpassungen.
Rollen und Vorteile in FDD
FDD definiert klare Rollen für den Entwicklungsprozess:
- Projektmanager: Verantwortlich für den Gesamtprozess und das Management
- Chief Architect: Leitet Design und Modellierung, überwacht die technische Qualität
- Feature Teams: Kleine, funktionsübergreifende Teams für spezifische Features
- Build-Manager: Zuständig für Integration und Build-Prozess
Vorteile von FDD:
- Klare, kurze Iterationen ermöglichen schnelles Feedback
- Feature-basiertes Vorgehen stellt den Kundennutzen in den Vordergrund
- Regelmäßiges Refactoring und fortlaufende Integration fördern Code-Qualität
FDD vs. Scrum: Wann welches Framework?
Beide sind agile Frameworks, unterscheiden sich aber in wichtigen Aspekten:
| Aspekt | FDD | Scrum |
|---|---|---|
| Iterationslänge | 2-10 Tage pro Feature | 2-4 Wochen pro Sprint |
| Meetings | Minimal, Fokus auf Dokumentation | Daily Standups, Reviews, Retrospectives |
| Dokumentation | Umfangreich, strukturiert | Minimal, “Working Software” |
| Team-Größe | Skaliert gut für große Teams | Optimal für 5-9 Personen |
| Rollenstruktur | Klar definiert (Chief Architect, Class Owners) | Flache Hierarchie (PO, SM, Team) |
Faustregel: Nutze FDD für große, langfristige Projekte mit stabilen Anforderungen. Nutze Scrum für kleinere Teams mit sich ändernden Anforderungen.
Was ist Domain-Driven Design?
Domain-Driven Design (DDD) ist ein Ansatz zur Softwareentwicklung, der die Fachdomäne in den Mittelpunkt stellt.
Entwickelt von: Eric Evans (2003, gleichnamiges Buch)
Kernidee: Software sollte die Sprache und Konzepte der Fachexperten widerspiegeln, nicht umgekehrt.
Wann DDD einsetzen?
- Komplexe Geschäftslogik mit vielen Regeln
- Langlebige Systeme, die sich weiterentwickeln
- Enge Zusammenarbeit zwischen Entwicklern und Fachexperten möglich
DDD ist kein Framework, sondern eine Denkweise. Du modellierst zuerst die Domäne, dann den Code.
Bounded Context: Klare Grenzen setzen
Ein Bounded Context definiert die Grenzen, innerhalb derer ein bestimmtes Domänenmodell gilt. Dieselben Begriffe können in verschiedenen Kontexten unterschiedliche Bedeutungen haben.
Beispiel E-Commerce:
| Begriff | Kontext “Bestellung” | Kontext “Versand” |
|---|---|---|
| Kunde | Käufer mit Zahlungsdaten | Empfänger mit Lieferadresse |
| Produkt | Bestellposition mit Preis | Paket mit Gewicht und Maßen |
Ohne klare Grenzen entstehen “Big Ball of Mud” Architekturen, in denen alles mit allem verbunden ist.
Context Mapping beschreibt die Beziehungen zwischen Bounded Contexts: Shared Kernel, Customer-Supplier, Conformist oder Anti-Corruption Layer.
Ubiquitous Language: Eine Sprache für alle
Die Ubiquitous Language (allgegenwärtige Sprache) ist ein gemeinsames Vokabular, das Entwickler und Fachexperten teilen. Sie durchdringt Code, Dokumentation und Gespräche.
Vorteile:
- Missverständnisse zwischen Business und IT werden reduziert
- Der Code wird selbstdokumentierend
- Fachexperten können den Code verstehen (zumindest die Struktur)
Beispiel Versicherung:
// Ohne Ubiquitous Language
if (customer.status == 2 && calc.getValue() > 1000) {...}
// Mit Ubiquitous Language
if (versicherungsnehmer.istPraemienbefreit() &&
schadenssumme.uebersteigt(selbstbeteiligung)) {...}
Die Sprache entwickelt sich iterativ. Wenn ein Begriff unklar ist, wird er im Team diskutiert und präzisiert.
Aggregates und Aggregate Root
Ein Aggregate ist eine Gruppe von zusammengehörigen Objekten, die als Einheit behandelt werden. Der Aggregate Root ist das einzige Objekt, über das von außen auf das Aggregate zugegriffen wird.
Regeln für Aggregates:
- Externe Objekte dürfen nur den Aggregate Root referenzieren
- Änderungen innerhalb des Aggregates erfolgen nur über den Root
- Der Root garantiert die Konsistenz aller enthaltenen Objekte
- Aggregates werden als Ganzes persistiert
Beispiel Bestellung:
Bestellung (Aggregate Root)
├── Bestellpositionen (intern)
├── Lieferadresse (intern)
└── Zahlungsinformation (intern)
Du greifst nie direkt auf eine Bestellposition zu. Stattdessen rufst du bestellung.fuegePositionHinzu(produkt, menge) auf. Der Aggregate Root prüft Geschäftsregeln wie Mindestbestellwert oder maximale Positionen.
Entities und Value Objects
DDD unterscheidet zwei Arten von Domänenobjekten:
Entities haben eine eindeutige Identität, die über die Zeit bestehen bleibt. Zwei Entities sind gleich, wenn sie dieselbe ID haben.
Value Objects haben keine Identität. Zwei Value Objects sind gleich, wenn alle ihre Attribute gleich sind. Sie sind unveränderlich (immutable).
| Merkmal | Entity | Value Object |
|---|---|---|
| Identität | Ja (ID) | Nein |
| Veränderbar | Ja | Nein (immutable) |
| Gleichheit | Nach ID | Nach Attributen |
| Beispiele | Kunde, Bestellung | Adresse, Geld, Zeitraum |
Warum Value Objects nutzen?
- Einfacher zu testen (keine Seiteneffekte)
- Thread-safe ohne Synchronisation
- Können frei geteilt werden
- Machen den Code ausdrucksstärker
Domain Events: Ereignisbasierte Kommunikation
Domain Events repräsentieren bedeutsame Geschäftsereignisse, die in der Domäne aufgetreten sind. Sie ermöglichen lose Kopplung zwischen Bounded Contexts.
Eigenschaften von Domain Events:
- Vergangenheitsform: “BestellungWurdeAufgegeben”, “ZahlungWurdeEmpfangen”
- Unveränderlich nach Erstellung
- Enthalten alle relevanten Daten zum Zeitpunkt des Ereignisses
- Können asynchron verarbeitet werden
Beispiel Event Flow:
1. Kunde gibt Bestellung auf
2. Event: BestellungWurdeAufgegeben
→ Lager-Context: Reserviert Artikel
→ Versand-Context: Plant Lieferung
→ Buchhaltung-Context: Erstellt Rechnung
Domain Events sind die Grundlage für Event Sourcing und CQRS (Command Query Responsibility Segregation). Sie ermöglichen skalierbare, entkoppelte Systeme.
Was ist Model-Driven Software Development?
Model-Driven Software Development (MDSD) verschiebt den Fokus von Code zu Modellen. Statt manuell Code zu schreiben, erstellst du abstrakte Modelle, aus denen der Code automatisch generiert wird.
Die Kernidee:
- Abstraktion erhöhen: Modelle beschreiben das “Was”, nicht das “Wie”
- Automatisierung nutzen: Generatoren erzeugen Code aus Modellen
- Plattformunabhängigkeit: Dasselbe Modell kann verschiedene Zielplattformen bedienen
Voraussetzungen für MDSD:
- Wiederkehrende Strukturen in der Software
- Wohldefinierte Domäne
- Investitionsbereitschaft in Tooling und DSLs
MDSD eignet sich besonders für Produktlinien, bei denen viele ähnliche Systeme entwickelt werden.
Der MDSD-Prozess: Von der DSL zum Code
Der MDSD-Prozess folgt einem klaren Ablauf:
1. DSL Definition
Eine Domain-Specific Language (DSL) ist eine spezialisierte Sprache für einen bestimmten Anwendungsbereich. Sie kann textuell (wie SQL) oder grafisch (wie UML) sein.
2. Modellierung
Fachexperten und Entwickler erstellen Modelle in der DSL. Diese Modelle sind präzise genug für automatische Verarbeitung.
3. Transformation
Generatoren transformieren Modelle in ausführbaren Code, Konfigurationsdateien oder Dokumentation.
4. Code/Artefakte
Der generierte Code wird mit handgeschriebenem Code kombiniert. Protected Regions markieren manuell erstellte Bereiche, die bei Neugenerierung erhalten bleiben.
Vorteile und Herausforderungen von MDSD
Vorteile:
- Produktivität: Weniger manueller Code, schnellere Entwicklung
- Konsistenz: Generierter Code folgt immer denselben Patterns
- Wartbarkeit: Änderungen am Modell wirken sich konsistent aus
- Dokumentation: Modelle dienen als lebende Dokumentation
- Wiederverwendung: DSLs und Generatoren sind projektübergreifend nutzbar
Herausforderungen:
- Initialer Aufwand: DSL und Generatoren müssen erst entwickelt werden
- Lernkurve: Teams müssen neue Tools und Konzepte lernen
- Tooling-Abhängigkeit: Generatoren müssen gepflegt werden
- Debugging: Fehler können im Generator oder Modell liegen
Wann lohnt sich MDSD?
- Mindestens 3-5 ähnliche Projekte geplant
- Klare, stabile Domäne
- Langfristige Produktstrategie
MDSD heute: Low-Code und No-Code Plattformen
Die MDSD-Prinzipien erleben eine Renaissance durch Low-Code und No-Code Plattformen. Diese demokratisieren die Softwareentwicklung.
Low-Code Plattformen:
- Visuelle Entwicklung mit minimalem Code
- Beispiele: OutSystems, Mendix, Microsoft Power Platform
- Zielgruppe: Entwickler, die schneller liefern wollen
No-Code Plattformen:
- Komplett visuelle Entwicklung ohne Programmierung
- Beispiele: Bubble, Webflow, Airtable
- Zielgruppe: Citizen Developer, Fachexperten
Gemeinsamkeiten mit klassischem MDSD:
- Abstraktion über Code-Level
- Automatische Code-Generierung
- Fokus auf Geschäftslogik statt Technik
Unterschiede:
- Geringere Einstiegshürde
- Weniger Anpassungsmöglichkeiten
- Vendor Lock-in statt eigener DSLs
Low-Code/No-Code eignet sich für MVPs, interne Tools und Standard-Workflows.
Was ist DevOps?
DevOps ist eine Kultur und Praxis, die Entwicklung (Dev) und Betrieb (Ops) zusammenbringt.
Ziel: Software schneller und zuverlässiger ausliefern.
Die traditionelle Trennung:
- Entwickler wollen neue Features, schnelle Änderungen
- Operations will Stabilität, minimale Änderungen
- Ergebnis: Konflikte, lange Release-Zyklen, Schuldzuweisungen
DevOps löst diesen Konflikt durch:
- Gemeinsame Verantwortung für den gesamten Lebenszyklus
- Automatisierung repetitiver Aufgaben
- Kontinuierliches Feedback und Verbesserung
- “You build it, you run it” Mentalität
DevOps ist keine Rolle oder Tool, sondern eine Arbeitsweise.
Die Schlüsselelemente von DevOps
DevOps basiert auf fünf Säulen, oft als CALMS zusammengefasst:
Culture (Kultur)
Vertrauen, Zusammenarbeit, Experimentierfreude. Fehler sind Lernchancen, keine Schuldfragen.
Automation (Automatisierung)
Alles, was automatisiert werden kann, wird automatisiert: Builds, Tests, Deployments, Infrastruktur.
Lean (Schlanke Prozesse)
Kleine Batches, schnelles Feedback, kontinuierliche Verbesserung.
Measurement (Messung)
Datengetriebene Entscheidungen. Key Metrics:
- Deployment-Frequenz
- Lead Time
- MTTR
- Change Failure Rate
Sharing (Wissensaustausch)
Transparenz über Silos hinweg. Postmortems, Dokumentation, gemeinsame Tools.
CI/CD ist das technische Rückgrat von DevOps.
Der Continuous Delivery Prozess
Continuous Delivery (CD) automatisiert den Weg vom Code-Commit bis zur Produktionsreife:
1. Commit Stage
Entwickler pusht Code. Automatisch: Kompilierung, Unit-Tests, statische Analyse.
2. Acceptance Test Stage
Integrationstests, API-Tests, End-to-End-Tests gegen Testumgebung.
3. Staging Stage
Deployment auf produktionsähnliche Umgebung. Performance-Tests, Security-Scans.
4. Manual Approval (optional)
Bei kritischen Änderungen: Review durch QA oder Product Owner.
5. Production Stage
Automatisches Deployment auf Production. Monitoring aktiviert.
Continuous Deployment geht noch weiter: Jeder erfolgreiche Build wird automatisch deployed, ohne manuellen Schritt.
Moderne DevOps-Praktiken: Feature Flags und Progressive Delivery
Moderne DevOps-Teams nutzen fortgeschrittene Deployment-Strategien:
Feature Flags (Feature Toggles)
Features werden im Code versteckt und per Konfiguration aktiviert:
- Deployment und Release entkoppeln
- A/B-Tests und Canary Releases ermöglichen
- Schnelles Rollback ohne neues Deployment
- Beispiel: LaunchDarkly, Unleash, eigene Implementierung
Progressive Delivery
Schrittweise Ausrollung an immer mehr Nutzer:
- Canary Release: 1-5% der Nutzer sehen das neue Feature
- Monitoring: Fehlerraten, Performance, User-Feedback beobachten
- Gradual Rollout: Bei Erfolg auf 25%, 50%, 100% erhöhen
- Rollback: Bei Problemen sofort zurück
Blue-Green Deployment
Zwei identische Produktionsumgebungen. Traffic-Switch zwischen “Blue” (alt) und “Green” (neu) in Sekunden.
Diese Praktiken minimieren Risiko und ermöglichen schnelle Iterationen.
DevOps-Werkzeuge 2025
Die DevOps-Toollandschaft entwickelt sich kontinuierlich. Hier die wichtigsten Kategorien:
CI/CD Plattformen:
- GitHub Actions: Native Integration in GitHub, YAML-basiert
- GitLab CI/CD: Integrierte DevOps-Plattform
- Jenkins: Open Source, hohe Flexibilität, große Community
- CircleCI, Travis CI: Cloud-native Optionen
Infrastructure as Code (IaC):
- Terraform: Multi-Cloud, deklarativ, State Management
- Pulumi: IaC mit echten Programmiersprachen
- AWS CloudFormation, Azure Bicep: Cloud-spezifisch
Container und Orchestrierung:
- Docker: Container-Standard
- Kubernetes: Container-Orchestrierung
- Helm: Kubernetes Package Manager
Monitoring und Observability:
- Prometheus + Grafana: Metriken und Dashboards
- Datadog, New Relic: All-in-One Observability
- OpenTelemetry: Vendor-neutraler Standard
Die Toolauswahl hängt von Team-Größe, Cloud-Strategie und Budget ab.
Wann welches Modell? Eine Entscheidungshilfe
Die Wahl des richtigen Vorgehensmodells hängt von Projektkontext, Team und Zielen ab:
| Modell | Best für | Nicht geeignet für |
|---|---|---|
| RUP | Große, komplexe Projekte mit klaren Phasen | Kleine, agile Teams mit schnellen Iterationen |
| FDD | Feature-getriebene Entwicklung, große Teams | Unklare Requirements, explorative Projekte |
| DDD | Komplexe Geschäftsdomänen, langlebige Systeme | Einfache CRUD-Anwendungen, Prototypen |
| MDSD | Produktlinien, wiederkehrende Strukturen | Einmalige Projekte, hohe Individualität |
| DevOps | Kontinuierliche Delivery, Cloud-native Apps | Legacy-Systeme ohne Automatisierung |
Kombinationen sind möglich:
- DDD + DevOps: Domänenmodellierung mit schneller Delivery
- RUP + FDD: Strukturierte Phasen mit Feature-Fokus
- MDSD + DevOps: Generierter Code mit automatisiertem Deployment
Es gibt kein “bestes” Modell. Die Kunst liegt in der Anpassung an den Kontext.
Zusammenfassung und Ausblick
Zusammenfassung
In dieser Lerneinheit hast du fünf wichtige hybride und spezialisierte Vorgehensmodelle kennengelernt. Jedes adressiert unterschiedliche Herausforderungen in der Softwareentwicklung:
| Modell | Kernkonzept | Besonderheit |
|---|---|---|
| RUP | Vier Phasen mit iterativer Entwicklung | Sechs Best Practices, UML-basiert |
| FDD | Feature-basierte Entwicklung | 2-10 Tage Iterationen, skaliert gut |
| DDD | Domäne im Mittelpunkt | Bounded Context, Ubiquitous Language |
| MDSD | Modelle statt Code | DSLs, automatische Codegenerierung |
| DevOps | Dev + Ops vereint | CI/CD, Feature Flags, Progressive Delivery |
Der Rational Unified Process (RUP) strukturiert große Projekte in vier Phasen (Inception, Elaboration, Construction, Transition). Die sechs Best Practices bilden das methodische Fundament und lassen sich gut mit agilen Praktiken kombinieren.
Feature Driven Development (FDD) fokussiert auf Features als zentrale Planungseinheit. Die fünf Kernaktivitäten ermöglichen kurze Iterationen und eignen sich besonders für große Teams.
Domain-Driven Design (DDD) stellt die Fachdomäne in den Mittelpunkt. Bounded Contexts, Aggregates und Domain Events sind die zentralen Bausteine für komplexe Geschäftslogik.
Model-Driven Software Development (MDSD) verschiebt den Fokus von Code zu Modellen. Moderne Low-Code und No-Code Plattformen setzen diese Prinzipien für breitere Zielgruppen um.
DevOps und Continuous Delivery verbinden Entwicklung und Betrieb. Die CALMS-Prinzipien bilden die kulturelle Basis, Feature Flags und Progressive Delivery ermöglichen risikoarme Releases.
Ausblick
In der nächsten Lerneinheit Tailoring und Anpassung von Vorgehensmodellen lernst du, wie du diese Modelle systematisch an Projektgröße, Teamstruktur und Rahmenbedingungen anpasst. Du erfährst, welche Elemente du kombinieren kannst und welche sich gegenseitig ausschließen.