Skills / Project_300

Rational Unified Process

The Rational Unified Process is a software engineering process. It provides a disciplined approach to assigning tasks and responsibilities within a development organization. Its goal is to ensure the production of high-quality software that meets the needs of its end-users within a predictable schedule and budget.

The Rational Unified Process (RUP) is a prescriptive, iterative software development framework that structures projects across four phases — Inception, Elaboration, Construction, and Transition — and nine engineering and support disciplines. It is use-case driven, architecture-centric, and applies risk-driven iteration to surface and resolve the highest-priority technical risks early. RUP is purpose-built for enterprise and regulated-industry software projects where formal governance, traceable artifacts, and milestone-based accountability are required.

By Philippe Kruchten  ·  Free

Use this skill See it in action

Specimen 01 · Live diagnosisRational Unified Process

Input

“We're supposedly in Construction, three sprints in, but the architecture keeps shifting. We're still arguing about service boundaries and the…”

Diagnosis

Welcome.

Full transcript ↓

Calibrated referenceagent-skills.ai

The gap

Tame software complexity with four phases, nine disciplines, and architecture-first iteration

RUP structures a software project along two axes: time and content. Along the time axis, projects move through four phases — Inception (scope and business case), Elaboration (architectural baseline and risk resolution), Construction (iterative feature build-out), and Transition (deployment and user acceptance) — each ending at a named milestone gate: Lifecycle Objective, Lifecycle Architecture, Initial Operational Capability, and Product Release. Along the content axis, nine disciplines — Business Modeling, Requirements, Analysis & Design, Implementation, Test, Deployment, Configuration & Change Management, Project Management, and Environment — operate across all phases with shifting intensity. Three principles unify the framework: all work traces back to use cases (use-case driven); architectural decisions are made explicitly and early using Kruchten's 4+1 View Model covering Logical, Process, Development, Physical, and Use Case perspectives (architecture-centric); and every iteration is prioritized by residual risk rather than feature desirability (iterative and incremental). Projects produce a defined artifact set at each phase: Vision Document, Software Architecture Document, Use Case Model, Risk List, Iteration Plan, and Deployment Plan.

The problem

Software projects fail not from lack of effort but from deferred architecture decisions, risks that surface in the final sprint, and milestones that nobody can agree are genuinely 'done.' Teams enter Construction while service boundaries are still debated and database schemas are on their fourth revision — because there was no formal Elaboration milestone to pass. RUP addresses this by enforcing phase gates with explicit entry and exit criteria, requiring architecture to be proven executable before bulk Construction begins, and ensuring every requirement traces to a testable use case.

The solution

Stop treating each sprint as a self-contained island. With RUP, every iteration is positioned within a phase, every phase ends at a documented milestone gate, and every requirement traces to a use case — so your team always knows where you are, what risks remain, and what 'done' actually means.

You bring

A description of your software project — its domain, scale, regulatory context, and team size
Your current phase or the specific breakdown — unclear scope, unstable architecture, open integration risks, or deployment pressure
Stakeholder requirements, business objectives, or constraints (even if partially formed)
Any existing artifacts — use case drafts, architecture diagrams, risk lists — for review or extension

You get

A milestone gate readiness assessment — a structured checklist mapping your project against Lifecycle Objective, Lifecycle Architecture, Initial Operational Capability, or Product Release criteria with specific open items
A Software Architecture Document (SAD) draft organized across all five 4+1 views: Logical, Process, Development, Physical, and Use Case
Fully structured Use Case Specifications with actors, preconditions, main flows, alternative flows, exception flows, and postconditions
A risk-prioritized Iteration Plan sequencing work by Risk List ranking so the highest-residual-risk scenarios are retired first

In action

Watch the methodology work.

Three specimens from a single real session: the same situation, unaided and calibrated, the full transcript, and the skill answering live in the channel where the work happens.

Fig.01  —  The same situation, two ways

Specimens A · B

Specimen AVague

Unaided

“Your team of twelve is in week nine of what the schedule calls Construction. The database schema is on its fourth revision. Service boundaries were renegotiated last sprint. Integration tests are failing across the board. The project manager says you are on track because no calendar dates have slipped yet — but rework is accelerating, no one can articulate what the architecture actually is, and two senior engineers are quietly designing around each other's assumptions.”

×Vague — nothing concrete to act on.

Specimen BCalibrated

With Rational Unified Process

“After a properly gated Elaboration phase, you have an executable prototype validating your service boundaries and persistence strategy, a Software Architecture Document with all five 4+1 views baselined and team-reviewed, and a Construction plan sequenced by Risk List priority. New use cases slot into a stable architecture without schema renegotiations. Integration tests pass because the seams are defined. Rework has dropped because the foundation is no longer moving.”

◦Specific, grounded, and ends with one clear next step.

Fig.02  —  A real session, unedited

In-app · assistant

Rational Unified ProcessClaude

Rational Unified Process

Welcome. I work with teams applying the Rational Unified Process — from scoping Inception through Transition gate reviews. Before we begin: which phase is your project currently in, and what is the most pressing breakdown you are facing? Unclear scope, an unstable architecture, unresolved integration risk, or deployment pressure? The answer determines whether we start with a milestone assessment, architecture documentation, use case development, or iteration planning.

We're supposedly in Construction, three sprints in, but the architecture keeps shifting. We're still arguing about service boundaries and the database schema has changed three times.

That's the signature symptom of a missed Lifecycle Architecture Milestone. In RUP, you cannot enter Construction until you have an executable architectural prototype that proves the critical technical risks are resolved — including your persistence strategy and service decomposition. The fact that both are still open means your project is in late Elaboration, not Construction, regardless of what the schedule says.

Let me ask the milestone gate questions directly: Do you have a running prototype that exercises your service boundaries and database layer under realistic conditions? Has the team reviewed and version-controlled an architecture baseline? Has your Risk List been reduced to implementation tasks rather than architecture unknowns?

We have some UML diagrams but nothing executable. No formal architecture review has happened — we basically just started building.

Then you have not passed the Lifecycle Architecture Milestone. The correct move is to stop adding features and spend one iteration on two things: an executable prototype that exercises your database layer and service communication under realistic conditions, and a Software Architecture Document that baselines your decisions across the 4+1 views.

Here is the practical case for your team: every Construction iteration you run right now accumulates rework debt on a foundation that has not been validated. Schema change number three became expensive — change number five in Construction will be catastrophic. The time spent stabilizing architecture now is less than the rework it prevents.

Shall I run the full Lifecycle Architecture Milestone checklist so you have a concrete, criteria-based list to take to your team?

Yes — I need something concrete to show them. Right now it's just my opinion that we have a problem.

The Lifecycle Architecture Milestone has six entry criteria. Tell me your current status on each — Completed, In Progress, or Not Started:

Executable architectural prototype — A running system exercises the highest-risk scenarios: your service communication, persistence layer, and any third-party integration points.2. Major risks retired — Each Risk List item is either resolved or reduced to an acceptable residual with a documented mitigation strategy.3. Architecture baseline documented — A Software Architecture Document captures key structural decisions across all 4+1 views and is version-controlled.4. Architecturally significant use cases traced — The use cases that stress quality attributes (performance, integration, security) are identified and traced to specific design decisions.5. Development environment stable — Build, test, and configuration management tooling is operational and non-blocking for the full team.6. Construction plan credible — Estimates for Construction are based on the architecture you now understand — not the architecture you hoped for at kickoff.

Items 1, 3, and 4 are Not Started. Items 2 and 6 are In Progress but shaky. Only item 5 is solid.

One of six criteria met. That is your artifact-backed argument: the Lifecycle Architecture Milestone is a defined gate with documented entry criteria, and you have three open blockers on the critical path. This is not an opinion — it is a checklist with evidence.

Your highest-leverage next step is probably item 1: scoping a one-iteration architectural prototype. Once you have a running system that exercises your service boundaries and database schema, items 3 and 4 become much easier to complete — because you will be documenting what you proved, not speculating about what you plan. I can help you define the prototype scope right now: which three to five use cases stress the architecture most? Those are your prototype candidates.

Reply to Rational Unified Process…

What the skill is doing

01Phase Milestone Gate Assessment

024+1 Architecture View Modeling

03Use Case Specification Authoring

Fig.03  —  The same skill, in the channel you already use

WhatsApp · live

9:41

RURational Unified Processtyping…

Messages are end-to-end encrypted. No one outside of this chat can read them.

Today

We're supposedly in Construction, three sprints in, but the architecture keeps shifting. We're still arguing about service boundaries and the database…9:14✓✓

I work with teams applying the Rational Unified Process — from scoping Inception through Transition gate reviews.9:14

Before we begin: which phase is your project currently in, and what is the most pressing breakdown you are facing?9:15

Unclear scope, an unstable architecture, unresolved integration risk, or deployment pressure?9:15

Message

The same skill, where the work happens.

No new app to learn. The methodology runs over the WhatsApp Business API, so the answer lands as a reply in the thread you’re already in — same rigour, zero context-switch.

◦Reads the situation, names the pattern, returns one concrete next move.

◦Delivered in seconds, inside a conversation that already exists.

Specimen · WhatsApp Business API · live

Capabilities

What it does, specifically.

Each capability is a distinct move drawn straight from the source methodology — not a generic assistant guessing.

CapabilityC-01

Phase Milestone Gate Assessment

Evaluates your project against RUP's four milestone gate criteria — Lifecycle Objective, Lifecycle Architecture, Initial Operational Capability, or Product Release — to determine whether you are genuinely ready to advance phases or have unresolved gaps. Produces a structured pass/partial/fail checklist with specific open items and remediation actions, giving teams an artifact-backed argument for phasing decisions.

◦ MethodBased on Kruchten's defined milestone entry and exit criteria: for example, the Lifecycle Architecture Milestone requires a running executable architectural prototype that proves critical technical risks resolved — not merely documented design diagrams.

CapabilityC-02

4+1 Architecture View Modeling

Applies Kruchten's 4+1 View Model to analyze and document your system from five concurrent perspectives: the Logical View (domain structure and functionality), Process View (runtime concurrency and inter-process communication), Development View (code and module organization), Physical View (deployment topology and infrastructure), and Use Case View (the architecturally significant scenarios that drive and validate the other four views).

◦ MethodDirectly implements Kruchten's 1995 IEEE Software paper 'The 4+1 View Model of Architecture,' the architectural cornerstone of RUP's architecture-centric principle, designed to ensure that no single diagram can adequately represent an enterprise system's architecture.

CapabilityC-03

Use Case Specification Authoring

Translates stakeholder goals into fully structured Use Case Specifications — the fundamental unit of requirements traceability in RUP — including actors, preconditions, basic flow, alternative flows, exception flows, and postconditions. Each specification becomes the anchor from which Analysis & Design, Implementation, and Test activities derive, ensuring every engineering decision can be traced to a stakeholder intent.

◦ MethodImplements RUP's use-case driven principle: all development activities trace to use cases, and architecturally significant use cases — those stressing quality attributes like performance, security, or interoperability — must have resolved design and prototype evidence before the Lifecycle Architecture Milestone can be passed.

CapabilityC-04

Risk-Driven Iteration Planning

Constructs an Iteration Plan that sequences development cycles within a phase by ordering highest-residual-risk scenarios and architectural unknowns first. Each iteration entry includes its goal, selected use cases or risk items, architectural concerns to resolve, entry/exit criteria, and assigned roles. The plan makes visible which risks remain at any point and why each iteration's scope was chosen.

◦ MethodImplements RUP's iterative and incremental principle: Kruchten specifies that iteration scope must be driven by Risk List rankings rather than feature desirability, ensuring the project's most dangerous technical assumptions are proven or disproven in the earliest possible iterations — especially during Elaboration.

CapabilityC-05

RUP Tailoring Advisor

Recommends which of RUP's nine disciplines, defined roles, and artifact types to retain fully, abbreviate, or waive — based on project size, team composition, regulatory context, and risk profile. Produces a tailoring decision record that defines your project's custom RUP configuration and prevents both over-engineering (applying full enterprise RUP to a five-person project) and under-engineering (skipping architecture documentation in a safety-critical system).

◦ MethodReflects Kruchten's explicit design of RUP as an adaptable process framework: full RUP specifies over thirty artifact types and two dozen roles, but the framework explicitly requires project-specific tailoring — selecting a context-appropriate subset rather than applying every element uniformly.

Tested

Graded before it shipped.

Every skill is scored against independent scenarios for methodology fidelity before it goes live — not vibes, a rubric.

What it produces

OutputD-01

Software Architecture Document (SAD)

A multi-section architecture record organized across Kruchten's five 4+1 views: Logical (key abstractions and class model), Process (threads, processes, and runtime communication), Development (component and package structure), Physical (deployment topology), and Use Case (architecturally significant scenarios that drove the preceding four views). The primary Elaboration deliverable and the baseline document that stabilizes all subsequent Construction work.

OutputD-02

Milestone Gate Readiness Checklist

A structured assessment against one of RUP's four phase milestone criteria. Lists each entry condition as met, at risk, or open — with the specific evidence required and the remediation actions needed before the project is genuinely ready to advance rather than calendar-ready.

OutputD-03

Use Case Model

A complete set of actor definitions and Use Case Specifications covering the project's architecturally significant scenarios. Each spec includes basic and alternative flows, exception flows, preconditions, and postconditions — the requirements backbone from which all Analysis & Design, Implementation, and Test activities derive.

OutputD-04

Risk-Prioritized Iteration Plan

An iteration-by-iteration roadmap for a single phase, ordered by residual risk exposure. Each entry includes: iteration goal, targeted use cases or risk items, architectural concerns to resolve, and entry/exit criteria. Makes visible which risks remain at any point and why the iteration sequence is ordered as it is.

OutputD-05

RUP Tailoring Decision Record

A project-specific configuration document listing which RUP disciplines are applied fully, which are abbreviated, and which are waived — with explicit rationale for each. Prevents both gold-plating on small projects and dangerous shortcuts on regulated-industry builds where artifact compliance is a legal requirement.

The source

Grounded in the original work.

Every answer traces back to a real source and the practitioner who wrote it — not a secondhand summary. Here is the source of record.

Source authorA-01

Philippe Kruchten

Philippe Kruchten is a Belgian-Canadian software engineer who formalized the Rational Unified Process while serving as Distinguished Engineer at Rational Software Corporation. He invented the 4+1 Architectural View Model, published in IEEE Software in November 1995, which became a canonical multi-perspective technique for software architecture documentation adopted in textbooks and engineering curricula worldwide. Following IBM's acquisition of Rational Software, Kruchten became a Professor of Software Engineering at the University of British Columbia.

Status · Inspired by Philippe Kruchten’s work — not yet claimed. Are you Philippe Kruchten?

Primary sourceS-01

The Rational Unified Process: An Introduction (3rd ed., Addison-Wesley, 2003)

by Philippe Kruchten

Distinguished Engineer at Rational Software Corporation; inventor of the 4+1 Architectural View Model (IEEE Software, 1995); Professor of Software Engineering, University of British Columbia.

Read the original ↗

Citationinformit.com

In the build queue

Be first to run it.

Rational Unified Process is being built right now. Leave your email and we’ll tell you the moment it goes live.

Notify meEmail

At launchMy team is in Construction but our architecture keeps changing — we're still arguing about service boundaries and the database schema has changed three times. Have we actually passed the Lifecycle Architecture Milestone, or are we still in Elaboration?