Software reliability engineering study of a large-scale telecommunications software system

Carman, D.W.; Dolinsky, A. A.; Lyu, Michael R.; Yu, Jun-Wu

doi:10.1109/issre.1995.497677

Cited by 14 publications

(4 citation statements)

References 10 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…D ESPITE some heroic efforts from a small number of research centers and individuals (see, for example, [4], [7], [20], [24], [25], [28], [35], [38]), there continues to be a dearth of published empirical data relating to the quality and reliability of realistic commercial software systems. Two of the most important studies [1] and [3] are now over 16 years old.…”

Section: Introductionmentioning

confidence: 99%

Quantitative analysis of faults and failures in a complex software system

Fenton

Ohlsson²

2000

IIEEE Trans. Software Eng.

557

358

View full text Add to dashboard Cite

AbstractÐThe dearth of published empirical data on major industrial systems has been one of the reasons that software engineering has failed to establish a proper scientific basis. In this paper, we hope to provide a small contribution to the body of empirical knowledge. We describe a number of results from a quantitative study of faults and failures in two releases of a major commercial system. We tested a range of basic software engineering hypotheses relating to: The Pareto principle of distribution of faults and failures; the use of early fault data to predict later fault and failure data; metrics for fault prediction; and benchmarking fault data. For example, we found strong evidence that a small number of modules contain most of the faults discovered in prerelease testing and that a very small number of modules contain most of the faults discovered in operation. However, in neither case is this explained by the size or complexity of the modules. We found no evidence to support previous claims relating module size to fault density nor did we find evidence that popular complexity metrics are good predictors of either fault-prone or failure-prone modules. We confirmed that the number of faults discovered in prerelease testing is an order of magnitude greater than the number discovered in 12 months of operational use. We also discovered fairly stable numbers of faults discovered at corresponding testing phases. Our most surprising and important result was strong evidence of a counter-intuitive relationship between pre-and postrelease faults: Those modules which are the most fault-prone prerelease are among the least fault-prone postrelease, while conversely, the modules which are most faultprone postrelease are among the least fault-prone prerelease. This observation has serious ramifications for the commonly used fault density measure. Not only is it misleading to use it as a surrogate quality measure, but, its previous extensive use in metrics studies is shown to be flawed. Our results provide data-points in building up an empirical picture of the software development process. However, even the strong results we have observed are not generally valid as software engineering laws because they fail to take account of basic explanatory data, notably testing effort and operational usage. After all, a module which has not been tested or used will reveal no faults, irrespective of its size, complexity, or any other factor.

show abstract

Section: Introductionmentioning

confidence: 99%

Quantitative analysis of faults and failures in a complex software system

Fenton

Ohlsson²

2000

IIEEE Trans. Software Eng.

557

358

View full text Add to dashboard Cite

show abstract

“…Hence, the software reliability is an important factor that should be considered when evaluating the data storage reliability. There are various metrics to specify the software reliability, such as failure rate, mean time to failure (MTTF), and reliability function [32]. In this paper, the software reliability is evaluated to be the mission success rate, which can be calculated to the ratio of allocating tasks to the successfully completed tasks.…”

Section: Software Reliabilitymentioning

confidence: 99%

Multiobjective Reliable Cloud Storage with Its Particle Swarm Optimization Algorithm

Liu

Fan

Wei

et al. 2016

Mathematical Problems in Engineering

View full text Add to dashboard Cite

Information abounds in all fields of the real life, which is often recorded as digital data in computer systems and treated as a kind of increasingly important resource. Its increasing volume growth causes great difficulties in both storage and analysis. The massive data storage in cloud environments has significant impacts on the quality of service (QoS) of the systems, which is becoming an increasingly challenging problem. In this paper, we propose a multiobjective optimization model for the reliable data storage in clouds through considering both cost and reliability of the storage service simultaneously. In the proposed model, the total cost is analyzed to be composed of storage space occupation cost, data migration cost, and communication cost. According to the analysis of the storage process, the transmission reliability, equipment stability, and software reliability are taken into account in the storage reliability evaluation. To solve the proposed multiobjective model, a Constrained Multiobjective Particle Swarm Optimization (CMPSO) algorithm is designed. At last, experiments are designed to validate the proposed model and its solution PSO algorithm. In the experiments, the proposed model is tested in cooperation with 3 storage strategies. Experimental results show that the proposed model is positive and effective. The experimental results also demonstrate that the proposed model can perform much better in alliance with proper file splitting methods.

show abstract

“…However, the framework is difficult to utilize in practice because it requires a detailed knowledge about the program input space and the program execution times which is prohibitively difficult to obtain for modern software designs. A test compression factor that is estimated by comparing test and field failure data from a previous release was utilized in Carman et al (1995). Borrowing an idea from hardware reliability modeling, the concept of accelerated life testing was applied to software failure data in Okamura et al (2001).…”

Section: Introductionmentioning

confidence: 99%