IBM Rational Unified Process

The Rational Unified Process (RUP) is an iterative software development process framework created by the Rational Software Corporation, a division of IBM since 2003. RUP is not a single concrete prescriptive process, but rather an adaptable process framework, intended to be tailored by the development organizations and software project teams that will select the elements of the process that are appropriate for their needs.

Contents [hide] 1 History 2 Rational Unified Process topics 2.1 RUP building blocks 2.2 Four project lifecycle phases 2.2.1 Inception phase 2.2.2 Elaboration phase 2.2.3 Construction phase 2.2.4 Transition phase 2.3 Six engineering disciplines 2.4 Three supporting disciplines 2.4.1 Phase plan 2.4.2 Iteration plan 2.4.3 Work Product (Artifact) 2.5 The IBM Rational Method Composer product 2.6 Certification 2.7 Six Best Practices 3 Other frameworks 3.1 Refinements and variations 3.2 Competing frameworks and methodologies 4 See also 5 References 6 Further reading 7 External links

History

The Rational Unified Process (RUP) is a software process product, originally developed by Rational Software, which was acquired by IBM in February 2003. The product includes a hyperlinked knowledge base with sample artifacts and detailed descriptions for many different types of activities. RUP is included in the IBM Rational Method Composer (RMC) product which allows customization of the process.
By 1997, Rational had acquired Verdix, Objectory, Requisite, SQA, Performance Awareness, and Pure-Atria. Combining the experience base of these companies led to the articulation of seven best practices for modern software engineering:

1. Develop iteratively, with risk as the primary iteration driver
2. Manage requirements
3. Employ a component-based architecture
4. Model software visually
5. Continuously verify quality
6. Control changes
7. Customization

These best practices both drove the development of Rational's products, and were used by Rational's field teams to help customers improve the quality and predictability of their software development efforts. To make this knowledge more accessible, Philippe Kruchten, a Rational techrep, was tasked with the assembly of an explicit process framework for modern software engineering. This effort employed the HTML-based process delivery mechanism developed by Objectory. The resulting "Rational Unified Process" (RUP) completed a strategic tripod for Rational:

• a tailorable process that guided development
• tools that automated the application of that process
• services that accelerated adoption of both the process and the tools.

Rational Unified Process topics

RUP building blocks

RUP is based on a set of building blocks, or content elements, describing what are to be produced, the necessary skills required and the step-by-step explanation describing how specific development goals are achieved. The main building blocks, or content elements, are the following:

• Roles (who) – A Role defines a set of related skills, competences, and responsibilities.
• Work Products (what) – A Work Product represents something resulting from a task, including all the documents and models produced while working through the process.
• Tasks (how) – A Task describes a unit of work assigned to a Role that provides a meaningful result.

Within each iteration, the tasks are categorized into nine disciplines: six "engineering disciplines" (Business Modeling, Requirements, Analysis and Design, Implementation, Test, Deployment) and three supporting disciplines (Configuration and Change Management, Project Management, Environment).

Four project lifecycle phases

RUP phases and disciplines.

The RUP has determined a project lifecycle consisting of four phases. These phases allow the process to be presented at a high level in a similar way to how a 'waterfall'-styled project might be presented, although in essence the key to the process lies in the iterations of development that lie within all of the phases. Also, each phase has one key objective and milestone at the end that denotes the objective being accomplished.

Inception phase

The primary objective is to scope the system adequately as a basis for validating initial costing and budgets. In this phase the business case which includes business context, success factors (expected revenue, market recognition, etc), and financial forecast is established. To complement the business case, a basic use case model, project plan, initial risk assessment and project description (the core project requirements, constraints and key features) are generated. After these are completed, the project is checked against the following criteria:

• Stakeholder concurrence on scope definition and cost/schedule estimates.
• Requirements understanding as evidenced by the fidelity of the primary use cases.
• Credibility of the cost/schedule estimates, priorities, risks, and development process.
• Depth and breadth of any architectural prototype that was developed.
• Establishing a baseline by which to compare actual expenditures versus planned expenditures.

If the project does not pass this milestone, called the Lifecycle Objective Milestone, it can either be cancelled or it can repeat this phase after being redesigned to better meet the criteria.

Elaboration phase

The primary objective is to mitigate the key risk items identified by analysis up to the end of this phase. The elaboration phase is where the project starts to take shape. In this phase the problem domain analysis is made and the architecture of the project gets its basic form.
This phase must pass the Lifecycle Architecture Milestone by the following criteria:

• A use-case model in which the use-cases and the actors have been identified and most of the use-case descriptions are developed. The use-case model should be 80% complete.
• A description of the software architecture in a software system development process.
• An executable architecture that realizes architecturally significant use cases.
• Business case and risk list which are revised.
• A development plan for the overall project.
• Prototypes that demonstrably mitigate each identified technical risk.

If the project cannot pass this milestone, there is still time for it to be canceled or redesigned. After leaving this phase, the project transitions into a high-risk operation where changes are much more difficult and detrimental when made.
The key domain analysis for the elaboration is system architecture.

Construction phase

The primary objective is to build the software system. In this phase, the main focus is on the development of components and other features of the system being designed. This is the phase when the bulk of the coding takes place. In larger projects, several construction iterations may be developed in an effort to divide the use cases into manageable segments that produce demonstrable prototypes.
This phase produces the first external release of the software. Its conclusion is marked by the Initial Operational Capability Milestone.

Transition phase

The primary objective is to 'transition' the system from development into production, making it available to and understood by the end user. The activities of this phase include training of the end users and maintainers and beta testing of the system to validate it against the end users' expectations. The product is also checked against the quality level set in the Inception phase.
If all objectives are met, the Product Release Milestone is reached and the development cycle ends.

Six engineering disciplines

This article may require copy-editing for grammar, style, cohesion, tone or spelling. You can assist by editing it. (September 2009)

Business modeling discipline

Business modeling explains how to describe a vision of the organization in which the system will be deployed and how to then use this vision as a basis to outline the process, roles and responsibilities.

Organizations are becoming more dependent on IT systems, making it imperative that information system engineers know how the applications they are developing fit into the organization. Businesses invest in IT when they understand the competitive advantage and value added by the technology. The aim of business modeling is to first establish a better understanding and communication channel between business engineering and software engineering. Understanding the business means that software engineers must understand the structure and the dynamics of the target organization (the client), the current problems in the organization and possible improvements. They must also ensure a common understanding of the target organization between customers, end users and developers.

Requirements discipline

This discipline explains how to elicit stakeholder requests and transform them into a set of requirements work products that scope the system to be built and provide detailed requirements for what the system must do.

Analysis and design discipline

The goal of analysis and design is to show how the system will be realized. The aim is to build a system that

• Performs — in a specific implementation environment — the tasks and functions specified in the use-case descriptions.
• Fulfills all its requirements.
• Is easy to change when functional requirements change.

Design results in a design model and analysis optionally an analysis model. The design model serves as an abstraction of the source code; that is, the design model acts as a 'blueprint' of how the source code is structured and written. The design model consists of design classes structured into packages and subsystems with well-defined interfaces, representing what will become components in the implementation. It also contains descriptions of how objects of these design classes collaborate to perform use cases.

Implementation discipline

The purposes of implementation are:

• To define the organization of the code, in terms of implementation subsystems organized in layers.
• To implement classes and objects in terms of components (source files, binaries, executables, and others).
• To test the developed components as units.
• To integrate the results produced by individual implementers (or teams) into an executable system.

Systems are realized through implementation of components. The process describes how to reuse existing components, or implement new components with well defined responsibility, making the system easier to maintain, and increasing the possibilities to reuse.

Test discipline

The purposes of the Test discipline are:

• To verify the interaction between objects.
• To verify the proper integration of all components of the software.
• To verify that all requirements have been correctly implemented.
• To identify and ensure that defects are addressed prior to the deployment of the software.
• Ensure that all the defects are fixed, retested, and closed.

The Rational Unified Process proposes an iterative approach, which means that you test throughout the project. This allows you to find defects as early as possible, which radically reduces the cost of fixing the defect. Tests are carried out along four quality dimensions: reliability, functionality, application performance, and system performance. For each of these quality dimensions, the process describes how you go through the test lifecycle of planning, design, implementation, execution, and evaluation.

Deployment discipline

The purpose of deployment is to successfully produce product releases, and to deliver the software to its end users. It covers a wide range of activities including producing external releases of the software, packaging the software and business application, distributing the software, installing the software, and providing help and assistance to users. Although deployment activities are mostly centered around the transition phase, many of the activities need to be included in earlier phases to prepare for deployment at the end of the construction phase. The Deployment and Environment workflows of the Rational Unified Process contain less detail than other workflows.

Three supporting disciplines

Environment discipline 

The environment discipline focuses on the activities necessary to configure the process for a project. It describes the activities required to develop the guidelines in support of a project. The purpose of the environment activities is to provide the software development organization with the software development environment - both processes and tools - that will support the development team. If the users of RUP do not understand that RUP is a process framework, they may perceive it as a weighty and expensive process. However a key concept within RUP was that the RUP process could and often should itself be refined. This was initially done manually, ie by writing a "Development case" document that specified the refined process to be used. Later the IBM Rational Method Composer product was created to help make this step simpler, so process engineers and project managers could more easily customize the RUP for their project needs. Many of the later variants of RUP, including OpenUP/Basic, the lightweight and open source version of RUP, are now presented as separate processes in their own right, and cater for different types and sizes of projects and trends and technologies in software development. Historically, as the RUP is often customized for each project by a RUP process expert, the project's overall success can be somewhat dependent on the abilities of this one person.

Configuration and Change management discipline 

The Change Management discipline in RUP deals with three specific areas: configuration management, change request management, and Status and measurement management.

• Configuration management: Configuration management is responsible for the systematic structuring of the products. Artifacts such as documents and models need to be under version control and these changes must be visible. It also keeps track of dependencies between artifacts so all related articles are updated when changes are made.
• Change request management: During the system development process many artifacts with several versions exist. CRM keeps track of the proposals for change.
• Status and measurement management: Change requests have states such as new, logged, approved, assigned and complete. A change request also has attributes such as root cause, or nature (like defect and enhancement), priority etc. These states and attributes are stored in database so useful reports about the progress of the project can be produced. Rational also has a product to maintain change requests called ClearQuest. This activity has procedures to be followed.

Project management discipline 

The Project management discipline and project planning in the RUP occur at two levels. There is a coarse-grained or Phase plan which describes the entire project, and a series of fine-grained or Iteration plans which describe the iterations. This discipline focuses mainly on the important aspects of an iterative development process: Risk management, Planning an iterative project, through the lifecycle and for a particular iteration, and Monitoring progress of an iterative project, metrics. However, this discipline of the RUP does not attempt to cover all aspects of project management.

For example, it does not cover issues such as:

• Managing people: hiring, training, etc.
• Managing budget: defining, allocating, etc.
• Managing contracts: with suppliers, with customers, etc.

The project management discipline contains a number of other Plans and Artifacts that are used to control the project and monitoring its performance. Such Plans are:

• The Phase Plan (The Software Development Plan)
• The Iteration Plan

Phase plan

Each Phase is treated as a project, controlled and measured by the Software Development Plan which is grouped from a subset of monitoring plans:

• The Measurement Plan defines the measurement goals, the associated metrics, and the primitive metrics to be collected in the project to monitor its progress.
• The Risk Management Plan details how to manage the risks associated with a project. It details the risk management tasks that will be carried out, assigned responsibilities, and any additional resources required for the risk management activity. On a smaller scale project, this plan may be embedded within the Software Development Plan.
• The Risk list is a sorted list of known and open risks to the project, sorted in decreasing order of importance and associated with specific mitigation or contingency actions.
• The Problem Resolution Plan describes the process used to report, analyze, and resolve problems that occur during the project.
• The Product Acceptance Plan describes how the customer will evaluate the deliverable artifacts from a project to determine if they meet a predefined set of acceptance criteria. It details these acceptance criteria, and identifies the product acceptance tasks (including identification of the test cases that need to be developed) that will be carried out, and assigned responsibilities and required resources. On a smaller scale project, this plan may be embedded within the Software Development Plan.

Iteration plan

The iteration plan is a fine-grained plan with a time-sequenced set of activities and tasks, with assigned resources, containing task dependencies, for the iteration.
There are typically two iteration plans active at any point in time.

• The current iteration plan is used to track progress in the current iteration.
• The next iteration plan is used to plan the upcoming iteration. This plan is prepared toward the end of the current iteration.

To define the contents of an iteration you need:

• the project plan
• the current status of the project (on track, late, large number of problems, requirements creep, etc.)
• a list of scenarios or use cases that must be completed by the end of the iteration
• a list of risks that must be addressed by the end of the iteration
• a list of changes that must be incorporated in the product (bug fixes, changes in requirements)

These lists must be ranked. The objectives of an iteration should be aggressive so that when difficulties arise, items can be dropped from the iterations based on their ranks.
Therefore there is a set of supported Artifacts that help in measuring and building each iteration plan.

Work Product (Artifact)

IBM has replaced the term "Artifact" with the term "work product". The work products used are:

• The Iteration Assessment captures the result of an iteration, the degree to which the evaluation criteria were met, lessons learned, and changes to be done.
• The project measurements is the project's active repository of metrics data. It contains the most current project, resources, process, and product measurements at the primitive and derived level.
• The periodic Status Assessment provides a mechanism for managing everyone's expectations throughout the project lifecycle to ensure that the expectations of all parties are synchronized and consistent.
• The work order is the Project Manager's means of communicating with the staff about what is to be done and when it is to be completed. It becomes an internal contract between the Project Manager and those assigned responsibility for completion.
• The Issues List is a way to record and track problems, exceptions, anomalies, or other incomplete tasks requiring attention.

The IBM Rational Method Composer product

The IBM Rational Method Composer product is a tool for authoring, configuring, viewing, and publishing processes. See IBM Rational Method Composer and an open source version Eclipse Process Framework (EPF) project for more details.

Certification

This article may require copy-editing for grammar, style, cohesion, tone or spelling. You can assist by editing it. (September 2009)

In January 2007, the new RUP certification examination for IBM Certified Solution Designer - Rational Unified Process 7.0 was released which replaces the previously called IBM Rational Certified Specialist - Rational Unified Process.^[1] The new examination will not only test knowledge related to the RUP content but also to the process structure elements.^[2]
To pass the new RUP certification examination, a person must take IBM's Test 839: Rational Unified Process v7.0. You are given 75 minutes to take the 52 question exam. The passing score is 62%.^[3]

Six Best Practices

Six Best Practices as described in the Rational Unified Process is a paradigm in software engineering, that lists six ideas to follow when designing any software project to minimize faults and increase productivity . These practices are:^[4][5]

Develop iteratively 

It is best to know all requirements in advance; however, often this is not the case. Several software development processes exist that deal with providing solution on how to minimize cost in terms of development phases.

Manage requirements 

Always keep in mind the requirements set by users.

Use components 

Breaking down an advanced project is not only suggested but in fact unavoidable. This promotes ability to test individual components before they are integrated into a larger system. Also, code reuse is a big plus and can be accomplished more easily through the use of object-oriented programming.

Model visually 

Use diagrams to represent all major components, users, and their interaction. "UML", short for Unified Modeling Language, is one tool that can be used to make this task more feasible.

Verify quality 

Always make testing a major part of the project at any point of time. Testing becomes heavier as the project progresses but should be a constant factor in any software product creation.

Control changes 

Many projects are created by many teams, sometimes in various locations, different platforms may be used, etc. As a result it is essential to make sure that changes made to a system are synchronized and verified constantly. One tool used for this is Concurrent Versions System.

Other frameworks

Refinements and variations

• Unified Process - The generic Unified Process, and ...
• Open Unified Process (OpenUP) - An open source software development process, created as part of the Eclipse Process Framework (EPF) project.

Simplified subsets:

• Agile Unified Process - a simplified RUP, featuring "Test Driven development"
• Essential Unified Process (EssUP) - a model that simplifies The Agile Unified Process
• OpenUP/Basic - The most agile and lightweight form of OpenUP, targets small and collocated teams interested in agile and iterative development.
• UPEDU - The Unified Process for Education - a subset of RUP for presenting within the education system

Expanded supersets:

• Enterprise Unified Process - has wider scope, including software purchase, production operations and support, product retirement and replacement etc.

Supporting Specific Commercial Development Products

• IBM Tivoli Unified Process (ITUP)
• Oracle Unified Method

Competing frameworks and methodologies

The referenced methodologies and / or frameworks below do not necessarily compete with RUP on all fronts, but do so to differing degrees

• Cleanroom Software Engineering
• Dynamic Systems Development Method (DSDM)
• ICONIX Process is a lightweight, agile subset of the RUP practices
• Extreme Programming
• Microsoft Solutions Framework (MSF)
• Oracle Unified Method (OUM)
• TenStep Project Management Process
• OpenUP is an OpenSource lightweight agile version of RUP supported by IBM Rational, Number Six Software and others
• Personal Software Process (PSP)
• Scrum