book

Metrics and Models in Software Quality Engineering, Second Edition

by Stephen H. Kan

September 2002

Intermediate to advanced

560 pages

13h 51m

English

Addison-Wesley Professional

Read now

Unlock full access

Dedication
Themes of This BookOrganization of This BookSuggested Ways to Read This BookAcknowledgments
1.1. Quality: Popular Views1.2. Quality: Professional Views1.2.1. The Role of the Customer1.3. Software Quality1.4. Total Quality Management1.5. SummaryReferences
2.1. The Waterfall Development ModelHigh-Level DesignLow-Level DesignCode StageUnit TestComponent TestSystem-Level TestEarly Customer Programs2.2. The Prototyping ApproachRapid Throwaway PrototypingEvolutionary Prototyping2.3. The Spiral Model2.4. The Iterative Development Process Model2.5. The Object-Oriented Development Process2.6. The Cleanroom Methodology2.7. The Defect Prevention Process2.8. Process Maturity Framework and Quality Standards2.8.1. The SEI Process Capability Maturity ModelLevel 1: InitialLevel 2: RepeatableLevel 3: DefinedLevel 4: ManagedLevel 5: OptimizingMaturity Level 1: InitialMaturity Level 2: ManagedMaturity Level 3: DefinedLevel 4: Quantitatively ManagedLevel 5: Optimizing2.8.2. The SPR Assessment2.8.3. The Malcolm Baldrige Assessment2.8.4. ISO 90002.9. SummaryReferences
3.1. Definition, Operational Definition, and Measurement3.2. Level of MeasurementNominal ScaleOrdinal ScaleInterval and Ratio Scales3.3. Some Basic MeasuresRatioProportionPercentageRateSix Sigma3.4. Reliability and Validity3.5. Measurement Errors3.5.1. Assessing Reliability3.5.2. Correction for Attenuation3.6. Be Careful with Correlation3.7. Criteria for Causality3.8. SummaryReferences

4.1. Product Quality Metrics4.1.1. The Defect Density MetricLines of CodeExample: Lines of Code Defect RatesCustomer’s PerspectiveFunction PointsExample: Function Point Defect Rates4.1.2. Customer Problems Metric4.1.3. Customer Satisfaction Metrics4.2. In-Process Quality Metrics4.2.1. Defect Density During Machine Testing4.2.2. Defect Arrival Pattern During Machine Testing4.2.3. Phase-Based Defect Removal Pattern4.2.4. Defect Removal Effectiveness4.3. Metrics for Software Maintenance4.3.1. Fix Backlog and Backlog Management Index4.3.2. Fix Response Time and Fix Responsiveness4.3.3. Percent Delinquent Fixes4.3.4. Fix Quality4.4. Examples of Metrics Programs4.4.1. Motorola4.4.2. Hewlett-Packard4.4.3. IBM Rochester4.5. Collecting Software Engineering Data4.6. SummaryReferences
5.1. Ishikawa’s Seven Basic Tools5.2. Checklist5.3. Pareto Diagram5.4. Histogram5.5. Run Charts5.6. Scatter Diagram5.7. Control Chart5.8. Cause-and-Effect Diagram5.9. Relations Diagram5.10. SummaryReferences
6.1. Literature Review6.2. A Closer Look at Defect Removal Effectiveness6.3. Defect Removal Effectiveness and Quality Planning6.3.1. Phase-Based Defect Removal Model6.3.2. Some Characteristics of a Special Case Two-Phase Model6.4. Cost Effectiveness of Phase Defect Removal6.5. Defect Removal Effectiveness and Process Maturity Level6.6. SummaryReferences
7.1. Reliability Models7.2. The Rayleigh Model7.3. Basic Assumptions7.4. Implementation7.5. Reliability and Predictive Validity7.6. SummaryReferences
8.1. The Exponential Model8.2. Reliability Growth Models8.2.1. Jelinski-Moranda Model8.2.2. Littlewood Models8.2.3. Goel-Okumoto Imperfect Debugging Model8.2.4. Goel-Okumoto Nonhomogeneous Poisson Process Model8.2.5. Musa-Okumoto Logarithmic Poisson Execution Time Model8.2.6. The Delayed S and Inflection S Models8.3. Model Assumptions8.4. Criteria for Model Evaluation8.5. Modeling ProcessStep 1Step 2Step 3Step 4Step 5Step 68.6. Test Compression Factor8.7. Estimating the Distribution of Total Defects over Time8.8. SummaryReferences
9.1. The Rayleigh Model Framework9.2. Code Integration Pattern9.3. The PTR Submodel9.4. The PTR Arrival and Backlog Projection Model9.5. Reliability Growth Models9.6. Criteria for Model Evaluation9.7. In-Process Metrics and Reports9.8. Orthogonal Defect Classification9.9. SummaryReferences
10.1. In-Process Metrics for Software Testing10.1.1. Test Progress S Curve (Planned, Attempted, Actual)10.1.2. Testing Defect Arrivals over Time10.1.3. Testing Defect Backlog over Time10.1.4. Product Size over Time10.1.5. CPU Utilization During Test10.1.6. System Crashes and Hangs10.1.7. Mean Time to Unplanned IPL10.1.8. Critical Problems: Showstoppers10.2. In-Process Metrics and Quality Management10.2.1. Effort/Outcome Model10.3. Possible Metrics for Acceptance Testing to Evaluate Vendor-Developed Software10.4. How Do You Know Your Product Is Good Enough to Ship?10.5. SummaryReferences
11.1. Lines of Code11.2. Halstead’s Software Science11.3. Cyclomatic Complexity11.4. Syntactic Constructs11.5. Structure Metrics11.6. An Example of Module Design Metrics in Practice11.7. SummaryReferences
12.1. Object-Oriented Concepts and Constructs12.2. Design and Complexity Metrics12.2.1. Lorenz Metrics and Rules of Thumb12.2.2. Some Metrics Examples12.2.3. The CK OO Metrics Suite12.2.4. Validation Studies and Further Examples12.3. Productivity Metrics12.4. Quality and Quality Management Metrics12.5. Lessons Learned from OO ProjectsEducation and Skills LevelTools and Development EnvironmentProject ManagementReusePerformanceQuality and Development PracticesSummaryReferences
13.1 Definition and Measurements of System Availability13.2. Reliability, Availability, and Defect Rate13.3. Collecting Customer Outage Data for Quality Improvement13.4. In-process Metrics for Outage and AvailabilitySummaryReferences
14.1. Customer Satisfaction Surveys14.1.1. Methods of Survey Data Collection14.1.2. Sampling Methods14.1.3. Sample Size14.2. Analyzing Satisfaction Data14.2.1. Specific Attributes and Overall Satisfaction14.3. Satisfaction with Company14.4. How Good Is Good Enough14.5. SummaryReferences
15.1. The Preparation Phase15.1.1. What Data Should I Look At?15.1.2. Don’t Overlook Qualitative Data15.2. The Evaluation Phase15.2.1. Quantitative Data15.2.2. Qualitative Data15.2.3. Evaluation Criteria15.3. The Summarization Phase15.3.1. Summarization Strategy15.3.2. The Overall Assessment15.4. Recommendations and Risk Mitigation15.5. SummaryReferences
16.1. Audit and Assessment16.2. Software Process Maturity Assessment and Software Project Assessment16.3. Software Process Assessment Cycle16.4. A Proposed Software Project Assessment Method16.4.1. Preparation Phase16.4.2. Facts Gathering Phase 116.4.3. Questionnaire Customization and Finalization16.4.4. Facts Gathering Phase 216.4.5. Possible Improvement Opportunities and Recommendations16.4.6. Team Discussions of Assessment Results and Recommendations16.4.7. Assessment Report16.4.8. Summary16.5. SummaryReferences
17.1. Measuring Process Maturity17.2. Measuring Process Capability17.3. Staged versus Continuous—Debating Religion17.4. Measuring Levels Is Not Enough17.5. Establishing the Alignment Principle17.6. Take Time Getting Faster17.7. Keep It Simple — or Face Decomplexification17.8. Measuring the Value of Process Improvement17.9. Measuring Process Adoption17.10. Measuring Process Compliance17.11. Celebrate the Journey, Not Just the Destination17.12. SummaryReferences
18.1. Software Process Improvement Sequences18.1.1. Stage 0: Software Process Assessment and Baseline18.1.2. Stage 1: Focus on Management Technologies18.1.3. Stage 2: Focus on Software Processes and Methodologies18.1.4. Stage 3: Focus on New Tools and Approaches18.1.5. Stage 4: Focus on Infrastructure and Specialization18.1.6. Stage 5: Focus on Reusability18.1.7. Stage 6: Focus on Industry Leadership18.2. Process Improvement Economics18.3. Measuring Process Improvements at Activity Levels18.4. SummaryReferences
19.1. Data Quality Control19.2. Getting Started with a Software Metrics Program19.3. Software Quality Engineering Modeling19.4. Statistical Process Control in Software Development19.5. Measurement and the FutureReferences

Content preview from Metrics and Models in Software Quality Engineering, Second Edition

Foreword to the Second Edition

For more than 50 years software has been a troublesome discipline. Software’s problems are numerous and include cancelations, litigation, cost overruns, schedule overruns, high maintenance costs, and low levels of user satisfaction. The problems with software occur more often than not. My company’s research indicates that more than half of large software projects will encounter some kind of delay, overrun, or failure to perform when deployed.

But software does not have to be as troublesome as it has been. Some complex software projects do achieve their delivery schedules and cost targets, and behave properly when used. Throughout my career in software I’ve been interested in what distinguishes successful software ...