Welcome to the Training Program: Rational Unified Process

(RUP)

(ID: 3352)

Brief Description
This is a 1 day program for freshers specially configured to give good over on life cycle
of software development under the umbrella of RUP

Objectives

• To get the overview of Iterative Development

• To get acquainted with Phases & Disciplines of the RUP

Pre-Requisites
None

Hardware Requirements
Pentium Machines with minium 512 MB RAM and 500 MB of free disk space

Software Requirements
Each machine must be equipped with Internet Explorer

Network Requirements

• All the participant-machines must be networked

• Network access must be provided to the trainer's laptop

Rational Unified Process (RUP)
Chapter: 1 - Best Practices Of Software
Engineering

Trace Symptoms to Root Causes

Symptoms of Software Development Problems

• The Symptoms of Software Development Problems are:

o User or business needs not met
o Requirements churn
o Modules don’t integrate
o Hard to maintain
o Late discovery of flaws
o Poor quality or end-user experience
o Poor performance under load
o No coordinated team effort
o Build-and-release issues

Trace Symptoms to Root Causes

• Treat the root causes, amd you'll eliminate the symptoms:

Symptoms Root Causes Best Practices

Needs not met Insufficient requirements Develop Iteratively

Requirements Churn Ambiguos Manage Requirements
communications
Modules dont fit Use Component
Brittle Architecture Architectures
Hard to Maintain
Overwhelming Model Visually (UML)
Late Discovery
Complexity
Continuously Verify Quality
Poor Quality
Undetected
Manage Changes
Poor Performance inconsistencies
Colliding developers Poor testing
Build-and-release Subjective assessment
issues
Waterfall development
Uncontrolled change
Insufficient automation
 • Eliminate the symptoms and you will be in a much better
position to devleop quality software in a repeatable and
predictable fashion

• Best Practices are a set of commercially proven approaches to

software development, which, when used in combination, strike
at the root causes of software developement, problems.

• The best practices are harvested from thousands of customers

on thousands of projects and from industry experts.

Best Practice 1 - Develop Iteratively

What is Iterative Development ?

• Develop Iteratively is a technique that is used to deliver the

functionality of a system in a successive series of releases of
increasing completeness. Each release is developed in a
specific, fixed time period called an “iteration"

• Each iteration is focused on defining, analyzing, designing,

building and testing some set of requirements.

Waterfall Development Characteristics

• Waterfall is conceptually straightforward because it produces a

single deliverable.

• The fundamental problem of this approach is that it pushes risk

forward in time, where it is costly to undo mistakes from earlier
phases

• An initial design will likely be flawed with respect to its key

requirements

• The late discovery of design defects tends to result in costly

overruns and/or project cancellation

• To sum it up the problems with Water Development are:

o Delays confirmation of critical risk resolution
 o Measures progress by assessing work-products that are
poor predictors of time-to-completion
o Delays integration and testing
o Precludes early deployment
o Frequently results in major unplanned iterations

Iterative Development Produces an Executable

• In Iterative Approach:
o The earliest iterations address greatest risks. Each iteration
produces an executable release.
o Resolve major risks before making large investments
o Enable early user feedback
o Make testing and integration continuous
o Focus project short-term objective milestones
o Make possible deployment of partial implementations

• Instead of developing the whole system in lock step, an increment (i.e. a

subset of system functionality) is selected and developed, the another
increment, etc.
 • The selection of first increment to be developed is based on risk, the
highest priority risk first.

• To address the selected risk(s) choose a subset of use cases and other
non-functional requirements

• Develop the minimal set of use cases the will allow objective verification
of the risks that you have chosen

Risk Profiles

• Iterative Development produces the architecture first, allowing integration

to occur "as verification activity" of the design phase

• It allows design flaws to be detected and resolved earlier in the lifecycle.

• Continous integration throughout the project replaces the "big bang"

integration at the end of a project.

• Iterative Development provides much better insight into quality,

because system characteristics that are largely inherent in the architecture
(for e.g. performance, fault tolerance, maintainability) are tangible earlier
in the process.

•
• Issues are still correctable without jeopardizing target costs and schedules.
Best Practice 2 - Manage Requirements

Manage Requirements

• A report from the Standish Group confirms that a distinct

minority of software projects is completed on-time and on-
budget.

• The success rate was only 16.2%, while challenged projects

operational, but late and over budget accounted for 52.7%.
Impaired projects accounted for 31.1%.

• Reason: Poor definition of requirements, poor requirements

management and poor change management of requirements.

What is Requirements Management ?

• Making sure you

o Solve the right problem
o Build the right system

• By taking a systematic approach to

o Eliciting
o Organizing
o Documenting and
o Managing the changing requirements of a software
application

• Also managing traceability among requirements is important

activity in Requirements Management

Aspects of Requirements Management

• Following are workflow details of Requirments Management

o Analyze the Problem
o Understand the Stakeholders requests
 o Define the System
o Manage the scope of the System
o Refine the System Definition
o Build the Right System

Traceability

• Managing requirements involves the translation of stakeholder requests into a

set of key stakeholder needs and system features.

•
• Traceability allows us to:
o Assess the project impact of a change in a requirement
o Assess the impact of failure of test
o Manage the scope of the system
o Manage Change
Best Practice 3 - Use Component Architecture

Use Component Architecture

• Software Architecture is the development product that gives

highest ROI with respect to quality, schedule, and cost,
according to the authors of Software Architecture in Practice.

• Software Architecture is often misunderstood. It is not an

artifact which is merely on paper

• It must be validated and evaluated

• The Architecture is nothing but High Level Design

Resilient Component-Based Architecture

• Component Based Architecture is Resilient

o Meets current and future requirements
o Enables reuse
o Improves Extensibility
o Encapsulates system dependencies

• The Architecture must be based on components. It helps

o Reuse or customize components
o Select from commercially-available components
o Evolve existing software incrementally

• Architecture is about making decisions on how the system will

be built

• The elements of Architecture are those that have pervasice and

long-lasting effect on the systems performance and ability to
evolve.

• The most important property of an architecture is resilience -

flexibility in the face of change. The component orientedness
helps implement this property
Purpose of a Component-Based Architecture

• Basis for reuse

o Component Reuse
o Architecture reuse

• Basis for Project Management

o Planning
o Staffing
o Delivery

• Intellectual Control:
o Manage Complexity
o Maintain integrity

• RUP Definition of Component : A non-trivial, nearly

independent, and replaceable part of a system that fulfills a
clear function in the context of a well-defined architecture.

• UML Definition: A physical part of a system that packages

implementation, and conform to and provides the realization of
a set of interfaces.
Best Practice 4 - Model Visually (UML)

Model Visually

• A model is a simplification of reality that provides a complete description of a

system from a particular perspective.

• We build models because we cannot comprehend any system in its entirety.

Why Model Visually ?

• We do modeling to
o Capture structure & behavior
o Show how system elements fit together
o Keep design & implementation consistent
o Hide or expose details as appropriate
 language for all practitioners/ul>

o Visula Modeling also helps you tomaintian consitency

among a system's artifacts - its requirements, designs,
and implementations.

o Visual modeling helps improve a team's ability to

manage software complexity

o A model is a simplified view of a system.

It shows the essentials of the system from a particular

perspective and hides the non-essential details.

Visual Modeling with Unified Modeling Language (UML)

• Model Contains
o Static Diagrams
Use Case Diagrams to illustrate user interactions
with the system
Class Diagrams to illustrate logical structure
Object Diagrams to illustrate objects & links
Component Diagrams to illustrate the physical
structure of the system
Deployment Diagrams to show the mapping of
software to hardware config.
o Dynamic Diagrams
Sequence Diagrams to illustrate behavior
Collaboration Diagrams to illustrate behavior
State Chart Diagrams to illustrate behavior
Activity Diagrams to illustrate flow of events
Best Practice 5 - Continuously Verify Quality

Continuously Verify Quality

• Quality as used within Unified Process, is defined as “The

Characteristic of having demonstrated the achievement of
producing a product which meets or exceeds agreed upon
requirements, as measured by agreed upon measures and
criteria, and is produced by an agreed upon process”.

Continuosly Verify Your Software's Quality (Contd.)

• What to test:
o Test for key scenarios – ensure that all requirements are properly
implemented
o Poor application performance hurts as much as poor reliability
o Verify software reliability – memory leaks, bottlenecks
o Test every iteration – automate test

• Software problems are 100 to 1000 times more costly to find and repair
after deployment. Verifying and managing quality throughout the project
lifecycle is essential to achieving the right objectives at the right time.
Test all Dimensions

• Test all Dimensions of Software Quality:

o Functionality Test: Use case scenarios execute as
intended
o Performance Test: reliable under load, benchmark
tests, load tests and performance profile tests.
o Load Test: Application runs reliable under various loads
(peak hrs)
o Reliability Test: crahes, hangs, memory leaks,
integrity, structure, stress, contention and volume tests.
o Usability: human factors, aesthetics, wizards and
agents, user documentation

• Test Each Iteration

Test within the Product Development Life Cycle

• The testing lifecycle is a part of the software lifecycle; they should start
at the same time.

• The design and development process for tests is as complex and arduous
as the application being built. - If not started early enough, the tests will
either be deficient, or cause a long testing and bug-fixing schedule to be
appended to the development schedule, which defeats the goals of
iterative development.

• The test planning and design activities can expose faults or flaws in the
application definition.

• The earlier these are resolved, the lower the impact on the overall
schedule
 •

Best Practice 6 - Manage Changes

Manage Changes

• We cannot stop change from being introduced into our project.

• However, we must control how and when changes are

introduced into project artifacts and who introduces the
changes.

• We also must synchronize change across development teams &

locations

What do you want to Control ?

 • Establishing secure workspaces for each developer provides isolation
from changes made in other workspaces and control of all software
artifacts – models, code, docs etc.

•
• Three common problems that result are:
1. Simultaneous update – When two or more roles separately
modify the same artifact, the last one to make changes destroys
the work of the former.
2. Limited Notification – When a problem is fixed in shared
artifacts, some of the users are not notified of the change.
3. Multiple versions – With iterative development, it would not be
unusual to have multiple versions of an artifact in different
stages of development at the same time. For e.g. one release is
in customer use, one is in test, and one is still in development. If
a problem is identified in any one of the versions, the fix must be
propagated among all of them.

Aspects of Change Management

• Aspects of Change Management Includes

1. Change Request Management (CRM)
2. Configuration Status Reporting
3. Configuration Management (CM)
4. Change Tracking
5. Version Selection
 6. Software Manufacture

• Change Requestion Management

o CRM addresses the organizational infrastructre required
to assess the cost and schedule impacts of a requested
change to the existing product
o CRM addresses the workings of a Change Review Team
or Change Control Board

• Configuration Status Accounting (Measurement)

o This is used to describe the "state" of the product based
on the type, number, rate and severity of defects found
and fixed during the course of product development.
o Metrics derived under this aspect, either through audits
or raw data, are useful in determining the overall
completeness of the project

• Configuration Management
o This describes the product structure and identifies its
constituent configuration items that are treated as single
versionable entities in the configuration management
process
o CM deals with defining configurations, building and
labeling, and collecting versioned artifacts into
constituent sets and maintaining traceability between
these versions

• Change Tracking
o This describes what is done to components for what
reason and at what time.
o It serves as histroy of rationale and change
o It is quite different from assessing the impact of
proposed changes

Version Selection

o This is to ensure that the right versions of configuration

items are selected for change or implementation
o Version selection relies on a solid foundation of
"configuration identification"
 Software Manufacture

o This covers the need to automate the steps to compile,

test, and package software distribution

Unified Change Management (UCM)

• Unified Change Management (UCM) is Rational Software's

approach to managing change in software development, from
requirments to release

• UCM spans the development lifecycle, defining how to manage

change to requirments, design models, documentation,
components, test cases and source code.

• One of the key aspects of the UCM is that it unifies the activities
used to plan and track project and the artifacts undergoing
change

Rational Unified Process Implements Best Practices

Why have a Process ?

• Provides guidelines for efficient development of quality software

• Reduces risk and increases predictability

• Promotes a common vision and culture

• Captures and institutionalizes best practices

Achieving Best Practices

• Iterative approach

• Guidance for activities and artifacts

• Process focus on architecture

• Use cases which drive design and implementation

• Models which abstract the system

A Team-Based Definition of Process

• A process defines WHO is doing WHAT WHEN and HOW to

reach a certain goal.

Process Structure - Life Cycle

• The 4 Phases of RUP are explained below

• Inception
o Define the scope of the project - what is included and
what is not
o This is done by identifying all the actors and use cases,
and by drafting the most essential use cases (usually
20% of the complete model)
o A business plan (business case document) is developed
 the project

• Elaboration
o Focus on 2 things: a) getting good grasp of the
requirements (80%), and b) establishing an architectural
baseline
o Plan project in detail, features specied in detail
o A detailed cost/resource estimations at the end of
Elaboration is achieved

• Construction
o Build the product in several iterations upto beta release
o Detailed Level Design of all Use Cases including
important, ancillary and other that were not
architecurally significant
o Unit Test, Integration Test & System Tests all completed
here

• Transition
o The product goes to end-user community
o Focus is on end user training, installation, and support

Phase Boundaries Mark Major Milestones

• At each of the major milestones, we review the project and decide

whether to proceed with the project as planned, to abort the project, or to
revise it.

• The criteria used to make this decision vary by phase

 •
• Definitions

LCO: Scope agreed upon and risks understood and reasonable

LCA: High risks addressed and architecture stable

IOC: Product is complete and quality acceptable

The Evaluation Criteria

• Inception - Evaluation Criteria

o Stakeholders concurrence on scope definition and
cost/schedule estimates
o Requirements understanding as evidenced by the fidelity
of the primary use cases
o Credibility of cost/schedule guestimates, priorities, risks,
and development process
o Depth & breadth of any architectural prototype

• Elaboration - Evaluation Criteria

o Stability of the product vision and architecture
o Resolution of major risk elements
o Adequate planning and reasonable estimates for project
completion
o Stakeholder acceptance of product vision and project
plan
o Acceptable expenditure level
 • Construction - Evaluation Criteria
o Stability and Maturity of product release (i.e. it is ready
to be deployed)
o Readiness of the stakeholders for the transition
o Acceptable expenditure

• Transition - Evaluation Criteria

o Here we decide whether to release the product
o The decision is based on the level of user satisfaction
achieved during transition phase
o Users have accepted the product
o Product can be made "Generaly Available"

Following illustrates the effort and time devoted for each phase

Inception Elaboration Construction Transition

Effort ~5 % 20 % 65 % 10%
Schedule 10 % 30 % 50 % 10%

Iterations & Phases

• An iteration is a distinct sequence of activities based on established plan and

evaluation criteria, resulting in a release (Internal or External)

•
• Within each phase, there is a series of iterations

• The number of iterations per phase will vary

 • Each iteration results in an executable release encompassing larger and larger
subsets of the final application

• An internal release is kept within the development environment and

(optionally) demonstrated to the stakeholders

Usually External Releases are provided to the stakeholders

External Releases are usually in Transition phase - although not necessary

The end of an iteration marks a minor milestone. At this point, we

asses technical results and revise future plans as necessary

Discipline Product Models

• Following are the disciplines in RUP that produces model

o Business Modeling
o Requirements
o Analysis & Design
o Implementation
o Test
o Deployment

• Disciplines guide iterative development

Basic Concepts in RUP

• Role: A role defines the behavior and responsibilities of an

individual, or a set of individuals working together as a team.

• Activity: An activity is the smallest piece of work that is

relevant. Concepts, Guidelines, Tool Mentors

• Artifacts: Artifacts are the modeling constructs and documents

that activities evolve, maintain, or use as input.

• There are : Checkpoints, Template, Artifact Guideline, Report

for each artifacts explained in RUP
Chapter: 2 - RUP Structure & Content

A Development Process Should

A Development Process Should:

• Define the steps that leas to deliverables and who is reponsible

for them

• Help to control the project and reduce confusion

• Help project management to resource, plan, and measure

progress

• Help reduce risk

• Make Software Development Effort predictable, repeatable, and

measureable

Not be just another process gathering dust

RUP - A Software Development Process

• Provides guidelines for efficient development of quality software

• Reduces risk and increases predictability

• Captures and presents best practices

o Provides learning from other's experiences
o Acts as a mentor on your desktop
o Provides an extension of training material

• Promotes common vision and culture

• Mentors successful use of Rational Tools.

Role of UML in RUP

• Rational Unified Process was developed hand-in-hand witgh the

UML

• Many artifacts in Rational Unified Process have a UML

representation

• Rational Unified Process also includes guidelines for UML

Concepts

Process as a Product

• Delivered in source, as a Web site

• Continuously improved; regular upgrades

• Templates and Online Help provided for faster ramp-up

• RUP consists of a set of HTML pases which can be viewed using

any browser which supports frames.

RUP Structure

• Organization along time

o Lifecycle structure: phases, iterations
o Process enactment (performing): planning, executing
o Activity management, project control

The time structure refers to the lifecycle aspect of the process

i.e. how the process rolls out within the duration of a
project

• Organization based on content

o Disciplines, roles, artifactsm activities
o Process configuration, process enhancement
 The content structure refers to the Disciplines, which group
activities logically by nature

Organization Along Time

Organization Along Time

• Refer to RUP Overview figure and note that: The time aspect of
the process as it is enacted is shown by phases, iterations, and
milestones.

• Organization along time helps minimize risk of your resource

allocation since resources are allocated only on a firm basis

Major Milestones: Business Decision Points

• The phases of RUP were chosen such that phase boundaries

correspond to significant decision points in the life of a project.

• Milestones help us assess the progress of a project of a project

at key points.

• Management can use these milestones to establish clear criteria

from which to decide the course of a project.

They provide opportunity to change course

• Unlike Waterfall approach, phases contain iterations which yield

executable results.

• On the following pages we will see each one of the phases in

detail
Inception Phase: Objectives

• Establishing the project's software scope and boundary

conditions, including an operational vision, acceptance criteria
and what is intended to be in the product and what is not.

• Discriminating the critical use cases of the system, the primary

scenarios of operation that will drive the major design tradeoffs.

• Exhibiting, and maybe demonstrating, at least one candidate

architecture against some of the primary scenarios

• Estimating the overall cost and schedule for the entire project
(and more detailed estimates for the elaboration phase that will
immediately follow)

• Estimating potential risks (the sources of unpredictability)

Preparing the supporting environment for the project

Inception Phase: Evaluation Criteria

• Stakeholder concurrence on scope definition and cost/schedule

estimates

• Agreement that the right set of requirements have been

captured and that there is a shared understanding of these
requirements.

• Agreement that the cost/schedule estimates, priorities, risks,

and development process are appropriate.

• All risks have been identified and a mitigation strategy exists for
each.

• Essential Artifacts
o Vision Document
o Business Case
o Risk List
o Software Development Plan
o Iteration Plan
o Development Process
o Development Infrastructure
o Glossary
o Use Case Model (Actors, Use Cases)
 Optional Artifacts

o Domain Model (a.k.a Business Analysis Model)

o Prototypes

Elaboration Phase: Objectives

• To ensure that the architecture, requirements and plans are

stable enough, and the risks sufficiently mitigated to be able to
predictably determine the cost and schedule for the completion
of the development. For most projects, passing this milestone
also corresponds to the transition from a light-and-fast, low-risk
operation to a high cost, high risk operation with substantial
organizational inertia (lethargy, sluggish).

• To address all architecturally significant risks of the project

• To establish a baselined architecture derived from addressing

the architecturally significant scenarios, which typically expose
the top technical risks of the project.

• To produce an evolutionary prototype of production-quality

components, as well as possibly one or more exploratory,
throw-away prototypes to mitigate specific risks such as:
o design/requirements trade-offs
o component reuse
o product feasibility or demonstrations to investors,
customers, and end-users.

• To demonstrate that the baselined architecture will support the

requirements of the system at a reasonable cost and in a
reasonable time.

To establish a supporting environment

Elaboration Phase: Evaluation Criteria

• The product Vision and requirements are stable & The

architecture is stable.

• The key approaches to be used in test and evaluation are

proven & Test and evaluation of executable prototypes have
demonstrated that the major risk elements have been
addressed and have been credibly resolved.

• The iteration plans for the construction phase are of sufficient

detail and fidelity to allow the work to proceed.

• The iteration plans for the construction phase are supported by

credible estimates.

• All stakeholders agree that the current vision can be met if the
current plan is executed to develop the complete system, in the
context of the current architecture.

Actual resource expenditure versus planned expenditure is

acceptable.

Essential Artifacts ( In order of Importance)

o Prototypes: One or more executable architectural
prototypes to explore criticial functionality &
architecturally significant scenarios
o Risk List: Updated & Approved
o Development Process: Project-Specific guildelines and
templates refined
o Development Infrastructure: Development
environment for construction is in place
o Software Architecture Document: Created and
baselined
o Design Model: Defined and baselined. Use-case
realizations for architecturally significant scenarios have
been defined and required behavior has been allocated
to appropriate design elements. Components have been
identified and the make/buy/reuse decisions sufficiently
understood to determine the construction phase cost and
schedule with confidence. The selected architectural
components are integrated and assessed against the
primary scenarios. Lessons learned from these activities
may well result in a redesign of the architecture, taking
into consideration alternative designs or reconsideration
of the requirements.
o Data Model: Defined and baselined. Major data model
elements (e.g. important entities, relationships, tables)
defined and reviewed.
 major components prototyped.
o Vision: Refined
o Software Development Plan: Updated and expanded
to cover Construction and Transition
o Iteration Plan: Iteration plan for the construction
phase completed and reviewed.
o Use-Case Model (Actors, Use Cases) : A use-case
model (approximately 80% complete)—all use cases
having been identified in the use-case model survey, all
actors having been identified, and most use-case
descriptions (requirements capture) have been
developed.
o Supplementary Specifications : Supplementary
requirements capturing the non functional requirements
are documented and reviewed.
o Test Suite: Tests implemented and executed to validate
the stability of the build for each executable releases
created during the elaboration phase.

Construction Phase: Construction

• Minimizing development costs by optimizing resources and

avoiding unnecessary scrap and rework.

• Achieving adequate quality as rapidly as practical & Achieving

useful versions (alpha, beta, and other test releases) as rapidly
as practical

• Completing the analysis, design, development and testing of all

required functionality.

• To iteratively and incrementally develop a complete product

that is ready to transition to its user community. This implies
describing the remaining use cases and other requirements,
fleshing out the design, completing the implementation, and
testing the software.

• To decide if the software, the sites, and the users are all ready
for the application to be deployed.

To achieve some degree of parallelism in the work of development teams. Even on smaller
projects, there are typically components that can be developed independently of one another,
allowing for natural parallelism between teams (resources permitting). This parallelism can
accelerate the development activities significantly; but it also increases the complexity of
resource management and workflow synchronization. A robust architecture is essential if any
significant parallelism is to be achieved.
Construction Phase: Evaluation Criteria

• Is this product release stable and mature enough to be

deployed in the user community?

• Are all the stakeholders ready for the transition into the user
community?

• Are actual resource expenditures versus planned still

acceptable?

• Essential Artifacts (In order of importance) :

o The System: The executable system itself, ready to
begin "beta" testing.
o Deployment Plan: Initial version developed, reviewed
and baselined. On smaller projects, this may be
embedded in the Software Development Plan.
o Implementation Model: Expanded from that created
during the elaboration phase; all implementation
elements created by the end of the construction phase.
o Test Suite: Tests implemented and executed to validate
the stability of the build for each executable releases
created during the construction phase.
o End-User Support Material: User Manuals and other
training materials. Preliminary draft, based on use cases.
May be needed if the system has a strong user interface
aspect.
o Iteration Plan: Iteration plan for the transition phase
completed and reviewed.
o Design Model (and all constituent artifacts):
Updated with new design elements identified during the
completion of all requirements.
o Data Model: Updated with all elements needed to
support the persistence implementation (e.g. tables,
indexes, object-to-relational mappings, etc.)

Transition Phase: Objectives

• Beta testing to validate the new system against user

expectations & Beta testing and parallel operation relative to a
legacy system that it's replacing

• Converting operational databases, training of users and

 forces

• Deployment-specific engineering such as cutover, commercial

packaging and production, sales roll-out, field personnel training

• Tuning activities such as bug fixing, enhancement for

performance and usability assessment of the deployment
baselines against the complete vision and the acceptance
criteria for the product

• Achieving user self-supportability, achieving stakeholder

concurrence that deployment baselines are complete, achieving
stakeholder concurrence that deployment baselines are
consistent with the evaluation criteria of the vision

Transition Phase: Evaluation Criteria

• Is the user satisfied?

• Are actual resources expenditures versus planned expenditures

acceptable?

• Essential Artifacts (In order of importance)

o The Product Build: Complete in accordance with the
product requirements. The final product should be
useable by the customer.
o End-User Support Material: Materials that assist the
end-user in learning, using, operating and maintaining
the product should be complete in accordance with
requirements.
o Implementation Elements: The implementation is
complete and baselined, and the deployable elements
have been incorporated in the final product.
What Is an Iteration

What is an Iteration ?

• An iteration is one pass through all disciplines

• An Iteration can be seen as mini project with a aplan,

deliverables and assessment, in which periodic corrections are
applied to the remainder of the project.

• If you are using the four phases of RUP, you are already using
iterations, but more iterations can be added to each phase of
needed.

Phases & Iterations

Phases & Iterations

• The focus of an iteration changes across the cycle.

• Recall that each iteration is, in a sense a mini-waterfall.

• The iteration plan contains the activities of requirments

elicitation and analysis, of design and implemenration, and of
integration and test

• The emphasis on the various activities changes, however, from

one iteration to the next.

Iteration: Number and Duration

• Duration of an Iteration is driven by:

o + size of organization
o + size of project
o - familiarity with the process, maturity
o - technical simplicity

6 Plus or Minus 3
 Inception: 0 .. 1
Elaboration: 1 .. 3
Construction: 1 .. 3
Transition: 1 .. 2

• If Inception consits only of planning and marketing, tghen there

may be no real iteration.

If you need a prototype or need to immediately address a

techinical risk you will need an interation

• The number of iterations in Elaboration may depend on the

complexity of the architecture, where you're starting from, and
the experience of the team

• During Construction, you can use iterations to do a good job of

testing and integration

Transition would rfequire at least one iteration, and more.

Organization Based on Content

Organization Based on Content

• Organization into disciplines shows the content of the process

(Refer to Overview figure of RUP). - the activities, artifacts and
roles.

Key RUP Elements: Roles, Activities, Artifacts

• If the process describes who is doing what and how, then the
primary elements of Rational Unified Process can be described
as:

• Roles

This describes the who in the process

 • Activities

This describes the how in the process

• Artifacts

This describes the what in the process

• A Role performs certian Activities and is responsible for

certain Artifacts

Role Perform Activities and Produce Artifacts

• An Artifact is a work product of the process.

• Roles use artifacts to perform activities and product artifacts in the course of
performing activities.

• Artifacts are the responsibility of a sinle role. Even though one person may
"own" the artifact, many other people may use it or update it if permission is
granted
 •

Key RUP Element: Role

Role

• A role defines the behavior and responsibilities of an individual,

or a set of individuals working together as a team.

• Team members can “wear different hats,” that is, each member
can play more than one role.

• Roles have a set of cohesive activities that they perform.

• Activities of a particular role are closely related and functionally

related.

Roles Are Used for Resource Planning

 • The project typically has at its disposal a number of resources, individuals
which have specific competencies.

For example, Joe, Marie, Paul, Sylvia are individuals with different, although
overlapping competencies. Using the roles defined in the process, map
resources available to the project onto roles they can play.

•
• An individual might act as several different roles in the same day: For
example, Sylvia might be a Reviewer in the morning, and a Use-Case
Designer in the afternoon.

• An individual might act as several roles simultaneously: For example, Jane

could be both the Software Architect and the Designer of a certain class, and
also the Package Owner of the package that contains this class.

• Several people can act as the same role to perform a certain activity
together, acting as a team: For example, Paul and Mary could be both Use-
Case Designers of the same use case.

Key RUP Element: Activity

Activity

• An activity is a unit of work that an individual playing the

described role may be asked to perform.
 • The activity has a clear purpose, usually expressed in terms of
creating or updating some artifacts, such as a model, a class, or
a plan.

Every activity is assigned to a specific role.

• The granularity of an activity is generally a few hours to a few

days, it usually involves one role, and affects one or only a
small number of artifacts.

• Examples of Activities: Develop Iteration Plan, Find Actors &

Use Cases, Review the Architecture, Use Case Design.

Key RUP Element: Artifact

Artifact

• A document or model produced, evolvedm or used by a process

• The responsibility of a Role

• LIkely to be subject to configuration control

• May contain other artifacts

• Only one role is responsible for the artifact but others can use it

Key RUP Element Workflow

Workflow

• A mere enumeration of all roles, activities and artifacts does not

constitute a process; we need a way to describe meaningful
sequences of activities that produce some valuable result, and to
show interactions between roles.

• A workflow is a sequence of activities that produces a result of

observable value
 •

Workflow Details

• A grouping of activites that are performed in close collaboration

to accomplish some result (See figure on previous slide)

• A unit of planning
 output from one activity serving as the input to another activity

• Used to group activities to provide a higher level of abstraction

and to improve the comprehensibility of workflows

• Workflow guides iterative development

Iteration Plan

• A given iteration includes multiple disciplines

• The form a discipline will take varies depending on its position

within the overall lifecycle and the nature of the project.

• The Iteration Plan includes all relevant portions of the

disciplines for that particular iteration

• Characteristics of Iteration Plan

o Instantiation of the discipline
o One for each iteration
o A fine-grained plan
o Expressed in terms of selected Workflow Details or
Activities from the disciplines
o Shows assigned resources
Artifact Set Evolution Over Development Phases

• With the iterative approach, artifact sets mature over time

Economy of Artifacts

• Produce only the artifacts that get used

• Keep the artifact in the most appropriate tool, in electronic form

(Rose, Excel, RequisitePro etc.)

• Use reports to extract snapshots of information out of models in

tools, for review (SoDA, scripts, etc.)

• Put effort into artifacts that are part of the product e.g. models
Additional Process Elements

Additional Process Elements

• Additional process Elements

o Discipline
Introduction
Concepts
Workflow
Activity Overview
And associated Tool Mentors and
Guidelines
Artifacts Overview
And associated Templates and Guidelines
Guidelines Overview
Roadmaps

Process Elements: Concepts

• Attached to the relevant Discipline

• Explanation of key ideas

• Examples of Concepts Related to Requirements

o Requirements management
o Types of Requirements
o Traceability

• Example of Concepts Related to Analysis and Design

o Software Architecture
o Analysis mechanisms
o Web Architecture patterns
Process Elements: Guidelines

• These are Rules, recommendations, heuristics that support

activities and heir steps. They:

• Describe specific techniques like transformations from one

artifact to another and Use of UML

• Are attached to relevant discipline.

• Are kept short and to the point.

• Describe well-form artifacts and focus on qualities.

Are used also to assess the quality of artifacts.

Are tailored for the project.

Process Elements: Tool Mentors

• Attached to relevant activity

• Explain how to use specific tool to perform an activity or steps

in an activity

• Linked by default to Rational tools:

o RequisitePro: requirement management
o Rational Rose: visual modeling, using UML
o SoDA: documentation generation
o ClearQuest: change management, defect tracking

Process Element: Templates

• Attached to relevant document type

• Predefined artifacts, prototypes:

o Documents(Microsoft® Word,Adobe® Framemaker)
o MS Project
o HTML
 o

o Can be tailored for the process

Process Element: Roadmap

• Apply the general-purpose process to solve specific types of

problems.

• Describe process variants using phases.

• Provide a mechanism for extending and adapting the process.

• Highlight certain process features to achieve a particular goal.

Chapter: 3 - Disciplines - I

Discipline: Environment

Development Case

Discipline: Project Management

Planning for Iterative Development

Concerns in Project Management

Discipline: Requirements

Major Concepts in the Use Case Model

What is in a Use-Case Model

Discipline: Business Modeling

Chapter: 4 - Disciplines II

Discipline: Analysis & Design

Discipline: Test

Discipline: Implementation

Discipline: Deployment

Discipline: Configuration & Change Management

Chapter: 5 - Implementing RUP

Implementing Process - The Steps

Environment Discipline

Environment: Workflow

Environment: Artifact Overview

Configuring a Process

The Development Case

Implementing a Process

Common Mistakes and Solutions

Best Practices for Process Implementation