Rational Unified Process (RUP)
Rational Unified Process: this article explains the Rational Unified Process (RUP) in a practical way. After reading, you’ll understand this powerful agile software development method.
What is a Rational Unified Process (RUP)?
Rational Unified Process (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.
The Rational Unified Process (RUP) is iterative, meaning repeating; and agile. Iterative because all of the process’s core activities repeat throughout the project. 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.
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
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.
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.
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.
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:
- Application management and system performance
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:
- Help and assistance
- Beta tests
- Data migration
In addition, there are three supporting disciplines:
- Configuration and change management
- Project management
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.
- 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: 03/15/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>
We are sorry that this post was not useful for you!
Let us improve this post!
Tell us how we can improve this post?