Rational Unified Process

RATIONAL UNIFIED PROCESS

Seminar Report

Submitted in partial fulfilment of the requirements

for the award of the degree of

Bachelor of Technology

in

Computer Science Engineering

of

Cochin University Of Science And Technology

by

JERRY MANALIL (12080035)

DIVISION OF COMPUTER SCIENCE

SCHOOL OF ENGINEERING

COCHIN UNIVERSITY OF SCIENCE AND TECHNOLOGY KOCHI-682022

AUGUST 2010

DIVISION OF COMPUTER SCIENCE

SCHOOL OF ENGINEERING

COCHIN UNIVERSITY OF SCIENCE AND TECHNOLOGY KOCHI-682022

Certificate

Certified that this is a bonafide record of the seminar entitled

“RATIONAL UNIFIED PROCESS”

Presented by the following student

“JERRY MANALIL”

of the VIIth semester, Computer Science and Engineering in the year 2010

in partial fulfillment of the requirements in the award of Degree of

Bachelor of Technology in Computer Science and Engineering of Cochin

University of Science and Technology.

Mr. SUDHEEP ELAYIDOM Dr. DAVID PETER

SEMINAR GUIDE HEAD OF DIVISION

ACKNOWLEDGEMENT

I thank GOD almighty for guiding me throughout the seminar. I would like to

thank all those who have contributed to the completion of t he seminar and

helped me with valuable suggestions for improvement.

I am extremely grateful to Dr. David Peter, Head Of Division, Division of

Computer Science, for providing me with best facilities and atmosphere for the

creative work guidance and encouragement. I would like to thank my

coordinator and guide, Mr. Sudheep Elayidom, Sr. Lecturer, Division of

Computer Science, for all help and support extend to me. I thank all Staff

members of my college and friends for extending their cooperation during my

seminar.

Above all I would like to thank my parents without whose blessings; I would

not have been able to accomplish my goal.

JERRY MANALIL

ii

ABSTRACT

It has become fashionable to blame many problems

and failures in software development on the sequential, or waterfall model.

This is rather surprising because at first this method seems like a reasonable

approach to system development. The Rational Unified Process is a Software

Engineering Process. It provides a disciplined approach to assigning tasks and

responsibilities within a development organization. Its goal is to ensure the

production of high-quality software that meets the needs of its end-users,

within a predictable schedule and budget. The Rational Unified Process is a

process product, developed and maintained by Rational Software.

TABLE OF CONTENTS

CHAPTER TITLE PAGE

LIST OF FIGURES i

INTRODUCTION ii

1. SEQUENTIAL PROCESS 1

• A reasonable approach 2

• Wrong assumption 1: 3

• Wrong assumption 2: 4

• Bring risk into picture 4

• Stretching time scale 5

• Pushing paper work to shelves 5

• Volume based versus time based 6

• From sequential process RUP 7

• RATIONAL UNIFIED PROCESS 7

• Process overview 8

• Phase the time domain 8

• Inception phase 9

• Elaboration phase 10

• Construction phase 11

• Transition phase 12

• Iteration 13

• Benefits of an iterative approach 13

• Core workflow 13

• Business modelling 15

• Requirements 16

• Analysis design 16

• Implementation 17

• Test 18

• Deployment 19

• Project management 20

• Configuration management 20

• Environment 21

• Implementing Rational Unified Process 23

• A model of Rational Unified Process 24

• Roles 24

• Activities 25

• Activity steps 25

• Artefacts 26

• BENEFITS OF ITERATIVE APPROACH 28

• Risk mitigation 28

• Accommodating changes 28

• Changes in requirement 28

• Tactical changes 28

• Technological changes 28

• Learning as you go 29

• Increased opportunity for reuse 29

• Better overall quality 29

• Conclusion 30

• References 31

LIST OF FIGURES

FIGURE NAME PAGE 1.8 Sequential process to RUP 7 2.1 The iterative mode graph 8 2.2 The phases and major milestones in the phases 9 2.4(a) Example for workflow 15 2.4(b) Workflow 23 2.5 RUP Implementation 24

Rational Unified Process

Division Of Computer Science, SOE Page 1

1. THE SEQUENTIAL PROCESS

It has become fashionable to blame many problems and failures in software

development on the sequential, or waterfall model, process depicted in the fig.

This is rather surprising because at first this method seems like a reasonable

approach to system development.

Requirement

Analysis

(Requirement specification)

Design

(Design Specification)

Implementation

(Code)

Integration

Software product



1.1 A REASONABLE APPROACH

Completely understand the problem to be solved, its requirements, and

it’s constrains. Capture them in writing and get all interested parties to

agree that this is what they need to achieve.

Design a solution that satisfies all requirements and constrains. Examine

this design carefully and make sure that all interested parties agree that

it is the right solution

Implement the solution using your best engineering techniques.

Verify the implementation satisfies the stated requirements.

Deliver. Problem solved!

If the sequential process is ideal, however, why aren’t the projects that use it

more successful? There are many reasons.

We made wrong assumption.

The context of software development is somewhat different from that of

other engineering disciplines.

We have failed to incorporate some human factors.

We have tried to stretch an approach that works in certain well-defined

circumstances beyond what it can bear.

We are still in the exploratory phase of software engineering.

1.2 WRONG ASSUMPTION 1: Requirement will be frozen

The requirement changes for many reasons.

The user changes



This is especially true when the development time is measured not in

weeks or months but in years. Users see other systems and other

products and they want some of the features they see. Their own work

environment evolves, and they become better educated.

The problem changes

After the system is implemented or while it is being implemented, the

system itself affects the perspective of users. Trying out features or

seeing them demonstrated is quite deferent from reading about them. As

soon as the end users see how their intentions have been translated into

a system, the requirement change.

The underlying technology changes

New software or hardware techniques and products emerge, and you

will want to exploit them. On a multiyear project, the hardware platform

bid at the beginning of the project may no longer be manufactured at

delivery time.

The market changes

The competition might produce better products to the market. What is

the point of developing the perfect product relative to the original spec

if you end up with the wrong product relative to what the marketplace

expects when you are finally finished?

We cannot capture requirements with sufficient detail and precisions.



1.3 WRONG ASSUMPTION 2: We can get the Design Right On Paper

before Proceeding

The second step of the sequential process assumes that we can confirm

that our design is the right solution to the problem. By “right” we imply all the

obvious qualities: correctness, efficiency, feasibility, and so on. With complete

requirement tracing, formal derivation methods, automated proof, generator

techniques, and design simulation, some of the qualities can be achieved. Few

of these techniques are readily available to practitioners, however, and many

of them require that you begin with a formal definition of the problem. You

can accumulate pages of pages of design documentation and hundreds of

blueprints and spend week in review, only to discover late in the process that

the design has major flaws that cause serious breakdowns.

1.4 BRING RISK INTO PICTURE

The sequential, or waterfall, process does work. It has worked fine for

the projects lasting for a few weeks to a few months, on projects in which we

could clearly anticipate that would happen, and on projects in which all hard

aspects were well understood. For projects having little or no novelty, you can

develop a plan and execute it with little or no surprise. If the current project is

somewhat like the one you completed last year-and the one the year before-

and if you use the same people, the same tool, and the same design, the

sequential approach will work well.

The sequential process break down when you tackle projects that have a

significant level of novelty, unknowns, and risks. You cannot anticipate the

difficulties you may encounter, let alone how you will address them. The only



thing you can do is to build some slack into the schedule and cross your

fingers.

1.5 STRETCHING THE TIME SCALE

If you stretch what works for a three month project to fit a three year

project, you expose the project not only to the changing context we have

discussed but also to the other subtle effects related to the people involved.

Software developers who know that they will see tangible results within the

next two to three months can remain well focused don the qualities of their

work. If small mistakes are discovered along the way, the developers won’t

have to go very far back in time to correct them.

But imagine the mindset of developers in the middle of the design phase

of a three year project. The target is to finish the design within four months. In

a sequential process, the developers may not even be around to see the final

product up and running. Progress is measured in pages or diagrams and not in

operational features. There is nothing tangible, nothing to get the adrenaline

flowing.

1.6 PUSHING PAPER WORKS TO SHELVES

In the sequential process, the goal of each step except the last one is to

produce and complete an intermediate artifact that is reviewed, approach,

frozen, and then used as the sequential process place an excessive emphasis on

the production and freezing of documents. Some limited amount of feedback

to the preceding step is tolerated, but feedback on the results of earlier step is

seen as disruptive. This is related to the reluctance to change requirements and

to the loss of focus on the final product that is often seen during long projects.



1.7 VOLUME BASED VERSUS TIME BASED

Often, timeliness is the most important factor in the success of a

software project. In many industries, delivery of a product on time and with a

short turnaround for new features is far more important than delivery of a

complete, full featured, perfect system. To achieve timeliness, you must be

able to adjust the contents dynamically by dropping or postponing some

features to deliver incremental value on time. With a linear approach, you do

not gain much on the overall schedule if you decide in the middle of the

implementation to drop feature X. You have already expended the time and

effort to specify, design, and code the feature. That’s why this model isn’t

suitable when a company wants to work with schedules that are time based

and not volume-based



1.8 FROM SEQUENTIAL TO ITERATIVE PROCESS

Fig 1.8 Sequential process to RUP

2. RATIONAL UNIFIED PROCESS The Rational Unified Process is a Software Engineering Process. It

provides a disciplined approach to assigning tasks and responsibilities within a

development organization. Its goal is to ensure the production of high-quality

software that meets the needs of its end-users, within a predictable schedule

and budget. The Rational Unified Process is a process product, developed and

maintained by Rational Software.



2.1 PROCESS OVERVIEW

The process can be described in two dimensions, or along two axes:

The horizontal axis represents time and shows the dynamic aspect of the

process as it is enacted, and it is expressed in terms of cycles, phases,

iterations, and milestones.

The vertical axis represents the static aspect of the process: how it is

described in terms of activities, artifacts, workers and workflows.

Figure 2.1 The Iterative Model graph shows how the process is structured

along two dimensions.

2.2 PHASES - THE TIME DIMENSION

This is the dynamic organization of the process along time. The software

lifecycle is broken into cycles, each cycle working on a new generation of the

product. The Rational Unified Process divides one development cycle in four

consecutive phases.

Inception phase

Elaboration phase

Construction phase



Transition phase

Each phase is concluded with a well-defined milestone—a point in time at

which certain critical decisions must be made, and therefore key goals must

have been achieved. Each phase has a specific purpose.

Figure 2.2 the phases and major milestones in the process.

2.2.1 Inception Phase

During the inception phase, you establish the business case for the

system and delimit the project scope. To accomplish this you must identify all

external entities with which the system will interact (actors) and define the

nature of this interaction at a high-level. This involves identifying all use cases

and describing a few significant ones. The business case includes success

criteria, risk assessment, and estimate of the resources needed, and a phase

plan showing dates of major milestones.

The outcome of the inception phase is:

A vision document: a general vision of the core project’s requirements,

key features, and main constraints.

An initial use-case model (10%-20% complete).

A Project plan, showing phases and iterations.



2.2.2 Elaboration Phase

The purpose of the elaboration phase is to analyze the problem domain,

establish a sound architectural foundation, develop the project plan, and

eliminate the highest risk elements of the project. To accomplish these

objectives, you must have the “mile wide and inch deep” view of the system.

Architectural decisions have to be made with an understanding of the whole

system: its scope, major functionality and nonfunctional requirements such as

performance requirements.

It is easy to argue that the elaboration phase is the most critical of the

four phases. At the end of this phase, the hard “engineering” is considered

complete and the project undergoes its most important day of reckoning: the

decision on whether or not to commit to the construction and transition phases.

For most projects, this also corresponds to the transition from a mobile, light

and nimble, low-risk operation to a high-cost, high-risk operation with

substantial inertia. While the process must always accommodate changes, the

elaboration phase activities ensure that the architecture, requirements and

plans are stable enough, and the risks are sufficiently mitigated, so you can

predictably determine the cost and schedule for the completion of the

development. Conceptually, this level of fidelity would correspond to the level

necessary for an organization to commit to a fixed-price construction phase.

The outcome of the elaboration phase is:

A use-case model (at least 80% complete) — all use cases and actors

have been identified, and most use-case descriptions have been

developed.



Supplementary requirements capturing the non-functional requirements

and any requirements that are not associated with a specific use case.

Software Architecture Description.

A development plan for the overall project, including the coarse-grained

project plan, showing iterations and evaluation criteria for each

iteration.

2.2.3 Construction Phase

During the construction phase, all remaining components and

application features are developed and integrated into the product, and all

features are thoroughly tested. The construction phase is, in one sense, a

manufacturing process where emphasis is placed on managing resources and

controlling operations to optimize costs, schedules, and quality. In this sense,

the management mindset undergoes a transition from the development of

intellectual property during inception and elaboration, to the development of

deployable products during construction and transition.

Many projects are large enough that parallel construction increments

can be spawned. These parallel activities can significantly accelerate the

availability of deployable releases; they can also increase the complexity of

resource management and workflow synchronization. A robust architecture

and an understandable plan are highly correlated. In other words, one of the

critical qualities of the architecture is its ease of construction. This is one

reason why the balanced development of the architecture and the plan is

stressed during the elaboration phase.



The outcome of the construction phase is a product ready to put in hands of its

end-users. At minimum, it consists of:

The software product integrated on the adequate platforms.

A description of the current release.

2.2.4 Transition Phase

The purpose of the transition phase is to transition the software product to

the user community. Once the product has been given to the end user, issues

usually arise that require you to develop new releases, correct some problems,

or finish the features that were postponed. The transition phase is entered

when a baseline is mature enough to be deployed in the end-user domain. This

typically requires that some usable subset of the system has been completed to

an acceptable level of quality and that user documentation is available so that

the transition to the user will provide positive results for all parties. This

includes:

“Beta testing” to validate the new system against user expectations

Parallel operation with a legacy system that it is replacing

Conversion of operational databases

training of users and maintainers

roll-out the product to the marketing, distribution, and sales teams

The transition phase focuses on the activities required to place the software

into the hands of the users. Typically, this phase includes several iterations,

including beta releases, general availability releases, as well as bug-fix and

enhancement releases. Considerable effort is expended in developing user-

oriented documentation, training users, supporting users in their initial product



use, and reacting to user feedback. At this point in the lifecycle, however, user

feedback should be confined primarily to product tuning, configuring,

installation, and usability issues.

2.3 ITERATIONS

Each phase in the Rational Unified Process can be further broken down

into iterations. Iteration is a complete development loop resulting in a release

(internal or external) of an executable product, a subset of the final product

under development, which grows incrementally from iteration to iteration to

become the final system.

2.3.1 Benefits of an iterative approach

Compared to the traditional waterfall process, the iterative process has

the following advantages:

Risks are mitigated earlier

Change is more manageable

Higher level of reuse

The project team can learn along the way

Better overall quality

2.4 CORE WORKFLOWS

The core process workflows are divided into six core “engineering”

workflows

1. Business modeling workflow

2. Requirements workflow

3. Analysis & Design workflow



4. Implementation workflow

5. Test workflow

6. Deployment workflow

And three core “supporting” workflows:

1. Project Management workflow

2. Configuration and Change Management workflow

3. Environment workflow

Although the names of the six core engineering workflows may evoke

the sequential phases in a traditional waterfall process, it should be kept in

mind that the phases of an iterative process are different and that these

workflows are revisited again and again throughout the lifecycle. The actual

complete workflow of a project interleaves these nine core workflows, and

repeats them with various emphasis and intensity at each iteration.

It is really possible to represent all the dependencies between activities.

Often two activities are more tightly interwoven, especially when they involve

the same role or the same individual. People are not machines, and the

workflow cannot be interpreted literally as a program that people are to follow

exactly and mechanically



Fig 2.4(a): Example for a workflow

2.4.1 Business Modeling

One of the major problems with most business engineering efforts is

that the software engineering and the business engineering community do not

communicate properly with each other. This leads to that the output from

business engineering is not used properly as input to the software development

effort, and vice versa. The Rational Unified Process addresses this by

providing a common language and process for both communities, as well as

showing how to create and maintain direct trace ability between business and



software models. In Business Modeling we document business processes

using so-called business use cases. This assures a common understanding

among all stakeholders of what business process needs to be supported in the

organization. The business use cases are analyzed to understand how the

business should support the business processes. This is documented in a

business object-model. Many projects may choose not to do business

modeling.

2.4.2 Requirements

The goal of the Requirements workflow is to describe what the system

should do and allows the developers and the customer to agree on that

description. To achieve this, we elicit, organize, and document required

functionality and constraints; track and document tradeoffs and decisions. A

Vision document is created, and stakeholder needs are elicited. Actors are

identified, representing the users, and any other system that may interact with

the system being developed. Use cases are identified, representing the

behavior of the system. Because use cases are developed according to the

actor's needs, the system is more likely to be relevant to the users.

2.4.3 Analysis & Design

The goal of the Analysis & Design workflow is to show how the system

will be realized in the implementation phase. You want to build a system that:

Performs—in a specific implementation environment—the tasks and

functions specified in the use case descriptions.

Fulfills all its requirements.



Is structured to be robust (easy to change if and when its functional

requirements change).

Analysis & Design results in a design model and optionally an analysis

model. The design model serves as an abstraction of the source code; that is,

the design model acts as a 'blueprint' of how the source code is structured and

written. The design model consists of design classes structured into design

packages and design subsystems with well-defined interfaces, representing

what will become components in the implementation. It also contains

descriptions of how objects of these design classes collaborate to perform use

cases.

The design activities are centered on the notion of architecture. The

production and validation of this architecture is the main focus of early design

iterations. Architecture is represented by a number of architectural views.

These views capture the major structural design decisions. In essence,

architectural views are abstractions or simplifications of the entire design, in

which important characteristics are made more visible by leaving details aside.

The architecture is an important vehicle not only for developing a good design

model, but also for increasing the quality of any model built during system

development.

2.4.4 Implementation

The purpose of implementation is:

To define the organization of the code, in terms of implementation

subsystems organized in layers.



To implement classes and objects in terms of components (source files,

binaries, executables, and others).

To test the developed components as units.

To integrate the results produced by individual implementers (or teams),

into an executable system.

The system is realized through implementation of components. The

Rational Unified Process describes how you reuse existing components, or

implement new components with well-defined responsibility, making the

system easier to maintain, and increasing the possibilities to reuse.

Components are structured into Implementation Subsystems. Subsystems take

the form of directories, with additional structural or management information.

2.4.5 Test

The purposes of testing are:

To verify the interaction between objects.

To verify the proper integration of all components of the software.

To verify that all requirements have been correctly implemented.

To identify and ensure defects are addressed prior to the deployment

of the software.

The Rational Unified Process proposes an iterative approach, which means

that you test throughout the project. This allows you to find defects as early as

possible, which radically reduces the cost of fixing the defect. Test are carried

out along three quality dimensions reliability, functionality, application

performance and system performance. For each of these quality dimensions,



the process describes how you go through the test lifecycle of planning,

design, implementation, execution and evaluation. Strategies for when and

how to automate test are described. Test automation is especially important

using an iterative approach, to allow regression testing at then end of each

iteration, as well as for each new version of the product.

2.4.6 Deployment

The purpose of the deployment workflow is to successfully produce

product releases, and deliver the software to its end users. It covers a wide

range of activities including:

Producing external releases of the software.

Packaging the software.

Distributing the software.

Installing the software.

Providing help and assistance to users.

In many cases, this also includes activities such as:

Planning and conduct of beta tests.

Migration of existing software or data.

Formal acceptance.

Although deployment activities are mostly centered on the transition phase,

many of the activities need to be included in earlier phases to prepare for

deployment at the end of the construction phase. The Deployment and

Environment workflows of the Rational Unified Process contain less detail

than other workflows.



2.4.7 Project Management

Software Project Management is the art of balancing competing objectives,

managing risk, and overcoming constraints to deliver, successfully, a product

that meets the needs of both customers (the payers of bills) and the users. The

fact that so few projects are unarguably successful is comment enough on the

difficulty of the task. This workflow focuses mainly on the specific aspect of

an iterative development process. Our goal with this section is to make the

task easier by providing:

A framework for managing software-intensive projects.

Practical guidelines for planning, staffing, executing, and monitoring

projects.

A framework for managing risk.

It is not a recipe for success, but it presents an approach to managing the

project that will markedly improve the odds of delivering successful software.

2.4.8 Configuration & Change Management

In this workflow we describe how to control the numerous artifacts

produced by the many people who work on a common project. Control helps

avoid costly confusion, and ensures that resultant artifacts are not in conflict

due to some of the following kinds of problems:

Simultaneous Update -- When two or more workers work separately on

the same artifact, the last one to make changes destroys the work of the

former.

Limited Notification -- When a problem is fixed in artifacts shared by

several developers, and some of them are not notified of the change.



Multiple Versions -- Most large programs are developed in evolutionary

releases. One release could be in customer use, while another is in test,

and the third is still in development. If problems are found in any one of

the versions, fixes need to be propagated between them. Confusion can

arise leading to costly fixes and re-work unless changes are carefully

controlled and monitored.

This workflow provides guidelines for managing multiple variants of

evolving software systems, tracking which versions are used in given software

builds, performing builds of individual programs or entire releases according

to user-defined version specifications, and enforcing site-specific development

policies. We describe how you can manage parallel development,

development done at multiple sites, and how to automate the build process.

This is especially important in an iterative process where you may want to be

able to do builds as often as daily, something that would become impossible

without powerful automation. We also describe how you can keep an audit

trail on why, when and by whom any artifact was changed.

This workflow also covers change request management, i.e. how to report

defects, manage them through their lifecycle, and how to use defect data to

track progress and trends.

2.4.9 Environment

The purpose of the environment workflow is to provide the software

development organization with the software development environment both

processes and tools—that are needed to support the development team. This

workflow focuses on the activities to configure the process in the context of a



project. It also focuses on activities to develop the guidelines needed to

support a project. A step-by-step procedure is provided describing how you

implement a process in an organization. The environment workflow also

contains a Development Kit providing you with the guidelines, templates and

tools necessary to customize the process. The Development Kit is described in

more detail in the section “Development Kit for Process Customization" found

later in this paper. Certain aspects of the Environment workflow are not

covered in the process such as selecting, acquiring, and making the tools work,

and maintaining the development environment.



Fig 2.4(b) Workflow

2.5 Implementing Rational Unified Process

Step1: Assess the current state.

Step2: Set or revise goals.

Step3: Identify risks.

Step4: Plan the process implementation.



Step5: Execute the process implementation.

Step6: Evaluate the process implementation.

Fig 2.5 RUP Implementation

2.6 A MODEL OF RATIONAL UNIFIED PROCESS

A process describes who is doing what, how, when. The rational unified

process is represented using five primary elements.

Roles: who

Activities: how

Artifacts: what

Workflows: when

2.6.1 ROLES

The central concept in the process is that of a role. A role defines the

behavior and responsibilities of an individual or of a group of individuals

working together as a team. The behavior is expressed in the terms of



activities the role performs, and each role is associated with set of cohesive

activities. ”Cohesive” in this sense means activities that are best performed by

one person.

Each role is associated with a set of skills required to perform the

activities of the role. Roles are organized into five main categories

1. Analyst roles

2. Developer roles

3. Tester roles

4. Manager roles

5. Production and support roles

2.6.2 ACTIVITIES

Roles have activities, which define the work they perform. An activity

is a unit of work that an individual in that role may be asked to perform and

that produce a meaningful result in the context of the project. The granularity

of the project is generally a few hours to a few days. It usually involves one

person in the associated roles affects one or only a small number of artifacts.

In object oriented terms, role is an active object, and the activities that

the role performs are operations performed by that object.

2.6.2.1 Activity Steps

Activities are broken into steps. Steps fall into three main categories

Thinking steps

The person playing the role understands the nature of the

task, gathers and examines the input artifacts, and

formulates the outcomes.



Performing steps

The person playing the role creates or updates some

artifacts.

Reviewing steps

The person playing the role inspects the results against

some criteria.

2.6.3 ARTIFACTS

Activities have input and output artifacts. An artifact is a piece of

information that is produced, modified, or used by process. Artifacts are

tangible products of the projects: the things the project produce or use while

working toward the final product. Artifacts are used as input by roles to

perform an activity and are the result or output of such activity.

Artifacts take various shapes or forms

A model, such as the use-case model or the design model.

A model element –an element within a model-such as a class, a

use case, or a subsystem.

A document, such as business case or software architecture

document.

Source code.

Executables.

The artifacts of the rational unified process have been organized into

information sets that are aligned with the core disciplines.



The management set groups all artifacts related to the software

business and to the management of the project.

o Planning artifacts, such as SDP (software development

plan), the business case, the actual process instance

o Operational artifacts, such as release description, status

assessment, deployment documents, and defect data.

The requirement set groups all artifacts related to the definition of

the software system to be developed.

o The vision document.

o Requirement in the form of stakeholders ‘needs, use-case

model, and supplementary description.

The design set contains a description of the system to be built

o The design model

o The architecture description.

The implementation set

o The source code and executables

o The associated data files or the files needed to produce

them.

The deployment set contains all the information delivered,

including the following

o Installation material

o User documentation

o Training material



3.0 BENEFITS OF AN ITERATIVE APPROACH

3.1 RISK MITIGATION

An iterative approach lets you mitigate risks earlier than a sequential

process where the final integration is generally the only time that risks are

discovered or addressed. As you roll out the early iteration, you go through all

process components, exercising many aspects of the projects, including tool,

off-the-shelf software, and people skills. If a project must fail for some reason,

let it fail as soon as possible, before a lot of time, effort, and money are

expended.

3.2 ACCOMMODATING CHANGES

You can envisage several categories of change

3.2.1 Changes in requirement

The truth is that requirement normally changes. Changing requirement

and requirement creep have always been primary source of project trouble,

leading to late delivery, missed schedules, unsatisfied customer, and frustrated

developers.

3.2.2 Tactical changes

An iterative process provides management with a way to make tactical

changes to the product. You can decide to release a product early with reduced

functionality to counter a move by a competitor.

3.2.3 Technological change

To a lesser extent, an iterative approach lets you accommodate

technological changes. You can use it during the elaboration phase, but you



should avoid this kind of changes during construction and transition because it

is inherently risk.

3.3 LEARNING AS YOU GO

An advantage of the iterative process is that developers can learn along

the way, and the various competencies and specialties are employed during the

entire lifecycle. Training needs or the need for the additional help are spotted

early during the reviews. The process itself can also be improved and refined

long the way. The assessment at the end of aniteration looks at the status of

the project from a product/scheduled perspective and analyzes what should be

changed in the organization and the process so that it can perform better in the

next iteration.

3.4 INCREASD OPPORTUNITY FOR REUSE

An iterative process facilitate reuse of project elements because it is

easy to identify common parts as they are partially designed or implemented

instead of identifying all commonality in the beginning. Identifying and

developing reusable parts is difficult. Design reviews in early iterations allow

architect to identify unsuspected potential reuse and to develop and mature

common code in subsequent iteration

3.5 BETTER OVERALL QUALITY

The product that results from a n iterative will be of better overall

quality than that of conventional sequential process. The system has been

tested several times, improving the quality of testing



4.0 CONCLUSION

Optimize the collaboration of complete team.RUP helps you unify your

team. Deliver the right product on time and on budget. RUP helps you

focus on delivering working software. Effectively be able to adopt new

techniques and tools on your project. RUP helps you leverage new tools

and techniques. RUP enables the developer to select and deploy only the

process components they need for each stage of their project. RUP is a

configurable software development process platform that delivers practice

and configurable architecture. RUP is much more advanced than sequential

process



5.0 REFERENCES

1. The rational unified process An introduction

Third edition

Philippe kruchten

2. www.ibm.com/developer work

3. www.wikipedia.org

4. A managers introduction to Rational unified process

Scott W. Ambler

Rational Unified Process

Documents

Transcript of Rational Unified Process