Transcript No Slide Title

®
IBM Software Group
PRJ270: Essentials of Rational Unified Process
Module 2: Iterative Development
1
Module 2 Objectives
Be familiar with the guidance RUP provides for
iterative development by investigating:
 Phases and milestones
 Iterations
 Concepts that drive iterative development
 Early mitigation of risk
 Early baselining of architecture
 Use of objective measurements
 Characteristics of iterative development
2
Instructor Demonstration of RUP
 Your instructor will briefly demonstrate RUP,
showing you:
 Elements of the main interface
 Where to access the Classic RUP Getting
Started view and Team view
3
RUP Organization Along Time
Time
Organization by phases helps minimize the risks of resource allocation.
4
Major Milestones: Business Decision Points
Scope and
Business Case
agreement
Inception
Architecture
baselined
Product sufficiently
mature for customers
Elaboration
Construction
Customer
acceptance
or end of life
Transition
time
Lifecycle
Objective
Milestone
Lifecycle
Architecture
Milestone
5
Initial Operational
Capability
Milestone
Product
Release
Inception Phase: Objectives
 Establish project scope and boundary conditions
 Determine the use cases and primary scenarios
that will drive the major design trade-offs
 Demonstrate a candidate architecture against
some of the primary scenarios
 Estimate the overall cost and schedule
 Identify potential risks (the sources of
unpredictability)
 Prepare the supporting environment for the project
6
Inception Phase: Evaluation Criteria
 Stakeholder concurrence on scope definition
and cost/schedule estimates
 Agreement that the right set of requirements has
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
Milestone: Lifecycle Objectives (LCO)
7
Elaboration Phase: Objectives
 Define, validate and baseline the
architecture as rapidly as is practical
 Baseline the vision
 Refine support environment
 Baseline a detailed plan for the
Construction phase
 Demonstrate that the baseline architecture
will support the vision at a reasonable cost
in a reasonable period of time
8
Elaboration Phase: Evaluation Criteria
 Product Vision and requirements are stable.
 Architecture is stable.
 Key test and evaluation approaches are proven; major
risk elements have been addressed and resolved.
 Iteration plans for Construction phase are of sufficient
detail and fidelity to allow work to proceed, and are
supported by credible estimates.
 All stakeholders agree that 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 expenditures versus planned
expenditures are acceptable.
Milestone: Lifecycle Architecture (LCA)
9
Construction Phase: Objectives
 Complete the software product for transition
to production
 Minimize development costs by optimizing
resources and avoiding unnecessary scrap
and rework
 Achieve adequate quality as rapidly as is
practical
 Achieve useful versions (alpha, beta, and
other test releases) as rapidly as possible
10
Construction Phase: Evaluation Criteria
The evaluation criteria for the Construction phase
involve the answers to these questions:
 Is this product release stable and mature
enough to be deployed in the user community?
 Are all the stakeholders ready for the product’s
transition into the user community?
 Are actual resource expenditures versus
planned still acceptable?
Milestone: Initial Operational Capability (IOC)
11
Transition Phase: Objectives
 Achieve user self-supportability
 Achieve stakeholder concurrence that
deployment baselines are complete and
consistent with the evaluation criteria of the
vision
 Achieve final product baseline in a rapid
and cost-effective manner
12
Transition Phase: Evaluation Criteria
The primary evaluation criteria for the Transition
phase involve the answers to these questions:
 Is the user satisfied?
 Are actual resources expenditures versus
planned expenditures acceptable?
Milestone: Product release (“GA”)
13
What Is an Iteration?
In an
iteration,
you walk
through all
disciplines.
Iteration: A distinct sequence of activities with a baselined
plan and evaluation criteria resulting in a release (internal
or external).
14
Changing Focus of Phases Over Time
Planned (Business) Decision Points
Scope and Business
Case agreement
(Understand the
problem)
Inception
Preliminary
Iteration
Architecture
baselined
(Understand the
solution)
Elaboration
Architecture
Iteration
Architecture
Iteration
Product sufficiently
mature for
customers to use
(Have a solution)
Construction
Development
Iteration
Development
Iteration
Transition
Development
Iteration
Planned (Technical) Visibility Points
15
Acceptance
or end of life
Transition
Iteration
Transition
Iteration
Changing Focus of Iterations Over Time
Iteration 1
Iteration 2
Req
Design
Impl
Test
Deploy
Time
16
Iteration 3
Duration of an Iteration
 An iteration begins with planning and
requirements and ends with an internal or
external release.
 Ideally an iteration should run from two to six
weeks, depending on your project size and
complexity.
 Factors that affect duration of an iteration:
 Size, stability and maturity of organization
 Familiarity with the iterative process
 Size of project
 Technical simplicity of project
 Level of automation used to manage code, distribute
information, perform testing
17
Number of Iterations
 Rule of thumb: Use 6 ± 3 iterations
Phase
Low
Medium
High
Inception
0
1
1
Elaboration
1
2
3
Construction
1
2
3
Transition
1
1
2
3
6
9
Total
18
Conditions that Increase the Number of Iterations
Inception
Elaboration
 Working with new
functionality
 Unknown business
environment
 Highly volatile scope
 Make-buy decisions
 Working with new system
environment (new
architectural features)
 Untested architectural
elements
 Need for system prototypes
Construction
Transition
 Lots of code to write and
verify
 New technology or
development tools
 Need for alphas and betas
 Conversions of customer
base
 Incremental delivery to
customers
19
One Iteration
Start Iteration Using
Iteration Plan
•Consider risks
Artifact: Iteration
Assessment
•Add Change
Control Boardapproved changes
Complete Planned
Iteration Work
Assess
Iteration
Project Stopped
Stop
Reduce risk
Continue
Adjust
Objectives
Accept
change
Adjust Target
Product
Steer project
Adjust Remaining
Plan
Plan Next
Iteration
Artifact: Iteration
Plan
Start Next Iteration
20
Artifact: Iteration Plan
A time-sequenced set of activities and tasks,
with assigned resources, and containing task
dependencies. A fine-grained plan, one per
iteration.
21
Iteration Plan Example
Outline of an
Iteration Plan
 Shows timeframes
and resources by
discipline
Iteration
Schedule section
for Requirements
discipline
22
Artifact: Iteration Assessment
The Iteration Assessment captures the result
of an iteration, the degree to which the
evaluation criteria were met, lessons learned,
and changes to be done.
23
Concepts That Drive Iterative Development
Some important concepts that affect iterative
development are:
 Early mitigation of risk
 Early baselining of architecture
 Use of objective metrics
24
Definition of Risk
An ongoing or upcoming concern that has a
significant probability of adversely affecting the
success of major milestones. (RUP Glossary)
Some Risk Types:
• Technical/Architectural risks
 Unproven technology, uncertain scope
• Resource risks
 People, skills, funding
• Business risks
 Competition, ROI, supplier interfaces
• Schedule risks
 Project dependencies
 Only 24 hours in a day
25
Need to be
identified and
prioritized in
Risk List
artifact.
Risk Terms
 Direct risk - the project has a large degree
of control
 Indirect risk - the project has little or no
control
 Risk Magnitude is used for ranking risks. It
is a combination of:
 Probability of occurrence
 Impact on the project (severity) e.g. project
delays
26
Risk Management Strategies
 Risk avoidance, risk transfer OR risk
acceptance
 Mitigate accepted risks by:
 Creating a Risk List artifact
 Taking some immediate, pro-active steps to
reduce the probability or the impact of the risk
 Defining a contingency plan
The Risk List is created early in Inception and
updated for every iteration.
27
Risk Profiles
Risk
Waterfall Risk
Risk Reduction
Iterative Risk
Time
28
Risk Reduction Drives the Iterative Lifecycle
 Early iterations should address the risks of
highest magnitude.
 Risk assessment is a continuous process;
risks change over time.
 An updated Risk List is input to the activity
Develop Iteration Plan.
29
More RUP Resources for Managing Risk
 Risk List artifact at Artifacts->Project
Management Artifact Set->Risk List
 Risk List Guideline and Risk Concept under
Artifacts->Project Management Artifact
Set->Risk List
 Risk Management Plan artifact at Artifacts>Project Management Artifact Set>Software Development Plan->Risk
Management Plan
30
An Executable Architecture
 A (testable) validation of the architecture
 Tested via architecturally-significant use cases
 The baseline for the rest of development
 Provides mitigation for numerous risks
Applicationspecific
Businessspecific
Middleware
Systemsoftware
31
Intellectual Control: 4+1 Architecture Views
Logical View
Analysts/Designers
Structure
Implementation View
End-user
Functionality
Programmers
Software management
Use-Case View
Process View
Deployment View
System integrators
Performance
Scalability
Throughput
System engineering
System topology
Delivery, installation
communication
32
Architecture Description
 Software Architecture Document
 Represents comprehensive overview of the
architecture of the software system
 Includes
• Architectural Views
• Goals and constraints
 Requirements that architecture must support
 Technical constraints
 Change cases
• Size and performance characteristics
• Quality, extensibility, and portability targets
33
Architecture Description (cont.)
 Views are pulled from other artifacts
Implementation Model
Deployment Model
Design Model
34
Architecture As a Basis for Project Management
 A stable architecture represents a
significant project milestone.
 Poor architecture is often a reason for
project failure.
 Architecture is a prerequisite for predictable
planning.
 Architecture is the source of numerous
high-payoff/high-risk decisions.
35
Early Baselining of Architecture
 Architecture
 drives the definition of phases
 drives the content of iterations
 drives team organization
 In RUP, you baseline your architecture at
the end of Elaboration, and refine your
architecture in following iterations.
36
More RUP Resources About Architecture
 Disciplines->Analysis and Design->
Concepts/Guidelines
 Software Architecture Document artifact
description at Artifacts->Analysis and Design
Artifact Set->Software Architecture Document
 Architecture-related guidelines at Artifacts ->
Analysis and Design Artifact Set-> Software
Architecture Document-> Guidelines
 Architecture-related concepts at Artifacts->
Analysis and Design Artifact Set-> Software
Architecture Document-> Concepts
37
Use of Objective Measurements
Measurements are used to provide the
development team with:
 An accurate assessment of progress to
date
 Insight into the quality of the evolving
software product
 A basis for estimating the cost and schedule
for completing the product with increasing
accuracy over time
Measurements should reflect the “real” state of what is
measured. Subjective measurements have much less value.
38
Use of Measurements in Iterations
Start Iteration Using
Iteration Plan
Complete Planned
Iteration Work
Measurements
Assess
Iteration
Project Stopped
Stop
Continue
Adjust
Objectives
Adjust Target
Product
Measurements are
used to assess
iterations.
They are built into the
Iteration Plan
evaluation criteria.
Adjust Remaining
Plan
Plan Next
Iteration
Start Next Iteration
39
Measurements Collection
Measurements should:
 Be simple and objective
 Be easy to collect
 Be easy to interpret and hard to misinterpret
Measurements collection should:
 Be automated and non-intrusive for developers
 Contribute to quality assessment early in the lifecycle, when efforts to
improve software quality are effective
Measurements absolute values and trends should:
 Be actively used to communicate progress and quality in a consistent
format
The selection of a set of measurements will depend
on the project's characteristics and context.
40
Seven Core Metrics
There are seven core metrics that should be used in
iterative development:
Management Indicators:
1. Work and progress (work performed over time)
2. Budgeted cost and expenditures (cost incurred over time)
3. Staffing and team dynamics (personnel changes over time)
Quality Indicators:
4. Change traffic and stability (change traffic over time)
5. Breakage and modularity (average breakage per change over
time)
6. Rework and adaptability (average rework per change over time)
7. Mean time between failures (MTBF) and maturity (defect rate
over time)
41
Purpose of Seven Core Metrics
Metric
Purpose
Work and progress
Iteration planning, plans vs. actuals, management indicator
Budgeted cost and expenditures
Financial insight, plan vs. actuals, management indicator
Staffing and team dynamics
Resource plan vs. actuals, hiring rate, attrition rate
Change traffic and stability
Iteration planning, management indicator of schedule
convergence
Breakage and modularity
Convergence, software scrap, quality indicator
Rework and adaptability
Convergence, software rework, quality indicator
MTBF and maturity
Test coverage/adequacy, robustness for use, quality
indicator
42
Metrics Over Phases
The metrics shown in the previous slide will evolve across the
lifecycle of the project. A mature organization will be able to
describe much more precise targets.
Examples:
Metric
Inception
Elaboration
Construction
Transition
Expenditures
Effort
Schedule
Low
5%
10%
Moderate
25%
40%
High
90%
90%
High
100%
100%
Stability
Architecture
Applications
Volatile*
Volatile
Volatile
Moderate*
Moderate
Volatile
Moderate*
Stable
Moderate
Stable*
Stable
Stable
*Objective measure must be defined.
43
More Resources About Measurements
 In RUP
 Metrics guideline at Artifacts->Project Management
Artifact Set->Software Development Plan->
Measurement Plan-> Metrics (Guideline)
 Metrics concept at Roles and Activities->Managers>Project Manager->Assess Iteration->Metrics
(Concept)
 Rational® ProjectConsole
 Collects metrics from Rational tools and other sources
 Displays metrics in form of charts, bar graphs, and so
on
44
Characteristics of Iterative Development
 You can control allocation of resources by
phase.
 You can evolve artifacts as required by
phase.
 You can increase the precision of your cost
estimates from phase to phase.
45
Typical Effort and Time Percentages by Phase
People
Inc
Elab
Const
Trans
Time
Effort
Time/Schedule
Inc
5%
10%
Elab
20%
30%
46
Const
65%
50%
Trans
10%
10%
Lifecycle Evolution of Artifacts
With the iterative approach, artifact sets mature over time.
47
Cost Estimate Fidelity
Error in Cost to Complete Estimate
4X
Over-estimated
0
Inception
Elaboration
Construction
Under-estimated
X/4
48
Transition
Review
The Rational Unified Process:
 Is divided into four phases, each with a distinct milestone. These
phases are further divided into iterations.
 Addresses several areas of concern (disciplines) repeatedly in each
phase. Each area is addressed at different levels in each phase.
 Contains artifacts that help you plan and assess each iteration.
 Contains information and guidance to help you address the major
concerns in iterative development. These major concerns are:
• Early mitigation of risk
• Early executable architecture
• Use of objective measurements for planning
 Allows you to control allocation of resources by phase, to evolve
artifacts as required by phase, and to increase the precision of your
cost estimates from phase to phase.
49
Exercise: Student Exploration of RUP
 15 minute student exploration of RUP to review module.
Explore:
 RUP Lifecycle
• Inception
• Elaboration
• Construction
• Transition
 Iteration Plan artifact description and related guidelines/concepts
 Iteration Assessment artifact description and related
guidelines/concepts
 Risk resources
 Architecture resources
 Measurements/Metrics resources
50