The Duane Model
The Duane model is a hardware reliability growth model, not a software-specific one — it assumes MTBF improves as a smooth power-law function of cumulative test time. That assumption reflects how mechanical and electronic systems mature under test, but it doesn't match how software defects actually get found and fixed, which is why IEEE 1633 flags it as a model not recommended for software.
A hardware model applied to software it wasn't built for
J.T. Duane originally developed this model observing aircraft engine and generator reliability improvement under test — a smooth, continuous power-law relationship that fits mechanical wear-in and design-maturity processes well. Applying that same continuous power-law assumption to software, where defects are found and fixed in discrete, uneven jumps, is exactly the kind of mismatch IEEE 1633 warns programs against.
Power-Law Reliability Growth
Assumes cumulative failure rate decreases (and MTBF increases) as a smooth power-law function of cumulative operating or test time.
1964 — J.T. Duane, GE
Developed from empirical observations of hardware systems — aircraft generators and hydromechanical devices — improving under test.
Not Recommended for Software
Explicitly called out among the models the IEEE 1633 working group considers a faulty-assumption fit for software reliability growth.
How the Duane Model works — and why it doesn't transfer to software
The model's power-law formula is a good description of how hardware systems mature, but the smooth, continuous assumption it relies on breaks down for discrete software defect discovery and repair.
Cumulative MTBF Growth
The reliability growth rate parameter α is assumed constant throughout testing — a reasonable assumption for hardware wear-in, but a poor fit for the uneven, batch-like way software defects are actually found and fixed.
- MTBF_c(t) — cumulative mean time between failures at cumulative test time t
- K — a scale constant
- α — the reliability growth rate parameter
- t — cumulative operating or test time
Cumulative Failure Rate
This is the same power-law relationship, expressed as a decreasing failure rate rather than an increasing MTBF.
- λ_c(t) — cumulative failure rate at cumulative test time t
- K, α, t — same as in the MTBF formula above
- A plot of log(λ_c) versus log(t) should be a straight line if the power-law assumption holds
Why the Assumption Breaks Down for Software
Duane's power-law assumption reflects continuous physical wear-in and design maturation — not how software defects are discovered and repaired.
- Software defects are found and fixed in discrete, uneven batches, not through continuous physical maturation
- A single fix can remove several failure modes at once, or introduce a new one — neither fits a smooth power-law curve
- The model assumes a constant growth rate α throughout testing, which rarely holds across different software test phases
- It was validated against mechanical and electronic hardware failure data, not software defect data
Parameter Estimation
K and α are typically estimated with linear regression on the log-log plot of cumulative failure rate versus cumulative test time — a technique that works well for hardware data with a genuine underlying power-law relationship, but can produce a misleadingly clean-looking fit on software data that doesn't actually follow that pattern.
- α — the reliability growth rate, from the slope of the log-log plot
- K — the scale constant, from the intercept of the log-log plot
Strengths, limitations, and why it's not recommended for software
Well-validated for hardware
A long, well-established track record modeling reliability growth in mechanical and electronic systems under test.
Assumes smooth, continuous maturation
Software defect discovery and repair happens in discrete, uneven jumps that don't follow a hardware-style power-law improvement curve.
Hardware reliability growth tracking
Appropriate for mechanical and electronic hardware reliability growth testing — the domain it was actually built and validated for.
Flagged as not recommended for software
Explicitly called out by the working group as one of the models with a faulty underlying assumption for software reliability growth, alongside Crow-AMSAA.
See which growth models actually fit your software's failure data.
Start with the Requs Trend online demo or a discussion of your current reliability growth modeling approach.