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
Presented by the following student
JERRY MANALIL
of the VII
th
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
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.
ii
TABLE OF CONTENTS
CHAPTER
1.
TITLE
PAGE
LIST OF FIGURES
INTRODUCTION
ii
SEQUENTIAL PROCESS
A reasonable approach
Wrong assumption 1:
Wrong assumption 2:
Bring risk into picture
Stretching time scale
Pushing paper work to shelves
Volume based versus time based
From sequential process RUP
Process overview
Phase the time domain
Inception phase
Elaboration phase
10
Construction phase
11
Transition phase
12
Iteration
13
Benefits of an iterative approach
Core workflow
13
13
Business modelling
15
Requirements
Analysis design
16
Implementation
17
16
Test
18
Deployment
19
Project management
20
Configuration management
Environment
21
Implementing Rational Unified Process
23
A model of Rational Unified Process
24
Roles
24
Activities
20
25
Activity steps
25
Artefacts
BENEFITS OF ITERATIVE APPROACH
26
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
2.1
The iterative mode graph
2.2
The phases and major milestones in the phases
2.4(a)
Example for workflow
15
2.4(b)
Workflow
23
2.5
RUP Implementation
24
Rational Unified Process
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
Division Of Computer Science, SOE
Page 1
1.1 A REASONABLE APPROACH

Completely understand the problem to be solved, its requirements, and
its 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 arent 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
Page 2
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.
Page 3
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 beforeand 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
Page 4
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 wont
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.
Page 5
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. Thats why this model isnt
suitable when a company wants to work with schedules that are time based
and not volume-based
Page 6
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.
Page 7
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
Page 8
Transition phase
Each phase is concluded with a well-defined milestonea 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 projects requirements,
key features, and main constraints.
An initial use-case model (10%-20% complete).
A Project plan, showing phases and iterations.
Page 9
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.
Page 10
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.
Page 11
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 useroriented documentation, training users, supporting users in their initial product
Page 12
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
Page 13
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
Page 14
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
Page 15
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:
Performsin a specific implementation environmentthe tasks and
functions specified in the use case descriptions.
Fulfills all its requirements.
Page 16
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.
Page 17
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,
Page 18
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.
Page 19
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.
Page 20
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 toolsthat are needed to support the development team. This
workflow focuses on the activities to configure the process in the context of a
Page 21
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.
Page 22
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.
Page 23
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
Page 24
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.
Page 25
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.
Page 26
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
Page 27
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
Page 28
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
Page 29
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
Page 30
5.0REFERENCES
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
Page 31

Rational Unified Process

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Rational Unified Process

Загружено:

Авторское право:

Доступные форматы

RATIONAL UNIFIED PROCESS

DIVISION OF COMPUTER SCIENCE

DIVISION OF COMPUTER SCIENCE

semester, Computer Science and Engineering in the year 2010

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

Mr. SUDHEEP ELAYIDOM

Dr. DAVID PETER

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

Bring risk into picture

Stretching time scale

Pushing paper work to shelves

Volume based versus time based

From sequential process RUP