Hardware metrics are not suitable for software since its matrices are based on notation of component failure. Software failures are often design failures. Often the system is available after the failure has occurred.

No single metric is universally appropriate and the particular metric used should depend on the application domain and the expected usage of the system.

Important software reliability matrices are the following
•    Mean time to failure (MTTF)
•    Mean time between failure (MTBF)
•    System Availability (AVAIL)
•    Probability of failure on demand (POFOD)
•    Rate of failure occurrence (ROCOF)
•    Probability of failure for a given output

All the above metrics are described briefly below.

It is defined is the time interval between successive failure.

An MTTF of 100 indicates that the average failure interval is 100 time units. The time units are totally dependent on the system and it can even be specified in the number of transactions, as is the case of database query system.

For time-based system, to ensure that there is not failure within a transaction, MTTF should be at least greater than response time.

MTTF is relevant for system with long transactions i.e., where system processing takes a longer time. MTTF should be longer than transaction length.

For example, it is suitable for computer-aided design system where a designer wil. work on a design for several hours, words processor system.

Mean time between failures is defined as the summation of MTTF and MTTR (mean time to repair). Thus,

MTBF = MTTF + MTTR

Some contend that MTBF is a better measure than defects/KLOC because defect density is less of a concern than failures.

Availability is a measure of the time during which the system is available over long time periods. It takes into account the repair and restart times for the system. It is given as:

Reliability can be calculated as, Reliability = MTBF / (1 + MTBF)

An availability of 0.995 indicates the system is available 995 out of 1000 time units. It is relevant for non-stop, continuously running system, such as telephone switching system , rollaway signaling system.

It is defined as the probability that the system will be available when a services is requested It is useful when demand for service are intermittent and relatively infrequent.

A POFOD of 0.1 indicates that at least one out of 10 service requests will fail.

It is appropriate for protection system where services are demanded occasionally and where there are serious consequences of the service is not delivered.

POFOD is an important measure for safety critical systems and should be kept as low as possible. It is relevant for much safety-critical system with exception management components such as emergency shutdown system in a chemical plant.

It is the number of failures occurring in unit time, interval. ROCOF of 0.02 means 2 failures will occur for every 10 operational time unit steps.

A measure of the number of values tested and the number of inputs causing failures in each input sub-domain gives an indication of the confidence for that input variable.

This is particularly important for software with a large number of inputs and outputs each covering a large range of values.

It is relevant for operating systems, transaction processing systems where the system has to process a large number of similar requests that are relatively frequent, e.g., Credit card processing system, airline booking system.

Because real-time software is used to control hardware events and these events are prioritized, an important metric would be to find the probability of failure for a given output variable controlling the event.

A lower probability of failure is desired for events with high priority.

For more help in Software Reliability Metric click the button below to submit your homework assignment