Software Failure Mechanisms
The software failure can be classified as:
Transient failure: These failures only occur with specific inputs.
Permanent failure: This failure appears on all inputs.
Recoverable failure: System can recover without operator help.
Unrecoverable failure: System can recover with operator help only.
Non-corruption failure: Failure does not corrupt system state or data.
Corrupting failure: It damages the system state or data.
Software failures may be due to bugs, ambiguities, oversights or misinterpretation of the specification that the software is supposed to satisfy, carelessness or incompetence in writing code, inadequate testing, incorrect or unexpected usage of the software or other unforeseen problems.
Hardware vs. Software Reliability
| Hardware Reliability | Software Reliability |
|---|---|
| Hardware faults are mostly physical faults. | Software faults are design faults, which are tough to visualize, classify, detect, and correct. |
| Hardware components generally fail due to wear and tear. | Software component fails due to bugs. |
| In hardware, design faults may also exist, but physical faults generally dominate. | In software, we can simply find a strict corresponding counterpart for “manufacturing” as the hardware manufacturing process, if the simple action of uploading software modules into place does not count. Therefore, the quality of the software will not change once it is uploaded into the storage and start running |
Hardware exhibits the failure features shown in the following figure:  It is called the bathtub curve. Period A, B, and C stand for burn-in phase, useful life phase, and end-of-life phase respectively. | Software reliability does not show the same features similar as hardware. A possible curve is shown in the following figure: If we projected software reliability on the same axes. |
There are two significant differences between hardware and software curves are:
One difference is that in the last stage, the software does not have an increasing failure rate as hardware does. In this phase, the software is approaching obsolescence; there are no motivations for any upgrades or changes to the software. Therefore, the failure rate will not change.
The second difference is that in the useful-life phase, the software will experience a radical increase in failure rate each time an upgrade is made. The failure rate levels off gradually, partly because of the defects create and fixed after the updates.
The upgrades in above figure signify feature upgrades, not upgrades for reliability. For feature upgrades, the complexity of software is possible to be increased, since the functionality of the software is enhanced. Even error fixes may be a reason for more software failures if the bug fix induces other defects into the software. For reliability upgrades, it is likely to incur a drop in software failure rate, if the objective of the upgrade is enhancing software reliability, such as a redesign or reimplementation of some modules using better engineering approaches, such as clean-room method.
A partial list of the distinct features of software compared to hardware is listed below:
Failure cause: Software defects are primarily designed defects.
Wear-out: Software does not have an energy-related wear-out phase. Bugs can arise without warning.
Repairable system: Periodic restarts can help fix software queries.
Time dependency and life cycle: Software reliability is not a purpose of operational time.
Environmental factors: Do not affect Software reliability, except it may affect program inputs.
Reliability prediction: Software reliability cannot be predicted from any physical basis since it depends entirely on human factors in design.
Redundancy: It cannot improve Software reliability if identical software elements are used.
Interfaces: Software interfaces are merely conceptual other than visual.
Failure rate motivators: It is generally not predictable from analyses of separate statements.
Built with standard components: Well-understood and extensively tested standard element will help improve maintainability and reliability. But in the software industry, we have not observed this trend. Code reuse has been around for some time but to a minimal extent. There are no standard elements for software, except for some standardized logic structures.