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]

• It is an iterative and incremental development framework
• It is architecture-centric with major work being done to define and validate an architectural design for most coding is done
• It is risk-focused and emphasizes that highest-risk factors be addressed in the earliest deliverables possible
• It is use-case and UML model driven with nearly all requirements being documented in one of those forms

 

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

 

---

History

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:

• Cycles
• Phases
• Iterations
• Disciplines  (also known as Workflows)
• Activities
• Artifacts
• Workers

 

The disciplines are:

• Business Modeling
• Requirements
• Analysis and Design
• Implementation
• Testing
• Deployment
• Configuration and Change Management
• Project Management
• Environment

The four phases are:

• Inception phase
• Elaboration phase
• Construction phase
• Transition phase

 

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

   

---

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]

• Enterprise business rules
• Enterprise business process model
• Enterprise domain model
• Enterprise mission statement
• Enterprise vision
• Organization model

 

Requirements

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]

• Understanding and analyzing the requirements for the system
• Defining a candidate architecture for a system
• Constructing a proof-of-concept or prototype to validate a candidate architecture
• Design of components, services, and/or modules
• Design of interfaces (network, user, and databases)

 

Implementation

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

 

Testing

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

• Planning test efforts
• Creating test cases
• Running tests
• Reporting defects

 

Deployment

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]

• Planning the deployment
• Developing support and operations materials
• Planning alpha, beta, and pilot testing efforts
• Deploying the software
• Training end users
• Managing acceptance testing efforts

 

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]

• Managing change requests
• Setting up the Change Management process and environment
• Planning configuration control
• Monitoring and reporting the configuration status
• Managing baselines and releases

 

Project Management

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

• Managing project staff
• Stakeholder coordination and management
• Managing project risks
• Project estimating, planning, and scheduling
• Iteration planning
• Project initiation and close-out

 

Environment

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

• Processes
• Standards
• Tools (hardware, software, etc.)

 

---

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:

• Defining the business case
• Creating a vision document with core requirements, features, and constraints
• Creating an initial risk assessment
• Creating early use cases (10-20% complete, mostly use-case models)
• Creating a initial project plan
• And the creation of one or more prototypes (especially architectural prototypes)

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

• Stakeholder agreement on business case, scope, and project cost and schedule estimates
• Agreement that the content of the primary use cases is an accurate representation of what the software will deliver (at a high level)
• That the final prototypes are sufficient indications of the correct future development goals

 

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 identification of all actors and use cases, with most use cases having been defined to at least 80% completion (use-case descriptions rather than models)
• Supplementary requirements detailing the non-functional requirements and any requirements not related to a use case are completed
• A Software Architecture Description has been completed
• The business case and risk lists have been updated with higher-confidence information
• The project and development plans have been defined to at least a level that shows all iterations and the evaluation criteria for each iteration
• An executable architecture prototype has been created and approved for use (this may involve creating more than one)
• A preliminary user manual has been created (optional)

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

• The product vision is stable and approved
• The product architecture is stable and approved
• The executable architecture prototype shows that the major risk elements have been identified and credibly resolved
• The project and development plans sufficiently detailed, accurate, and credible
• All stakeholders agree that the vision can be achieved is the project and development plans are executed with the architecture specified

 

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 software is built, integrated, and tested
• The user manuals have been created (or updated)
• The details of the software developed are documented and ready to be provided to end users or support staff (including changes, etc.)

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

• The software product is stable and mature enough to be deployed to end users
• All stakeholders are ready to transition to the new / updated software
• Actual versus planned expenditures are still acceptable enough to move forward with the project

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:

• beta testing or user acceptance testing by end users to validate the new software against user expectations
• Parallel operation with legacy systems (if in existence) that will be replaced
• Operational databases are converted (if necessary)
• Users and maintainers of the software are fully trained
• The software is fully rolled-out

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

• Users are satisfied with the software
• Actual versus planned expenditures are still acceptable enough to move forward with the project

 

---

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 adds agile techniques such as test driven development (TDD), Agile Model Driven Development (AMDD), agile change management, and database refactoring
• It combines the Business Modeling, Requirements, and Analysis & Design disciplines from UP into a single Modeling discipline
• It re-names the Configuration and Change Management discipline to "Configuration Management"

It is based on the following principles: ^[8]

• Your staff knows what they're doing:  People aren't going to read detailed process documentation, but they will want some high-level guidance and/or training from time to time. The AUP product provides links to many of the details, if you're interested, but doesn't force them upon you.

• Simplicity: Everything is described concisely using a handful of pages, not thousands of them.
• Agility: The Agile UP conforms to the values and principles of the Agile Alliance.
• Focus on high-value activities: The focus is on the activities which actually count, not every possible thing that could happen to you on a project.
• Tool independence: You can use any toolset that you want with the Agile UP.  My suggestion is that you use the tools which are best suited for the job, which are often simple tools or even open source tools.

• You'll want to tailor this product to meet your own needs: The AUP product is easily tailorable via any common HTML editing tool. You don't need to purchase a special tool, or take a course, to tailor the AUP.

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:

• Pre-Inception: This is not called out as an explicit phase in the EUP diagram, but it is in the phases description.  This phase focuses on activities such as Portfolio Planning, Staff Allocation, Enterprise Architecture Modelling, and similar efforts. ^[11]
• Production: The goal of the Production phase is to keep systems useful and productive after they have been deployed to the user community. ^[10]
• Retirement: The focus of the Retirement phase is the successful removal of a system from production. ^[11]

The new Disciplines are: ^[9]

• Operations and Support
• Enterprise Business Modeling
• Portfolio Management
• Enterprise Architecture
• Strategic Reuse
• People Management
• Enterprise Administration
• Software Process Improvement

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

• Iterative Essentials
• Architecture Essentials
• Use-Case Essentials
• Component Essentials
• Model Essentials

Social Engineering, Process and other Supporting Practices

• Product Essentials
• Process Essentials
• Team Essentials

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]

• Balance competing priorities to maximize stakeholder value:  Promote practices that allow project participants and stakeholders to develop a solution that maximizes stakeholder benefits, and is compliant with constraints placed on the project.
• Collaborate to align interests and share understanding:  Promote practices that foster a healthy team environment, enable collaboration and develop a shared understanding of the project.
• Focus on the architecture early to minimize risks and organize development:  Promote practices that allow the team to focus on architecture to minimize risks and organize development.
• Evolve to continuously obtain feedback and improve:  Promote practices that allow the team to get early and continuous feedback from stakeholders, and demonstrate incremental value to them.

 

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

• A shared vision is created in the inception phase:   The stakeholders’ key needs and features are captured in the Vision document. It describes high-level requirements and design constraints, and gives an overview of the system’s functional scope.
• All project work is driven by use cases and other requirements:   The Work Items List constitutes a laundry list of features, requirements and change requests raised on the system.
• An executable architecture is created in the elaboration phase:  The Architecture Notebook along with the other development work products represent a base-lined executable architecture that demonstrates how the system supports the key scenarios and constraints, and which serves as basis for the ensuing construction phase. It is worth noting that architecture is not a separate thing – it is the underlying organization and qualities of the system being built – and the executable architecture is just a state of the underlying design, implementation and test products. To create the right focus on the architectural concerns we prioritize those use cases and other requirements during the elaboration phase that involve the highest technical risks, as identified in the risk list.
• Each iteration is planned just in time, and the project team is involved in the detailed estimation and planning activities:  For each iteration the Iteration Plan is populated with the highest-prioritized work items from the work items list and risk list. The team is responsible for identifying and estimating tasks for each work item.
• Risks are pro-actively identified and mitigated: The Risk List identifies a prioritized list of risks that are associated with the project. All critical risks have been removed at the end of the elaboration phase.

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

• While the Unified Process is described as a customizable framework, if you follow the detailed activities that are often specified (especially in the massive RUP library from IBM) it can be very documentation heavy. However, as a framework you have the option of skipping nearly all of those and customizing your implementation to your needs.
• According to Scott Ambler, typical RUP projects spend approximately 10% of time in Inception, 25% in Elaboration, 55% in Construction and 10% in Transition, although these figures vary from organization to organization and even from project to project.^[3]

 

---

References

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  http://en.wikipedia.org/wiki/Basic_Unified_Process
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

• Wikipedia page:  Enterprise Unified Process
• Web Page:  History of the Unified Process.  By Scott Ambler.
• Article:  Understanding the Unified Process.  By Sinan Si Alhir.  Methods & Tools magazine.  Spring 2002.
• Article:  An Introduction to the Rational Unified Process.  2002.
• Article:  The Essential Unified Process.  By Ivar Jacobson, Pan Wei Ng, and Ian Spence.  Dr. Dobbs Journal.  2 August 2006.
• There is a nice process flow chart of the Rational Unified Process on the RVS Infotech web site.  I don't know the copyright status of the graphic so I will just provide a link to it here.