The document discusses iterative and agile software development processes. It describes some limitations of traditional waterfall models, noting that software requirements often change and feedback is needed from early development stages. Iterative development processes are presented as an alternative, with development occurring in short iterations of 2-6 weeks to incorporate feedback. Specific agile methods like Scrum and Extreme Programming are discussed as examples that implement iterative principles through practices like daily standups, pair programming, and test-driven development. The Unified Process is also introduced as a customizable framework that uses iterative phases and disciplines to structure agile development activities.

1. http://flic.kr/p/7u4Xr2
Iterative and Agile
Development

2. Engineering software is a big job
Variety of tasks:
• Requirements
• Design
• Implementation
• Verification (testing)
• Maintenance
http://flic.kr/p/5w9rXP
http://flic.kr/p/7GereG

3. Practical issue:
What order should tasks be done in?
That is, what process to use?
http://flic.kr/p/9ksxQa

4. http://en.wikipedia.org/wiki/File:Waterfall_model_%281%29.svg
The old way: Waterfall (sequential) model

5. Using Waterfall turns out to be a poor practice
• High failure rates
• Low productivity
• High defect rates
45% of features
in requirements
never used
Early schedule
and estimates
off by up to 400%
Statistic:
Statistic:

6. http://flic.kr/p/9ksxQa
Why doesn’t Waterfall work?
To find out, let’s
read a passage from
Schwaber and Beedle (2001*)
*Agile Software Development with Scrum

7. Why Waterfall doesn’t work
False assumption:
Specifications predictable and stable,
and can be correctly defined at the start,
with low change rates
25% change in
requirements 35% to 50% change
for large projects
Statistic:
Statistic:

8. Waterfall is a “defined”
process control model
http://flic.kr/p/9xmccb
(think mass manufacturing)
http://flic.kr/p/4Xt7Xe
Software development
needs an “empirical” model
(think new product development)

9. Basis of empirical process model:
Feedback and adaptation
• Feedback from early development
– Programmers reading specifications
– Client demos
• Feedback from tests to refine
design/implementation
• Feedback from progress to refine
schedules/estimates
• Feedback from client/marketplace
to refine/re-prioritize features
Feedback
Adaptation

10. Larman Figure 2.1
Iterative and incremental development
also called iterative and evolutionary

11. 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

12. 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.

13. 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.

14. Larman Figure 2.2
System converges over time

15. 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

16. 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

17. What is an agile method?
Where does it come from?
Agile values,
principles
Agile method
values,
principles,
practices
beget
Types of advice
more specific
more general
values principles practices

18. Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Recall: Agile Values
From the Agile Manifesto
http://flic.kr/p/6Ag67y

19. Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Can you think of a principle and a practice
that might be based on the agile values?
http://flic.kr/p/9ksxQa

20. Examples of agile methods and their practices
• Scrum
– Common project workroom
– Self-organizing teams
– Daily scrum
– …
• Extreme programming (XP)
– Pair programming
– Test-driven development
– Planning game
– …
http://flic.kr/p/8Mbo3N

21. 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

22. 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

23. Larman Figure 2.6
Phases of UP (cont’d)

24. 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)

25. Larman Figure 2.7
Discipline activity across iterations

26. Larman Table 2.1
Disciplines/artifacts across phases
s = started r = refined

27. A word about agile modeling
(quoting Larman)
Experienced analysts and
modelers know the
secret of modeling:
Thus, we favor hand-drawn
diagrams over typeset ones
The purpose of modeling
(sketching UML, …) is
primarily to understand,
not to document.
http://flic.kr/p/7SFKjj

28. 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