Software Development Process 10 | Rational Unified Software Process and Phases in a Cycle

Series: Software Development Process

Software Development Process 10 | Rational Unified Software Process and Phases in a Cycle

Rational Unified Process (RUP)

(1) The History of RUP

In 1997, Rational defined six best practices for modern software engineering,

Develop iteratively, focusing on risk
Manage requirements
Employ a component-based architecture
Model software visually
Continuously verify quality
Control changes

These six practices, that we just mentioned were the starting point for the development of the Rational Unified Process, which is what we’re going to discuss next.

(2) Key Features of RUP

Now let’s start by seeing how these activities and principles are reflected in the key features of the Rational Unified Process,

RUP is a software process model: this means that it defines an order of phases and it prescribes transition criteria
RUP is component-based: this means that it is defined and built as a set of software components and there must be well-defined interfaces between these components
RUP is tightly related to UML: this means that it relies on the UML notations and basic principles
RUP has three distinguishing aspects: these three aspects are use-case driven, architecture-centric, iterative and incremental

So let’s now look in more detail at these three distinguishing aspects, and we’re going to look at each one of them individually.

(3) Distinguishing Aspect 1: Use-Case Driven

Generally speaking, we can see a system as something that performs a sequence of actions in response to user inputs. So use cases capture exactly this interaction and answer the question about what is the system supposed to do for each user. This is a very important point, and they can represent what a system can do for each of the different types of users of the system. Once more, use cases are used to support and help each one of these phases in the RUP.

(4) Distinguishing Aspect 2: Architecture-Centric

A soft architecture is a view of the entire system that represents all high-level principal design decisions. Another way to see this is by saying that use cases define the function of the system, whereas architecture defines the form of the system. To define a software architecture in the RUP, we have to,

Start by creating a rough outline of the system
Use the key use cases in our use case diagram to define the main subsystems of my architecture
Again, use the key use cases to identify and define the key subsystems for our architecture. We have to keep refining the architecture by using additional use cases. This will continue until we are happy with the architecture that we define.

(5) Distinguishing Aspect 3: Iterative and Incremental

Basically, the lifetime of a RUP consists of a series of cycles (aka. increments) of Cycle/Increment 1, Cycle/Increment 2, Cycle/Increment 3, etc. And each one of the cycles involves all of the main phases of software development. That means,

Code
Manuals
Use cases
Non-functional specification
Test cases
etc.

Specifically, each cycle is further divided into four phases,

Inception
Elaboration
Construction
Transition

The following diagram shows perfectly a workload distribution within a cycle/increment.

For each of these individual phases, there might still be multiple iterations. For example, for the construction phase in the diagram above, you can notice that we have 4 stages as C1, C2, C3, and C4. Each of these iterations corresponds to a group of use cases that are selected so as to deal with the most important risks first. So if you have a set of use cases that you’re considering, which means that you have a set of features that you need to implement, you will select for each iteration the riskiest ones that you still haven’t realized, and realize them in that iteration. And then continue in the following iterations with less and less risky ones.

(6) Phases in a Cycle

I’m going to start by representing the four RUP phases here with possible internal iterations I1, E1 and E2, C1, C2, and so on. We will start with Inception and we will finish with Transition. Based on the diagram above, we can generate the following conclusions,

Business Modeling: we have the business modeling activity that happens mainly in the Inception and a little bit in the Elaboration phase
Requirements: requirements engineering starts in the Inception phase, is mostly performed in the Elaboration phase, and then it continues, although to a lesser extent, throughout all phases up until the end of the Transition.
Analysis & Design: if we consider analysis and design, we can see that analysis and design are mainly performed in the Elaboration phase.
Implementation: the implementation happens mostly in the Construction phase, which is, unsurprisingly, the phase that is mostly concerned with actual code development
Testing: Testing is performed throughout most phases, with, peaks in some specific point, for example, at the end of some iterations.
Deployment: deployment activity which happens a little bit throughout but the bulk of it is really in the Transition phase, which is actually the phase that has to do with deployment and then maintenance.

(7) Iterations

So within each phase, we also have multiple iterations. And the question here is what exactly happens with an iteration? In almost every iteration, the developers perform the following activities,

Identify Relevant Use Cases: which pieces of functionality this iteration will develop and implement?
Create Design: guided by the chosen architecture
Implement the Design: result in a set of software components
Verify Code against Use Cases: realizing the use cases through testing or some other verification or validation activities
Release a Product: the end of this iteration

2. Phases in a Cycle

(1) The Definition of Inception Phase

The inception phase is actually the first phase that goes from the idea of the product to the vision of the end product. What this involves is to delimiting the project scope and making the business case for the product considered. Specifically, this phase answers three main questions,

What are the major users or actors and what will the system do for them?: The solution is a simplified use-case model.
What could be an architecture for the system?: The solution is to develop a tentative architecture.
What is the plan and how much it will cost?: The solution is to identify the main risk of the project and produce a rough plan with estimates of resources, initial planning for the phases, and dates and milestones.

(2) Deliverables Generated by Inception Phase

Specifically, the inception phase generates several deliverables,

Vision Document: a document that provides a general vision of the core project’s requirements, key features, and main constraints.
Initial Use-case Model: a use case model that includes an initial set of use cases and they will be later refined.
Initial Project Glossary: describes the main terms used in the project and their meaning.
Initial Business Case: it includes business context and success criteria.
Initial Project Plan: it shows the phases, iterations, roles of the participants, schedule, and initial estimates.
Risk Assessment Document: it describes the main risk and countermeasures for this risk.
One/More Prototypes: this is optional

(3) Evaluation Criteria for Concluding an Inception Phase

Stakeholder Concurrence: it means that all the stakeholders must agree on the scope, definition, and cost schedule estimates for the projects.
Requirement Understanding: are the initial, primary use cases that we have identified so far, the right ones for our system?
Credibility: Another criterion is the credibility of the cost-schedule estimates, the priorities defined, the risks identified, and the countermeasures for those risks, and the development process that we’re following.
Prototypes: We produce prototypes as part of the inception phase, this will also be evaluated and assessed to judge the overall outcome of the phase.

If the outcome of the inception phase is considered to be inadequate with respect to one or more of these criteria, we’re kind of in an initial phase of the cycle, the project might be canceled or considerably re-thought.

(4) Goals for Elaboration Phase

There are four main goals and activities for the elaboration phase,

Analyzing the problem domain: to get a better understanding of the domain.
Establishing architectural foundation: establishing a solid architectural foundation for the project.
Eliminating highest-risk elements: Eliminating the highest risk elements which basically means addressing the most critical use-cases.
Refine plans: refine the plan of activities and estimates of resources to complete the project.

(5) Outcomes for Elaboration Phase

The outcome of the elaboration phase reflects these activities and also in this case produces several artifacts.

Almost complete use-case model
Supplementary requirements: all the requirements that are not associated with a use case including non-functional requirements
Software architecture: also, we have to develop the software architecture in an incremental way
Lower-level designs: including design models, test cases, executable prototype
Revised project plan
Risk assessment
Preliminary user manual

(6) Evaluation Criteria for Concluding an Elaboration Phase

Whether the vision and architecture stable?
Does the prototype show that the major risks have been addressed or resolved?
Is the plan sufficiently detailed and accurate?
Do all stakeholders agree that the vision can be achieved with the current plan?
Is the actual resource expenditure versus the planned expenditure acceptable?

(7) The Definition of Construction Phase

The construction phase is basically the phase in which most of the actual development occurs. Therefore, this phase has the following features,

All the features considered are developed
All the features are roughly tested

We have verified and validated the software, the system, and we know that it works correctly (or at least that it works correctly as far as we can tell). So, in general, the construction phase is the phase in which there is a shift in emphasis from intellectual property development to product development (from ideas to products).

(8) The Outcome of Construction Phase

Realized all the use cases with traceability information
Complete software product integrated on all the needed platforms
Complete set of results for our tests
User manual ready to be provided
Complete set of artifacts: including design, code, test cases

(9) Evaluation Criteria for Concluding a Construction Phase

Whether the product is stable and mature enough to be deployed to users?
Are the stakeholders ready for the transition into the user community?
Are the actual resource expenditures versus the planned expenditures still acceptable?

At this point, we can really assess whether our estimates were accurate enough with respect to what we actually spent for the project up to this point.

(10) The Definition of Transition Phase

If we are ready to go to the market, or if we are ready to deploy our product, then we can move to the transition phase, which has mainly to do with the deployment and maintenance of a system. The goals of this phase are,

Maintaining issues after deployment: including corrective maintenance for bug reports, perfective maintenance for feature requests, and adoptive maintenance for environment changes.
New release of the system
Training customer service
Providing help-line assistance

In the end, because something else might happen in the transition phase, a new cycle may start.

(11) The Outcome of Transition Phase

Complete object
Product in use
Lessons learnt
Plan for the next release

(12) Evaluation Criteria for Concluding a Transition Phase

Is the user satisfied?
Are actual resourced expenditures versus planned expenditures still acceptable?