The Unified Software Development Process

What is it?

The Unified Process (UP), or Unified Software Development Process, is a iterative and incremental software development framework from which a customized process can be defined. The framework contains many components and has been modified a number of times to create several variations. The most popular variations include the Rational Unified Process (RUP) and the Open Unified Process (OpenUP). The framework has several key characteristics which seem to carry across all variations (as far as I can tell).

The key characteristics of the Unified Process are: [5]


In general, the Unified Process is built around the idea of incorporating six specific best practices into a configurable process framework. Those best practices are:

  1. Develop Software Iteratively
  2. Manage Requirements
  3. Use Component-based Architectures
  4. Visually Model Software
  5. Verify Software Quality
  6. Control Changes to Software


Much of the concepts in the Unified Process began with work Ivar Jacobson did at Ericsson in the 1960's. Jacobson went out on his own in 1987, codified his earlier work into what became the Objectory Process, and started the Objectory AB company to sell the process. After a number of years further developing the Objectory process, Jacobson released the book Object-Oriented Software Engineering in 1995 which described the Objectory Process in detail.

In 1996 Rational Software acquired the Objectory Process and company.[1] Jacobson worked at Rational and teamed up with Grady Booch and Jim Rumbaugh and together they spent the next several years further developing the Objectory Process (now known as the Rational Objectory Process) and the Unified Method (which later became UML). In 1998, Rational changed the name from the Rational Objectory Process to the Rational Unified Process. However, because RUP was the trademarked property of Rational, further work by the software and academic community usually referred to just the Unified Process in order to avoid trademark issues. And by 1999, the first book to describe the generic Unified Process was written by Jacobson, Booch, and Rumbaugh.

IBM acquired Rational Software in 2003, and in 2005 donated the core of the Rational Process to the Eclipse Foundation open-source community. [7]

There were originally just five Disciplines in the Unified Process, but over the years that has been expanded to where there are now up to nine.


The Components of the Unified Process

The Unified Process framework is made up of the following components:


The disciplines are:

The four phases are:


Each cycle defines a new major version of the software being developed. Each cycle is broken into four different phases, which may have multiple iterations within the phase. Each iteration results in an incremental version of the software. Across the cycles, phases, and iterations; work from different disciplines is undertaken by Workers (think of these as project roles). This work takes the form of specific activities with a discipline that result in specific artifacts (for example, a Create Work Breakdown Structure activity with the Project Management Discipline, which results in a WBS artifact).

Each phase is concluded when a measurable milestone has been reached and is followed by a go / no-go decision by the project team on whether to move forward with the next phase.

It is important to note that although different amounts of work from each discipline may occur in each phase or iteration, work from all disciplines occurs in every phase.

The UP framework is commonly visualized in ways such as the graphic below (from the Wikimedia Commons).

Unified Process - Use Case Diagram    

The Disciplines

Business Modeling

The Business Modelling discipline focuses on efforts to understand the organization, its processes, and the problem domain. The discipline focuses on understanding the following factors and how they may impact or relate to the software being considered: [4]



The requirements discipline in RUP is like the requirements discipline in pretty much every other software process. The main difference is that RUP requirements are highly focused in the form of UML models and Use Cases (both diagrams and descriptions).


Analysis and Design

The Analysis and Design discipline would be better named the Solution Analysis and Design discipline in my opinion. This is because the requirements are analyzed from a solution design perspective, rather than a requirements analysis perspective. Specific activities that are part of this discipline include: [4]



The Implementation discipline consists of coding, unit testing, and integration of the software.



The Testing discipline is focused on quality assurance of the software being released in that cycle or iteration. It includes such activities as: [4]



The Deployment discipline is focused on planning the deployment of, and actually deploying, the software that is being completed that cycle, phase or iteration.  It includes such activities as:[4]


Configuration and Change Management

The Configuration and Change Management discipline is focused on managing change to the project’s work products.  This includes such activities as: [4]


Project Management

The Project Management discipline is focused on standard project management activities such as: [4]



The Environment discipline is focused on supporting the overall project and development efforts through managing environmental factors such as:


The Phases

Inception Phase

The Inception Phase is the part of the framework when the why of the development effort is defined. This includes such activities as:

The milestones (that together comprise the Lifecycle Objectives Milestone) that show completion of the Inception phase are:


Elaboration Phase

The Elaboration Phase is the part of the framework when more detailed analysis and planning are undertaken to better understand the problem domain, develop a more concrete project plan, identify and eliminate the high-risk elements of the effort, and to establish a solid architectural foundation for the software to be developed.  The goal is to develop a "mile wide and inch deep" view of the system to be developed. [2]

The specific activities of this phase include:

The milestones (that together comprise  the Lifecycle Architecture Milestone) that show completion of the Elaboration phase are:


Construction Phase

The Construction Phase is the part of the framework where software development, integration, and testing takes place. Because of the emphasis on component-based architectures and the significant attention paid to the architectural plan in the Inception and Elaboration phases, it should be possible to initiate multiple Construction Phases within a single cycle if the software to be developed is complex enough to support multiple discreet components.

The specific activities of this phase include:

The milestones (that together comprise  the Initial Operational Capability Milestone) that show completion of the Construction phase are:

The outcome of the construction phase should be a product that is ready to put into the hands of end-users in at least a beta release state.


Transition Phase

The Transition Phase of the framework is where the software is deployed to end users and is essentially a broad beta test of the application. Users begin to use the new software, issues are identified and potentially corrected, and any features that were delayed are finished and deployed. The transition phase can include multiple iterations of the software, including beta releases, bug fixes, and enhancements.

The specific activities of this phase include:

The milestones (that together comprise  the Product Release Milestone) that show completion of the Transition phase are:


Unified Process Variations

In addition to the general Unified Process described above (which also covers the Rational Unified Process), the following are other UP variants I have come across.  The main difference seems to be in the number of Disciplines each defines (some add, some subtract) and in the number and type of Activities and Artifacts.

Agile Unified Process (AUP)

The Agile Unified Process is a simplified version of RUP developed by Scott Ambler. It makes a number of changes to RUP, including: [8]

It is based on the following principles: [8]

You can download the entire Agile Unified Process documentation from Scott Ambler's Ambysoft web site.

Enterprise Unified Process (EUP)

The Enterprise Unified Process is an extension of the Rational Unified Process that was also developed by Scott Ambler. The main differences take the form of new phases and new disciplines.[9]

The three new phases are:

The new Disciplines are: [9]

Essential Unified Process (EssUP)

The Essential Unified Process was created by Ivar Jacobson as a refined of RUP with the idea of making the Disciplines (now called Practices) user selectable from a library of options so that the user can create a tailored process that meets their needs best. This was considered an improvement because the Disciplines in RUP are all intertwined and cannot be extracted from the overall framework. Jacobson took Practices from RUP, CMMI, and various agile development processes and included them within the option of EssUP.

This separation was undertaken in order to better support aspect-oriented thinking, or what Jacobson called Separation of Concerns. The Practices were grouped into eight groupings, with five Development and Technical Practices, and three Social Engineering, Process, and other Supported Practices. These were:

Development and Technical Practices

Social Engineering, Process and other Supporting Practices

The EssUP web pages are no longer present on Jacobson's web site and development seems to have stopped.

Open Unified Process (OpenUP)

OpenUP is based on the core of the Rational Unified Process that was donated by IBM to the Eclipse Foundation. That core was called the Basic Unified Process (BUP) by IBM, but was evolved into OpenUP. Most of the optional parts of RUP were excluded and some elements were merged. [12] One of the main differences is that the Eclipse Foundation starts with an Agile core and then adds the framework on top. The goal was to refine RUP so that it included many of the best practices from the agile world, and so that it was highly suitable for small teams (3-6 people) and small projects (3-6 months effort). [12] However, the OpenUP process can be extended to make it usable in larger projects.

OpenUP is based on four mutually supporting core principles.  These are: [15]


Because of it's design, OpenUp is thought to address the following issues: [14]

The entire OpenUP process is fully detailed and publicly accessible via the Eclipse Foundation web site. You can even download and customize the framework using the Eclipse Method Composer tool. [15]


Final Notes



  1. Wikipedia page:  IBM Rational Unified Process
  2. White Paper:  Rational Unified Process - Best Practices for Software Development Teams.  Rational Software White Paper TP026B.  November 2001.
  3. White Paper:  A Manager's Introduction to the Rational Unified Process.  By Scott Ambler.  2005.
  4. Web Page:  Enterprise Business Modelling, by Scott Ambler.
  5. Wikipedia page: Unified Process
  6. Article:  Overview of the Unified Process.  By Kendall Scott.  On the InformIT web site.  28 December 2001.
  7. Press Release:  IBM to Contribute Software Development Blueprints to Open Source Community.  12 October 2005.
  8. Web Page:  The Agile Unified Process (AUP).  By Scott Ambler.
  9. Web Page:  Enterprise Unified Process.  By Scott Ambler.
  10. Web Page: The EUP Production Phase.  By Scott Ambler.
  11. Web Page: Enterprise Agile - Lifecycle Phases.  By Scott Ambler.
  12. Web Page (archived):  The Essential Unified Process - An Introduction.  By Ivar Jacobson.
  13. Wikipedia page:  OpenUP
  14. Article:  OpenUP - The Best of Two Worlds.  By Bjorn Gustafsson.  Methods & Tools Magazine.  Spring 2008.
  15. Wiki:  The OpenUP Wiki.  On the Eclipse Foundation website.

Related Resources