The Schneidwind Model
Schneidewind's model is built on a simple observation: the most recent failure data is usually a better predictor of future reliability than the earliest data. Rather than fitting every interval equally, it lets you discard early, less-representative testing intervals and fit only from a chosen starting point onward.
A model built around discarding unreliable early data
Most SRGMs fit every observed data point equally. Schneidewind's key insight was that early testing intervals often reflect an immature test process rather than the software's true reliability, and including them can distort the fit. His model introduces a selectable starting interval s, letting only data from interval s onward drive the parameter estimates.
Concave NHPP, Interval Data
Works with grouped failure counts per testing interval rather than individual failure timestamps.
1975 — Norman Schneidewind
Later validated and refined using Space Shuttle onboard software failure data, and implemented in SMERFS.
Assumptions of the model sound good, but the model itself isn't practical
The founder of Mission Ready Software, Ann Marie Neufelder, is the chair of the IEEE 1633. She gave the working group a set of data and asked them to estimate the reliability metrics using this model. Not a single working group member was able to do so.
How the Schneidewind Model works
The model's exponential failure intensity is fit only from a chosen starting interval s onward, letting the analyst exclude testing intervals that don't reflect the software's current reliability.
Failure Intensity by Interval
Only intervals from s onward are used to estimate α and β — earlier intervals are deliberately excluded from the fit.
- λ(i) — expected number of failures in testing interval i
- α — the failure intensity at the chosen starting interval s
- β — the exponential decay rate of failure intensity across intervals
- s — the analyst-selected starting interval; data before it is excluded
Choosing the Starting Interval
Because s is a free choice rather than a fitted parameter, Schneidewind's later work proposed criteria for selecting it objectively rather than by eye — most commonly minimizing the mean square error of the resulting fit across candidate values of s.
- Fit the model separately for each candidate starting interval s
- Compare resulting goodness-of-fit (e.g., mean square error) across candidates
- Select the s that produces the best-fitting, most stable parameter estimates
Key Assumptions
The core NHPP assumptions still apply, plus an explicit assumption that early data is less trustworthy than recent data.
- Failure counts per interval follow a nonhomogeneous Poisson process
- Failure intensity decreases exponentially across testing intervals
- Data from before the chosen starting interval s is not representative of current reliability and should be excluded
- Testing intervals are consistent in length and effort
Parameter Estimation
α and β are typically estimated with weighted least squares or maximum likelihood estimation over the grouped interval counts from interval s onward, as originally proposed by Schneidewind and later refined in tools like SMERFS (obsolete).
- α — the failure intensity level at the starting interval s
- β — how quickly that intensity decays across subsequent intervals
- s itself, chosen separately via a goodness-of-fit search
Strengths, limitations, and best fit for the Schneidewind Model
Handles unreliable early test data directly
Rather than forcing a single fit across the whole history, it explicitly accounts for the reality that early testing often isn't representative.
The choice of s adds subjectivity
Results can shift meaningfully depending on which starting interval is selected, and different selection criteria can disagree.
Projects with a known rocky testing start
Particularly useful when the test process itself matured partway through the project, making early intervals a poor predictor.
Needs grouped interval counts
The model was too complex for any of the IEEE 1633 working group members to use
See alternatives to this model
Start with a Requs Trend demo or a discussion of your current reliability growth modeling approach.