Iterative Project
Management
Chapter 7.2 – Evolution and Phase Planning
Modified considerably by your Instructor
Overview: Iterations Across The Lifecycle
• Inception
– Executable release optional
Early iterations address:
– May only be one iteration
• High risks
• Elaboration
• Stability
– Demonstrate critical use cases
• Understanding
– Result in executable architecture
• Construction
– Result in usable software
– Typically two or more iterations
• Transition
– Releases based on feedback and fixes
© 2005 Ivar Jacobson International
Late iterations address:
•Functionality
•Performance
•Robustness
Iterative Project Management / 04 - Phase Planning and Assessment
2
Planning an Evolution:
Iteration Patterns – To show different Strategies…
•
•
•
•
•
Incremental Development
Evolutionary Development
Incremental Delivery
Extreme Programming / No Elaboration
Immediate Construction / Virtual Phases
© 2005 Ivar Jacobson International
Iterative Project Management / 04 - Phase Planning and Assessment
3
An Incremental Development Strategy (1 of 2)
• This is the ‘ideal’ iteration pattern offering all the benefits of ‘rapid
application development’ (RAD) without the risks. (Slide next page)
• “The incremental strategy determines user needs and defines the system
requirements, then performs rest of development in a sequence of builds.
• The first build incorporates parts of the planned capabilities, the next build
adds more capabilities, and so on until the system is complete.” [Software
Development and Documentation, MIL-STD-498, U.S. Department of Defense, 12/1994]
•
•
•
•
•
The following iterations are characteristic:
a short Inception iteration to establish scope, vision; define business case
a single Elaboration iteration; requirements defined, architecture established
several Construction iterations; use cases realized, architecture fleshed-out
several Transition iterations, migrate product into the user community
•
© 2005 Ivar Jacobson International
Iterative Project Management / 04 - Phase Planning and Assessment
4
Incremental Development - Strategy
Resources
Conceptual Architectural
Prototype Baseline
Inception
Elaboration
Release
Construction
Delivery
Transition
Time
This strategy is appropriate when:
• Problem domain is familiar.
• Architecture is already proven / familiar
• Risks well understood and under control
• Team is experienced.
• A RAD approach….
© 2005 Ivar Jacobson International
Iterative Project Management / 04 - Phase Planning and Assessment
5
Evolutionary Development – Strategy (1 of 2)
• This is the pattern that most team’s first iterative and incremental
evolution conforms to. (Slide next page)
• "The evolutionary strategy differs from the incremental in acknowledging
user needs are not fully understood, and requirements cannot be
defined up front,
– Requirements are refined in each successive build." [MIL-STD-498]
• The following iterations are characteristic:
• Short Inception iteration - establish scope, vision; define business case
• Several Elaboration iterations; requirements refined at each iteration and
the architecture evolved
• One or two Construction iterations; use cases realized, architecture is
expanded upon; the application given a final polish
• Several Transition iterations to migrate product into user community
•
© 2005 Ivar Jacobson International
Iterative Project Management / 04 - Phase Planning and Assessment
6
Evolutionary Development
Resources
Conceptual
Prototype
Inception
Architectural Release
Baseline
Elaboration
Const’n
This strategy is appropriate when:
• Problem domain - new or unfamiliar.
• Architecture - new or unfamiliar
• Iterative development - new or unfamiliar
• Team - inexperienced.
•
Delivery
Transition
Time
all high risk
factors…
(note: number of iterations only for illustrative purposes)
© 2005 Ivar Jacobson International
Iterative Project Management / 04 - Phase Planning and Assessment
7
An Incremental Delivery Strategy…(1 of 2)
• Pattern where multiple deliveries provided to customer is quite common for
Internet site development where new content releases are expected monthly
• May be required for tight time-to-market pressures, where delivery of certain
key features early can yield significant business benefits. [Tom Gilb, Principles of
Software Engineering Management, Wokingham, Addison-Wesley, 1988].
• In terms of the phase-iteration approach, the transition phase begins early
on and has the most iterations.
•  Strategy requires a very stable architecture, which is hard to achieve
in an initial development cycle, for an "unprecedented" system.
• The following iterations are characteristic:
• Short Inception iteration: establish scope, vision: define business case
• Single Elaboration iteration - a stable architecture is baselined
• Single Construction iteration: use cases realized; architecture fleshed-out
• Several Transition iterations each of which delivers a new release of the
product (with increased functionality) into the user community
© 2005 Ivar Jacobson International
Iterative Project Management / 04 - Phase Planning and Assessment
8
Incremental Delivery Strategy (2 of 2)
Resources
Conceptual Architectural Delivery
Prototype Baseline
Inception
Elaboration
Const’n
Delivery
Delivery
Delivery
Transition
Delivery
Delivery
Time
This strategy is appropriate when:
• Small increments have high value to the customer.
• The architecture is already proven and familiar
• The requirements are stable and low risk
• The team is experienced in the architecture and the
domain
© 2005 Ivar Jacobson International
Iterative Project Management / 04 - Phase Planning and Assessment
9
Immediate Construction / Virtual Phases (1` of 2)
• In some cases, anchor point milestones can be merged.
• A project deciding to use a mature and appropriately scalable
4th generation language (4GL) or product line framework will
have already determined its choice of life cycle architecture by
its LCO milestone enabling the LCO and LCA milestones to
be merged.
• As Barry Boehm observed, in his paper Spiral Development:
Experience, Principles and Refinements (CMU/SEI-2000-SR-008),
• Merging of the milestones is often compounded by the fact that
another project (typically a feasibility project or the previous
release) has already done the work for you.
• Leads to pattern appearing like no Inception or Elaboration
• In this case the phases have been suppressed but the
milestones are still there, with the reviews being undertaken
before the set of construction iterations can commence.
© 2005 Ivar Jacobson International
Iterative Project Management / 04 - Phase Planning and Assessment
10
Immediate Construction / Virtual Phases (2 of 2)
Resources
First
Release
Delivery
LCO and LCA
Passed
Construction
Transition
Time
This strategy is appropriate when:
• Architecture already proven and familiar
• Requirements are known and of low technical risk
• Team is experienced in the architecture and the domain
• Project is collaborative and informal
© 2005 Ivar Jacobson International
Iterative Project Management / 04 - Phase Planning and Assessment
11
No Elaboration Strategy
• This is another variant where milestones have been merged
providing impression of no Elaboration Phase.
• Enter most ‘Extreme Programming’ and SCRUM projects
Architecture is a given at the start of the set of
development iterations.
• Architecture can be adjusted by refactoring during
Construction but this is typical of most iterative and
incremental projects post LCA.
• Some Extreme Programming authors, most noticeably
Martin Fowler, would allow technical concerns to affect the
allocation of work to the initial development iterations
creating an informal Elaboration Phase.
© 2005 Ivar Jacobson International
Iterative Project Management / 04 - Phase Planning and Assessment
12
Agile’s Terminology – via Kent Beck
• Note In Agile and Iterative Development a Manager’s Guide, the XP Lifecycle
phases as defined by Beck are described as:
• Exploration - Purpose: Enough well-estimated story cards for first release,
feasibility ensured.
– Activities: Prototypes, exploratory proof of technology programming, story card
writing and estimating
• Planning - Purpose: Agree on date and stories for first release.
– Activities: Release Planning Game, story card writing and estimating
• Iterations To First Release - Purpose: Implement a tested system ready for
release.
– Activities: testing, programming, Iteration Planning Game, task writing, estimating
• Productionizing - Purpose: Operational deployment.
– Activities: documentation, training. marketing ….
• Maintenance - Purpose: Enhance, fix, build major releases.
– Activities: May include these phases again for incremental releases
• These have been mapped to the UP phases for the purpose of this example
© 2005 Ivar Jacobson International
Iterative Project Management / 04 - Phase Planning and Assessment
13
No Elaboration
Resources
Start Development
Iterations / First Release
Date Agreed
Inception
Construction
Release
Delivery
Transition
Time
This strategy is appropriate when:
• Architecture is already proven and familiar
• Requirements are known and of low technical risk
• Team is experienced in the architecture and the domain
• Project team is small; project is collaborative and informal
© 2005 Ivar Jacobson International
Iterative Project Management / 04 - Phase Planning and Assessment
14
Typical Iteration Patterns for Multiple Release
In practice you often end up with a hybrid, some evolution at the beginning,
some incremental building, and multiple deliveries.
Immediate Construction (2)
Evolutionary (1)
Resources
Resources
Conceptual
Prototype
Ince
ption
Architectural Release
Baseline
Const’n
Elaboration
LCO and
LCA
Passed
Transition
Construction
Time
Delivery
Transition
Time
Incremental delivery (4)
Incremental (3)
Resources
Resources
Conceptual Architectural
Prototype
Baseline
Inception
First
Release
Delivery
Elabor
ation
© 2005 Ivar Jacobson International
Release
Construction
Delivery
Transition
Time
Conceptual Architectural Delivery
Prototype
Baseline
Inception Elaborati
on
Const’n
Iterative Project Management / 04 - Phase Planning and Assessment
Delivery
Delivery
Delivery
Transition
Delivery
Delivery
Time
15
Think:
• Among the advantages of the Unified Process phased iterative model
is that it lets you accommodate a hybrid approach, simply by increasing
the length and number of iterations in particular phases:
• For complex or unfamiliar problem domains, where there is a high
degree of exploratory business work required: increase the length of,
and the number of iterations in, the inception phase.
• For complex or unfamiliar technology problems, where there is a
high degree of technological exploratory work required: increase the
length of, and the number of iterations in, the elaboration phase.
• For more complex development technologies, where there is
complexity translating the requirements and design into code: increase
the length of, and the number of iterations in, the construction phase.
• To deliver software in a series of frequent incremental releases:
increase the length of, and the number of iterations in, the transition
phase.
© 2005 Ivar Jacobson International
Iterative Project Management / 04 - Phase Planning and Assessment
16
How To Use The Iteration Patterns
• Think about your risks
• Think about your team’s skills and experience
• Think about where your project is in the lifecycle
• Select a pattern as a reference model
– Don’t be scared to adjust the model
– You may require a hybrid pattern
© 2005 Ivar Jacobson International
Iterative Project Management / 04 - Phase Planning and Assessment
17
How To Use The Numbers
• Use the numbers to challenge your plans and estimates
– The numbers are for “typical projects”
– You should be able to explain why your project doesn’t conform
• The numbers for Inception and Transition carry least weight:
– These can vary massively depending on the nature of the project
– These figures are not part of the COCOMO statistical model
• Elaboration should be small in comparison to Construction
when considered across the entire endeavor
– Architecture is the most important 20% of the development
– Elaboration may be relatively large in early project evolutions
The only thing we know for certain about your
project is that it is not typical
© 2005 Ivar Jacobson International
Iterative Project Management / 04 - Phase Planning and Assessment
18
Some Hints and Tips
•
•
•
•
•
Name Iterations – they have a theme
Number iterations within phases.
Make milestones real to the business
Give project a heartbeat
Be prepared to adjust iteration numbers and lengths
based on lessons learned
• Anything beyond the next iteration is only a sketch
•  You cannot create a concrete plan until the end of
Elaboration – there are too many unknowns
© 2005 Ivar Jacobson International
Iterative Project Management / 04 - Phase Planning and Assessment
19
Effort By Phase By Discipline
Development
EIA Stage
Inception
Elaboration
Construction
Transition
Management
14%
12%
10%
14%
Environment /
CM
10%
8%
5%
5%
Requirements
38%
18%
8%
4%
Analysis &
Design
19%
36%
16%
4%
Implementation
(Code & Unit
Test)
8%
13%
34%
19%
Assessment
8%
10%
24%
24%
Deployment
3%
3%
3%
30%
Note: COCOMO II uses Design instead of Analysis and Design. Analysis is not mentioned in the breakdown.
© 2005 Ivar Jacobson International
Iterative Project Management / 04 - Phase Planning and Assessment
20
What Gets Produced?
The Key Development Products
© 2005 Ivar Jacobson International
Iterative Project Management / 04 - Phase Planning and Assessment
21
The 10 Essentials of RUP
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Vision – Develop a Vision
Plan – Manage to the Plan
Risks – Identify and Mitigate Risks
Issues – Assign and Track Issues
Business Case – Examine the Business Case
Architecture – Design a Component Architecture
Product – Incrementally Build and Test the Product
Evaluation – Regularly Assess Results
Change Requests – Manage and Control Change
User Support – Provide Assistance to the User
Source: The Ten Essentials of RUP – The Essence of an Effective Development Process, Leslee Probasco, Rational Software White Paper
© 2005 Ivar Jacobson International
Iterative Project Management / 04 - Phase Planning and Assessment
22
Phase Review
• What to look for at a Phase Review
–
–
–
–
–
–
–
Why
What
When
Who
Where
How
How Much
The Phase Reviews are stakeholder decision points.
A go / no go decision is made based upon the
business case, risks, progress and plans.
© 2005 Ivar Jacobson International
Iterative Project Management / 04 - Phase Planning and Assessment
23
Phases and Use Cases
By the end of:
Use-Case
State
Inception
Elaboration
Construction
Transition
Identified
60%
> 80%
100%
100%
Outlined
50%
20% - 60%
0%
0%
Described
10%
40% - 80%
100%
100%
Analyzed
< 10% *
20% - 40 %
100%
100%
Designed,
Implemented
and Verified
< 5% *
< 10%
100%
100%
* A small percentage may be addressed for proof of concept purposes.
Source: Adapted from The Unified Software Development Process, Jacobson et al (page 358).
© 2005 Ivar Jacobson International
Iterative Project Management / 04 - Phase Planning and Assessment
24
Summary / Conclusion
• Each Phase is driven by a different set of forces
–
–
–
–
Inception – Business risks
Elaboration – Technical risks
Construction – Project logistical risks
Transition – Solution roll-out risks
• Each phase needs to be managed a little differently
– Each phased requires a different mixture of skills and levels of
resources; it is not unreasonable to expect that different teams may
staff each phase so long as there is a continuity of vision and
expertise across phases
• Be rigorous about phase-end milestones
– Do not move to next phase until you have met milestone objectives
– Don’t be pressured by the schedule into “declaring victory” – you will
pay for it later!
© 2005 Ivar Jacobson International
Iterative Project Management / 04 - Phase Planning and Assessment
25