book

Software Estimation: Demystifying the Black Art

by Steve McConnell

February 2006

Beginner to intermediate

352 pages

9h 23m

English

Addison-Wesley Professional

Read now

Unlock full access

Art vs. Science of Software EstimationWhy This Book Was Written and Who It Is ForKey Benefits Of This BookWhat This Book Is Not AboutWhere to Start
1.1. Estimates, Targets, and Commitments1.2. Relationship Between Estimates and Plans1.3. Communicating about Estimates, Targets, and Commitments1.4. Estimates as Probability Statements1.5. Common Definitions of a “Good” Estimate1.6. Estimates and Project Control1.7. Estimation’s Real Purpose1.8. A Working Definition of a “Good Estimate”Additional Resources
2.1. A Simple Estimation Quiz2.2. Discussion of Quiz ResultsHow Confident Is “90% Confident”?How Wide Should You Make Your Ranges?Where Does Pressure to Use Narrow Ranges Come From?How Representative Is This Quiz of Real Software Estimates?
3.1. Is It Better to Overestimate or Underestimate?Arguments Against OverestimationArguments Against UnderestimationWeighing the Arguments3.2. Details on the Software Industry’s Estimation Track RecordHow Late Are the Late Projects?One Company’s ExperienceThe Software Industry’s Systemic Problem3.3. Benefits of Accurate Estimates3.4. Value of Predictability Compared with Other Desirable Project Attributes3.5. Problems with Common Estimation TechniquesAdditional Resources
4.1. Sources of Estimation Uncertainty4.2. The Cone of UncertaintyCan You Beat the Cone?The Cone Doesn’t Narrow ItselfAccounting for the Cone of Uncertainty in Software EstimatesRelationship Between the Cone of Uncertainty and CommitmentThe Cone of Uncertainty and Iterative Development4.3. Chaotic Development Processes4.4. Unstable RequirementsEstimating Requirements Growth4.5. Omitted Activities4.6. Unfounded Optimism4.7. Subjectivity and Bias4.8. Off-the-Cuff Estimates4.9. Unwarranted Precision4.10. Other Sources of ErrorAdditional Resources
5.1. Project SizeWhy Is This Book Discussing Size in Lines of Code?Diseconomies of ScaleWhen You Can Safely Ignore Diseconomies of ScaleImportance of Diseconomy of Scale in Software Estimation5.2. Kind of Software Being Developed5.3. Personnel Factors5.4. Programming Language5.5. Other Project Influences5.6. Diseconomies of Scale RevisitedAdditional Resources

6.1. Considerations in Choosing Estimation TechniquesWhat’s Being EstimatedProject SizeSoftware Development StyleEffect of Development Style on Choice of Estimation TechniquesDevelopment StageAccuracy Possible6.2. Technique Applicability Tables
7.1. Count First7.2. What to Count7.3. Use Computation to Convert Counts to Estimates7.4. Use Judgment Only as a Last ResortAdditional Resources
8.1. Improved Accuracy and Other Benefits of Historical DataAccounts for Organizational InfluencesAvoids Subjectivity and Unfounded OptimismReduces Estimation Politics8.2. Data to CollectIssues Related to Size MeasuresIssues Related to Effort MeasuresIssues Related to Calendar Time MeasuresIssues Related to Defect MeasuresOther Data Collection Issues8.3. How to Calibrate8.4. Using Project Data to Refine Your Estimates8.5. Calibration with Industry Average Data8.6. SummaryAdditional Resources
9.1. Structured Expert JudgmentWho Creates the Estimates?GranularityUse of RangesFormulasChecklists9.2. Compare Estimates to ActualsAdditional Resources
10.1. Calculating an Accurate Overall Expected CaseThe Law of Large NumbersHow Small Should the Estimated Pieces Be?10.2. Decomposition via an Activity-Based Work Breakdown Structure10.3. Hazards of Adding Up Best Case and Worst Case EstimatesWarning: Math Ahead!What Went Wrong?10.4. Creating Meaningful Overall Best Case and Worst Case EstimatesComputing Aggregate Best and Worst Cases for Small Numbers of Tasks (Simple Standard Deviation Formula)Computing Aggregate Best and Worst Cases for Large Numbers of Tasks (Complex Standard Deviation Formula)Creating the Aggregate Best and Worst Case EstimatesCautions About Percentage Confident EstimatesAdditional Resources
11.1. Basic Approach to Estimating by AnalogyStep 1: Get Detailed Size, Effort, and Cost Results for a Similar Previous ProjectStep 2: Compare the Size of the New Project to a Similar Past ProjectStep 3: Build Up the Estimate for the New Project’s Size as a Percentage of the Old Project’s SizeStep 4: Create an Effort Estimate Based on the Size of the New Project Compared to the Previous ProjectStep 5: Check for Consistent Assumptions Across the Old and New Projects11.2. Comments on Uncertainty in the Triad EstimateEstimation Uncertainty, Plans, and Commitments
12.1. Fuzzy LogicHow to Get the Average Size NumbersHow to Classify New FunctionalityHow Not to Use Fuzzy LogicExtensions of Fuzzy Logic12.2. Standard ComponentsUsing Standard Components with PercentilesLimitations of Standard Components12.3. Story PointsCautions About Ratings Scales12.4. T-Shirt Sizing12.5. Other Uses of Proxy-Based Techniques12.6. Additional Resources
13.1. Group Reviews13.2. Wideband DelphiEffectiveness of Wideband Delphi“The Truth Is Out There”When to Use Wideband DelphiAdditional Resources
14.1. Things You Can Do with Tools That You Can’t Do Manually14.2. Data You’ll Need to Calibrate the Tools14.3. One Thing You Shouldn’t Do with a Tool Any More than You Should Do Otherwise14.4. Summary of Available ToolsAdditional Resources
Additional Resources
16.1. Flow of an Individual Estimate on a Poorly Estimated Project16.2. Flow of an Individual Estimate on a Well-Estimated Project16.3. Chronological Estimation Flow for an Entire ProjectEstimation Flow for Large ProjectsEstimation Flow for Small Projects16.4. Estimate Refinement16.5. How to Present Reestimation to Other Project StakeholdersWhen to Present the ReestimatesWhat If Your Management Won’t Let You Reestimate?16.6. A View of a Well-Estimated Project
17.1. Usual Elements of a Standardized Procedure17.2. Fitting Estimation into a Stage-Gate Process17.3. An Example of a Standardized Estimation Procedure for Sequential Projects17.4. An Example of a Standardized Estimation Procedure for Iterative Projects17.5. An Example of a Standardized Estimation Procedure from an Advanced Organization17.6. Improving Your Standardized ProcedureAdditional Resources
18.1. Challenges with Estimating SizeRole of Lines of Code in Size Estimation18.2. Function-Point EstimationConverting from Function Points to Lines of Code18.3. Simplified Function-Point TechniquesThe Dutch MethodGUI Elements18.4. Summary of Techniques for Estimating SizeAdditional Resources
19.1. Influences on Effort19.2. Computing Effort from SizeComputing Effort Estimates by Using Informal Comparison to Past ProjectsWhat Kinds of Effort Are Included in This Estimate?19.3. Computing Effort Estimates by Using the Science of Estimation19.4. Industry-Average Effort Graphs19.5. ISBSG MethodKind of project: GeneralKind of project: MainframeKind of project: Mid-RangeKind of project: DesktopKind of project: Third Generation LanguageKind of project: Fourth Generation LanguageKind of project: EnhancementKind of project: New Development19.6. Comparing Effort EstimatesAdditional Resources
20.1. The Basic Schedule Equation20.2. Computing Schedule by Using Informal Comparisons to Past Projects20.3. Jones’s First-Order Estimation Practice20.4. Computing a Schedule Estimate by Using the Science of Estimation20.5. Schedule Compression and the Shortest Possible Schedule20.6. Tradeoffs Between Schedule and EffortSchedule Compression and Team Size20.7. Schedule Estimation and Staffing Constraints20.8. Comparison of Results from Different MethodsAdditional Resources
21.1. Estimating Activity Breakdown on a ProjectEstimating Allocation of Effort to Different Technical ActivitiesEstimating Requirements EffortEstimating Management EffortEstimating Total ActivityAdjustments Due to Project TypeExample of Allocating Effort to ActivitiesDeveloper-to-Tester Ratios21.2. Estimating Schedule for Different Activities21.3. Converting Estimated Effort (Ideal Effort) to Planned Effort21.4. Cost EstimatesOvertimeIs the Project Cost Based on Direct Cost, Fully Burdened Cost, or Some Other Variation?Other Direct Costs21.5. Estimating Defect Production and RemovalEstimating Defect RemovalAn Example of Estimating Defect-Removal Efficiency21.6. Estimating Risk and Contingency Buffers21.7. Other Rules of Thumb21.8. Additional Resources
22.1. Communicating Estimate Assumptions22.2. Expressing UncertaintyPlus-or-Minus QualifiersRisk QuantificationConfidence FactorsCase-Based EstimatesCoarse Dates and Time Periods22.3. Using Ranges (of Any Kind)Usefulness of Estimates Presented as RangesRanges and CommitmentsAdditional Resources
23.1. Attributes of Executives23.2. Political Influences on EstimatesExternal ConstraintsBudgeting and DatesNegotiating an Estimate vs. Negotiating a CommitmentWhat to Do if Your Estimate Doesn’t Get AcceptedResponsibility of Technical Staff to Educate Nontechnical Stakeholders23.3. Problem Solving and Principled NegotiationA Problem-Solving Approach to NegotiationSeparate the People from the ProblemFocus on Interests, Not PositionsInvent Options for Mutual GainInsist on Using Objective CriteriaTechnical Staff and Technical Management Own the EstimateNontechnical Stakeholders Own the TargetTechnical Staff and Nontechnical Staff Jointly Own the CommitmentAdditional Resources
Scoring
Chapter 1Chapter 2Chapter 3Chapter 4Chapter 5Chapter 6Chapter 7Chapter 8Chapter 9Chapter 10Chapter 11Chapter 12Chapter 13Chapter 14Chapter 15Chapter 16Chapter 17Chapter 18Chapter 19Chapter 20Chapter 21Chapter 22Chapter 23

Content preview from Software Estimation: Demystifying the Black Art

Appendix . Steve McConnell

Steve McConnell is Chief Software Engineer at Construx Software where he oversees Construx’s software engineering practices. Steve is the lead for the Construction Knowledge Area of the Software Engineering Body of Knowledge (SWEBOK) project. Steve has worked on software projects at Microsoft, Boeing, and other Seattle-area companies. Steve was the lead developer of Construx Estimate and of SPC Estimate Professional, winner of a Software Development magazine Productivity Award.

Steve is the author of Rapid Development (1996), Software Project Survival Guide (1998), Professional Software Development (2004) and Code Complete, ...