Software Reliability Theory

Abstract

Software reliability modeling has, surprisingly to many, been around since the early 1970s with the pioneering works of Jelinski and Moranda, Shooman, and Coutinho. The theory behind software reliability is presented, and some of the major models that have appeared in the literature from both historical and applications perspectives are described. Emerging techniques for software reliability research field are also included. The following four key components in software reliability theory and modeling: historical background, theory, modeling, and emerging techniques are addressed. These items are discussed in a general way, rather than attempting to discuss a long list of details. 1.1.5. Time Reliability quantities are defined with respect to time, although it is possible to define them with respect to other bases such as program runs of number of transactions. We discuss the notation of time in the next session. 1.1.6. Failure Functions When a time basis is determined, failures can be expressed in several ways: the cumulative failure function, the failure intensity function, the failure rate function, and the meantime to failure function. The cumulative failure function (also called the mean-value function) denotes the expected cumulative failures associated with each point of time. The failure intensity function represents the rate of change of the cumulative failure function. The failure rate function (or called the rate of occurrence of failures) is defined as the probability that a failure per unit time occurs in the interval [t , t + Dt], given that a failure has not occurred before t. The mean time to failure (MTTF) function represents the expected time that the next failure will be observed. (MTTF is also known as MTBF, mean time between failures.) 1.1.7. Mean Time to Repair and Availability Another quantity related to time is mean time to repair (MTTR), which represents the expected time until a system will be repaired after a failure is observed. When the MTTF and MTTR for a system are measured, its availability can be obtained. Availability is the probability that a system is available when needed. Typically, it is measured by 1.1.8. Operational Profile The operational profile of a system is defined as the set of operations that the software can execute along with the probability with which they will occur. An operation is a group of runs that typically involve similar processing. SOFTWARE RELIABILITY ENGINEERING in this encyclopedia provides a detailed description on the structure, development, illustration, and project application of the operational profile. In general, the number of possible software operations is quite large. When it is not practical to determine all the operations and their probabilities in complete detail, operations based on grouping or partitioning of input states (or system states) into domains are determined. 1.2. The Advantages of Using Execution Time Three kinds of time are relevant to software reliability: execution time, calendar time, and clock time. The execution time f...

Towards Pattern-Based Reliability Certification of Services

“…We can assess the level of reliability in an implemented system that was built with the use of reliability patterns by evaluating different reliability metrics. There are many metrics in the literature [3,16,17,22,27,28] that can be used to calculate the reliability using data collected by monitoring an implemented system. We have selected some reliability metrics from the literature and proposed some of our own.…”

Mapping Software Metrics to Module Complexity: A Pattern Classification Approach

“…This investigation considers the Medical Imaging System (MIS) dataset [12] that has been used in some other studies dealing with software quality [13,14]. MIS is a commercial software system consisting of approximately 4500 modules and comprising approximately 400000 lines of code.…”

Reliability Allocation

“…In some cases, such as in software reliability engineering, it is the failure rate that is often specified [8,9]. The cost function of a subsystem can also be given in terms of its failure rate.…”