Reliable Software Allocation
A system-level reliability requirement means little to a software engineer unless it is broken down into a target they can actually design against. Below are the core elements of allocating system reliability down to the software.
Why allocation has to happen before anything else can be measured
Prediction, evaluation, and test are only meaningful if there is a target to compare against. Allocation takes the system-level reliability requirement and apportions it down to CSCIs, services, or components, so every part of the software has a quantitative reliability goal.
Requirement to target
Every allocated value traces back to a specific system-level reliability requirement, not an arbitrary number.
Weighted by risk and role
Allocation accounts for criticality, duty cycle and complexity rather than dividing the budget evenly across components.
A number designers can use
Allocated targets are stated in units that a software team can design, predict, and test against.
The core elements of reliable software allocation
Each element below is a step in turning a system-level reliability requirement into a set of quantitative targets for the software.
Allocation Method
The developer shall define and justify the method used to allocate reliability from the system level down to software elements.
- Method selection: recent historical data, achievable failure rates, development labor, and other methods discussed in IEEE 1633 clause 5.3. Mission Ready Software consultants have experience with every allocation method. We can guide you in method selection.
- Equal apportionment is not recommended
- Rationale documented for why the chosen method fits the architecture
- Method applied consistently across all software elements
Requirement Traceability
Each allocated software target shall be traceable to the system-level reliability requirement it derives from.
- Traceability matrix linking system requirement to allocated software value
- Allocation reviewed alongside the system reliability model
- Gaps or unallocated requirements flagged for resolution
CSCI/Component-Level Targets
Each software element shall receive a quantitative reliability target consistent with its role and criticality.
- Targets expressed in failure rate, MTBF, or defect density as appropriate
- Higher-criticality components allocated tighter targets
- Targets documented in a form usable by the prediction and evaluation tasks
Re-Allocation Process
A defined process shall rebalance allocated targets when the software architecture or component boundaries change.
- Triggers for re-allocation identified (e.g., major design change, new component)
- Updated allocation reviewed at the next applicable milestone
- Change history maintained for auditability
Use as Acceptance Criteria
Allocated values shall serve as the acceptance criteria used by the evaluation and test tasks to judge whether reliability goals were met.
- Allocated targets referenced directly in evaluation task metrics
- Test entrance/exit criteria tied to allocated values
- Shortfalls against allocation escalated through the risk assessment task
What proper allocation buys the program
A target for every team
Software teams get a concrete, quantitative goal instead of a vague expectation to "write reliable code."
Risk-weighted, not arbitrary
Critical components get tighter targets, so reliability budget goes where it actually matters.
Something to measure against
Prediction, evaluation, and test all have a defined target instead of an open-ended goal.
A defensible paper trail
Every allocated value ties back to a system requirement, giving the customer confidence the numbers aren't made up.
Give every software component a reliability target it can actually be measured against.
Mission Ready Software consultants have used every allocation method. We can help you get started.
Start with a discussion of your allocation approach.