Date post: | 02-Jan-2016 |
Category: |
Documents |
Upload: | ramona-smith |
View: | 13 times |
Download: | 0 times |
Chapter 2
Iteration
• The most import aspect of OOA/D• An agile practice
• vs waterfall – early and repeated programming, feedback, adaptation
• waterfall is the opposite – big up front requirements investment
http://en.wikipedia.org/wiki/Agile_software_development
Unified Process (UP)
• one iterative approach• RUP is UP using Rational• incorporates from other iterative methods like XP• features iterative lifecycle and risk-driven development• is a model/example for how to do OOA/D
• incorporates book’s central ideas – how to think about objects, applying UML, using design patterns, agile modeling, evolutionary approach, use cases, etc.
“This book is an introduction to an agile approach to UP”
short time boxes; attack core
What is it?
• development organized is a series of short, fixed-length mini-projects called iterations.
• each mini-project results in tested, integrated, executable partial programs
• each mini-project has its own requirements analysis and design, implementation and testing phases
• complete project implemented by successive enlargement and refinement
• feedback and adaptation at the end of a mini-project is crucial.
• both iterative and incremental as well as iterative an evolutionary
Fig. 2.1
Requirements
Design
Implementation &Test & Integration
& More Design
Final Integration & System Test
Requirements
Design
3 weeks (for example)
The system grows incrementally.
Feedback from iteration N leads to refinement and adaptation of the requirements and design in iteration N+1.
Iterations are fixed in length, or timeboxed.
Time
Implementation &Test & Integration
& More Design
Final Integration & System Test
Example (three week iteration):
• Monday AM, kick-off meeting, clarify tasks and goals• meanwhile reverse engineer last iteration’s code into
UML diagrams• Monday PM, whiteboard work in pairs, UML diagrams
captured with digital camera, some pseudocode, notes• next three weeks – coding, testing, design, integration,
daily builds• NOTES:
– requirements/design part of each iteration– after three weeks, something should execute– output is NOT experimental or throw-away, this is not
prototyping
Handling Change
• Embrace it
• Don’t try to avoid change by being “complete” up front• adaptation drives success
• should not be uncontrolled (feature creep), must be disciplined
• keep to small subset of requirements, quick coding, early feedback, be ready for change
I have always found that plans are useless, but planning is indispensable.
- Dwight Eisenhower
US Patent: Gives protection but only if you disclose all.
Value of Feedback
• Can’t be underestimated. Yes, some new features will be added but mostly it will clarify requirements
• Example, load testing could show fundamental approach is not scalable.
• Early on, you see more deviation caused by feedback, later on, less
Fig. 2.2
Early iterations are farther from the "truepath" of the system. Via feedback andadaptation, the system converges towardsthe most appropriate requirements anddesign.
In late iterations, a significant change inrequirements is rare, but can occur. Suchlate changes may give an organization acompetitive business advantage.
one iteration of design,implement, integrate, and test
Benefits:
• less project failure, better productivity, fewer defects• early mitigation of high risks• early visible progress• early feedback• managed complexity (bite-sized chunks)• learned in one iteration, used in next
How long should an Iteration be?
• usually two to six weeks• regardless, fix the time (timeboxed)
What about Waterfall?
• decidedly sequential• requirements before programming• too much time invested in UML diagrams that change• high failure rates, defect rates• 45% of requirements never used• schedule varies up to 400%• need to avoid “waterfall” thinking in our project (let’s write
all the use cases first) or (let’s design all our classes with UML before we code)
Why Waterfall Fails:
• false assumption: specifications are predictable and stable (remember Churchill) and can be correctly defined at the start
• typical is 25% change in requirements, more in big projects
• change is the only constant so feedback and adaptation are essential but considered necessary in waterfall
Fig. 2.3
0
5
10
15
20
25
30
35
40
10 100 1000 10000Project Size in Function Points
Req
uire
men
ts c
hang
e
How to do Iterative:
• analysis and design are essential starting points, just don’t try to be complete
• A recipe: – before 1st iteration meet with business people and
decide list of use-case names, non-functional features– pick 10% of use-cases with these qualities
• significant, high business value, high risk– do detailed analysis on these 10%– select a subset of the 10% for design and
implementation (3-week timebox)– list the tasks of this iteration
How to do Iterative (2):
• Iteration 1:– days 1 & 2: modeling and design work in pairs,
whiteboarding, UMP, use a war room– after day 2: put on your programming hat – program, test,
integrate– various levels of testing – unit, acceptance, load,
usability, …– 1 week to go: check if iteration goals met; if not, scale
down expectations (create “to do” list). NOTE: You will almost certainly only have a fraction of coding done.
– 4 days to go: freeze code, check into CVS– 3 days to go: demo– rest: get ready for next iteration (next slide)
How to do Iterative (3):
• After Iteration 1:– do second requirements workshop; review results of
last iteration, identify another 10% of the requirements that you will work on (most significant, etc) and analyze them in detail
– at this point up to 25% of requirements are detailed– last day: planning day for next iteration
• Iteration 2:– do it as before
• Repeat for a couple more iterations– we now have 80% of detailed requirements but only
10% of code
How to do Iterative (4):
• After 4 Iterations:– 20% of iterations done– in UP this is called the end of the elaboration phase.– time to estimate what is needed to complete detailed
requirements (should be good estimates)– no more requirements; 3-week iterations until you are
done.
Fig. 2.4
Iteration 1 Iteration 2 Iteration 3 Iteration 4 Iteration 5
20%
2%
requ
irem
ent
s
soft
war
e30%
5%
requ
irem
ent
s
soft
war
e
50%
8%
90% 90%
20%10%
requirements workshops
Imagine this will ultimately be a 20-iteration project.
In evolutionary iterative development, the requirements evolve over a set of the early iterations, through a series of requirements workshops (for example). Perhaps after four iterations and workshops, 90% of the requirements are defined and refined. Nevertheless, only 10% of the software is built.
1 2 3 4 5 ... 20
week 1
M T W Th F
week 2
M T W Th F
week 3
M T W Th F
kickoff meeting clarifying iteration goals with the team. 1 hour
team agile modeling & design, UML whiteboard sketching.5 hours
start coding & testing
a 3-week iteration
de-scope iteration goals if too much work
final check-in and code-freeze for the iteration baseline
demo and 2-day requirements workshop
next iteration planning meeting;2 hours
Most OOA/D and applying UML during this period
Use-case modeling during the workshop
What is Risk-Driven and Client-Driven Planning?
• Risk-Driven: early iterations driven by high risk requirements
• Client-Driven: early iterations driven by what client cares most about
• NOTE: Our book chooses iteration activities based on pedagogical issues; not high risk.
What are Agile Methods and Attitudes?
• Agile development uses timeboxed, iterative and evolutionary approaches.
• Use adaptive approaches, incremental delivery, encourage speed and flexibility
• Some practices: – common project workroom, – self-organizing teams
• read Agile Manifesto and Agile Principles on page 29
www.agilealliance.org
What is Agile Modeling?
• Secret of Modeling: to understand not document
(why I say using Visio for 1st pictures is ok)• purpose of UML is to give you well-defined language in
which to develop your understanding• together these make up “agile modeling”
Consequences:
• not about avoiding modeling• modeling to support understanding• don’t use UML everywhere; too time consuming• follow the “simplest tool” approach• work in pairs; switch roles• create models in parallel (use case || sequence diagram)• use “good enough” notation; reduce UML• realize your understanding will be imperfect; fill in the
details later• developers should do their own design; letting others
design for you is “waterfall”
Fig. 2.5 intersystem collaboration understanding
What is Agile UP?
• UP is big; pick a small subset of activities you like best• UP is iterative and evolutionary so agile by nature• follow agile modeling practices• not a detailed plan for entire project; Iteration Planning is
done one iteration at a time
Other UP Practices:
• essential idea: short timeboxed iterative, evolutionary and adaptive programming
• Also:– tackle high-risk, high-value issues first– engage users at feedback time– build the core early– continuous verify; test early and often– use use-cases– use visual modeling– manage requirements (no feature creep)– create a change request mechanism
What are the UP Phases?
• Inception:– approximate vision, business case, scope, estimates
• Elaboration:– refined vision, core implemented iteratively, attack
high risks, most requirements identified• Construction:
– fill in the details through iteration• Transition:
– beta tests and deployment
Fig. 2.6
inc. elaboration construction transition
iteration phase
development cycle
release
A stable executablesubset of the finalproduct. The end ofeach iteration is aminor release.
increment
The difference(delta) between thereleases of 2subsequentiterations.
final productionrelease
At this point, thesystem is releasedfor production use.
milestone
An iteration end-point when somesignificant decisionor evaluation occurs.
What are the UP Disciplines?
• In UP, a type of activity is a discipline; an artifact is a work product
• Business Modeling: – The Domain Model artifact
• Requirements: – Use-Case Model, Supplementary Specifications
• Design:– Design Model
Disciplines and Artifacts
Fig. 2.7
Iterations
SampleUP Disciplines
Business Modeling
Requirements
Design
Implementation
Test
Deployment
Configuration & Change Management
Project Management
Environment
Focus of this book
Note that although an iteration includes work in most disciplines, the relative effort and emphasis change over time.
This example is suggestive, not literal.
A four-week iteration (for example). A mini-project that includes work in most disciplines, ending in a stable executable.
setting up workspace
Disciplines and Phases:
• work goes on in all disciplines during all phases of project to a greater or lesser extent.
• the book focuses on inception and elaboration since its main topic is analysis and design
Fig. 2.8
SampleUP Disciplines
Business Modeling
Requirements
Design
Implementation
...
The relative effort indisciplines shiftsacross the phases.
This example issuggestive, not literal.
incep-tion
elaboration constructiontransi-
tion
...
Fig. 2.9
Overview InceptionElaborationIteration 1
ElaborationIteration 2
ElaborationIteration 3
Object-OrientedAnalysis
Object-OrientedDesign
TranslatingDesigns to Code
The Book
Topics such as OO analysis and OOdesign are incrementally introduced initeration 1, 2, and 3.
SpecialTopics
How to Customize the Process?
• Almost everything is optional. (not the code)
Business Modeling
Agile modeling
Req. workshop
Domain Model s
Requirements
Req. workshop
Vision box
Dot voting
Use-Case Model
Vision
Supp Spec
s
s
s
r
r
r
Design Agile modeling
Test-driven dev.
Design Model
SW Arch doc
Data Model
s
s
s
r
r
Implementation
Test-driven dev.
Pair prog’ing
Cont. integration
Coding standards
…
Project Management
Agile PM
Daily scrum meeting
Discipline Activity Artifact Inc: Elab: Con: Tran:
s- start, r - refine