1. Royce 1970 Dr. Winston W. Royce, “Managing the development of large software systems”. Proc. IEEE WESCON, Aug 1970. Reprinted 9 th Intl. Conf. Softw. Eng., 1987. Universally cited as the reference for the waterfall model  But, the word “waterfall” is not mentioned  And the model looks more like a cascade Moreover, the paper is actually against the waterfall model

2. The Basic Waterfall Model Engineering at its best!

3. With Fallback

4. Problems Doing everything in a single sequence is unrealistic A better model involves iteration between successive steps Testing comes too late and may uncover problems in the initial design The solution: do it twice (Same advice as Fred Brooks in The Mythical Man- Month, but referring to a full-scale system)

5. Using a Prototype Note that prototype is actually used! New stage of preliminary design

6. Learning from Prototypes Verify feasibility of approach and design Temporary executable system used to gain experience and identify problems in performance, resource requirements, etc. Study and compare alternative designs or implementations, and foster creativity Try out the user interface, to show clients/users, get feedback, and understand requirements May be used in real application domain and actually evolve into full system

7. Exercise: The ministry of interior wants to create a computerized system for filing forms. There are 31 different forms that need to be supported, with various fields. Need to be able to save partially filled forms, return to form started earlier, print a completed form, and submit it electronically. What would you implement in a prototype?

8. Additional Emphases Need to plan and control the testing Need to involve the client in key points

10. Additional Emphases Need to plan and control the testing Need to involve the client in key points Create multiple documents (requirements, specification, design, test plan, manual) and keep them up to date  “Write an overview document that is understandable, informative, and current. Each and every worker must have an elemental understanding of the system.”  “If the documentation is in serious default my first recommendation is simple: replace project management.”

12. Summary

13. Frederick P. Brooks, Jr. The Design of Design Addison Wesley, 2010 Project manager for IBM’s System/360 and OS/360 Founded CS department at University of North Carolina Received National Medal of Technology 1985 Received Turing Award 1999 Many other awards and honors Famous for The Mythical Man-Month, Brooks’s Law, No Silver Bullet

14. Waterfall Doesn’t Work Clients don’t know what they want We can’t map out all the alternatives in advance The design cannot be decomposed into a sequence of decisions The goodness function cannot be computed incrementally Desiderata and constraints keep changing Designers just don’t work that way

15. Root Causes I Requirements are done once up front  Need to get everything you might need in Sometimes done by committee  I’ll support yours if you support mine Outcome: requirements bloat

16. Root Causes II we are not perfect Greedy clients try to pay less Builders tray to maximize income and not value/cost Misunderstandings abound So we need contracts Contracts must spell out the details before the project is started

17. Alternative Contracting Scheme 1.Develop programatic idea 2.Contract with architect for services Complete requirements Conceptual design Detailed design Pay for hours worked 3.Contract with constructor Use design document produced above Fixed price contract for production

18. The Frustration Royce’s paper is very insightful and foreshadows several modern ideas. On page 2 it says (of the waterfall) “I believe in this concept, but the implementation described above is risky and invites failure.” Others have identified many additional problems. So why is the waterfall model still being used? And why is it a standard?