The Crow-AMSAA Model
Crow-AMSAA is the formal statistical (NHPP) version of the Duane model, developed at the US Army Materiel Systems Analysis Activity to add proper maximum likelihood estimation and confidence bounds to Duane's original power-law curve. It carries the same hardware-oriented assumptions Duane does — and the same IEEE 1633 caution against using it for software.
Duane's curve, formalized as a proper statistical model
Where Duane's original model was fit by eye on a log-log plot, Crow-AMSAA (also known as the Power Law Process, or NHPP Weibull) puts the same underlying power-law relationship on rigorous statistical footing, complete with maximum likelihood estimation and confidence bounds. That statistical rigor doesn't change the underlying assumption, though — it's still a continuous hardware-maturation curve, which is why it carries the same IEEE 1633 caution as Duane.
Power-Law NHPP (Weibull Process)
The statistical formalization of Duane's power-law reliability growth curve as a nonhomogeneous Poisson process.
1974 / 1984 — US Army AMSAA
Developed by Dr. Larry Crow at the Army Materiel Systems Analysis Activity, building on Duane's original 1964 work.
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 Crow-AMSAA Model works — and why it doesn't transfer to software
The model puts Duane's power-law relationship into a formal NHPP mean value function with maximum likelihood estimators, but keeps the same continuous-maturation assumption underneath.
Mean Value Function
β < 1 indicates reliability growth (decreasing failure rate); β = 1 indicates no improvement (a homogeneous Poisson process); β > 1 indicates reliability decline.
- μ(t) — expected cumulative number of failures by cumulative time t
- λ — a scale parameter
- β — the growth/decline shape parameter, directly comparable to Duane's α
Failure Intensity Function
Because this is a formal NHPP, standard maximum likelihood confidence intervals can be placed directly around β, unlike Duane's original graphical fitting method.
- λ(t) — instantaneous failure intensity at cumulative time t
- λ, β — same parameters as the mean value function
- This is mathematically the same functional form as the general Weibull SRGM, applied to cumulative rather than testing-interval time
Why the Assumption Breaks Down for Software
Statistical rigor doesn't fix the underlying assumption problem — Crow-AMSAA still assumes continuous power-law maturation, the same mismatch that makes Duane a poor fit for software.
- Software defects are found and fixed in discrete batches, not through continuous physical maturation
- A single power-law shape parameter β is assumed constant across the whole test program, which rarely holds across different software test phases
- Developed and validated for military hardware systems (vehicles, weapons systems), not software defect data
- The added statistical rigor (MLE, confidence bounds) improves precision, but doesn't correct the underlying assumption mismatch
Parameter Estimation
λ and β are estimated with maximum likelihood estimation, with well-established closed-form estimators and confidence bound formulas available — a genuine improvement in statistical rigor over Duane's original graphical approach, but applied to the same underlying assumption.
- β — the growth/decline shape parameter, with a standard closed-form MLE estimator
- λ — the scale parameter, likewise with a closed-form MLE estimator
- Confidence bounds around both parameters are standard outputs of the MLE fit
Strengths, limitations, and why it's not recommended for software
Statistically rigorous and well-validated for hardware
Adds proper maximum likelihood estimation and confidence bounds to Duane's original curve, and has decades of validated use in military hardware reliability testing.
Still assumes continuous power-law maturation
The added statistical rigor doesn't change the underlying assumption mismatch with how software defects are actually discovered and fixed.
Hardware and systems-level reliability growth tracking
Appropriate for the hardware and complex systems reliability testing programs it was 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 Duane.
See which growth models actually fit your software's failure data.
Start with the Requs Trend demo or a discussion of your current reliability growth modeling approach.