Musa Basic Execution Time Model
One of the earliest and most widely taught software reliability growth models, the Musa Basic Execution Time Model assumes every fault is equally likely to cause a failure and contributes equally to a constant, per-fault hazard rate. It's the finite-failure exponential NHPP model expressed in terms of CPU execution time rather than calendar time.
A finite-failure model built around execution time
The Basic Execution Time Model assumes a fixed, finite number of faults exist in the software at the start of testing, and that each fault contributes an equal, constant amount to the overall failure intensity. As faults are found and perfectly repaired, the failure intensity decreases exponentially with execution time.
Concave, Finite-Failure NHPP
Mathematically equivalent in shape to the Goel-Okumoto model, but parameterized around CPU execution time and per-fault hazard rate.
1975 — John Musa
Developed at Bell Labs as part of Musa's broader software reliability engineering methodology.
Covered — Exponential / NHPP
This model's exponential decay shape is one of the model families included in Requs Trend's ensemble averaging.
How the Basic Execution Time Model works
The model is expressed as a mean value function describing cumulative expected failures, and a failure intensity function describing the instantaneous failure rate, both as functions of execution time.
Mean Value Function
As execution time τ grows, μ(τ) rises toward the total fault count ν₀, with the rate of approach governed by θ.
- μ(τ) — expected cumulative number of failures by execution time τ
- ν₀ — total number of faults expected to be found over infinite testing time
- θ — the per-fault hazard rate, related to the initial failure intensity by θ = λ₀ / ν₀
- τ — CPU execution time (not calendar time)
Failure Intensity Function
Failure intensity starts at λ₀ and decays exponentially as faults are removed, approaching zero as τ grows large.
- λ(τ) — instantaneous failure intensity (failures per unit execution time) at time τ
- λ₀ — initial failure intensity at the start of testing (τ = 0)
- θ — same per-fault hazard rate as in the mean value function
Key Assumptions
The model rests on a small set of assumptions that determine when it will fit well.
- A fixed, finite number of faults (ν₀) exist in the software at the start of testing
- Each fault is equally likely to cause a failure and contributes equally to failure intensity. This only happens when the early blocking defects are removed. So, this model should not be used early in testing.
- Failures are independent of one another. This only happens after the blocking defects are removed. So, this model should not be used early in testing.
- Fault repair is instantaneous and perfect — no new faults are introduced by a fix. This rarely happens in the real world. What may happen is that the user simply avoides the defect until it is fixed. During early testing, defects may not be avoidable.
- Testing follows an operational profile representative of actual field use
Parameter Estimation
ν₀ and θ are typically estimated with maximum likelihood estimation (MLE) or nonlinear least-squares regression against observed cumulative failure counts, using either individual failure times or grouped interval counts.
- ν₀ — fit from the shape of the cumulative failure curve as it flattens out
- θ (or equivalently λ₀) — fit from how quickly the curve approaches ν₀
- Goodness-of-fit is typically checked with AIC, PSSE, or a Laplace trend test on the residuals
Strengths, limitations, and best fit for the Basic Execution Time Model
Simple, well-understood, and well-documented
As one of the foundational models in software reliability engineering, it's extensively validated, easy to explain to stakeholders, and computationally simple to fit.
Assumes perfect, instantaneous repair
Real fixes take time and occasionally introduce new faults — a violation that shows up as poor fit on projects with heavy imperfect debugging.
Execution-time data from stable testing
Works best when testing follows a consistent operational profile and CPU execution time (not calendar time) is tracked directly. So, that means it doesn't work well when the software test engineers are trying to stress the system.
Included in the ensemble
This exponential/NHPP shape is one of the model families Requs Trend. However, since the model is useful only after blocking defects are removed, Requs Trend includes other models that can be used earlier in testing.
See this model fit against real project data.
Start with the Requs Trend demo or a discussion of your current reliability growth modeling approach.