Software faults & reliability Presented by: Presented by: Pooja Jain Pooja Jain

What is Software Reliability The probability of failure-free software operation for a specified period of time in a specified environment The probability of failure-free software operation for a specified period of time in a specified environment It denotes a product’s trustworthiness or dependability. It denotes a product’s trustworthiness or dependability.

Software Reliability Software reliability not caused due to aging but due to bugs Software reliability not caused due to aging but due to bugs The more the bugs, the lesser the reliability of the software The more the bugs, the lesser the reliability of the software Still failures seem random, hence reliability theory can be applied Still failures seem random, hence reliability theory can be applied

Software faults Software is said to contain fault if for some set of input data the output is not correct. Software is said to contain fault if for some set of input data the output is not correct.

Software Reliability Software systems often are one-off Software systems often are one-off Measuring reliability in lab not practical as too much failure data is needed; requires time Measuring reliability in lab not practical as too much failure data is needed; requires time Failures often result in fault removal, leading to reliability improvement Failures often result in fault removal, leading to reliability improvement Predicting future reliability from measured reliability is harder Predicting future reliability from measured reliability is harder Hence different models needed Hence different models needed

Software Reliability Models Jelinski and Moranda Model Jelinski and Moranda Model Realizes each time an error is repaired reliability does not increase by a constant amount. Realizes each time an error is repaired reliability does not increase by a constant amount. Reliability improvement due to fixing of an error is assumed to be proportional to the number of errors present in the system at that time. Reliability improvement due to fixing of an error is assumed to be proportional to the number of errors present in the system at that time.

Software Reliability Models Block coverage model Block coverage model Goel – Okumoto (G-O) Imperfect debugging model Goel – Okumoto (G-O) Imperfect debugging model GONHPP GONHPP Musa – Okumoto (M-O) Logarithmic Poisson Execution Time model Musa – Okumoto (M-O) Logarithmic Poisson Execution Time model

Software Reliability Growth Models Assume that reliability is a function of the defect level and as defects are removed, reliability improves Assume that reliability is a function of the defect level and as defects are removed, reliability improves Model parameters determined from past data on failures and fixes Model parameters determined from past data on failures and fixes

Software Failure Mechanisms Failure cause: Software defects are mainly design defects. Failure cause: Software defects are mainly design defects. Wear-out: Software does not have energy related wear-out phase. Errors can occur without warning. Wear-out: Software does not have energy related wear-out phase. Errors can occur without warning. Repairable system concept: Periodic restarts can help fix software problems. Repairable system concept: Periodic restarts can help fix software problems. Time dependency and life cycle: Software reliability is not a function of operational time. Time dependency and life cycle: Software reliability is not a function of operational time. Environmental factors: Do not affect Software reliability, except it might affect program inputs. Environmental factors: Do not affect Software reliability, except it might affect program inputs. Reliability prediction: Software reliability can not be predicted from any physical basis, since it depends completely on human factors in design. Reliability prediction: Software reliability can not be predicted from any physical basis, since it depends completely on human factors in design.

Software Reliability Models After fitting a model describing the failure process we can estimate its parameters, and the quantities such as the total number of faults in the code, future failure intensity and additional time required to achieve a failure intensity objective. After fitting a model describing the failure process we can estimate its parameters, and the quantities such as the total number of faults in the code, future failure intensity and additional time required to achieve a failure intensity objective.

Software fault tolerance techniques: are designed to allow a system to tolerate software faults that remain in the system after its development are designed to allow a system to tolerate software faults that remain in the system after its development provide mechanisms to the software system to prevent system failure from occurring provide mechanisms to the software system to prevent system failure from occurring

Multiple data representation enviroment: Data diverse techniques are used in a multiple data representation environment utilize different representations of input data to provide tolerance to software design faults Multiple version software enviroment: Design diverse techniques are used in a multiple version software environment use the functionally of independently developed software versions to provide tolerance to software design faults

Design diversity Popular techniques which are based on the design diversity concept for fault tolerance in software are: Popular techniques which are based on the design diversity concept for fault tolerance in software are:  Recovery Block  N-Version Programming  N-Self-Checking Programming

Data Diversity Techniques While the design diversity approaches to provide fault tolerance rely on multiple versions of the software written to the same specifications, the data diversity approach uses only one version of the software. While the design diversity approaches to provide fault tolerance rely on multiple versions of the software written to the same specifications, the data diversity approach uses only one version of the software. This approach relies on the observation that a software sometime fails for certain values in the input space and This approach relies on the observation that a software sometime fails for certain values in the input space and this failure could be avoided if there is a minor perturbation of input data which is acceptable to the software. this failure could be avoided if there is a minor perturbation of input data which is acceptable to the software.

Enviroment Diversity Techniques The environment diversity approach requires reexecuting the software in a different environment. The environment diversity approach requires reexecuting the software in a different environment. Transient faults typically occur in computer systems due to design faults in software which result in unacceptable and erroneous states in the OS environment. Transient faults typically occur in computer systems due to design faults in software which result in unacceptable and erroneous states in the OS environment. When the software fails, it is restarted in a different, error-free OS environment state which is achieved by some clean up operations When the software fails, it is restarted in a different, error-free OS environment state which is achieved by some clean up operations

Software Failure Mechanisms Redundancy: Can not improve Software reliability if identical software components are used. Redundancy: Can not improve Software reliability if identical software components are used. Interfaces: Software interfaces are purely conceptual other & not visual. Interfaces: Software interfaces are purely conceptual other & not visual. Failure rate motivators: Usually not predictable from analyses of separate statements. Failure rate motivators: Usually not predictable from analyses of separate statements..

Testing Testing remains main verification activity – most reliance on it Testing remains main verification activity – most reliance on it Consumes as much as half of the total effort in a sw product Consumes as much as half of the total effort in a sw product Testing: test case design, execution, checking the results, then debugging, fixing, retesting Testing: test case design, execution, checking the results, then debugging, fixing, retesting Each step is expensive Each step is expensive

Conclusions Software reliability is a key part in software quality Software reliability is a key part in software quality Software reliability improvement is hard Software reliability improvement is hard There are no generic models. There are no generic models. Statistical testing should be used but it is not easy again to implement them Statistical testing should be used but it is not easy again to implement them

Thank You!! Any Questions?