Upload
melanie-hampton
View
215
Download
0
Tags:
Embed Size (px)
Citation preview
“You should use iterative development only on projects that you want to succeed.”
− Martin Fowler
Barry W. Boehm, “A Spiral Model of Software Development and Enhancement”. Computer
21(5), pp. 61-72, May 1988
Prof. Software engineering, Univ. Southern California
Worked at General Dynamics, Rand, TRW
Director of DARPA Information Science and Technology Office 1989-1992
Fellow of ACM, IEEE
COCOMO cost model, Spiral model, ...
The Basic Force
Code-driven development “Code-and-fix” approach No design leads to poor code and frustrated clients
Document-driven development Waterfall model: each step produces a new document Requirement for fully developed documents unrealistic
Risk-driven development Support iterative development Decide how to proceed by reducing risk of failure
The Spiral Model
Several rounds of development: system concept, requirements, design
In each round, mitigate risks Define objectives of part you are doing Map alternatives for implementation Recognize constraints on these alternatives Use prototyping, analysis, etc. to gain necessary
knowledge and reduce risk Plan the next step
At the end, perform sequence of coding, testing, and integration
What you actuallydo depends on
the biggestremaining risk
Using the Spiral
Start with hypothesis that something can be done
Round 1: concept and lifecycle plan Round 2: top level requirements Additional rounds: preliminary design, detailed
design May go back and redo previous round if needed If the evaluation at some stage shows that it
won't work then stop
Risks
Developing software is fraught with uncertainty Uncertainty implies risk This needs to be quantified:
RiskExposure = Probability x Loss Can be used to chose between alternatives:
select the one where the expected exposure is smaller
Risk Management
Riskmanagement
assessment
control
identification
analysis
prioritization
planning
resolution
monitoring
Milestones
In waterfall model there are many milestones This is too rigid and sequential
But there are three really important ones: Life-cycle objectives Life-cycle architecture Initial operational capability
(these foreshadow the unified process)
Make sure weknow what we want
to do, and that itcan be done
Elaborate onhow things will
be builtPrepare for thetransition to theclient in terms ofsite and training
Milestones
Milestones are not (necessarily) documents! Not a fully specified spec or architecture, but a
framework that will evolve For example, important interfaces must be specified
precisely, but user interfaces can be a prototype Articulation of feasibility and rationale are important Agreement of stakeholders is crucial
Tom Gilb
Principles of Software Engineering Management
Addison Wesley, 1988
Born in the USAMoved to UK to studyFell in love, moved to NorwayWorked for IBM for 5 yearsIndependent consultant with son Kaiwww.gilb.com
EVO
• Short for Evolutionary Delivery, chapters 7 and 13 in the book
• “Arguably the best systems engineering project management method. However, it is also probably the least known and the least discussed”
• Core idea:
Deliver value to stakeholders early and often
EVO
• Iterative and incremental
• Deliver in small parts, instead of big bang at the end (note: not only develop in parts, but actually deliver)
EVO
• Iterative and incremental
• Deliver in small parts, instead of big bang at the end (note: not only develop in parts, but actually deliver)
• Each iteration is like a waterfall
• Analysis, design, build, test
• Small scope and fast turnaround
• Each iteration must give customer some value
• Prioritize according to maximal value for minimal cost
• Don’t over-plan
EVO
The Norwegian mountain survival principle:
You need never be ashamed of turning back in time
The juicy bits first principle:
If you deliver the juiciest bits of the project first, they will forgive cost and budget overruns
The mountain goat principle:
Take one step at a time up the slippery mountain, and make sure each hoof is on solid ground first
Prioritization1. Divide functions into “urgently needed”, “needed
soon”, and “needed later”
2. Divide urgent functions into high/low political value and high/low economic value
3. Divide high-value functions into low/high implementation cost
4. Divide low-cost functions into fast implementation or slower implementation
5. Divide fast implementation into low/high risk of failure
6. Implement low-risk, fast, low-cost, high-value, urgent function
7. Repeat, monitoring and learning from mistakes
Planning
• Need a general idea of where you want to go
• But not a detailed plan for the whole way
• inflexible
• Wasted effort
• Analogy of road trip from London to Rome
• At each step, plan only that step
Contracts
• Conventionally pay for work
• Millions of dollars paid for work that led to failure
• No incentive to deliver working software
• “No cure no pay”
• Pay for delivered functionality
• Incremental payments match incremental development
• Incentive to produce working software
Additional Emphases
• Don’t forget non-functional requirements
• Quality attributes such as performance
• Resource attributes such as storage space
• Providing this can be more costly than the basic functionality
• Everything can and should be quantified
• Break it down into components
• Find the relevant scale for each one
Example: Ease of Access
Perspective
• What projects can benefit from EVO?
Slide from presentation about NSA system leaked by Edward Snowden, 2013