Jump to content

Rational unified process

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by 82.41.206.69 (talk) at 13:02, 25 May 2003 (A brief abstract outline of the Rational Unified Process). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

(diff) ← Previous revision | Latest revision (diff) | Newer revision → (diff)

The Rational Unified Process (RUP) is a software design methodology describing how to effectively deploy software using commercially proven techniques. It is a heavyweight process (also described as a Thick methodology) and hence more applicable to larger Software Development teams working on large projects.

(Please note: this article has been abstracted from the RUP as defined by the Rational Corporation who are responsible for it’s development. It also attempts to be concise, outlining the reasoning behind the RUP as opposed to the specific methodologies used)

Competing methods within the field of software engineering include:

The RUP defines the following guidelines and templates for team members to follow during a product’s lifecycle.

  1. Develop Software Iteratively
  2. Manage Requirements
  3. Use Component Based Architecture
  4. Visually model software
  5. Verify software quality
  6. Control changes to software

Develop Software Iteratively

Given the time it takes to develop large sophisticated software systems it not possible to define the problem and build the solution in a single step. Requirements will often change throughout a projects development, due to architectural constraints, customer’s needs or a greater understanding of the original problem. Iteration allows greater understanding of a project through successive refinements and addresses a projects highest risk items at every stage of it’s lifecycle. Ideally each iteration ends up with an executable release – this helps reduce a projects risk profile, allows greater customer feedback and help developers stay focused.

Manage Requirements

A documentation framework is essential for any large project and hence the RUP describes how to document functionality, constraints, design decisions and business requirements.

Use Case and Scenarios proscribed in the process have been found very effective at capturing functional requirements, providing coherent threads throughout the development and deployment of the system.

Use component based architecture

Component Based Architecture creates a system that is easily extensible, promotes software reuse and intuitively understandable. A component often relates to an object in Object Orientated Programming.

The RUP provides a systematic way to build this kind of system, focusing on producing an early executable architecture before committing full scale resources on a project.

These components are often assembled within existing infrastructures such as CORBA and COM.

Visually Model Software

Abstracting your programming from it’s code and representing it using graphical building blocks is an effective way to get an overall picture of a solution. It can also allow less technically competent individuals who may have a better understanding of the problem to have a greater input.

Unified Modelling Language (UML) is the industry standard way of representing projects and is hence usually used by the RUP.

Verify Software Quality

Quality Assessment is the most common failing point of all software projects, often an afterthought in such projects and even handled by a different team. The RUP assists in planning quality control and assessment built into the entire process involving all members of a team.

Control Changes to Software

In all software projects change is inevitable, the RUP defines methods to control track and monitor changes. As a seemingly small change can affect applications in entirely unpredictable ways this is essential for a successful project. The RUP also defines “secure workspaces” allowing a programmer to be guaranteed that changes in another system will not affect his system. This ties in heavily with Component based architectures.

So far these guidelines are general, to be adhered to throughout a projects lifecycle. To capture the time dimension of a project the RUP also divides a project into four distinct phases:

  1. Inception
  2. Elaboration
  3. Construction
  4. Transition

...