CSE Senior Design ICSE Senior Design I

Feature-Set ControlFeature-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’DellInstructor: Mike O’Dell

7

2

The ProblemThe ProblemProducts are initially stuffedinitially stuffed with more

features (requirements) than can be reasonably accommodated

Features continue to be addedadded as the project progresses (“Feature-Creep”)

Features must be removed/reducedremoved/reduced or significantly changed late in a project

… Inevitably resulting in schedule/cost schedule/cost overrunsoverruns

7

3

The Bottom LineThe Bottom Line

Without aggressive aggressive feature-set control feature-set control throughout a projectthroughout 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

7

4

ExamplesExamples

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 systems6X largest previous project Boeing

Delivered ON-TIME in 18 months

7

5

Examples – Lessons Learned Examples – Lessons Learned (DIA Baggage System)(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 evolve it from a small system that workssystem 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

7

6

Examples – Lessons Learned Examples – Lessons Learned (Boeing 777)(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 primary means for Boeing system designers to communicate the requirements to the Boeing system designers to communicate the requirements to the supplier of the systemsupplier of the system. It formed the basis of an ongoing dialog between system designer and developer and between the designers of the various systems. ChangesChanges to the SCD were subject to rigorous change board to the SCD were subject to rigorous change board review and approvalreview 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 madeonly necessary changes were made to the systems. Control Control of changesof changes was increasingly important as development progressed 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 The importance of controlling change cannot be overemphasized.overemphasized. ”

Software Development for the Boeing 777Ron J. Pehrson, The Boeing Company (emphasis added)

7

7

Feature-Set ControlFeature-Set Control

Three general types/phases: Early-project control – defining a feature-

set that is consistent with your project’s schedule and budget objectives/constraintsschedule and budget objectives/constraints

Mid-project control – controlling creeping creeping requirementsrequirements

Late-project control – cutting/trimming cutting/trimming featuresfeatures to meet your schedule and budget goals

7

8

Early Project ControlEarly Project Control

Goal: Narrow the scope of the project Reduce the feature-set Eliminate unnecessary features Ensure baseline requirements are achievableachievable

with project budget and scheduleApproach

Minimal specification Requirements scrubbing (BP 32,McConnell) Versioned development

7

9

Minimal SpecificationMinimal Specification

Goal: specify the minimal amountminimal amount of information needed to meaningfully meaningfully describedescribe 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…

7

10

Minimal SpecificationsMinimal SpecificationsWhat’s wrong with traditional (excessively

long-winded) requirements specifications? Wasted effortWasted effort – specifying a level of details that is

not important to the customer ObsolescenceObsolescence – changes as a project progresses can

obsolete large parts of a detailed SRD. Document management overhead grows out of control.

Lack of efficacyLack of efficacy – satisfying the details of a specification to the letter does not guarantee success

Overly constrained designOverly constrained design – over-specifying requirements may sub-optimize the approach taken (taking away developer discretion)

7

11

Benefits of Minimal Requirements Benefits of Minimal Requirements SpecificationSpecification

Improved morale and motivationImproved morale and motivation – giving the benefit of the doubt to the developers

Less wasted effortLess wasted effort – decreases unnecessary work on product and on maintaining specification

Shorter requirements phaseShorter requirements phase – less (often useless) work on the front end

7

12

Risks of Minimal Requirements Risks of Minimal Requirements SpecificationSpecification

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

7

13

Risks of Minimal Requirements Risks of Minimal Requirements SpecificationSpecification

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

7

14

Keys to Successful Use of Minimal Keys to Successful Use of Minimal Requirements SpecificationRequirements 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…”)

7

15

Requirements ScrubbingRequirements 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 EliminateEliminate ALL requirements that are not absolutely

necessary SimplifySimplify ALL requirements that are more complex

than necessary SubstituteSubstitute Simpler-Cheaper-Faster wherever the

option exists

7

16

Versioned DevelopmentVersioned Development

Use evolutionary or phased deliveryevolutionary or phased delivery, whenever possible

Develop the requirements and plan for “the whole enchilada”… but deliver it in stagesdeliver it in stages (versions)

Delineate release planrelease plan, as clearly as possible, in the initial requirements specification

Requirements for later deliverables are likely likely to changeto change based on deployment and customer use Saving you the wasted effort of implementing these

things in “Version 1”

7

17

Mid-Project Feature CreepMid-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

7

18

Feature Creep Control: A Starting Feature Creep Control: A Starting Point!Point!

NO!NO!

(What part of this don’t you understand?)

7

19

Sources of ChangeSources of ChangeEnd-usersEnd-users: driven by the “need” for

additional or different functionality, or unclear/impossible goals

MarketersMarketers: driven by the fact that markets and customer perspectives on requirements change (“killer-app” or “latest and greatest” syndromes)

DevelopersDevelopers: driven by emotional/ intellectual desire to build the “best” widget

7

20

Effects of ChangeEffects of Change

Impact in every phase of developmentevery phase of development: design, code, test, documentation, support, training, people, planning, tracking, etc.

Visible effectsVisible effects: schedule, budget, product quality

Hidden effectsHidden 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

7

21

When Change is NecessaryWhen Change is Necessary

Customers don’t knowdon’t know what they wantYou need to be responsiveresponsive to the

customerThe marketmarket is changing rapidlyYou want to give latitude (flexibility) to

the developersdevelopers

7

22

Change ControlChange ControlGoals:

Allow change that results in the best best possible product in the time availablepossible product in the time available. Disallow all other changes

Allow everyone affected by a proposed change to participateparticipate in assessing the impact

Broadly communicatecommunicate proposed changes and their impact

Provide an audit trailaudit trail for all decisions (i.e., document them well)

A process to accomplish the above as efficientlyefficiently as possible

7

23

Change Control: The GoalChange Control: The Goal

Maybe!Maybe!

(Yes - if it’s the rightright thing to do.)

7

24

Methods of Change ControlMethods of Change Control

Customer-oriented requirementsCustomer-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

7

25

Methods of Change ControlMethods of Change ControlChange AnalysisChange Analysis to screen out frivolous

change Implement a procedureprocedure for change

requests that requires analysis Make it hardMake it hard (i.e., require thought and

time) to submit a change requestWritten requestBusiness case analysisSample of user-visible changes and impact

analysis Specify, up front, a minimum schedule minimum schedule

impactimpact for any change request in the later stages of a project

7

26

Methods of Change ControlMethods of Change Control

“Version 2” Instead of “no,” say “yes” for a follow-on follow-on

releaserelease Create a list of future requirementslist of future requirements Establish a multi-release technology plantechnology plan

that identifies future versions of the product

7

27

Methods of Change ControlMethods of Change Control

Short Release Cycles Evolutionary development, evolutionary

prototyping, staged delivery on a short cycle

Builds user confidenceuser confidence Enables real user feedbackuser feedback for follow-on

product requirements

7

28

Methods of Change ControlMethods of Change Control

Change Control Board Structure: representatives from all

stakeholdersstakeholders, with ownershipownership 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: categorizecategorize change requests as, e.g., critical, needed, wanted, and nice to haveSome things must be done, others won’t be done

7

29

Methods of Change ControlMethods 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 jobResponsibility – produce the best possible

product in the time availableDon’t rubber stamp, and don’t just say “no”

7

30

Late Project Feature CutsLate Project Feature CutsGoal: Eliminate features in an effort

save the project’s schedule/budgetsave the project’s schedule/budgetFact: Project may (will?) fall behind for

many reasons other than feature-set control

Fact: Removing features too late incurs additional costs and schedule impactadditional costs and schedule impact

Approach: analyzeanalyze the cost of removal and reusability, then strip out unused code, remove documentation, eliminate test cases, etc.

7

31

Late Project Feature CutsLate Project Feature CutsKey to successful late feature cuts:

Involve everyoneeveryone

7

32

Managing Change EffectivelyManaging Change Effectively(C.S. 14-1)(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?