Rational Unified Process

Kamphol Wipawayangkool

University of Houston – Clear Lake

ABSTRACT

This is a research paper about the Rational Unified Process (RUP), an approach to develop a system. With iterations in each phase of the process, the RUP provides more advantages than the traditional waterfall process. The paper covers the overview of the RUP.

Keywords

Rational Unified Process (RUP), Waterfall Model, Iteration, Unified Modeling Language (UML)

1INTRODUCTION

The RUP is a software engineering process. It guides a development team in an organization how to assign tasks and responsibilities. Rather than focusing on the production of large amount of paper documents, the RUP focuses on the development and maintenance of models—semantically rich representations of the software system under development. Nowadays, the RUP is the appropriate approach to a guide for how to use the Unified Modeling Language (UML) effectively. The UML is an industry-standard language that allows us to communicate requirements, architectures and designs clearly.

2PROCESS OVERVIEW

The process can be illustrated in two axes – The first is the horizontal axis that represents time and the dynamic aspect of the process, and it is expressed in terms of cycles, phases, and iterations. The other is the vertical axis that represents the static aspect of the process: how it is described in terms of activities, artifacts, workers and workflows.

3DYNAMIC ASPECT

In RUP, the software lifecycle is broken into cycles, and each cycle works on a new generation of the system. One cycle has four consecutive phases:

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

Inception Phase

The purpose of inception phase is to have an initial business case, and defined concept and scope of the system. The business case includes success criteria, risk assessment, estimate of the resources needed, and a phase plan focusing on the criteria to accept whether the system should be passed to the next phase. The deliverables of this phase are vision document, use-case model, iteration plan, and initial business case.

At the end of this phase, the criteria for evaluation are about the scope definition and credibility of cost and schedule estimates, and risks.

Elaboration Phase

The purpose of elaboration phase is to analyze the problems, establish a sound architectural foundation, develop the project plan, and eliminate the highest risk elements of the project. This phase ensures that architectures, requirements, and plans are stable enough, and risks are sufficiently mitigated so that the cost and schedule of the entire of the development can be determined. Arguably, this phase is the most critical of all phases. The deliverables of this phase are a software architecture description, a revised business case, a revised risk lists, a more-completed use-case model, iteration plans, and a development plan for the overall project.

At the end of this phase, the criteria for evaluation are about the stableness of the architecture, vision, and development plan. In addition, the actual expenditure must be determined against the planned expenditure whether it is acceptable.

Construction Phase

All remaining components and application features are implemented and integrated into the system. All features are completely tested. The outcome of this phase is a product ready to deliver into hands of users. In addition, it consists of the user manuals and description of the current release.

At the end of this phase, the release of the system is often called a beta release. The main evaluation is the maturity of the system to be used in the hands of users.

Transition Phase

The purpose of this phase is to transition the system to the user community by focusing on the activities to put the system into the hands of the users. After given to users, issues or problems typically arise. Therefore, the new and corrected releases must be developed. The activities include several iterations, fixed, and enhanced releases. More importantly, user feedback should be concerned for product configuring, installation, and usability issues.

The primary evaluation is whether the users are satisfied. In addition, the actual and planned expenditures must be determined whether it is acceptable.

Iteration

Each phase in the RUP can be broken into iterations. The essence of iteration is to repeat the sequence to yield results successively closer to the required product. Iteration is a complete development loop resulting in a release of an executable product, which grows significantly from iteration to iteration to become the final system.

Compared to the traditional waterfall process, the iteration of RUP has more advantages as the following:

  • Risks are mitigated earlier
  • Better overall quality of the system
  • Allow for changes, and change is more manageable
  • Continuous integration
  • Higher level of reuse
  • The project team can learn along the way of development

4STATIC ASPECT

The four modeling elements in the RUP are:

  • Workers (who) defines the behavior and responsibilities of an individual
  • Activities (how) is a unit of work an individual in that role may be asked to do
  • Artifacts (what) is a piece of information that is produced or used by a process
  • Workflows (when) is a sequence of activities that produces a result of observable value

Core Workflows

Business Modeling

RUP uses business uses cases to document business processes. It assures a common understanding among all stakeholders of what and how business process needs to be supported in the organization.

Requirements

The goal is to describe what the system should do and allow the developer and the users to agree on that description. Use cases are identified, representing the behavior of the system. Use cases functions as a unifying thread throughout the system development cycle.

Analysis and Design

The goal is to show how the system will be realized in the implementation phase. Analysis and design results in a design model, and optionally an analysis model. The design model serves as an abstraction or blueprint of the source code. The design activities center on the notion of the architecture. The architecture also increases the quality of any model built during the system development.

Implementation

The purpose is to define the organization of code, implement classes and objects in terms of components, test the developed components as units, and to integrate the subsystem into an executable system. In addition, the RUP describes how to reuse or create newly components.

Test

Given the iteration approach throughout each phase in the RUP, the defects are likely to be found as early as possible.

Deployment

The goal is to produce the system release successfully, and deliver it to the users. It covers such activities as producing the external release, installing software, providing help to users. This workflow contains less detail than other workflows.

Project Management

This workflow focuses on mostly on the iteration of the development process. It provides a framework for managing risk, guidelines for developing a system. It will remarkably improve the chances of delivering successful system.

Configuration and Change Management

This workflow describes how to control a number of artifacts created by many people in a project. Control helps avoid confusion, and also help keep track version of components and system releases.

Environment

The purpose of this workflow is to provide software development organization with the software development environment – both processes and tools – that are needed to support the team. It focuses on the activities to configure the process, and to develop the guidelines needed to support a project.

REFERENCES

  1. Rational Unified Process: Best Practices for Software Development Teams. Rational Software White Paper TP026B, Rev 11/01. Rational Software, 2001. Retrieved from
  2. Using the Rational Unified Process: Section 3 – Requirements and Iterations. Sample of RUP materials. Fhoton Learning, 2002. Retrieved from
  3. Sample of RUP job aid. Fhoton Learning, 2002. Retrieved from