Chapter 2
Iterative, Evolutionary, and Agile
You should use iterative development only
on projects that you want to succeed. Martin Fowler
CS6359 -- John Cole
1
Waterfall Development
• Communication: project initiation;
requirements gathering
• Planning: estimating; scheduling; tracking
• Modeling: analysis, design
• Construction: code, test
• Deployment: delivery, support, feedback
CS6359 -- John Cole
2
Unified Process
•
•
•
•
Iterative and Incremental
Use Case Driven
Architecture Centric
Risk Focused
CS6359 -- John Cole
3
Iterative Development
•
•
•
•
Development is in short cycles, or iterations
Each one is tested and integrated
Each one gives an executable partial system
Feedback from each iteration leads to
refinement and adaptation of the next.
CS6359 -- John Cole
4
Handling Change
• “Change is good. Hard cash is better.” John
Cole
• Don’t fight changes to the software
• Let users guide the development
• They cannot tell you what they do not know
CS6359 -- John Cole
5
Benefits of Iterative
•
•
•
•
Fewer failures, lower defect rates
Early mitigation of high risks
Early visible progress
Early feedback, user engagement, and
adaptation
• Managed complexity: team sees small pieces
at a time
• Use of learning within an iteration
CS6359 -- John Cole
6
Feedback
• From early development, programmers
reading specs, and users, refine requirements
• From tests and developers refine the design or
models
• From the progress of the team writing early
features to refine the schedule and estimates
• From the client and market to re-prioritize
features for the next iteration
CS6359 -- John Cole
7
Risk-Driven and Client-Driven Planning
• Identify and minimize highest risks
• Build visible features client wants most.
CS6359 -- John Cole
8
The Agile Manifesto
We Value
Individuals and interactions
over processes and tools
Working software
over comprehensive documentation
Customer collaboration
over contract negotiation
Responding to change
over following a plan
That is, while there is value in the items on the right, we value
the items on the left more.
CS6359 -- John Cole
9
Agile Modeling
• The purpose of modeling is to understand, not
to document
• Purpose is not for designer to create UML
diagrams that are then given to a programmer.
• Don’t model or apply the UML to all or most
of the design. Use it for unusual, difficult, or
tricky parts.
• Use simplest tools possible
CS6359 -- John Cole
10
Agile Modeling (2)
•
•
•
•
Don’t model alone
Create models in parallel
Use “good enough” simple notation
Know that all models are inaccurate; the final
arbiter of the design is the code
• Developers should do the OO design modeling
for themselves, not other programmers
CS6359 -- John Cole
11
Agile Modeling (3)
• Use a small set of UP activities and artifacts
• There is no detailed plan for the entire
project. There is a high-level plan that
estimates the end date and other milestones
CS6359 -- John Cole
12
Critical UP Practices
•
•
•
•
•
•
•
•
Tackle high-risk and high-value activities early
Continuously engage users
Build cohesive core architecture early
Test early, often, and realistically
Apply use cases where appropriate
Do visual modeling
Carefully manage requirements
Practice change request and configuration
management.
CS6359 -- John Cole
13
UP Phases
• Inception: approximate vision, business case,
scope, vague estimates
• Elaboration
• Construction
• Transition
CS6359 -- John Cole
14
UP Disciplines
• Business modeling – visualize concepts in the
application domain
• Requirements – Use case model and
supplementary specifications to capture
functional and non-functional requirements
• Design
• Implementation
• Test
• Deployment
• Configuration and change management
CS6359 -- John Cole
15
Customizing the UP
• Most activities and artifacts are optional
• Choose the ones that make sense for your
project
CS6359 -- John Cole
16