The Rational Unified Proces Methodology (RUP)

Article by: Ben Janse

Last update: October 20, 2022

The Rational Unified Proces Methodology (RUP): this article explains the Rational Unified Process (RUP) in a practical way.

After reading, you’ll understand this powerful agile software development method. Next to the defintion, also the four phases are being explanied, including the approach and tips.

What is the Rational Unified Proces Methodology (RUP)?

Definition

The Rational Unified Proces Methodology (RUP) is an agile software development method, in which the life cycle of a project, or the development of software, is divided into four phases. Various activities take place during these phases: modelling, analysis and design, implementation, testing and application.

RUP is iterative, meaning repeating; and agile. Iterative because all of the process’s core activities repeat throughout the project.

Methodology

The process is agile because various components can be adjusted, and phases of the cycle can be repeated until the software meets requirements and objectives.

The process, as visualised in the image in this article, should be looked at from two dimensions. Firstly, there is the time dimension, represented by the horizontal axis. The time dimension is expressed in terms of the phases and cycles, iterations, and milestones.

Secondly, the vertical axis is the process dimension. This dimension represents the static aspect of the process and is described in terms of activities, artefacts, workers, and workflow.

The Rational Unified Proces Methodology (RUP) example - Toolshero

Figure 1 – Rational Unified Process flow overview. Read further for the explanation.

Rational Unified Process: time dimension

The time dimension means the dynamic organisation from the process over time. The software’s life cycle is itself divided further into cycles.

Each cycle corresponds to, for example, a period in which a new generation of a product is being worked on. The Rational Unified Process (RUP) divides development into the four consecutive phases:

Inception phase
Elaboration phase
Construction phase
Transition phase

Each phase is finalised with a milestone. A milestone is a point in time where decisions of critical importance must to be made. In order to be able to make those decisions, the objectives must have been accomplished.

For example, a milestone from the first two phases is the progress of the use case. A use case is a description of a system’s behaviour and describes who can do what using a system. This is an important component in the development of software.

As can also be seen in the RUP visualisation, testing already starts in the first phase. Normally, a product will already have to be completed by then. That is because this involves prototypes and test models.

Phase 1: Inception

During the first phase, the basic idea and structure of the project are determined. In this phase, the team meets regularly to determine the project’s necessity, but also its viability and suitability. Viability and suitability also include the expected costs and the means needed to complete the project after the green light has been given.

Depending on the project, the result of the first phase could be:

A vision statement
First use case (20% completed)
Market research results
Financial prognosis
Risk assessment
Project plan
Corporate or business model
Prototypes

The results should then be assessed according to several criteria:

Were all interested parties included and do they all agree?
Are the requirements of the development reliable?
Are the costs credible? What are the priorities and risks?

Phase 2: elaboration

During the elaboration phase, the system’s requirements and its required architecture are assessed and analysed. This is where the project begins to take shape. The objective of the elaboration phase is to analyse products and to lay a foundation for the future architecture. Results of the elaboration phase include:

Use case (80% completed)
Description of the feasible architecture
Project development plan
Prototypes for tackling risks
User manual

Criteria for the results:

Is the architecture stable?
Are important risks being tackled?
Is the development plan sufficiently detailed and accurate?
Do all interested parties agree on the current design?
Are the expenditures acceptable?

Phase 3: construction

In the construction phase of the Rational Unified Process (RUP), the software system is constructed in its entirety. The emphasis is on the development of components and other features of the system.

The majority of coding also takes place in this phase. In this production process, the emphasis is on managing costs and means, as well as ensuring quality. Results from the production phase include:

Fully completed software system
User manual

To be assessed according to:

Is the product stable and complete enough for use?
Are all interested parties/users ready for the transition into the product’s usage?
Are all the expenditures and means still in good order?

Phase 4: transition

The objective of the transition phase is to transfer the product to its new user. As soon as the user starts using the system, problems almost always arise that require changes to be made to the system. The goal, however, is to ensure a positive and smooth transition to the user. Results and activities in the last phase:

Beta testing
Conversion of existing user databases
Training new users
Rolling out of the project to marketing and distribution

Input from the new users should guide the assessment here.

Rational Unified Process: process dimension

The various phases related to developing software systems are now clear. As in any other process, the RUP describes who does what, where, and when. The ‘who’ in this process is the employee who is actively engaged in building the system. ‘What’ refers to something concrete, a piece of information. These ‘artefacts’ may take many forms, for example that of a user case or prototype.

The various phases already indicate the various activities involved in the development of a system. Here follows a more detailed explanation of the core activities.

1. Corporate modelling

One of the problems in the use of technical systems is that of the system and the user not being able to communicate properly. This leads to inefficiency in multiple areas.

For example, the input the developer receives from the user is not properly used for the development of the generation of systems. Rational Unified Process (RUP) partly solves this problem by creating an universal language and offering processes.

2. Requirements

The objective of requirements is to describe what the system should do and how it should function. Both the user and the developer should agree on the requirements as described in the first phase. Everything is included in a vision document. After that, a use case is developed.

3. Analysis and design

The objective of analysis and design is to show how the system is realised in the implementation phase. It should meet all requirements, be robust, and execute all its tasks as described in the use case. This model design functions as a blueprint for the rest of the process.

4. Implementation

Implementation is found throughout the Rational Unified Process (RUP), as is every other activity, but it is also one of the model’s engineering disciplines. The objective of implementation is to construct the full system. This is where components are tested and released.

5. Testing

The objective of testing is to verify the proper integration of all the components and the software. The testing phase is also where defects are identified and resolved. Testing does not only happen in the testing phase. The Rational Unified Process (RUP) is iterative, so testing happens throughout the project.

Tests are carried out along three dimensions:

Reliability
Functionality
Application management and system performance

6. Application

The objective of applying a system is, naturally, successfully releasing a software system and enabling the user to work with the new system. It includes many activities described in the transitional phase 4, including:

Packaging
Distribution
Installation
Help and assistance
Beta tests
Data migration
Acceptance

In addition, there are three supporting disciplines:

Configuration and change management
Project management
Environment

Now it’s your turn

What do you think? Do you recognise the explanation about the Rational Unified Process (RUP)? Do you use this IT-tool, or will you be using it from now on? What else do you think is important when designing a software system? Do you have any tips or additional comments?

Share your experience and knowledge in the comments box below.

More information

Ambler, S., Nalbone, J., & Vizdos, M. (2005). Enterprise unified process, the: extending the rational unified process. Prentice Hall Press.
Kroll, P., & Kruchten, P. (2003). The rational unified process made easy: a practitioner’s guide to the RUP. Addison-Wesley Professional.
Kruchten, P. (2004). The rational unified process: an introduction. Addison-Wesley Professional.
Manzoni, L. V., & Price, R. T. (2003). Identifying extensions required by RUP (rational unified process) to comply with CMM (capability maturity model) levels 2 and 3. IEEE Transactions on Software engineering, 29(2), 181-192.

How to cite this article:
Janse, B. (2019). Rational Unified Process (RUP). Retrieved [insert date] from Toolshero: https://www.toolshero.com/information-technology/rational-unified-process-rup/

Published on: 08/16/2019 | Last update: 10/19/2022

Add a link to this page on your website:
<a href=”https://www.toolshero.com/information-technology/rational-unified-process-rup/”>Toolshero: Rational Unified Process (RUP)</a>

Did you find this article interesting?

Your rating is more than welcome or share this article via Social media!

Average rating 4.2 / 5. Vote count: 11

No votes so far! Be the first to rate this post.

Article by:

Ben Janse

Ben Janse is a young professional working at ToolsHero as Content Manager. He is also an International Business student at Rotterdam Business School where he focusses on analyzing and developing management models. Thanks to his theoretical and practical knowledge, he knows how to distinguish main- and side issues and to make the essence of each article clearly visible.