Feature-Set ControlThe ProblemThe Bottom LineExamplesExamples – Lessons Learned (DIA Baggage System)Examples – Lessons Learned (Boeing 777)Slide 7Early Project ControlMinimal SpecificationMinimal SpecificationsBenefits of Minimal Requirements SpecificationRisks of Minimal Requirements SpecificationSlide 13Keys to Successful Use of Minimal Requirements SpecificationRequirements ScrubbingVersioned DevelopmentMid-Project Feature CreepFeature Creep Control: A Starting Point!Sources of ChangeEffects of ChangeWhen Change is NecessaryChange ControlChange Control: The GoalMethods of Change ControlSlide 25Slide 26Slide 27Slide 28Slide 29Late Project Feature CutsSlide 31Managing Change Effectively (C.S. 14-1)CSE Senior Design ICSE Senior Design IFeature-Set ControlFeature-Set ControlThe 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’Dell72The ProblemThe ProblemProducts 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 overrunsoverruns73The 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 cancelled74ExamplesExamples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 months75Examples – 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 projects76Examples – 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)77Feature-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 goals78Early 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 scheduleApproachMinimal specificationRequirements scrubbing (BP 32,McConnell)Versioned development79Minimal 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…710Minimal SpecificationsMinimal SpecificationsWhat’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)711Benefits 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