Unformatted text preview:

STUDIES OF DEFECTSDEFECT CHARACTERIZATIONDEFECT CHARACTERIZATIONDEFECT CHARACTERIZATIONDEFECT CHARACTERIZATIONDEFECT CHARACTERIZATIONDEFECT CHARACTERIZATIONDEFECT CHARACTERIZATIONDEFECT CHARACTERIZATIONDEFECT CHARACTERIZATIONREQUIREMENTS DOCUMENT EVALUATIONREQUIREMENTS DOCUMENT EVALUATIONREQUIREMENTS DOCUMENT EVALUATIONREQUIREMENTS DOCUMENT EVALUATIONREQUIREMENTS DOCUMENT EVALUATIONProduct QuestionsREQUIREMENTS DOCUMENT EVALUATIONProduct QuestionsTYPES OF CHANGESEFFORT TO CHANGECONFINEMENT OF CHANGESNONCLERICAL ERRORS BY TYPEUSE OF DOCUMENTDiscovery of Need for ChangeREQUIREMENTS DOCUMENT EVALUATIONConclusionsREQUIREMENTS DOCUMENT EVALUATIONConclusionsBUILDING DEFECT BASELINESBUILDING DEFECT BASELINESBUILDING DEFECT BASELINESConclusionsBUILDING DEFECT BASELINES SIMULATOR FOR SATELLITE PLANNING STUDIESPROJECT BACKGROUNDLIFE CYCLE OF ANALYZED SOFTWARENUMBER MODULES# OF MODULES AFFECTED BY AN ERRORFaults:“211 Texual Errors 174 Conceptual Errors)NUMBER OF ERRORS PER MODULE(Faults: 215 Faults)Effort to Correct Faults in the Most Fault-Prone New ModelEffort to Correct Faults in the Most Fault-Prone Modified ModelERROR DISTRIBUTION BY TYPESOURCE OF ERRORSSOURCES OF ERRORSSEL2 SOURCES OF NONCLERICAL ERRORSEFFORTFAULT TYPESCLASSIFICATION OF FAULTSFAULT TYPESFAULTS/1000 EXECUTABLE LINES(INCLUDES ALL MODULES)AVERAGE CYCLOMATIC COMPLEXITY FOR ALL MODULESCOMPLEXITY AND ERROR RATEFOR ERRORED MODULESSUMMARYBUILDING DEFECT BASELINESStudy ConclusionsBUILDING DEFECT BASELINESInspection Process Fault ClassificationBUILDING DEFECT BASELINESInspection Process Fault CharacterizationBUILDING DEFECT BASELINESInspection Process Fault Characterization ConclusionsInvestigating Influential Factors for Software Process ImprovementInvestigating Influential Factors for Software Process ImprovementSome ResultsKnowledge PackagingKnowledge PackagingFUNCTIONAL TEST PLAN EVALUATIONFUNCTIONAL TEST PLAN EVALUATIONFUNCTIONAL TEST PLAN EVALUATIONFUNCTIONAL TEST PLAN EVALUATIONFUNCTIONAL TEST PLAN EVALUATIONFUNCTIONAL TEST PLAN EVALUATIONStructural Coverage of Acceptance TestFUNCTIONAL TEST PLAN EVALUATIONStructural Coverage of Operational UseFUNCTIONAL TEST PLAN EVALUATIONFUNCTIONAL TEST PLAN EVALUATIONObservationsSTUDIES OF DEFECTSDEFECT CHARACTERIZATIONGoalAnalyze the DOS/VS Operating system release 28in order to characterizeit with respect to the defects, interface defects, types of misunderstanding from the point of view of the organization.Environment:IBM GermanyOperating System Release~ 500 modules affected by the modificationaverage size ~360 LOC (480LOC with comments)432 faults reportedExperimental design:Single project/case studyin vivo, no report on experience EndresDEFECT CHARACTERIZATIONDefinitionsDefect:Number of defect report formsInterface defect:more than one module affected by defect fixMisunderstanding type:Problem specific, implementation specific, textual specificDEFECT CHARACTERIZATIONDefect Distribution by ModulesNumber of Defects Number of Modules Affected371 (85%) 150 263341518DEFECT CHARACTERIZATIONDefect Distribution by ModulesNumber of Defects Number of Modules Affected371 (85%) 150 263341518DEFECT CHARACTERIZATIONDefect Distribution by ModulesNumber of Defects per ModuleNumber of Modules Number of Defects/Modules112 136 215 311 48526475839210114115119128DEFECT CHARACTERIZATIONProblem Specific DefectsMachine Configuration and Architecture 10Dynamic Behavior and Communication between Processes 17Functions Offered 12Output Listings and Formats 3Diagnostics 3Performance 146%DEFECT CHARACTERIZATIONImplementation Specific DefectsInitialization (of Fields and Areas) 8Addressability (in the sense of the assembler) 7Reference to Names 7Counting and Calculating 8Masks and Comparisons 2Estimation of Range Limits (addresses and parameters) 1Placing of instructions within a module (bad fixes) 538%DEFECT CHARACTERIZATIONTextual DefectsSpelling in messages and commentaries 4Missing commentaries or flowcharts 5(standards)Incompatible status of macros or modules 5(integration defects)Not classifiable 216%DEFECT CHARACTERIZATIONConclusionsInterface between modules not a major source of defectsApproximately half the defects originated in misunderstanding of the problem to be solved or potential solutions(=> not susceptible to improved programming techniques,I.e., a higher order programming language)Consider this asAnalyze the defects in order to characterize them with respect to the various classification schemesfrom the point of view of the knowledge builder.in the context of a single version of an operating system, ...REQUIREMENTS DOCUMENT EVALUATIONGoalAnalyze the SCR requirements methodin order to evaluate it with respect to the ease of modification and quality of the requirements document produced from the point of view of the organization.Environment:Naval Research LaboratoryOn-board flight program for the A-7 aircraftreal-time, interactive, using TC-2computer 16K 16 bit wordsData collected after document baselinedExperimental design:Single project/case studyin vivo, experience in method, novices in applicationBasili/WeissREQUIREMENTS DOCUMENT EVALUATIONGoalAnalyze the methodin order to evaluate it with respect to the effect on productfrom the point of view of the organization.Analyze the SCR methodin order to evaluate it with respect to the ease of modification of the requirements document structuredness of the requirements documentability to minimize consistency and ambiguity faultsfrom the point of view of the organization.Analyze the requirements documentin order to characterize it with respect to the ease of modification, structure, and consistency and un-ambiguousnessfrom the point of view of quality assurance.Analyze the use of the requirements documentin order to characterize it with respect to the its worthiness to be maintainedfrom the point of view of the organization.REQUIREMENTS DOCUMENT EVALUATIONProcess QuestionsProcess conformance:What is the requirements development methodology?(formal specifications using a state machine model)How well is it being applied?(developers were experimenting with the methodology)Domain understanding:How well do the developers understand the application?(they had minimal expertise)REQUIREMENTS DOCUMENT EVALUATIONProduct QuestionsProduct dimensions:What is the size of the requirements document? (462 pages)Cost:What is the staff effort expended in producing the document?(17 staff months)What is the staff effort expended in making the


View Full Document

UMD CMSC 735 - STUDIES OF DEFECTS

Download STUDIES OF DEFECTS
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view STUDIES OF DEFECTS and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view STUDIES OF DEFECTS 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?