Skip to contentScholarGate
LibraryBookshelfDeskReview StudioAssistant
Sign in
On this page
IntuitionHow it worksWhen to use itStrengths & limitationsCommon pitfallsApplicationsFrequently asked🔒 Read the full methodSourcesRelated methods
Cite this pageSpotted an issue on this page? Report or suggest a fix →
Home›Software Engineering›Defect Prediction Model
Process / pipelineQuality prediction

Defect Prediction Model

Software Defect Prediction and Risk Classification · Also known as: fault prediction, bug prediction, defect classification

Defect prediction models forecast the likelihood of software faults in code modules using statistical or machine learning approaches. Pioneered by Ostrand, Weyuker, and Bell (2005), these models correlate code metrics (complexity, churn, coupling) with historical defect data to identify high-risk components. Organizations use predictions to allocate testing resources, guide code review, and prioritize refactoring.

ScholarGate
  1. Process / pipeline
  2. v1
  3. 3 Sources
  4. PUBLISHED
Cite this page →
Tools & resources
Download slides
Learn & explore

Read the full method

Members only

Sign in with a free account to read this section.

Sign in

Method map

The neighbourhood of related methods — select a node to explore.

Defect Prediction Model
Agile Velocity TrackingCode Coverage AnalysisSoftware Complexity Metr…Static Code AnalysisArchitecture Smell Detec…Equivalence Partitioning…Software Reliability Mod…Technical Debt Measureme…Use Case Point Estimation

When to use it

Apply defect prediction in large development organizations where test capacity is limited and defects are expensive to detect post-release. Effective for prioritizing code review, allocating test automation effort, and planning release cycles. Assume sufficient historical project data (50+ modules with known defects); sparse data degraded prediction. Prediction works best for within-project transfer; cross-project transfer remains challenging.

Strengths & limitations

Strengths
  • Enables proactive resource allocation before release, reducing defect escape rates
  • Uses objective, measurable code metrics rather than subjective reviewer judgment
  • Scales to large codebases; automation identifies at-risk modules faster than manual inspection
  • Supports cost-benefit analysis: predicts where testing investment yields highest return
Limitations
  • Predictions are probabilistic; individual module predictions remain unreliable, especially for low-defect systems
  • Model performance degrades when predicting new projects or domains markedly different from training data
  • Defect definition and labeling in historical data introduce systematic bias affecting model validity
  • Class imbalance: most modules are defect-free, making rare-defect prediction inherently challenging

Frequently asked

How much historical data do I need to build an accurate defect prediction model?

A minimum of 50–100 modules with known defect labels typically provides adequate training data. Ideally, use 200+ modules spanning multiple releases to capture temporal patterns. More data improves performance, but diminishing returns apply; quality of defect labels matters more than raw volume.

Which code metrics are most predictive of defects?

Empirical studies consistently identify: code complexity (cyclomatic, McCabe), lines of code (LOC), change frequency (churn), coupling, and test coverage as strong predictors. No single metric dominates; ensemble approaches combining multiple metrics outperform individual metrics. Domain-specific metrics (e.g., nesting depth in embedded systems) add value.

Can defect prediction work across projects or programming languages?

Cross-project and cross-language prediction remains challenging. Models trained on Java projects often fail on C++ projects due to language-specific metric meanings and development practices. Transfer learning approaches show promise but require careful validation. Within-project prediction is vastly more reliable.

How do I handle severely imbalanced data where few modules contain defects?

Use techniques like stratified sampling, SMOTE (synthetic minority oversampling), class weighting in loss functions, and ensemble methods (random forest, gradient boosting). Evaluate using ROC-AUC or precision-recall curves rather than accuracy; accuracy alone misleads on imbalanced datasets. Threshold adjustment allows tuning precision vs. recall tradeoffs.

Sources

  1. Ostrand, T. J., Weyuker, E. J., & Bell, R. M. (2005). Predicting the location and number of faults in large software systems. IEEE Transactions on Software Engineering, 31(4), 340–355. DOI: 10.1109/tse.2005.49 ↗
  2. Nagappan, N., Ball, T., & Zeller, A. (2006). Mining metrics to predict component failures. In Proceedings of the 28th International Conference on Software Engineering (pp. 452–461). DOI: 10.1145/1134285.1134349 ↗
  3. Menzies, T., Greenwald, J., & Russ, P. (2007). Problems with precision: A response to comments on 'Data mining static code attributes to learn defect predictors'. IEEE Transactions on Software Engineering, 33(9), 637–640. DOI: 10.1109/tse.2007.70721 ↗

How to cite this page

ScholarGate. (2026, June 3). Software Defect Prediction and Risk Classification. ScholarGate. https://scholargate.app/en/software-engineering/defect-prediction-model

Related methods

Agile Velocity TrackingCode Coverage AnalysisSoftware Complexity MetricsStatic Code Analysis

Which method?

Set this method beside its closest kin and read them side by side — the library lays the books on the table; the choice is yours.

  • Agile Velocity TrackingSoftware Engineering↔ compare
  • Code Coverage AnalysisSoftware Engineering↔ compare
  • Software Complexity MetricsSoftware Engineering↔ compare
  • Static Code AnalysisSoftware Engineering↔ compare
Compare side by side →

Referenced by

Agile Velocity TrackingArchitecture Smell DetectionCode Coverage AnalysisEquivalence Partitioning TestingSoftware Complexity MetricsSoftware Reliability ModelStatic Code AnalysisTechnical Debt MeasurementUse Case Point Estimation

Similar methods

Software Reliability ModelSoftware Complexity MetricsHalstead ComplexityTechnical Debt MeasurementStatic Code AnalysisFagan InspectionCleanroom Software EngineeringCode Coverage Analysis

Related reference concepts

Software Estimation and PlanningSoftware Construction and QualitySoftware Quality ManagementSoftware Verification and ValidationCode Quality and RefactoringSoftware Maintenance and Evolution

Spotted an issue on this page? Report or suggest a fix →

ScholarGate — Defect Prediction Model (Software Defect Prediction and Risk Classification). Retrieved 2026-07-21 from https://scholargate.app/en/software-engineering/defect-prediction-model · Dataset: https://doi.org/10.5281/zenodo.20539026
Quick facts
Originator
Thomas Ostrand, Elaine Weyuker, Robert Bell
Subfamily
Quality prediction
Year
2005
Type
machine learning model
Related methods
Agile Velocity TrackingCode Coverage AnalysisSoftware Complexity MetricsStatic Code Analysis
ScholarGate

A content-first reference library for research methods — what each one is, how it works, and where it comes from.

Open data (CC-BY)

Explore

  • Library
  • Search the library…
  • Browse by field
  • Fields
  • Journey
  • Compare
  • Which method?

Reference

  • Subjects
  • Atlas
  • Glossary
  • Methodology
  • Philosophy

Your tools

  • Bookshelf
  • Desk
  • Chat

Company

  • About
  • Pricing
  • Contact
  • Suggest a method

Entries are compiled from published sources for reference. Verifying the accuracy and suitability of any information for your own use remains your responsibility.

© 2026 ScholarGate · A research-method reference library
  • Privacy
  • Cookies
  • Terms
  • Delete account