Scribd
Upload
57 views18 pages

Software Relaibility Models

This document discusses software reliability and difficulties in measuring it. It defines software reliability as a product's trustworthiness and probability of working correctly over time. While intuitively less defects means higher reliability, there is no simple relationship between observed reliability and latent defects. Reliability depends on usage and is observer-dependent. Common metrics for measuring reliability include rate of failure occurrence, mean time to failure, mean time to repair, mean time between failures, and probability of failure on demand. The document also covers different types of failures.

Uploaded by

Atul Vinod
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
57 views18 pages

Software Relaibility Models

This document discusses software reliability and difficulties in measuring it. It defines software reliability as a product's trustworthiness and probability of working correctly over time. While intuitively less defects means higher reliability, there is no simple relationship between observed reliability and latent defects. Reliability depends on usage and is observer-dependent. Common metrics for measuring reliability include rate of failure occurrence, mean time to failure, mean time to repair, mean time between failures, and probability of failure on demand. The document also covers different types of failures.

Uploaded by

Atul Vinod
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 18

Software Reliability: 2

Alternate Definitions
$ Informally denotes a
product’s trustworthiness or
dependability.
$ Probability of the product
working “correctly” over a
given period of time.
Software Reliability
$ Intuitively:
$ a software product having a large
number of defects is unreliable.
$ It is also clear:
$ reliability of a system improves if
the number of defects is reduced.
Difficulties in Software
Reliability Measurement (1)
$ No simple relationship between:
$ observed system reliability
$ and the number of latent software
defects.
$ Removing errors from parts of
software which are rarely used:
$ makes little difference to the
perceived reliability.
Difficulty in Software
Reliability Measurement (2)
$ The perceived reliability
depends to a large extent
upon:
$ how the product is used,
$ In technical terms on its
operation profile.
Software Reliability
$ Different users use a software product in
different ways.
$ defects which show up for one user,
$ may not show up for another.
$ Reliability of a software product:
$ clearly observer-dependent
$ cannot be determined absolutely.
Difficulty in Software
Reliability Measurement (3)
$ Software reliability keeps
changing through out the life of
the product
$ Each time an error is detected and
corrected
Hardware vs. Software
Reliability
$ Hardware failures:
$ inherently different from software
failures.
$ Most hardware failures are due to
component wear and tear:
$ some component no longer functions
as specified.
Hardware vs. Software
Reliability
$ Software faults are latent:
$ system will continue to fail:
$ unless changes are made to the
software design and code.
Hardware vs. Software
Reliability
$ When a hardware is repaired:
$ its reliability is maintained
$ When software is repaired:
$ its reliability may increase or
decrease.
Reliability Metrics
$ A good reliability measure
should be observer-independent,
$ so that different people can agree
on the reliability.
Rate of occurrence of failure
(ROCOF):
$ ROCOF measures:
$ frequency of occurrence failures.
$ observe the behavior of a software
product in operation:
$ over a specified time interval
$ calculate the total number of failures
during the interval.
Mean Time To Failure (MTTF)

$ Average time between two


successive failures:
$ observed over a large number of
failures.
Mean Time to Repair (MTTR)

$ Once failure occurs:


$ additional time is lost to fix faults
$ MTTR:
$ measures average time it takes to
fix faults.
Mean Time Between Failures
(MTBF)
$ We can combine MTTF and MTTR:
$ to get an availability metric:
$ MTBF=MTTF+MTTR
$ MTBF of 100 hours would indicae
$ Once a failure occurs, the next failure
is expected after 100 hours of clock
time (not running time).
Probability of Failure on
Demand (POFOD)
$ Unlike other metrics
$ This metric does not explicitly involve time.
$ Measures the likelihood of the system
failing:
$ when a service request is made.
$ POFOD of 0.001 means:
$ 1 out of 1000 service requests may result in a
failure.
Availability
$ Measures how likely the system shall
be available for use over a period of
time:
$ considers the number of failures occurring
during a time interval,
$ also takes into account the repair time
(down time) of a system.
Failure Classes
$ Transient:
$ Transient failures occur only for certain
inputs.
$ Permanent:
$ Permanent failures occur for all input
values.
$ Recoverable:
$ When recoverable failures occur:
$ the system recovers with or without operator
intervention.
Failure Classes
$ Unrecoverable:
$ the system may have to be restarted.
$ Cosmetic:
$ These failures just cause minor irritations,
$ do not lead to incorrect results.
$ An example of a cosmetic failure:
$ mouse button has to be clicked twice instead of
once to invoke a GUI function.

You might also like