Ein KI-Agent schreibt schnell Code. Aber er weiss nicht, was das System leisten soll, und er weiss nicht, wie es gebaut sein muss. Genau diese zwei Fragen beantwortet der Unified Process seit über 25 Jahren: mit Use Cases für das Was und mit einer Architektur für das Wie.
In diesem Beitrag konzentriere ich mich auf diese beiden Prinzipien. Ich zeige zuerst, was der Unified Process damit meint. Danach zeige ich, wie der AI Unified Process Use Cases und Architektur mit KI unterstützt, und warum sie für KI-Agenten wichtiger sind als je zuvor.
Der Unified Process in Kürze
Der Unified Process ist ein iteratives und inkrementelles Vorgehensmodell für die Softwareentwicklung. Ivar Jacobson, Grady Booch und James Rumbaugh haben ihn 1999 im Buch «The Unified Software Development Process» beschrieben. Die bekannteste Ausprägung ist der Rational Unified Process (RUP). Weitere Varianten sind OpenUP, der Agile Unified Process und der Enterprise Unified Process.
Wichtig: Der Unified Process ist kein starres Rezept. Er ist ein Framework, das man an die Organisation und das Projekt anpasst.
Vier Prinzipien prägen ihn. Die ersten drei stehen schon im Titel des ersten Kapitels:
- Use-Case-getrieben: Use Cases beschreiben, was das System für seine Benutzer leisten muss. Sie steuern Analyse, Design, Implementierung und Test.
- Architekturzentriert: Eine stabile Architektur wird früh festgelegt und geprüft. Sie ist das Rückgrat für alles, was folgt.
- Iterativ und inkrementell: Das System wächst in kurzen Iterationen. Jede Iteration liefert lauffähige Software.
- Risikogetrieben: Die grössten Risiken werden zuerst angegangen, nicht am Schluss entdeckt.
Phasen und Disziplinen
Der Unified Process hat zwei Dimensionen. Die Zeit läuft durch vier Phasen. Quer dazu laufen die Disziplinen, also die Arbeit, die gemacht wird. Jede Phase besteht aus einer oder mehreren Iterationen und endet mit einem Meilenstein.
| Phase | Ziel | Meilenstein |
|---|---|---|
| Inception (Konzeption) | Vision, Umfang und wichtigste Use Cases klären. Lohnt sich das Projekt? | Lifecycle Objectives |
| Elaboration (Entwurf) | Die meisten Use Cases beschreiben, Architektur festlegen und mit einem lauffähigen Skelett prüfen, grosse Risiken beseitigen | Lifecycle Architecture |
| Construction (Konstruktion) | Das System Use Case für Use Case bauen und testen | Initial Operational Capability |
| Transition (Übergabe) | Abnahme durch die Benutzer, Schulung, Einführung in Produktion | Product Release |
Die Disziplinen sind Business Modeling, Requirements, Analyse und Design, Implementierung, Test und Deployment. Dazu kommen unterstützende Disziplinen wie Konfigurations- und Change-Management, Projektmanagement und Umgebung.
Das Entscheidende: Alle Disziplinen laufen in allen Phasen. Nur das Gewicht verschiebt sich. In der Inception dominiert Requirements, in der Construction die Implementierung. Genau das unterscheidet den Unified Process vom Wasserfall.
Use Cases und Architektur sind dabei keine Phase. Sie ziehen sich durch das ganze Projekt. Darum schaue ich sie mir in den nächsten Abschnitten genauer an.
Use-Case-getrieben: die Idee
Ein Use Case beschreibt, wie ein Akteur mit dem System ein Ziel erreicht. Er erzählt den Ablauf aus Sicht des Benutzers: das Hauptszenario, die alternativen Abläufe und die Regeln, die dabei gelten.
Im Unified Process ist der Use Case mehr als eine Anforderung. Er ist der rote Faden durch das ganze Projekt:
- Die Planung wählt pro Iteration die Use Cases mit dem grössten Risiko oder Nutzen.
- Analyse und Design zeigen in einer Use-Case-Realisierung, welche Teile des Systems einen Use Case umsetzen.
- Die Tests prüfen, ob die Szenarien des Use Case funktionieren.
- Die Benutzerdokumentation beschreibt die Aufgaben, die ein Benutzer mit dem System erledigt.
So bleibt jede Arbeit mit einem Nutzen für den Benutzer verbunden. Das Problem in der Praxis war immer der Aufwand. Use Cases schreiben, aktuell halten und mit Code und Tests verbinden kostet Zeit. Viele Teams haben deshalb aufgehört, sie zu pflegen. Mehr zu modernen Use Cases habe ich in Use-Case 2.0 und Use-Case 3.0 geschrieben.
Use Cases im AI Unified Process
Im AI Unified Process ist der Use Case die Arbeitseinheit. Es gibt keine Tasks als Zwischenschicht. Warum, erkläre ich in Spec-driven Development ist keine Task-driven KI. Ein Agent bekommt einen Use Case und setzt ihn vollständig um. Die KI übernimmt genau den Aufwand, der früher gefehlt hat.
Use Cases finden und beschreiben. /requirements erstellt den Anforderungskatalog mit Glossar. /use-case-diagram leitet daraus Akteure und Use Cases ab, jeder mit einer ID wie UC-001 und verknüpft mit seinen Anforderungen. /use-case-spec schreibt pro Use Case Auslöser, Vor- und Nachbedingungen, Hauptszenario, alternative Abläufe und Business Rules. Die KI stellt dabei Fragen, statt Lücken mit Annahmen zu füllen.
Freigeben und prüfen. Ein Use Case wird erst umgesetzt, wenn er den Status «Approved» hat. Diese Entscheidung trifft die Fachseite, nicht die KI. Vorher prüft /spec-review die Spezifikation auf Widersprüche, unklare Begriffe und Anforderungen ohne Use Case.
Umsetzen und testen. /use-case-implement setzt den Use Case über alle Schichten um. Der Code trägt Marker mit der Use-Case- und der Business-Rule-ID. Warum diese Nachvollziehbarkeit wichtig ist, beschreibe ich in How and Why to Trace Use Cases and Tests (englisch). /use-case-test schreibt die Tests. Dabei ist die Spezifikation das Orakel: Ein Test, der dem Code widerspricht, bleibt rot. Findet der Agent eine Lücke, erfindet er nichts. Er schreibt eine offene Frage.
Abdeckung nachweisen. /use-case-coverage zeigt pro Schritt, Ablauf und Regel, ob Code und Tests dahinter stehen. Das ist Spezifikationsabdeckung, nicht Zeilenabdeckung. /test-case verbindet mehrere Use Cases zu einer End-to-End-Journey.
Ausliefern. Auch am Ende bleibt der Use Case der rote Faden. /acceptance-protocol erstellt die Checklisten für den Abnahmetest, /user-guide das Benutzerhandbuch und /release-notes die fachlichen Release Notes. Alles aus den Use Cases, nicht aus Commit-Messages.
Damit wird wahr, was der Unified Process immer wollte: Der Use Case steuert Planung, Umsetzung, Test und Dokumentation. Und er bleibt aktuell, weil der Code ohne ihn nicht entsteht.
Architekturzentriert: die Idee
Im Unified Process wird die Architektur früh festgelegt und geprüft. Das ist das Ziel der Elaboration. Am Ende dieser Phase steht der Meilenstein «Lifecycle Architecture»: eine lauffähige Architektur, die die grossen technischen Risiken beseitigt hat.
Diese Architektur entsteht nicht im luftleeren Raum. Sie wird an den architekturrelevanten Use Cases entwickelt und geprüft. Dazu kommen die nicht-funktionalen Anforderungen wie Performance, Sicherheit und Verfügbarkeit.
Der RUP beschreibt die Architektur mit dem 4+1 View Model von Philippe Kruchten. Vier Sichten zeigen das System aus verschiedenen Blickwinkeln: logisch, Prozess, Entwicklung und physisch. Das «+1» sind die Szenarien, also die Use Cases. Sie verbinden die Sichten und zeigen, dass die Architektur die Anforderungen wirklich erfüllt. In Ein Paper von 1995 beschreibt, wie du mit AI-Agenten entwickeln solltest zeige ich, warum dieses Modell so gut zu KI-Agenten passt.
Auch hier war das Problem in der Praxis immer gleich. Architekturdokumente und Code laufen auseinander. Nach ein paar Monaten beschreibt das Dokument ein System, das es so nicht mehr gibt.
Architektur im AI Unified Process
Für einen KI-Agenten ist Architektur kein Dokument, das man einmal liest. Sie gibt ihm die Leitplanken, an denen er sich bei jedem Use Case orientiert. Im AI Unified Process nenne ich das den Harness (mehr dazu in Harness Engineering). Er besteht aus vier Teilen.
Nicht-funktionale Anforderungen und Constraints. /requirements erfasst sie messbar, mit IDs wie NFR-003 oder C-005. Wichtige NFRs führen zu eigenen Tests, zum Beispiel für Sicherheit oder Performance.
Architekturentscheide. /architecture-decision hält jeden Entscheid als ADR fest: Kontext, Entscheid, Konsequenzen. Jeder ADR ist mit den NFRs und Constraints verknüpft, denen er dient. Die KI prüft neue ADRs gegen die bestehenden und findet Widersprüche. So bleibt das Warum einer Entscheidung nachvollziehbar.
Der Stack. /stack beschreibt in einer Datei die technischen Schichten: Migration, Persistenz, Service, API, UI und End-to-End-Tests. Für jede Schicht steht dort die Technologie, zum Beispiel Flyway, jOOQ, Spring Boot und Vaadin, und welcher Skill sie baut und testet. Die Agenten lesen diese Datei vor jeder Umsetzung. Ein Beispiel für eine solche Architektur beschreibe ich in Eine KI-fähige Architektur für Geschäftsanwendungen.
Quality Gates. /spec-review läuft in der CI-Pipeline und bricht den Build ab, wenn die Spezifikation inkonsistent ist. /use-case-coverage zeigt, ob Code und Tests zur Spezifikation passen.
Der AI Unified Process schreibt bewusst kein Architektur-Framework vor. Jedes Unternehmen arbeitet anders. Die Stack-Datei funktioniert neben arc42, C4 oder dem 4+1 View Model.
Und wie im Unified Process wird die Architektur früh geprüft. Die ersten freigegebenen Use Cases werden als Walking Skeleton durch alle Schichten umgesetzt. Läuft dieser Durchstich, ist die Architektur bestätigt. Erst dann beginnt die breite Umsetzung.
Durch alle Phasen
Der AI Unified Process übernimmt die vier Phasen des Unified Process und gibt jeder Phase passende KI-Skills. Die Spezifikation liegt als Markdown, PlantUML und BPMN im Git-Repository. So arbeiten Menschen und KI-Agenten mit denselben Dokumenten.
Inception. Die KI macht aus Vision, Gesprächsnotizen und bestehenden Dokumenten einen strukturierten Anforderungskatalog und ein Use-Case-Diagramm. Spielen mehrere Rollen und Use Cases zusammen, modelliert /business-process den Geschäftsprozess in BPMN. Was unklar ist, landet mit /open-questions in einer zentralen Liste. Das ist Shift Left in der Praxis.
Elaboration. Im KI-Zeitalter ist das die wichtigste Phase. Hier entsteht die Spezifikation, aus der die Agenten später Code bauen. Neben Use Cases, ADRs und Stack erstellt /entity-model das Datenmodell als ER-Diagramm mit Attributen und Validierungen.
Construction. Die Agenten setzen Use Case für Use Case um und testen ihn. Die Menschen prüfen Abdeckung und beantworten offene Fragen.
Transition. Abnahmeprotokoll, Benutzerhandbuch und Release Notes entstehen aus der Spezifikation.
Über alle Phasen. /next liest den Zustand des Projekts und sagt, welcher Schritt als nächstes kommt. Das Navigator-Plugin des AI Unified Process für IntelliJ und VS Code verbindet Tests und Spezifikation per Klick. Und /spec-review läuft als Quality Gate in der CI-Pipeline.
Das Zusammenspiel: What, Harness, How
Use Cases und Architektur sind zwei Seiten derselben Sache. Der AI Unified Process trennt sie in drei Ebenen. Die Use Cases beschreiben das What. Die Architektur bildet den Harness. Der Code ist das How, und den schreiben die Agenten.
Die Agenten arbeiten autonom. Sie werden nicht Schritt für Schritt geführt. Darum ist KI-Entwicklung für mich eine Werkstatt und keine Fabrik. Damit das funktioniert, müssen die beiden oberen Ebenen gut sein. Ist ein Use Case unklar, baut der Agent das Falsche. Ist der Harness schwach, baut er das Richtige auf die falsche Art.
Darum verschiebt sich die Arbeit. Früher steckte der grösste Aufwand im Code. Heute steckt er in guten Use Cases und einer klaren Architektur. Genau dort, wo der Unified Process ihn immer haben wollte.
Früher war die Spezifikation oft ein Dokument, das niemand mehr gelesen hat, sobald der Code da war. Mit KI-Agenten ist das anders. Die Spezifikation ist die Eingabe für den Agenten. Ist sie schlecht, ist auch der Code schlecht. Darum lohnt sich die Arbeit in Inception und Elaboration heute mehr denn je. Oder wie ich schon geschrieben habe: Code ist nicht mehr der Engpass. Anforderungen schon.
Auch die Iterationen werden kürzer. Ein Agent setzt einen Use Case in Minuten statt Tagen um. Das Feedback der Fachseite kommt also viel schneller. Der Unified Process wollte genau das: frühes Feedback und frühe Risikoreduktion. Spec-Driven Development heisst darum nicht Wasserfall: Warum Spec-Driven Development iterativ, inkrementell und agil sein kann.
Fazit
Use Cases und Architektur waren im Unified Process immer richtig, aber teuer. Mit KI ändert sich die Rechnung. Die KI hilft beim Schreiben und Prüfen der Use Cases, hält Architekturentscheide nachvollziehbar und verbindet beides mit Code und Tests. Der AI Unified Process macht aus zwei alten Prinzipien eine praktische Arbeitsweise für KI-Agenten.
Mehr zum AI Unified Process und den Skills gibt es auf unifiedprocess.ai. Ein Beispielprojekt findest du auf GitHub unter ai-unified-process/petclinic.
Quellen: Jacobson, Booch, Rumbaugh: The Unified Software Development Process, Addison-Wesley 1999 · Philippe Kruchten: The 4+1 View Model of Architecture, IEEE Software 1995 · Wikipedia: Unified Process · BA Wiki: Unified Process
