2.

Explain the following concepts with respect to Software Reliability: A) Software Reliability Metrics B) Programming for Reliability Ans A) Software reliability Metrics The choice of which metric should be used depends on the type of system to which it applies and the requirements of the application domain. For some systems, it may be appropriate to use diffe rent reliability metrics for different sub-systems. In some cases, system users are most concerned about how often the system will fail, perhaps because there is a significant cost in restarting the system. In those cases, a metric based on a rate of failure occurrence (ROCOF) or the mean time to failure should be used. In other cases, it is essential that a system should always meet a request for service because there is some cost in failing to deliver the service. The number of failures in some time period is less important. In those cases, a metric based on the probability of failure on demand (POFOD) should be used. Finally, users or system operators may be mostly concerned that the system is available when a request for service is made. They will incur some loss if the system is unavailable. Availability (AVAIL). Which takes into account repair or restart time, is then the most appropriate metric. There are three kinds of measurement , which can be made when assessing the reliability of a system: 1) The number of system failures given a number of systems inputs. This is used to measure the POFOD. 2) The time (or number of transaction) between system failures. This is used to measure ROCOF and MTTF. 3) The elapsed repair or restart time when a system failure occurs. Given that the system must be continuously available, this is used to measure AVAIL.Time is a factor in all of this reliability metrics. It is essential that the appropriate time units should be chosen if measurements are to be meaningful. Time units, which may be used, are calendar time, processor time or may be some discrete unit such as number of transactions. Software reliability specification : System requirements documents, reliabilit y requirements are expressed in an informal, qualitative, untestable way. Ideally, the required level of reliability should be expressed quantitatively in the software requirement specification. Depending on the type of system, one or more of the metrics discussed in the previous section may be used for reliability specifications. Statistical testing techniques (discussed later) should be used to measure the system reliability. The software test plan should include an operational profile of the software to assess its reliability . The steps involved in establishing a reliability specification are as follows: 1) For each identified sub-system, identify the different types of system failur e, which may occur and analyze the consequences of these failures. 2) From the system failure analysis, partition failures into appropriate classes . For each failure class identified, define the reliability requirement using the appropriate reliability metric. It is not necessary to use the same metric for different classes of failure. For example, where a failure requires some intervention to recover from it, the probability of that failure occurring on demand might be the most appropriate metric. When automatic recover is possibl e and the effect of the failure is some user inconvenience, ROCOF might be more appropriate. The cost of developing and validating a reliability specification for software system is very high .

B)Programming for Reliability There is a general requirement for more reliable systems in all application domains. Customers expect their software to operate without failures and to be available when it is required. Improved programming techniques, better programmi ng languages and better quality management have led to very significant improvemen ts in reliability for most software. However, for some systems, such as those, whic h control unattended machinery, these normal techniques may not be enough to achieve the level of reliability required. In these cases, special programming techniqu es may be necessary to achieve the required reliability. Some of these technique s are discussed in this chapter. Reliability in a software system can be achieve d using three strategies: Fault avoidance: This is the most important strategy, which is applicable to all types of system. The design and implementation proces s should be organized with the objective of producing fault-free systems. Fault tolerance: This strategy assumes that residual faults remain in the system. Faci lities are provided in the software to allow operation to continue when these fa ults cause system failures. Fault detection: Faults are detected before the soft ware is put into operation. The software validation process uses static and dyna mic methods to discover any faults, which remain in a system after implementatio n.

Exception Handling When an error of some kind or an unexpected event occurs during the execution of a program, this is called an exception. Exceptions may be caused by hardware or software errors. When an exception has not been anticipated, contro l is transferred to system exceptions handling mechanism. If an exception has bee n anticipated, code must be included in the program to detect and handle that exce ption. Most programming languages do not include facilities to detect and handle excep tions. The normal decision constructs (if statements) of the language must be used to detect the exception and control constructs used to transfer control to exception occur s in a sequence of nested procedure calls, there is not easy way to transmit it from on e procedure to another. Defensive programming Defensive programming is an approach to program development whereby programmers assume that there may be undetected faults or inconsistencies in their programs.Redundant code is incorporated to check the Sy stem State after modifications and to ensure that the state changeis consistent. If inconsistencies are detecte d,

the state change is retracted or the state is restored to a known correct state. Defensive programming is an approach to fault tolerance, which can be carried ou t without a fault-tolerant controller. The techniques used, however, are fundamen tal to the activities in the fault tolerance process, namely detecting a failure, damage assessment, and recovering from that failure. Failure prevention Programming languages such as Ada and C++ allow many errors w hich cause state corruption and system failure to be detected at compile-time. The compiler can detect those problems which use s the strict type rules of the language. Compiler checking is obviously limited to sta tic values but the compiler can also automatically add code to a program to perform run-ti me checks. Damage assessment Damage assessment involves analyzing the system state to gauge the extent of the state corruption. In many cases, corruption can be avoided by checking for fault occurrence before finally commit ting a change of state. If a fault is detected, the state change is not accepted so t hat no damage is caused. However, damage assessment may be needed when a fault aris es because a sequence of state changes (all of which are individually correct) caus es the system to enter an incorrect state.