Software Failures in FRACAS
A Failure Reporting, Analysis, and Corrective Action System that only tracks hardware leaves the program blind to how software actually fails in the field. Below are the core elements needed to bring software fully into FRACAS.
Why software needs its own place in FRACAS
Software failures are frequently miscoded as hardware, dropped as "user error," or never entered at all because the reporting system and forms were built around physical parts. A Reliable Software SOW requires FRACAS to capture, classify, and root-cause software failures with the same discipline applied to hardware.
No blind spot for software
Software defects and failures may be in a different database. The goal isn't to duplicate the reports but rather to include in the reliability FRACAS report.
Failure Definition Scoring Criteria
This task requires that each defect/failure be assessed for the impact on reliability. Software engineering assess priority based on various factors such as safety, etc. But often ignore the effect on downtime, cascading failures, repeating failures, etc.
This task requires that the failure be traced to the Failure Definition Scoring Criteria and assessed as an essential function failure, etc.
This task requires that the defect tracking system record this assessment.
Feeds the rest of the program
The failure data captured here is the raw material for reliable software evaluation task
The core elements of software failures in FRACAS
Each element below is a capability the FRACAS process and tooling should support so software failures are captured and resolved with the same rigor as hardware.
Failure Definition & Classification
FRACAS shall define what constitutes a reportable software failure and provide a classification scheme that distinguishes software, hardware, and interface failures.
- Clear criteria for what counts as a software failure versus an operator or environmental issue
- Severity classification consistent with system-level Failure Definition Scoring Criteria (FDSC)
- Database fields in the tracking system to store the severity assessment
Reporting & Intake
Certain information is necessary to assess the effect on reliability
- How many times did the failure occur?
- How long was the system down when it happened?
- If there is a workaround, how long does it take to execute the workaround? Will every user know the workaround?
- Did the failure cascade to other failures? Does the failure repeat over a short period of time?
Root Cause Analysis
Every reported software failure shall undergo root cause analysis that identifies the underlying common defect enumeration and origin.
- Standard root-cause taxonomy, such as the Common Defect Enumeration applied consistently across builds
- Analysis depth scaled to failure severity
- Findings linked back to the responsible requirement or design element
Corrective Action & Closure
Defects that affect reliability are tracked to closure to ensure that reliability goals are met
- Closed-loop tracking for defects that affect reliabiity
- Regression testing required before closure
- Re-opened failures tracked separately to catch incomplete fixes
Trending & Metrics
FRACAS data shall be trended over time to show open/close aging by build.
- Failure rate trends by build or increment
- Open-failure aging reports to catch stalled corrective actions that affect reliability
- Trends feed directly into the evaluation tasks
What a complete software FRACAS buys the program
Nothing falls through the cracks
Software failures that either individually or collectively kill downtime are tracked
Track the things that actually affect reliability and availability
Workarounds that take forever, medium priority defects that repeatedly happen or have excessive downtime, cascading failures
Fuels the other 8 tasks
Reliable software evaluation depends on the failure history FRACAS captures here.
Track the issues that kill uptime
Start with a discussion of your FRACAS process.