Dependability Evaluation of Software Systems in Operation

Laprie, Jean-Claude

doi:10.1109/tse.1984.5010299

Cited by 133 publications

(48 citation statements)

References 27 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…A representative sample is (in discrete time) [2], [7], [9] and (in continuous time) [6], [3], [4], [5], [10].…”

Section: Software Dependability With a Markovian Structural Modelmentioning

confidence: 99%

“…We have (R + S)1 T = 0. The alternation operational-recovery periods is infinite 9 by assuming the generator Q of the Markov chain X is irreducible: The proposed set of failure processes can be seen as the superposition of the failure processes considered in [6] (or [3]) and [4]. In papers like [6] the considered failures are those called secondary here.…”

Section: The Operational Modelmentioning

confidence: 99%

“…In this case, the white-box (or structural) point of view is an alternative approach in which the structure of the system is explicitly taken into account. This is advocated for instance in [2], [3], [4]. In particular, the structural approach allows one to analyze the sensitivity of the dependability of the system with respect to the dependability of its components.…”

Section: Introductionmentioning

confidence: 99%

See 2 more Smart Citations

Availability modeling of modular software

Ledoux

1999

IEEE Trans. Rel.

View full text Add to dashboard Cite

Summary & Conclusions -Dependability evaluation is a basic component in the assessment of the quality of repairable systems. We develop here a general model specifically designed for software systems that allows the evaluation of different dependability metrics, in particular, of availability measures. The model is of the structural type, based on Markov process theory. In particular, it can be viewed as a attempt to overcome some limitations of the well-known Littlewood's reliability model for modular software. We give both the mathematical results necessary to the transient analysis of this general model and the algorithms that allow to evaluate it efficiently. More specifically, from the parameters describing : the evolution of the execution process when there is no failure, the failure processes together with the way they affect the execution, and the recovery process, we obtain the distribution function of the number of failures on a fixed mission period. In fact, we obtain dependability metrics which are much more informative than the usual ones given in a white-box approach.We briefly discuss the estimation procedures of the parameters of the model. From simple examples, we illustrate the interest in such a structural view and we explain how to take into account reliability growth of part of the software with the transformation approach developed by Laprie and al.Finally, the complete transient analysis of our model allows to discuss in our context the Poissonian approximation reported by Littlewood for its model.

show abstract

“…A representative sample is (in discrete time) [2], [7], [9] and (in continuous time) [6], [3], [4], [5], [10].…”

Section: Software Dependability With a Markovian Structural Modelmentioning

confidence: 99%

Section: The Operational Modelmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

Availability modeling of modular software

Ledoux

1999

IEEE Trans. Rel.

View full text Add to dashboard Cite

show abstract

“…Evaluation methods encompassing physical (hardware) faults and design faults introduced during the specification and development processes might help solve this problem. The need for such a combined evaluation has recently been pointed out [10]. In critical applications, the complexity of current software and hardware designs makes it no longer possible to cope with design faults using only a fault-avoidance approach, and faulttolerance techniques should be considered.…”

Section: Introductionmentioning

confidence: 99%

“…Some work has been done toward the combined modeling of physical and design faults [3,10,12], but, to the best of our knowledge, no evaluation of multiversion systems incorporating both types of faults has been carried out. In this paper, a Markov model to evaluate the unsafety of a twoversion system with version correction during operation is developed and solved.…”

Section: Introductionmentioning

confidence: 99%

Evaluation of safety-oriented two-version architectures

Carrasco

Figueras

Kuntzman

1991

Journal of Systems and Software

View full text Add to dashboard Cite

A Markov model taking into account physical and design faults for a two-version architecture oriented to safety-related applications is developed. Only a probabilistic knowledge of the initial state of the versions in relation to the presence of design faults is assumed. The model can be split into two submodels accounting separately for physical and design faults, and a closed form expression for the unsafety of the system is obtained. The parameter estimation problem is discussed and a method to predict the probability distribution of the number of related design faults at the beginning of the operational life of the system is proposed. The method uses a pool model to process fault-occurrence data collected during a "face-to-face" debugging of the two versions. It has by nature a limited capability for proving version diversity, but it is shown that the limit is of the order of the diversity reported by recent experiments on real software. Finally, the impact of version correction during operation is shown to be negligible for critical applications.

show abstract

Software Reliability Theory

Lyu

2002

Encyclopedia of Software Engineering

View full text Add to dashboard Cite

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...

show abstract

Dependability Evaluation of Software Systems in Operation

Cited by 133 publications

References 27 publications

Availability modeling of modular software

Availability modeling of modular software

Evaluation of safety-oriented two-version architectures

Software Reliability Theory

Contact Info

Product

Resources

About