36 IEEE SOFTWARE November/December 2000 0740-7459/00/$10.00 © 2000 IEEEand type of deviations from specified qual-ity goals).1,2Project managers can comparethat data to the quality goals in the projectplan, which were the basis for the initial es-timate. Software product inspection is effec-tive for determining the quality level.To assess the credibility of the initial costand schedule estimates, the project managermust know how many defects the softwareproduct contains (almost always more thanthe number of defects found during inspec-tion). One way to assess product quality isto monitor product defects throughout de-velopment and operation. However, becauseof this process’s time lag, the information isnot available in time for developers to de-cide on appropriate development and qual-ity assurance activities. Another approachuses estimation models based on the numberof defects found after a work product in-spection to estimate a product’s total num-ber of defects. In his recent software engi-neering textbook,3Watts Humphrey pro-poses a simple objective defect estimationmodel (DEM) to control project activities.Empirical evidence on the applicability andaccuracy of product quality estimation mod-els based on sound project data can encour-age wider use of such models. In this article, I investigate the accuracy ofobjective and subjective DEMs based on in-spection data. Objective DEMs do not de-pend on personal opinion but require inputfrom a high-quality data collection process.Subjective estimates, conversely, are rela-tively cheap and easy to obtain but, by defi-nition, depend on the knowledge and capa-bility of the individual estimator (in this case,an inspector who read the inspection objectcarefully and reported a list of defects).I propose models to calculate most likelyteam defect estimates and a confidence in-terval from subjective individual defect esti-mates. I report on data from an experimentfocusUsing InspectionData for Defect EstimationStefan Biffl, Vienna University of TechnologyTo control projects,managers need accurate andtimely feedback onthe quality of thesoftware productbeing developed. Ipropose subjectiveteam estimationmodels calculatedfrom individual estimates andinvestigate theaccuracy of defect estimationmodels based oninspection data.Product quality directly relates to project cost and schedule esti-mation; for example, undetected defects in a key work product—such as a requirements document—might lead to time-consumingadjustments. Thus, from the early project stages on, developersand project managers need to update their estimates of software projectschedules and activities with feedback from the development process. A major aspect of this feedback is data on work-product quality levels (number estimationto evaluate the accuracy of subjective teamestimates and objective DEMs on the num-ber of defects in a requirements document.Because the number of defects in the inspec-tion object is known, we can objectively as-sess the accuracy of the DEMs—that is,their usability in providing feedback onproduct quality for project control.Project Control with Product QualityAssessmentA large part of project management is riskmanagement. Therefore, project cost estima-tion strategies must consider risk assessmentto yield realistic results.1The quality ofwork products and the effectiveness of qual-ity assurance methods are important riskfactors for project planning and control. Estimating software project costs andschedules anticipates quality goals for thesoftware product to be delivered. The qual-ity levels of the final software productdepend on the respective quality levels ofdevelopment work products. Key require-ments for well-founded estimates are theavailability and use of sound data as well assome documented rationale for deriving theestimate. If the project-estimation approachallows developers to define software qualitylevels for those work products and linkthese to results of the development process,an assessment of the quality levels of thesework products can become a basis to adjustinitial cost and schedule estimates.Cost estimation without credible data iswidespread in practice, often for lack of adata basis on properties of past projects.4Creating an adequate data basis as requiredby sophisticated cost estimation models (forexample, Cocomo II5) becomes even moredifficult with changing development para-digms, new development methods, and newcomputing environments that quickly makehistorical data obsolete. Feedback on thequality levels of development products iscrucial to assess a given estimate, particu-larly in projects for which no historical dataexists to support a current cost and scheduleestimate.Product Quality AssessmentAlong the development life cycle, partic-ularly in the early stages of software devel-opment, inspection of software documentsis an effective quality assurance measure toNovember/December 2000IEEE SOFTWARE 37Feedback on thequality levels ofdevelopmentproducts iscrucial toassess a givenestimate.detect defects and provide timely feedbackon quality to developers and managers. In-spection denotes the verification of softwaredocumentation by a team of inspectors2with defect-detection, meeting, and repairsteps. The defect detection step is an indi-vidual activity, implying no interactionamong the inspection team.After inspection, developers and projectmanagers can analyze the retrieved data toevaluate the quality of the work product anddevelopment and quality assurance pro-cesses. The number of defects found duringinspection is not a sufficient criterion forthese quality evaluations, because bad prod-ucts with a bad inspection process might restundetected while very good products mightneedlessly be elected for another inspectioncycle. An approach to overcome this prob-lem is to estimate the number of defects orig-inally present in the document. With this es-timate, the project manager can identify relationships between product quality, in-spection process quality, and invested timeand costs.Similar to traditional cost estimationstrategies, defect content estimation ap-proaches based on historical project dataexist.6Project managers must use these ap-proaches with care because such historicaldata is often unavailable or inapplicable tothe project at hand.In this article, I solve this problem withDEMs that use data from inspection of de-velopment work products. These modelsyield an estimate for the most likely numberof defects