Royce 1970 Dr Winston W Royce Managing the

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

The Basic Waterfall Model Engineering at its best!

With Fallback

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)

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

Learning from Prototypes 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

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?

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

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. ”

Summary

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

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

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

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

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

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?