Fault Avoidance in Software Engineering

Pre-requisites: Software Engineering

Fault Avoidance in Software engineering is used either minimize the possibility of mistakes and/or that trap mistakes before they result in the introduction of system fault Examples of such techniques include avoiding error-prone programming language constructs such as pointers. Fundamental to the achievement of dependability in any system is the basic notions of redundancy and diversity. Diversity and redundancy strategies for avoiding failure.

By focusing on user-oriented concerns, SRE excludes such software testing measurements as unit-test code coverage which is a developer-oriented measure. The vital systems may include components that replicate the functionality of other components (redundancy) or additional checking code that is not strictly necessary for the system to function (redundancy).

Faults can therefore be detected before they cause failures, and the system may be able to continue operating if individual components fail. If the redundant components are not the same as other components (diversity), a common failure in the same, replicated component will not result in a complete system failure. Two approaches are available to software failure rates. The first is obvious, but not very feasible for real-life products one can simply execute all possible paths of execution using all possible test inputs and then total the number of observed failures. This approach is never used however as it would require allocating an infinite amount of testing resources to a problem. determining proof. 

A more likely approach is to estimate test failure rates by extrapolating from sample test results. By sampling a variety of operations and inputs with test cases it will be possible to build up a statistically significant set of test results. While these results will be nowhere near comprehensive, these numbers can be used to model expected failure rates for the whole system.

The mechanism used to extrapolate the failure rate of the system from sample test data is a reliability model. There are a number of these models such as exponential failure class models, Weibull and Gamma failure class models, and Bayesian models. These models will result in a mean-time between failures (MTBF) which is a useful measure of software failure rates and reliability.

For fault-free software development, you need to use a range of software engineering techniques:

1. Quality Management

There are many different models for software quality, but in almost all models, reliability is one of the criteria, attributes, or characteristics that is incorporated. ISO 9126 [1991] defines six quality characteristics, one of which is reliability. IEEE Std 982.2-1988 states "A software reliability management program requires the establishment of a balanced set of user quality objectives, and identification of intermediate quality objectives that will assist in achieving the user quality objectives." Since reliability is an attribute of quality, it can be concluded that software reliability depends on high-quality software. Building high-reliability software depends on the application of quality attributes at each phase of the development life cycle with an emphasis on error prevention, especially in the early life cycle phases. Metrics are needed at each development phase to measure applicable quality attributes.

2. Formal Specification

A formal specification is a mathematical description of software or hardware that may be developed and implemented. It describes what the system should do, (necessarily) the system should do it. Given such a specification, it is possible to use formal cation techniques to demonstrate that a candidate system design is correct with respect to the specification. This has the advantage that incorrect candidate system designs can be good before a major investment has been made in actually implementing the design. An alternative approach is to use provably correct steps to transform a specification design, and ultimately into an actual implementation, that is correct by construction.

A design (or implementation) cannot ever be declared "correct" in isolation, but only correct with respect to a given specification". Whether the formal specification correctly scribes the problem to be solved is a separate issue. It is also a difficult issue to address, ace it ultimately concerns the problem of constructing abstracted formal representations of an informal concrete problem domain, and such an abstraction step is not amenable to a formal pool. 

3. Software Dependability

In general, software customers expect all software to be dependable. However, for non-critical applications, they may be willing to accept some system failures. Some applications, however, have very high dependability requirements and special software engineering techniques may be used to achieve this.

4. Static Verification

Static verification is the process of checking that software meets requirements by doing a physical inspection of it. For Example Code conventions, Bad practices detection, and formal verification.

5. Strong Typing

Strong typing that the programming languages places severe restrictions on the intermixing that is permitted to occur. preventing the compiling or running of source code that uses data in what is considered to be an invalid way. If the language has strong typing, the language compiler can detect many programming errors before they can be introduced into the delivered program.

6. Safe Programming

Safe programming means avoiding or at least minimizing the use of complex and error-prone language constructs to minimize the probability of making mistakes if you use them.

7. Data Protection

Information hiding and encapsulation should be used for the development of programs that are designed for readability and understandability should be encouraged. 

itskawal2000

Follow

Improve

Article Tags :

• Misc
• Software Engineering

Practice Tags :

• Misc