The Nelson Mandela Institution of Science and Technology

School of Computational and Communication Sciences

Engineering (CoCSE)

Individual Assignment

Student name: Bernard Mramba

Registration: NM-AIST/M/335/T16

Programme: MSc. ICSE (ITSDM)

Course: IT Project Management (ICSE 6201)

Assignment Presentation on the Rational Unified Framework.

1. Introduction

Agile software development methods focus on iterative and incremental development, customer

collaboration, and frequent delivery (Ambler, 2002), as opposed to conventional predictive

software development models which are characterized by extensive planning, ordered process,

extensive requirements documentation and design before any software is developed

(Abrahamsson, SALO, Ronkainen, & Warsta, 2002; Boehm, 2002). One of these emerging agile

model is the rational unified process (RUP) (Kruchten, 2002). RUP captures many of the best

practices in modern software development in a form that is suitable for a wide range of projects

and organizations (Kroll & Kruchten, 2003, p. 32). This paper aims at providing an overview and

application of the rational unified process (RUP) for software development.

1.1 The Rational Unified Process

Rational Unified Process (RUP) is a software engineering process framework maintained by the

Rational Software, a division of IBM (IBM Corporation, 2007). RUP was first introduced by

Rational Software in mid 1990s (Kruchten, 2003). The process was further improved by adding

other disciplines such as business modelling and configuration and change management

(Kruchten, 2003). RUP provides a disciplined approach towards software development through

assigning tasks and responsibilities to different teams within a development organization. Its main

goal is to ensure production of high-quality software that meets the needs of its end-users, within

a predictable timeframe and budget (Shahid & Khan, 2009).

1.2 Phases of RUP Framework

RUP uses methodologies and techniques, such as development lifecycle approach used in other

software development models (Kroll & Kruchten, 2003, p. 38). It is organized into two dimensions
named phases and disciplines. Phases which can be considered as project states, defines lifecycles

or iterations, while the disciplines define set of activities and milestones. In addition, RUP is a risk

driven framework. During each phase, associated risks should be identified and properly mitigated.

For example, at inception phase, deals with business risks, and project feasibility risks; elaboration

phase technical risks; construction and transition phases deals with logistical risks (Kroll &

Kruchten, 2003, pp. 4041). Figure.1 below provides the phases and disciplines dimensions of

RUP framework.

Figure 1: Phases and disciplines

dimensions of RUP framework

Source: (Kroll & Kruchten, 2003, p. 38)

RUP software development framework is designed to follow four phases namely, inception,

elaboration, construction and transition. As figure 1 above indicates, the activities defined in the

disciplines are distributed across the phases. For example, business modelling starts early during

inception phase, and continues towards construction and transition phases. However, this activity

needs more effort during the early phases than the last phase. Below is a brief discussion on each

phase.
1.2.1 Inception

This phase deals with several objectives such as understanding the software to be built, identifying

key functionalities of the software, determining a prototype solution, understanding costs,

schedules and risks associated with the project and deciding processes and tools to use. For large

projects, there can be several iterations on this phase, but for smaller projects one iteration is

enough to capture the all aspects of the phase.

1.2.2 Elaboration

Elaboration phase focuses on further understanding of the requirements, design of architecture to

use, technical risks, accurate schedules and costs estimates and refinement of the software

development case. The number of iterations depends on the size and scope of the project.

1.2.3 Construction

This is the most time consuming phase of the project. Experience shows that more than 50 percent

of the scheduled time goes in this phase. This phase aims at minimizing development costs through

parallel development of components, and having a complete product that is ready for transition to

the end user. This phase naturally has more iteration than other phases.

1.2.4 Transition

This is the final phase of the RUP framework, which is entered when the beta version of the

software is completed together with supporting documentations and training materials. The focus

on this phase is to ensure that the software fully meets the user requirements. The objectives of

this phase are to test and ensure user expectations are met, users are trained, deployment site is
constructed, launching packages are prepared, sales personnel are trained, and improvement of the

future project performance.

1.3 Principles of RUP Framework

Kroll & Kruchten (2003, pp. 3336) provides several principles that support successful iterative

software development which represents the spirit of RUP. Some of the principles are itemized

below as key features of the RUP framework.

The first principle on which RUP is designed is how we deal with risk. This principle requires

risks to be attacked early and continuously throughout the project. Rather than addressing business

risks, technical risks, or other risks later in a project, identify and attack major risks as early as

possible.

The second principle focuses on value to the customer. The project should be to ensure that

customer value of the project is maximized at reasonable budget. Customer requirements are

documented in the form that is easily understood, and the team should work closely with the

customer through design, implementation, and testing phases.

The third principle focuses on change management. Today's applications are too complex to enable

us to get the requirements, design, and implementation correct the first time. This means that to

develop a good enough system, we need to allow and adapt to change as we progress with the

project.

The fourth principle focuses on system architecture. Applications built with components are more

resilient to change and can have radically reduced system maintenance cost. Components facilitate

reuse, allowing for building higher quality applications faster than using functional decomposition.

The fifth principle focuses on the project leadership and communication management. Software
development has become a team sport and an iterative approach emphasizes the importance of

good team communications and a team spirit where each team member feels responsible for the

completed product.

The sixth principle focuses on product quality. Ensuring high quality involves more than just the

testing team. It involves all team members and all parts of the lifecycle. An iterative approach

focuses on early testing and test automation for more effective regression testing, thus reducing

the number of defects.

2. Applications of RUP Framework A case study

Several projects have applied the RUP framework in software development projects. One such is

detailed on the IBM rational website (Wei, Field, Alladi, & Rhoad, n.d.). This project done as a

joint effort between Ford and Ford Financial Credit. Ford Financial Credit is a fully owned

subsidiary of Ford and the largest provider of automotive financing.

Some of the challenges of the project were difficulty in sharing project deliverables across several

projects, late involvement customer service teams, and late identification of project risks. Every

team had its own set of templates and its own methodology. When people moved from one team

to another, they had to learn new methods. Moreover, risks were left to the last-minute only to

discover issues such as performance problems.

The choice of RUP framework was motivated by having internal expertise in RUP their

organization. Some individuals on the frameworks team knew a lot about RUP framework.

The project was done by first piloting RUP on six projects, covering four different business areas.

Then promoted RUP awareness through presentations at community forums. Some of these forums

had a standing room only crowd, which gave the team a lot of encouragement. Subject matter
experts were identified throughout the company. Then two projects were designed. One to develop

a customized version of RUP and one to deploy what was developed. The result was a model based

on RUP customized for Ford with specific organizational and project needs. The model included

other internal Fords controls considerations and data and record retention policies. In addition, it

included roles defined Ford's job structure.

In conclusion, they discovered that RUP framework has all the tools and necessary for an

organization such as Ford. The framework was easily customized to meet their needs. The great

aspect of the framework was integration.

3. Advantages and disadvantages of RUP framework

3.1 Advantages

Info-Tech Research Group, (2014), a globally recognized corporation for providing IT research

and advice, provides the following challenges based on market trends for software industry

Applications are getting more distributed and complexity is increasing.

Development lifecycles are becoming shorter.

Pressure to ensure strong communication between team members is increasing.

Pressure to ensure deliverables align to business priorities is increasing.

The need to track multiple release schedules and operational changes concurrently requires strong

source code management, release scheduling, and data to support risk management
Considering the above challenges, the RUP promotes an iterative risk driven approach to software

development with continuous testing and integration. Ambler (2002) gives several advantages of

RUP strategy compared to other software development methodologies.

Firstly, RUP allows for an improved governance of the project. The project leader can easily

determine if the teams are on the right track based on the regular outputs produced in each phase

and take appropriate action when required.

Secondly, RUP allows stakeholders to understand what is going on with the project at each stage.

Stakeholders can see portions of the system sooner and receive assurances that they will receive

what they want. Moreover, as they work with teams iteratively, they can provide corrections early

compared to other models.

Thirdly, RUP provides improved risk management. Working incrementally allows any risks to be

addressed from the beginning. Correction actions can be determined before project goes too far.

Moreover, developers implement the actual requirements. At each iteration, changes can be taken

on board as expecting static requirements from the beginning of the project is unrealistic.

In addition, developers can discover what works early. During the elaboration phase, any faulty

architecture can be modified/corrected as many architectures and algorithms works on paper but

might be too complex to implement.

Finally, developers focus on what matters. When using RUP, developers immediately focus on

what matters that means the actual software development. With traditional software development,

a team of designers spends a lot of time modelling and writing technical specifications which have

no guaranteed that they wont be scrapped.

3.2 Disadvantages

Firstly, the RUP process is too complex to apply by organization which are in many cases resource

constrained. Unless you have a real expert in applying the framework, software development teams

who are ready to learn, and financial resources, it is unlikely for a company to succeed in adapting

to this process (IBM Corporation, 2007). The process is too complex, too difficult to learn, and

too difficult to apply correctly.

Moreover, the disintegrated nature of the Rational Unified Process may lead to a totally

undisciplined form of software development. This may happen when team are free to apply

different techniques in development and causing integration problems in the future (Kruchten,

2003).

4. Conclusion

The RUP is a process framework that enables production of customized process configurations

that are iterative and risk-driven, with continuous integration and testing. Many projects can

benefit from taking an iterative approach and using a RUP. To accomplish this, teams need to gain

experience with iterative development; have good process support, mentoring, and training; and

enhance their software development environment (Kroll & Kruchten, 2003)

Recent trends show that there are significant benefits of using RUP (Wei et al., n.d.), but

experience and technical know-how, good process support, and good software development

environments are limiting factors.

References

Abrahamsson, P., SALO, O., Ronkainen, J., & Warsta, J. Agile software development methods:

Review and analysis, VVT Publications (2002). Espoo: VTT Electronics. Retrieved from

http://www.pss-europe.com/P478.pdf

Ambler, S. W. (2002). Agile modeling. John Wiley & Sons New York.

Boehm, B. (2002). Get ready for agile methods, with care. Computer, 35(1), 6469. Retrieved

from http://www.csis.pace.edu/~ctappert/cs615-02/boehm-2002-agile.pdf

IBM Corporation. (2007). IBM Rational Unified Process: Best Practices for Software

development Teams. Version (Vol. 7). Retrieved from

http://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestp

ractices_TP026B.pdf

Info-Tech Research Group. (2014). Vendor Landscape: Application Lifecycle Management.

Retrieved March 12, 2017, from http://www.infotech.com/research/ss/it-vendor-landscape-

application-lifecycle-management

Kroll, P., & Kruchten, P. (2003). The Rational Unified Process Made Easy: A Practitioners

Guide to the RUP. Trial.

Kruchten, P. (2002). Tutorial: introduction to the rational unified process. In Proceedings of

the 24th international conference on Software engineering (p. 703). ACM.

Kruchten, P. (2003). The Rational Unified Process: An Introduction. Science.

https://doi.org/10.1109/ICSE.2002.146346

Shahid, N., & Khan, O. (2009). Rational Unified Process. Online Notes on RUP. , (1110), 48.
Wei, J., Field, M., Alladi, V., & Rhoad, W. (n.d.). A Case Study: Using IBM Rational Unified

Process as the Methodology Framework. Retrieved March 12, 2017, from

https://www.ibm.com/developerworks/rational/library/4474.html