The Littlewood-Verrall Model
Perhaps the best-known Bayesian software reliability model, Littlewood-Verrall directly acknowledges what most other models assume away: fixes aren't always perfect. By treating each fault's hazard rate as a random variable rather than a fixed constant, it allows for the possibility that a fix makes things worse, not just better.
The model that admits fixes aren't always improvements
Almost every other model on this list assumes fault repair is perfect and instantaneous. Littlewood and Verrall built a model that doesn't require that assumption: each fault's hazard rate is treated as a gamma-distributed random variable that can move up or down after a fix, formally allowing for imperfect debugging where a repair occasionally introduces a new problem or fails to fully resolve the old one.
Bayesian Reliability Growth
Two layers of uncertainty: each fault is a Poisson source of failure, and that fault's own rate is itself a gamma-distributed random variable.
1973 — Littlewood & Verrall
While the idea of imperfect debugging is a good one, this model was developed in an academic environment and hasn't been widely used.
Not mentioned in the IEEE 1633
This model was not selected for the IEEE 1633 recommended models
How the Littlewood-Verrall Model works
Instead of a single fixed hazard rate per fault, the model treats each fault's hazard rate as drawn from a gamma distribution whose parameters can themselves change with each successive fix.
Gamma-Distributed Hazard Rate
Rather than assuming a fixed hazard rate per fault, φᵢ is drawn from a gamma distribution — the shape parameter α is constant, but the scale parameter ψ(i) can change as i increases, allowing fix quality to vary.
- φᵢ — the hazard rate associated with the ith fault (a random variable, not a fixed constant)
- α — the shape parameter of the gamma distribution, assumed constant
- ψ(i) — the scale parameter, a function of the failure index i that captures whether fix quality is improving or worsening
Modeling Fix Quality Over Time
A linear ψ(i) implies steadily improving fix quality; a quadratic form allows for accelerating improvement — or, if the fitted trend runs the other way, for reliability actually degrading as testing continues.
- ψ(i) — the trend function describing how fix quality changes with each successive failure
- α₀, α₁ — coefficients fit from the data, describing the baseline level and rate of change
- If the fitted trend in ψ(i) is unfavorable, the model can signal that repairs are making reliability worse, not better
Key Assumptions
The Bayesian framing relaxes the perfect-repair assumption shared by most other models on this list, at the cost of added estimation complexity.
- Each fault's failure process is Poisson with its own hazard rate
- That hazard rate is not fixed — it's a gamma-distributed random variable that can change after each fix
- Fix quality can improve, stay flat, or worsen over time, rather than being assumed uniformly perfect
- The number of faults is not assumed to be a fixed, known constant
Parameter Estimation
α, α₀, and α₁ (or the equivalent quadratic coefficients) are typically estimated using maximum likelihood estimation, nonlinear least squares, or weighted least squares. Because the model has more structure than a simple two-parameter NHPP model, it generally needs a larger set of observed failure times to fit stably.
- α — the shape parameter of the gamma distribution governing per-fault hazard rates
- α₀, α₁ — the trend function coefficients describing how fix quality changes over time
Strengths, limitations, and best fit for the Littlewood-Verrall Model
Doesn't assume perfect debugging
One of the only classical models that formally allows for fixes making reliability worse, not just better — a real phenomenon most other models assume away.
More complex to fit and interpret
The added Bayesian structure and trend function require more data and more careful interpretation than a simple two-parameter exponential model.
Not developed for Agile development.
This model needs a larger, well-ordered failure history. Estimating a trend in fix quality over time requires a longer sequence of ordered individual failure times than simpler models do.
See alternatives to this model that work better for Agile development.
Start with the Requs Trend demo or a discussion of your current reliability growth modeling approach.