1. CSE Senior Design I Feature-Set Control The slides in this presentation are derived from materials in the textbook used for CSE 4316/4317, Rapid Development: Taming Wild Software Schedules, by Steve McConnell. Instructor: Mike O’Dell

2. 7 2 The Problem initially stuffed  Products are initially stuffed with more features (requirements) than can be reasonably accommodated added  Features continue to be added as the project progresses (“Feature-Creep”) removed/reduced  Features must be removed/reduced or significantly changed late in a project schedule/cost overruns … Inevitably resulting in schedule/cost overruns

3. 7 3 The Bottom Line aggressive feature-set control throughout a project  Without aggressive feature-set control throughout a project,  Projects suffer from excessive schedule pressure and budget overruns  The end result final feature-set is often not what you set out to do  Projects are often out of control and/or cancelled

4. 7 4 Examples  Denver International Airport:  Late changes to baggage handling software by planners cost the software team $20M  Meanwhile, DIA lost $1.1M per day due to the late delivery of luggage handling software  30% over budget, 18 months late… and didn’t work as planned  Boeing 777 (Pehrson, 1996):  Unprecedented software challenge for aircraft control systems… 2.5 MLOC new + 1.5 MLOC off-the-shelf, 79 systems 6X largest previous project Boeing  Delivered ON-TIME in 18 months

5. 7 5 Examples – Lessons Learned (DIA Baggage System) "There are a few lessons that large companies just don't seem to learn." evolve it from a small system that works "The first lesson is that the best way to build a large, complex system is to evolve it from a small system that works. No one bothered to get a small system up and running in the first place -- they went for the big bang." Bruce Webster, principal of Webster & Associates LLC, a Washington- based consulting company that works with companies on troubled IT projects

6. 7 6 Examples – Lessons Learned (Boeing 777) Specification Control Drawings primary means for Boeing system designers to communicate the requirements to the supplier of the system Changes to the SCD were subject to rigorous change board review and approval only necessary changes were madeControl of changes was increasingly important as development progressed The importance of controlling change cannot be overemphasized. “SCDs were developed for each of the systems on the 777. They ranged in size from approximately 100 pages for the simplest systems to over 10,000 pages for the most complex. The SCD is the primary means for Boeing system designers to communicate the requirements to the supplier of the system. It formed the basis of an ongoing dialog between system designer and developer and between the designers of the various systems. Changes to the SCD were subject to rigorous change board review and approval. The reviews assured that all aspects of a change were addressed, and the effects of the change were reflected in all the affected systems. These reviews also controlled the amount of change, assuring that only necessary changes were made to the systems. Control of changes was increasingly important as development progressed and the effects of changes could increasingly jeopardize the schedule. This led the BCAG to apply increasingly stringent criteria on acceptability of changes. The importance of controlling change cannot be overemphasized. ” Software Development for the Boeing 777 Ron J. Pehrson, The Boeing Company (emphasis added)

7. 7 7 Feature-Set Control  Three general types/phases: schedule and budget objectives/constraints  Early-project control – defining a feature-set that is consistent with your project’s schedule and budget objectives/constraints creeping requirements  Mid-project control – controlling creeping requirements cutting/trimming features  Late-project control – cutting/trimming features to meet your schedule and budget goals

8. 7 8 Early Project Control  Goal: Narrow the scope of the project  Reduce the feature-set  Eliminate unnecessary features achievable  Ensure baseline requirements are achievable with project budget and schedule  Approach  Minimal specification  Requirements scrubbing (BP 32,McConnell)  Versioned development

9. 7 9 Minimal Specification minimal amount meaningfully describe  Goal: specify the minimal amount of information needed to meaningfully describe a product  Wait a minute!  Wait a minute! Doesn’t this seem wrong… Doesn’t “more = better” when it comes to specifying requirements? Not necessarily…

10. 7 10 Minimal Specifications  What’s wrong with traditional (excessively long- winded) requirements specifications?  Wasted effort  Wasted effort – specifying a level of details that is not important to the customer  Obsolescence  Obsolescence – changes as a project progresses can obsolete large parts of a detailed SRD. Document management overhead grows out of control.  Lack of efficacy  Lack of efficacy – satisfying the details of a specification to the letter does not guarantee success  Overly constrained design  Overly constrained design – over-specifying requirements may sub-optimize the approach taken (taking away developer discretion)

11. 7 11 Benefits of Minimal Requirements Specification  Improved morale and motivation  Improved morale and motivation – giving the benefit of the doubt to the developers  Less wasted effort  Less wasted effort – decreases unnecessary work on product and on maintaining specification  Shorter requirements phase  Shorter requirements phase – less (often useless) work on the front end

12. 7 12 Risks of Minimal Requirements Specification  Omission of key requirements – the bet: time wasted on specifying detail outweighs time wasted on recovering from something you missed.  Unclear or impossible goals – if goals aren’t clearly agreed and documented, developers will not know how to resolve ambiguities  Gold-plating – if given flexibility to do so, developers may add their own “improvements” at the (often invisible) cost of schedule/budget

13. 7 13 Risks of Minimal Requirements Specification  Lack of support for parallel activities – detailed specs may help reduce time/effort spent in other phases, or accelerate the start of later phases  Increased developer attachment to specific feature – developer flexibility may breed unhealthy sense of ownership  Use of minimal specification for the wrong reason – using minimal specification to avoid doing necessary work will, inevitably, result in a lot of extra work/rework

14. 7 14 Keys to Successful Use of Minimal Requirements Specification  Only use for requirements that are flexible  Leave further specification to the developers (with customer agreement) wherever possible  Capture important requirements… everything the customer cares about  Use flexible development approaches that allow mistakes to be quickly corrected  Involve key users… communicate!  Where possible, use graphical or visual documentation to communicate and document requirements with customer (“a picture tells a…”)

15. 7 15 Requirements Scrubbing  Goal: remove unnecessary, unachievable, high risk requirements before you waste effort on them  Approach: go over the requirements specification with a fine-tooth comb during finalization of requirements phase  Eliminate  Eliminate ALL requirements that are not absolutely necessary  Simplify  Simplify ALL requirements that are more complex than necessary  Substitute  Substitute Simpler-Cheaper-Faster wherever the option exists

16. 7 16 Versioned Development evolutionary or phased delivery  Use evolutionary or phased delivery, whenever possible deliver it in stages  Develop the requirements and plan for “the whole enchilada”… but deliver it in stages (versions) release plan  Delineate release plan, as clearly as possible, in the initial requirements specification likely to change  Requirements for later deliverables are likely to change based on deployment and customer use  Saving you the wasted effort of implementing these things in “Version 1”

17. 7 17 Mid-Project Feature Creep  Goal: eliminate requirement changes after the requirements analysis phase  Fact: no matter how good your requirements specification (minimal, scrubbed, versioned delivery, frozen, etc.), it will come under pressure to change  Approach: Implement an effective change control process

18. 7 18 Feature Creep Control: A Starting Point! NO! (What part of this don’t you understand?)

19. 7 19 Sources of Change  End-users  End-users: driven by the “need” for additional or different functionality, or unclear/impossible goals  Marketers  Marketers: driven by the fact that markets and customer perspectives on requirements change (“killer-app” or “latest and greatest” syndromes)  Developers  Developers: driven by emotional/ intellectual desire to build the “best” widget

20. 7 20 Effects of Change every phase of development  Impact in every phase of development: design, code, test, documentation, support, training, people, planning, tracking, etc.  Visible effects  Visible effects: schedule, budget, product quality  Hidden effects  Hidden effects: morale, pay, promotion, etc.  Costs are typically 50 -200 * times less if changes are made during requirements phase, than if you discover them during implementation * Boehm and Pappico, 1988

21. 7 21 When Change is Necessary don’t know  Customers don’t know what they want responsive  You need to be responsive to the customer market  The market is changing rapidly developers  You want to give latitude (flexibility) to the developers

22. 7 22 Change Control  Goals: best possible product in the time available  Allow change that results in the best possible product in the time available. Disallow all other changes participate  Allow everyone affected by a proposed change to participate in assessing the impact communicate  Broadly communicate proposed changes and their impact audit trail  Provide an audit trail for all decisions (i.e., document them well) efficiently  A process to accomplish the above as efficiently as possible

23. 7 NO! (What part of this don’t you understand?) 23 Change Control: The Goal Maybe! right (Yes - if it’s the right thing to do.)

24. 7 24 Methods of Change Control  Customer-oriented requirements  Customer-oriented requirements practices, when they will work  Throwaway prototyping: get early feedback from customer on user-visible features  Joint Application Development (JAD) practices: bring the users into the development process as active participants

25. 7 25 Methods of Change Control  Change Analysis  Change Analysis to screen out frivolous change procedure  Implement a procedure for change requests that requires analysis  Make it hard  Make it hard (i.e., require thought and time) to submit a change request Written request Business case analysis Sample of user-visible changes and impact analysis minimum schedule impact  Specify, up front, a minimum schedule impact for any change request in the later stages of a project

26. 7 26 Methods of Change Control  “Version 2” follow-on release  Instead of “no,” say “yes” for a follow-on release list of future requirements  Create a list of future requirements technology plan  Establish a multi-release technology plan that identifies future versions of the product

27. 7 27 Methods of Change Control  Short Release Cycles  Evolutionary development, evolutionary prototyping, staged delivery on a short cycle user confidence  Builds user confidence user feedback  Enables real user feedback for follow-on product requirements

28. 7 28 Methods of Change Control  Change Control Board stakeholdersownership  Structure: representatives from all stakeholders, with ownership of critical process steps clearly identified  Change Analysis: process to rationally analyze schedule, cost and feature set trade-offs… from the perspective of each affected organization categorize  Triage: categorize change requests as, e.g., critical, needed, wanted, and nice to have Some things must be done, others won’t be done

29. 7 29 Methods of Change Control  Change Control Board (cont’d)  Bundling: handle multiple small changes as bundles, where possible E.g., “user interface color changes,” or “error message readability improvements”  Bureaucracy: must deal with the fact that change control is an unpopular job Responsibility – produce the best possible product in the time available Don’t rubber stamp, and don’t just say “no”

30. 7 30 Late Project Feature Cuts save the project’s schedule/budget  Goal: Eliminate features in an effort save the project’s schedule/budget  Fact: Project may (will?) fall behind for many reasons other than feature-set control additional costs and schedule impact  Fact: Removing features too late incurs additional costs and schedule impact analyze  Approach: analyze the cost of removal and reusability, then strip out unused code, remove documentation, eliminate test cases, etc.

31. 7 31 Late Project Feature Cuts  Key to successful late feature cuts: everyone Involve everyone

32. 7 32 Managing Change Effectively (C.S. 14-1)  What was source of the change to Square- Calc 4.0?  What phase was the project in?  What are the characteristics of the change management process?  What was the impact of the proposed change?  What was the outcome?