3. Waterfall Model – Revisited
• Disadvantages of Waterfall Model
– 1. Real projects are rarely so straightforward and sequential
– 2. It is generally not possible to completely define (and
freeze) all the requirements at the start of the project
– 3. Problem is discovered in testing?
– 4. Freight-Train Effect, or Late, or Over-Budget
4. What is “Wicked Problem”
• Problems we can’t really understand
until we’ve developed a solution.
• “That is not what I want ... but now I
know what I do want!”
5. The Mythical Man Month-
Dr. Frederick Brooks
• In software projects, what
will take one person ten
months can not be solved by
ten people in one month.
• Throwing people onto a late
project will just make it later
• Because of Wicked
Problems, “Plan to the throw
one away”
6. Rapid Prototyping
• Put together a team of “Smart
Guys” from multiple disciplines
• Develop the GUI on Paper
• Code the GUI in a fast language
(Make it look like it’s working)
<=Requirements=>
**<=Prototype=>**
• Show it to the USERS (A Picture
is worth a 1,000 words) <=Design=>
<=Code=>
• Get Feedback <=Test=>
<=Deploy=>
7. Case Study- RAD
Grand Community Calendar Project
– Project Manager, Developer, Community
Members write user requirements
– Coder writes sample HTML
– Shows the web page; heads bob, some
changes to navigation
– DBA, Coder, Project Manager determine the
architecture (Design)
– Coding & Review
– Shifting Requirements priced project out-of-
budget
8. Problems With Prototyping
• No “Current” Documents
• Functional Spec is Prototype +
Feedback
• Prototype is not “baseline”
functionality
• Same problems with Functional
Spec as waterfall!
9. Prototyping Part II:
The Rigged Demo
• Re-Visit and improve
the prototype to serve Listen To
as a “baseline” Customer
• Turns prototype into a
“rigged demo” Build/Revise
Mockup
Customer Test
• Show that to the
Drives Mockup
customer
10. At the Demo Dialogue
• Customer:“This looks great, and it looks like you’re about
done. When can we have it?”
• Developer: “Uh, it’s only a prototype – we plan to throw it
away and start over.”
• Customer: “No – this is exactly what we need, and we need
it now! We’ll take 50 prototypes!”
– The Sales Guy begins to see $$
signs.
– Under Rigged Demo scenarios,
there is either a lot of wasted effort,
or prototypes that were never
intended to ship end up shoved into
production.
11. Case Studies
Multi-Stage Prototyping
• Telecommunication
– The prototype made the sale!
– Was pushed into production
– From user requirements to “Ship”ing in 4 month
– Errors, Bugs, High Turn-Over
– Had to support bug fixes plus “incremental” change
• Visual Product Explorer
– Prototype created for internal consumption
– Feedback Cycle
– Modified for trade demo
– Next step: How do we write the spec?
– Product is the spec; shove it into production!
12. Iterative Models
What’s an Iteration?
• Iterative Design: Code as much as you can questions surface, then start
over.
• Every model we’ll talk about below is a variation on the Iterative Model.
13. Spiral Model
Determine Evaluate
objectives, alternatives,
alternatives, identify and
constraints resolve risks
Plan next Develop verify
phases next level
product
14. Risk Assessment
• Spiral Model – risk driven rather
than document driven
• The "risk" inherent in an activity is
a measure of the uncertainty of the
outcome of that activity
• High-risk activities cause schedule
and cost overruns
• Risk is related to the amount and
quality of available information.
The less information, the higher
the risk
• What happened with Denver
Airport Luggage System?
15. Spiral Model
Strength and Weaknesses
• Strengths
– Introduces risk management
– Prototyping controls costs
– Evolutionary development
– Release builds for beta testing
– Marketing advantage
• Weaknesses
– Lack of risk management experience
– Lack of milestones
– Management is dubious of spiral process
– Change in Management
– Prototype Vs Production
16. Win Win Spiral Model
• Win-Win Spiral Process Model is a model of a
process based on Theory W, which is a
management theory and approach "based on
making winners of all of the system's key
stakeholders as a necessary and sufficient
condition for project success."
17. WinWin Spiral Model
••Identify Nextproduct & process definitions
••Validate commitment holders process
Identify Stake holders win conditions
Evaluate Product of Process and
Reconcile Level Stake
Define next level & product Alternatives
Review, Win conditions
18. Win Win Spiral Cont
• Identifying the system's stakeholders and their
win conditions and
• reconciling win conditions through negotiation to
arrive at a mutually satisfactory set of objectives,
constraints, and alternatives for the next level.
• Evaluate Product and Process Alternatives.
Resolve Risks
• Define next level of product and process -
including partitions
• Validate Product and Process Definitions
• Review, commitment
19. WinWin Spiral-
Anchor Points
• Life Cycle Objective(LCO)
– What should the system accomplish?
• Life Cycle Architecture(LCA)
– What is the structure of the system?
• Initial Operational Capability(IOC)
– The first released version
21. Key Elements of IOC Milestone
• Software preparation
– Including both operational and support software with
appropriate commentary and documentation
– data preparation or conversion
– the necessary licenses and rights
• Site preparation
– including facilities, equipment, supplies and vendor
support
• User, Operator and Maintenance preparation
– including selection
– team building
– training
22. Win Win Spiral - Case Study
• Extending USC Integrated Library System to access
multimedia
– Flexibility and Discipline let the projects teams adapt to
challenges while staying on schedule
– Use of risk management helped team focus on CSF for their
projects
– One cycle for each milestone
– Communication and trust between stakeholders, shared vision
– Don’t finish negotiations before prototyping
– Client acceptance
23. Another Extreme
CleanRoom Methodologies
• From Hardware Cleanrooms
• An incremental process that encourages continuous improvement;
• Technical reviews that prevent defects and significantly reduce
costs
• Design and coding practices that make it easy to adapt as
requirements change
• Testing techniques that focus on
measuring quality;
• Solution-oriented teams that encourage
cooperation, reduce the dependence on
"gurus," and promote flexibility
• Documentation structures that reveal
the big picture and help team members
maintain intellectual control.
24. Clean Room Continued
• REAL Peer Review Mathematical proof of correctness
(Challenges associated with it?)
• Functional Specifications as Box Diagrams (State, Black, Clear)
25. Yet Another Extreme: Hacking
• Hacking:
– Code ‘n Fix
– More Common than you thought
• Makes Sense for:
– Low-Risk, Small Project
– We know exactly what we want (not “Wicked”)
– Use once, then throw away
– Bugs can be tolerated/fixed
• Problem:
– “Why not just re-use Hack X here with change Y …”
– Hack Code is hard to maintain, but appealing from a
management perspective.
• Case Study:
– I’m guessing … just about every project you ever did as an
undergraduate.
26. Summary
Summary
• Waterfall
– good for budgeting, but doesn’t analyze risk or have a
good way to manage errors found later in the process.
• Iterative
– Models attempt to solve this by coding “as far as
possible”, gathering feedback, and coding again..
– Prototyping “Plan to throw one away”, then re-build it
“right.”
– Incremental (“Staged”) Delivery Builds the software
by a series of waterfalls
27. Summary
• Spiral:
– Addresses Risk at every stage & let the
stakeholders determine the outcome.
• Win/Win
– Seeks ways to provide customer feedback through
anchor points, manages risk for management, and
provides win conditions for developers.
• Cleanroom / Hacking
– Are alternative models that work for large projects
that must work right the first time, and small
projects with little risk.
28. Resources
• Generally Interesting Theories for REAL-WORLD Development:
• Wicked Problems/State of Coding:
– http://www.unidata.ucar.edu/staff/caron/collab/wicked.html
– http://www.chc-3.com/pub/beautifulsoftware.htm
• Mythical Man Month
– (
http://www.amazon.com/exec/obidos/ASIN/0201835959/ref=bxgy_sr_text_a
)
• Code Complete
– (
http://www.amazon.com/exec/obidos/ASIN/1556154844/ref=bxgy_sr_text_a
)
• Joel Spolsky on Real-World Software Development
– http://www.joelonsoftware.com
• Software Engineering, A Practitioner’s Approach
– http://www.mhhe.com/engcs/compsci/pressman/
29. Resources (2)
• Spiral Model
– Using the WinWin Spiral Model: A case study, Boehm Barry, July
1998, Computer
• Spiral Development workshop
– www.sei.cmu.edu/cbs/spiral2000/february2000/BoehmSR.html
• Anchoring the Software Process, Boehm Barry
– http://www.csis.gvsu.edu/~ferguson/classes/cs641/papers/ASP.pdf
• Denver Airport Project
– http://www.time.com/time/magazine/archive/1994/940516/940516.tr
ansportation.html
• Cleanroom Model
– http://www.cleansoft.com/cleansoft_mgrguide.html
– http://www.sei.cmu.edu/pub/documents/96.reports/pdf/tr022.96.pdf
• Hacking
– http://www.plethora.net/~seebs/faqs/hacker.html
30. Homework
• Objective Question
– One major difference between
the Waterfall and iterative
models is that the iterative
models address risk. How do
they do that?
• Subjective Question
– Which of these models is the
best for the Customer? The
Seller? Why?
