Change and Defect Models and MetricsChange Models and MetricsChange Models and MetricsChange and Defect Models and MetricsChange and Defect Models and MetricsChange Models and MetricsDefect Models and MetricsBuilding ModelsBuilding ModelsCombining ModelsDefect Models and MetricsDefect Models and MetricsDefect Models and MetricsDefect Models and MetricsBuilding Defect BaselinesBuilding Defect BaselinesBuilding Defect BaselinesUnderstanding Defect CausesUnderstanding Defect CausesFault ClassificationFault Classification Fault ClassificationFault ClassificationBuilding Defect Baselines Error Origin ClassificationError Origin SEL Planning Studies SystemError Origin Old vs. New ApplicationInterface FaultDefinitionsInterface FaultsNumber of Components ChangedInterface FaultsComponents Changed vs. ExaminedChange and Defect Models and MetricsModels and MetricsReferencesOrthogonal Defect ClassificationChange and Defect Models and MetricsChange Models and MetricsThese models and metrics capture information about modificationsto the software system documentsThey can be categorized in a variety of ways, usually on a nominal scale Models are typically presented as distributions of the various classes of changesChange models and metrics can be used tocharacterize the projectprovide insight into the selection of the appropriate processes provide insight into the productChange Models and MetricsChange Data ClassesChanges can be categorized by purpose e.g., enhancement, adaptive, corrective, preventivetype e.g., requirements, specification, design, architecture, planned enhancements, insert/delete debug code, improve clarity, optimize: space or time, feature, enhancement, bugcause e.g., market/external and internal needssize e.g., number of lines of code or number of components affected,deposition e.g., rejected as a change, not relevant, under consideration, being worked on, completed, saved for next enhancementlevel of document changed e.g., changes back to requirements documentnumber of customers affected e.g., effects certain customer classesChange and Defect Models and MetricsExample DefinitionsEnhancement change: an addition to the original requirements observable to the user, e.g., adding a new functional capabilityAdaptive change: modification based upon the environment in which the system lives but does not add new capability observable to the user, e.g., modifying the system to interact with a change to the hardware or operating systemCorrective change: a modification made to correct a problem with the existing software solution, e.g., fixing a bugPreventive change: a modification that will make the system easier to modify in the future, e.g., restructuring the modulesChange and Defect Models and MetricsIssues associated with nominal scale dataChanges are usually classified on a nominal scale, based upon a classification schemeIt should be easy to classify an object into its nominal category The categories need to be well definedThe categories need to be orthogonalThe categories need to have intuitive meaning for the classifierChange Models and MetricsSample Change Metricsnumber of enhancements per month number of changes per line of code number of changes during requirementsnumber of changes generated by the user vs. internal requestnumber of changes rejected/ total number of changesChange Report history profileDefect Models and MetricsDefect DefinitionsErrorsDefects in the human thought process made while trying to understand given information, to solve problems, or to use methods and toolsFaultsConcrete manifestations of errors within the software- One error may cause several faults- Various errors may cause identical faultsFailuresDepartures of the operational software system behavior from userexpected requirements- A particular failure may be caused by several faults- Some faults may never cause a failure(difference between reliability and correctness)IEEE/StandardBuilding ModelsMethods and Tools Dealing with Software DefectsANALYZEMANAGEUNDERSTANDSolutions DocumentsProblemResultsUNDERSTANDEXECUTEDOCUMENTANALYZECONSTRUCTBuilding ModelsMethods and Tools Dealing with DefectsMETHODS & TOOLSPREVENT ISOLATE DETECTFAULTS FAILURESERRORScause may causeCombining ModelsMETHODS & TOOLSISOLATE DETECTPREVENTFAULTS FAILURESERRORScause may causeMethods and Tools Dealing with DefectsProblem Solution Model of Software Process ModelsUNDERSTANDSolutions DocumentsProblem ResultsUNDERSTANDDOCUMENTANALYZECONSTRUCTEXECUTEANALYZEMANAGEDefect Models and MetricsError Data ClassesError origin - the phase or activity in which the misunderstanding took place. Example subclasses: requirements, specification, design, code, unit test, system test, acceptance test, maintenanceError domain - the object or domain of the misunderstanding. Example subclasses: application, problem-solution, notation <semantics, syntax>, environment, information management, clerical Document error type - the form of misunderstanding contained in a document. Example subclasses: ambiguity, omission, inconsistency, incorrect fact,wrong sectionChange effect - the number of modules changed to fix an errorDefect Models and MetricsFault Data ClassesFault detection time - the phase or activity in which the fault was detected. Example subclasses: requirements, specification, design, code, unittest, system test, acceptance test, maintenanceFault Density - number of faults per KLOCEffort to Isolate/Fix - time taken to isolate of fix a fault usually in time intervals Example subclasses: 1 hour or less, 1 hour to 1 day, 1 day to 3 days, more than 3 daysOmission/commission - where omission is neglecting to include some entity and commission is the inclusion of some incorrect executable statement or factAlgorithmic fault - the problem with the algorithmExample subclasses: control flow, interface, data <definition, initialization, use>.Defect Models and MetricsFailure Data ClassesFailure detection time - the phase or activity in which the failure was detectedExample subclasses: unit test, system test, acceptance test, operationSystem Severity - the level of effect the failure has on the systemExample subclasses: operation stops completely, operation is significantly impacted, prevents full use of features but can be compensated, minor or cosmeticCustomer Impact - the level of effect the failure has on the customerExample subclasses: usually similar to the subclasses for system severity but filled out from the customer perspective so the same