Edward N. Adams. Optimizing Preventive Service of Software Products. IBM Journal of Research and Development, 28(1):2--14, 1984.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....parameter speed of compromise (l) The Poisson model is suitable for stochastic processes which are statistically independent of the past. When the hosts in our system are carefully maintained with all the known security holes fixed, Poisson model is a reasonable approximation. Earlier studies [11, 12] also showed that Poisson model can correctly characterize the behavior of software system with a small number of bugs. This further justifies of our model. 3 Analytical Results Using the models defined in Section 2, we study the effectiveness of the proxy network scheme. We focus on the two ....

Adams, E.N., Optimizing preventive service of software products. IBM Journal of Research and Development, 1984. 28(1): p. 2-14.

....[Basili96] They also promote team learning, and provide a general assessment of reviewed documents. Of current research topics are: The role of the final inspection meeting (emphasized by Tom Gilb [Gilb93] see also [Votta93] When to stop inspections When to stop testing, cf. [Adams84] The effect of root cause analysis on defects. The role of inspection vs. testing in finding defects, e.g. their relative effectiveness and costeffectiveness. The relationship between general document properties and defects. Defect densities of individual modules through phases and ....

) Edward Adams: "Optimizing Preventive Service of Software Products", IBM Journal of Research and Development, (1):2---14, 1984.

....4 0.1 0.3 2.0 4.4 11.9 18.7 28.5 34.2 5 0.7 1.4 2.9 4.4 9.4 18.4 28.5 34.2 6 0.3 0.8 2.1 5.0 11.5 20.1 28.2 32.0 7 0.6 1.4 2.7 4.5 9.9 18.5 28.5 34.0 8 1.1 1.4 2.7 6.5 11.1 18.4 27.1 31.9 9 0.0 0.5 1.9 5.6 12.8 20.4 27.6 31.2 Table 1: Mean time to fault occurrence, in years. From Adams [Ada84] x; if (a = 0) d = b b) 5 a c) Fault, should multiply by 4 if (d 0) x = 0; x = sqrt(d) 2 a) b; x = c b) if ( a x x b x c) 0) printf( d is an integral solution n ) printf( There is no integral solution n ) There are four possibilities: 1. ....

....by execution, examines the source code in a different way than is addressed by coding guidelines. One looks at only those parts of the program (in translated form) through which flow of control passes and applies specific values, the other examines source code in symbolic form. A study by Adams [Ada84] looked at faults found in applications over time. The results showed, Table 1, that approximately a third of all detected faults occurred on average every 5,000 years of execution time. Only around 2 of faults occurred every five years of execution time. There are two main classes of testing ....

E. Adams. Optimizing preventive service of software products. IBM Journal of Research and Development, 28(1):2--14, 1984.

....faults contribute differently to the overall unreliability of the program: some are larger than others. Large here means that the rate at which the fault would show itself (i.e. if we were not to remove it the first time we saw it) is large: different faults have different rates of occurrence. Adams [Adams 1984] shows a particularly dramatic example of this based on a large database of problem reports for some large IBM systems [Adams 1984] The smallest faults he discovered each occurred only about once every 5000 years. They accounted for 1 3 of uncovered faults. During reliability growth we assume ....

....at which the fault would show itself (i.e. if we were not to remove it the first time we saw it) is large: different faults have different rates of occurrence. Adams [Adams 1984] shows a particularly dramatic example of this based on a large database of problem reports for some large IBM systems [Adams 1984]. The smallest faults he discovered each occurred only about once every 5000 years. They accounted for 1 3 of uncovered faults. During reliability growth we assume that a fix is carried out at each failure. Let us assume for simplicity that each fix attempt is successful. As debugging progresses, ....

E. N. Adams, "Optimizing preventive service of software products", IBM Journal of Research and Development, 28 (1), pp.2-14, 1984. Bev Littlewood, Peter Popov, Lorenzo Strigini: Modelling software design diversity - a review 23

....indicate quite the opposite effect those modules that were most problematic pre release had the least number of faults associated with them post release. Indeed, many of the modules with a high number of defects pre release showed zero defects post release. This effect was first demonstrated by Adams [1984], and replicated by Fenton and Ohlsson [2000] Figure 2 is an example of the sort of results they both obtained. Figure 2 about here So, how can this be The simple answer is that faults found pre release gives absolutely no indication of the level of residual faults unless the prediction is ....

E. Adams, "Optimizing preventive service of software products", IBM Research Journal, 28(1), 2-14, 1984.

.... where over time the application experiences a crash or a hang failure [16] Avritzer and Weyuker have witnessed aging in telecommunications switching software where the effect manifests as gradual performance degradation 1 It should be noted that the term software aging was used in [1] to mean degradation in the quality of the software by an increase in number or severity of design faults due to repeated bug fixes, which is different from our meaning. Perhaps in our context process aging is more appropriate, but we choose to keep the term software aging to be consistent with ....

E. Adams, "Optimizing preventive service of the software products", IBM J. R&D, 28(1), Jan, 1984, pp. 2-14.

.... application experiences a crash or a hang failure [16] Avritzer and Weyuker have witnessed aging in telecommunications switching software where the effect manifests as gradual performance degradation [3] The service rate of the 1 It should be noted that the term software aging was used in [1] to mean degradation in the quality of the software by an increase in number or severity of design faults due to repeated bug fixes, which is different from our meaning. Perhaps in our context process aging is more appropriate, but we choose to keep the term software aging to be consistent ....

E. Adams, "Optimizing preventive service of the software products", IBM J. R&D, 28(1), Jan, 1984, pp. 2-14.

....in the way systems are used by different users, resulting in wide variations of operational profiles. It is thus difficult to predict which defects are likely to lead to failures (or to commonly occurring failures) The latter point is particularly serious and has been highlighted dramatically by [46]. Adams examined data from nine large software products, each with many thousands of years of logged use world wide. He charted the relationship between detected defects and their manifestation as failures. For example, 33 percent of all defects led to failures with a mean time to failure greater ....

# E. Adams, "Optimizing Preventive Service of Software Products," IBM Research J., vol. 28, no. 1, pp. 2-14, 1984.

....metrics have deemed a metric valid if it correlates with the (pre release) fault density. Our results suggest that valid metrics may therefore be inherently poor at predicting software quality. These remarkable results are also closely related to the empirical phenomenon observed by Adams [2] that most operational system failures are caused by a small proportion of the latent faults. The results have major ramifications for the commonly used fault density metric as a de facto measure of user perceived software quality. If fault density is measured in terms of pre release faults (as is ....

Adams E , "Optimizing preventive service of software products", IBM Research Journal, 28(1), 2-14, 1984.

....here the detectabilities of faults are different and the detectability values are set in favor of usage based testing. However, even for this case, uniform testing gives better MTTF once the number of tests exceeds about 110. 4 Usage Testing vs. Coverage Testing Adams study of some real software [1] shows that the operational failure rates for different projects follow a similar distribution with the number of faults having a certain failure rate being inversely proportional to the failure rate. Figure 7 plots the relative detectability profiles from two projects and the average ....

....many additional test inputs based on operational usage do not contribute to more coverage, coverage testing should be more effective in fault detection than usage testing. Assumption 3: The failure rate distribution remains the same when testing starts and after testing finishes. Adams data [1] gives the distribution of failures collected from operational use. For an untested software, the distribution of faults over different detectabilities would be more uniform. Trachtenberg [27] argue that the reason Adams data follows Zipf s law may be because during software development in IBM, ....

E.N. Adams, Optimizing Preventive Service of Software Products, IBM Journal of Research and Development, Vol. 28, No. 1, January 1984, pp. 2-13.

....0.7 0.8 0.9 1 0 2 4 6 8 10 12 14 16 18 20 K Density Ideal sample Model Figure 1: FER against D for an ideal case 2 1.5 1 0.5 0 0.5 1 1. 5 2 0 2 4 6 8 10 12 14 16 18 20 ln(KD) Density Ideal sample Model Figure 2: ln(KD) against D for an ideal case 3 Estimation of Fault Exposure Ratio Adams [13] noticed that software s failure rates in operational phase had a distribution which observes Zipf s law, the failure rate of a fault i is inversely proportional to a power of i, when faults are ranked by decreasing failure rate [15] Trachtenberg [15] proposed a software reliability model based ....

E. N. Adams, Optimizing Preventive Service of Software Products, IBM Journal of Research and Development, vol. 28, no. 1, January 1984, pp.2-14.

....models in order to predict patterns of future performance. The probability distributions for the number of failures within a specified time span, the failure interoccurrence time, and other relevant random variables are often adapted from hardware reliability theory [9] or justified empirically [1, 17]. Rare events and extreme values are topics in probability and statistics with application in several fields of science and engineering (cf. 3, 5, 6, 13, 20] When the necessary conditions are met, these topics lead to well defined distributions as approximate probability laws that are relevant ....

....models [9] ffl The exponential distribution may approximate the probability law for the interoccurrence time of rare failures in long intervals. This distribution is sometimes assumed for the TTF in software reliability computations because it is implied by certain empirical studies (cf. [1]) ffl Given a set of random samples of the TTF, the minimum value in the set is a random variable bounded away from 0 and its limiting distribution (for number of samples N 1) is Weibull. The Weibull distribution itself has been used or suggested for other phenomena (cf. 17] ffl If the ....

E. N. Adams. Optimizing Preventive Service of Software Products, IBM Jour. Res. Dev., vol. 28, no. 1, 1984, pp. 2-14.

....fi L 0 = 60 and fi L 1 = 1, we can calculate the values of K at different densities. The values are plotted in Figure 1 along with the fitted model of Equation 25. Figure 2 is a plot of ln(KD) against D. A perfect fit was shown on both cases as shown in the figures. 3 Estimation of K Adams [13] noticed that software s failure rates in operational phase had similar distribution, which observes Zipf s law, the failure rate of a fault i is inversely proportional to a power of i, when faults are ranked by decreasing failure rate [15] Trachtenberg [15] proposed a software reliability ....

E. N. Adams, Optimizing Preventive Service of Software Products, IBM Journal of Research and Development, vol. 28, no. 1, January 1984, pp.2-14.

....al 1995] Kaaniche and Kanoun 1996] Khoshgoftaar et al. 1996] Ohlsson N and Alberg 1996] Shen et al. 1985] there continues to be a dearth of published empirical data relating to the quality and reliability of realistic commercial software systems. Two of the best and most important studies [Adams 1984] and [Basili and Perricone 1984] are now over 12 years old. Adams study revealed that a great proportion of latent software faults lead to very rare failures in practice, while the vast majority of observed failures are caused by a tiny proportion of the latent faults. Adams observed a remarkably ....

....on the vital few, instead of the trivial many. There are a number of examples of the Pareto principle in software engineering. Some of these have gained widespread acceptance, such as the notion that in any given software system most faults lie in a small proportion of the software modules. Adams [1984] demonstrated that a small number of faults were responsible for a large number of failures. Munson et al. 1992] motivated their discriminative analysis by referring to the 20 80 rule, even though their data demonstrated a 20 65 rule. Zuse 1991] used Pareto techniques to identify the most ....

Adams E, `Optimizing preventive service of software products', IBM Research Journal, 28(1), 2-14, 1984.

No context found.

Edward N. Adams. Optimizing Preventive Service of Software Products. IBM Journal of Research and Development, 28(1):2--14, 1984.

No context found.

E.N. Adams. Optimizing Preventive Service of Software Products. IBM Journal of Research and Development, 28(1):2--14, 1984.

No context found.

E.N. Adams. Optimizing preventive service of software products. IBM Journal of Research and Development, 28(1):2--14, 1984.

No context found.

E. Adams. Optimizing preventive service of software products. IBM Journal for Research and Development, 28(1):3--14, 1984.

No context found.

E. N. Adams. Optimizing preventive service of software products. IBM Journal of Research and Development, 28(1):2--14, 1984.

No context found.

Edward N. Adams. Optimizing preventive service of software products. IBM Journal of Research and Development, 28(1):2--14, January 1984.

No context found.

E. Adams. Optimizing preventive service of software products. IBM Journal for Research and Development, 28(1):3--14, 1984.

No context found.

E. N. Adams, "Optimizing preventive service of software products", IBM Journal of Research and Development, 28, pp. 2-14, 1984.

No context found.

E. N. Adams, `Optimizing preventive service of software products', IBM Journal for Research and Development, 28, (1), 3--14 (1984).

No context found.

Adams E , "Optimizing preventive service of software products", IBM Research Journal, 28(1), 2-14, 1984.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC