Iterative and Agile
Development
Nha Tran
Engineering software is a big job
Variety of tasks:
• Requirements • Verification (testing)
• Design • Maintenance
• Implementation
http://flic.kr/p/7GereG http://flic.kr/p/5w9rXP
Practical issue:
What order should tasks be done in?
That is, what process to use?
http://flic.kr/p/9ksxQa
The old way: Waterfall (sequential) model
http://en.wikipedia.org/wiki/File:Waterfall_model_%281%29.svg
Using Waterfall turns out to be a poor practice
• High failure rates
• Low productivity
• High defect rates
Statistic:
45% of features Statistic:
in requirements Early schedule
never used and estimates
off by up to 400%
Why doesn’t Waterfall work?
To find out, let’s
read a passage from
Schwaber and Beedle (2001*)
http://flic.kr/p/9ksxQa *Agile Software Development with Scrum
Why Waterfall doesn’t work
False assumption:
Specifications predictable and stable,
and can be correctly defined at the start,
with low change rates
Statistic:
25% change in Statistic:
requirements 35% to 50% change
for large projects
Waterfall is a “defined”
process control model
(think mass manufacturing)
Software development
needs an “empirical” model
(think new product development)
http://flic.kr/p/4Xt7Xe http://flic.kr/p/9xmccb
Basis of empirical process model:
Feedback and adaptation
Feedback from early development
Programmers reading specifications
Client demos Feedback
Feedback from tests to refine
design/implementation
Feedback from progress to refine
schedules/estimates
Feedback from client/marketplace to refine/re-
prioritize features
Adaptation
Iterative and incremental development
also called iterative and evolutionary
Larman Figure 2.1
How long should iterations be?
Short is good
2 to 6 weeks
1 is too short to get meaningful feedback
Long iterations subvert the core motivation
http://flic.kr/p/368zW7
Example from Larman
As an example (not a recipe), in a two-week iteration half-way
through a project, perhaps:
• Monday is spent primarily on distributing and clarifying the
tasks and requirements of the iteration, while one person
reverse-engineers the last iteration's code into UML diagrams
(via a CASE tool), and prints and displays noteworthy
diagrams.
• Tuesday is spent at whiteboards doing pair design work
drawing rough UML diagrams captured on digital cameras,
and writing some pseudocode and design notes.
• The remaining eight days are spent on implementation,
testing (unit, acceptance, usability, ...), further design,
integration, daily builds, system testing, and stabilization of
the partial system.
• Other activities include demonstrations and evaluations with
stakeholders, and planning for the next iteration.
Iterative and incremental development
addresses the “yes…but” problem
Yes, that’s what I
asked for, but now
that I try it, what
I really need is
something slightly
different.
System converges over time
Larman Figure 2.2
More benefits of iterative
development
Less failure, better productivity, fewer defects
Early mitigation of risk
Early visible progress
Better meet real needs of stakeholders
No “analysis paralysis”
Iterative process improvement
http://flic.kr/p/7fD777
Iterative and incremental development
is a broad approach
But how to operationalize?
To help with that, there are
more specific methods and practices
In particular, there are agile methods
What is an agile method?
Where does it come from?
Types of advice
more general more specific
values principles practices
values,
Agile values, beget
Agile method principles,
principles
practices
Recall: Agile Values
From the Agile Manifesto
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
http://flic.kr/p/6Ag67y
Can you think of a principle and a practice
that might be based on the agile values?
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
http://flic.kr/p/9ksxQa
Examples of agile methods
and
Scrum
their practices
Common project workroom
Self-organizing teams
Daily scrum
…
Extreme programming (XP)
Pair programming
Test-driven development
Planning game
…
http://flic.kr/p/8Mbo3N
So what is this UP thing that
Larman keeps talking about?
UP = Unified Process
See also Rational Unified Process (RUP; IBM’s refinement)
Process framework
Customizable: other methods/practices can be plugged in
Agile methods for example!
But has some practices of its own as well
Iterative and incremental
Defines phases across series of iterations
Phases of UP
Inception: Approximate vision, business case, scope,
vague estimates
Elaboration: Refined vision, iterative implementation of
core architecture, resolution of high risks, most
requirements, more realistic estimates
Construction: Iterative implementation of remaining
lower risk and easier elements, prep for deployment
Transition: Beta tests, deployment
Phases of UP (cont’d)
Larman Figure 2.6
UP Disciplines
Set of activities in one subject area
Examples:
Business modeling
Requirements
Design
Test
Each discipline typically associated with particular
artifacts (e.g., code, models, documents)
Discipline activity across iterations
Larman Figure 2.7
Disciplines/artifacts across phases
s = started r = refined
Larman Table 2.1
A word about agile modeling
(quoting Larman)
Experienced analysts and
modelers know the
secret of modeling:
The purpose of modeling
(sketching UML, …) is
primarily to understand,
not to document.
Thus, we favor hand-drawn
diagrams over typeset ones
http://flic.kr/p/7SFKjj
You know you’re doing UP wrong
when…
Define most requirements before starting design or
implementation
Spend days/weeks modeling before programming
Think inception=requirements, elaboration=design,
construction=implementation
Think elaboration is to fully define models
Believe that iterations should be 3 months
Think you need to create many formal documents
Try to plan project in detail from start to finish
http://flic.kr/p/6FJZDY
