Feature-Set Control

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

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

The Bottom Line • 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

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 • 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

Examples – Lessons Learned (DIA Baggage System) "There are a few lessons that large companies just don't seem to learn." "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

Examples – Lessons Learned (Boeing 777) Specification Control Drawings “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)

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

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

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

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

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

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

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

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…”)

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 ALL requirements that are not absolutely necessary • Simplify ALL requirements that are more complex than necessary • Substitute Simpler-Cheaper-Faster wherever the option exists

Versioned Development • Use evolutionary or phased delivery, whenever possible • Develop the requirements and plan for “the whole enchilada”… but deliver it in stages (versions) • Delineate release plan, as clearly as possible, in the initial requirements specification • 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”

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

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

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

Effects of Change • Impact in every phase of development: design, code, test, documentation, support, training, people, planning, tracking, etc. • Visible effects: schedule, budget, product quality • 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

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

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

Change Control: The Goal Maybe! (Yes - if it’s the right thing to do.)

Methods of Change Control • 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

Methods of Change Control • Change Analysisto screen out frivolous change • Implement a procedure for change requests that requires analysis • 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 • Specify, up front, a minimum schedule impact for any change request in the later stages of a project

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

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

Methods of Change Control • Change Control Board • 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 • Triage: categorize change requests as, e.g., critical, needed, wanted, and nice to have • Some things must be done, others won’t be done

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”

Late Project Feature Cuts • 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 • Fact: Removing features too late incurs additional costs and schedule impact • Approach: analyze the cost of removal and reusability, then strip out unused code, remove documentation, eliminate test cases, etc.

Late Project Feature Cuts • Key to successful late feature cuts: • Involve everyone

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?

Feature-Set Control