J. D. Musa, A. Ianino, K. Okumuto, Software Reliability Measurement Prediction Application, McGraw-Hill, 1987.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....fault management it is important to distinguish the concepts of software failure and fault. A software failure is the departure of the external results of program operation from requirements. A fault is the defect in the program that, when executed under particular conditions, causes a failure [3]. A multiagent system is a complex distributed system. All possible faults in distributed systems may take place in multi agent systems, such as processor faults, network faults and software bugs. All these faults can impact the performance of the system and lead to a system failure [4] From the ....

John D. Musa, Anthony Iannino and Kazuhira Okumoto. "Software Reliability: Measurement, Prediction, Application". ISBN 0-07-044093-X

....a plane. But for software developers of new, shrink wrapped products, deriving accurate operational profiles is not so easy. Another problem facing publishers of mass marketed software stems from the accepted definition of operational profile. According to classic software reliability references [4, 3], an operational profile is defined as follows: An operational profile is the set of input events that the software will receive during execution along with the probability that the events will occur. The problem, however, is that this definition is too narrow in scope for the bulk of the ....

J.D. Musa, A. Iannino, and K. Okumoto. Software Reliability Measurement Prediction Application. McGraw-Hill, 1987. ISBN 0-07-044093-X.

....of severity and failure classes. A program to interface with a commercial suite of modelling programs. A program dealing with static assessment. 6.8. 1 Severity and class selection Where failures are classified by severity and type it is possible to perform reliability analysis for each class [MUS3, p80], although this does generally reduce the sample size considerably. If, for example, failure severities are classed as one of Annoying , or Blocking it is then possible to perform analysis on each or both of these severity classes. In practice however, it is generally found that there are two ....

Musa, J.D., Iannino, A., Okumoto, K., Software Reliability : Measurement Prediction and Application. McGraw-Hill. 1987

....is our operational profile. When we then shall choose test cases we simply generate random numbers between [0, 1] for each test case. 3.2. 4 Reliability One way to define reliability is the probability of failure free operation of a computer program for a specified time in a specified environment [6]. This means that if you have a reliability of 0.99 for 10 hours the program will, in average, during these 10 hours fail one time out of hundred. Another way to express reliability is failure intensity, i.e. failures per time unit. The relationship between failure intensity and reliability ....

....reliability and also projects the future reliability. This way the project manager knows how much more testing that needs to be done before they reach their objective. When you shall model reliability, the first you have to consider are the factors that affect the reliability. These factors are [6] fault introduction, fault removal and the environment. Fault introduction mainly depends on the characteristics of the developed code, primary size, and the development characteristics, software engineering technologies, tools and the level of experience of personnel. Fault removal depends on ....

[Article contains additional citation context not shown here]

J. D. Musa, A. Iannino, K Okumoto, "Software Reliability: Measurement, Prediction, Application", McGraw-Hill publishing Company, 1990

....for the late delivery. Therefore we need a method to predict when software is ready for release. Such estimations can be made by defect tracking. Figure 12 Viewpoint Directory Legend McConnell (McConnell, 97) describes four techniques to perform such estimations, Defect Density (Musa et al. 87) this measures the number of defects per KLOC 1 from previous projects. From this we can determine the expected number of defects in the current system, providing we know the program s length, and assuming that development has introduced the same defect density as in past projects. Defect ....

....total number of defects can be calculated by the following formula, Defects = Defects Defects Defects total group A group B (group A group B) Therefore we can predict how many defects are expected in the code, and hence estimate when testing will be complete. Defect Seeding (Musa et al. 87) this is the method used by the VOCAL viewpoint browser tool to calculate the total expected number of defects in the project (see later) It has the advantage of not requiring dual test teams (as in defect pooling above) when this would put too much strain on the testing budget. Of course we ....

[Article contains additional citation context not shown here]

MUSA, J. D.; IANNINO, A.; OKUMOTO, K.: "Software Reliability Measurement, Prediction, Application" (McGraw-Hill, 1987)

....by Airbus officials) the amount of software embedded in a typical device is doubling in the number of lines about every 18 months. Consider that even today s best systems still have software defect densities of around 3 6 faults per KSLOC (if you count every fault, no matter how small it may be) [4]. Interestingly, that rate has held constant for the last two decades regardless of the shift to object oriented technology, software reuse, automated debuggers, better test tools and compilers, stronger type safety, etc. Because all of the new ideas have not decreased this rate, it would appear ....

J. D. MUSA, A. IANNINO, AND K. OKUMOTO. Software Reliability Measurement Prediction Application. McGraw-Hill, 1987. ISBN 0-07-044093-X.

....is creating, to some degree, an artificial personnel shortage. Further indications that our profession is in turmoil can be seen when we look at the quality of our products. Musa et al. exposed that defect densities have remained fairly constant during the past 20 years: 3 6 faults per KSLOC [8]. There are two interpretations that can made from this finding. We can argue that this is good news since systems are larger and more complex. Or we can argue a negative case since all of our advanced software engineering theory and tools have failed to decrease defect densities. Since the 3 6 ....

J. D. MUSA, A. IANNINO, AND K. OKUMOTO. Software Reliability Measurement Prediction Application. McGraw-Hill, 1987. ISBN 0-07-044093-X. 9

....even if there is not any proved relation between internal attributes values and external quality attributes values. The practice has defined this heuristic. For example, the level of reliability obtained by each system component is estimated using reliability growth models during system testing [4, 5, 6]. The information obtained can be used to drive testing influencing controlling in this way the software development process. We do not describe the internal characteristics of the system for reason of conciseness. These characteristics are shown together with their target values in table 2 for ....

Musa, J.D., Iannino, A., Okumoto, K., "Software Reliability: Measurement, Prediction, Application", McGraw-Hill, 1987.

....0.314 F14 0.076 0.124 0.114 0.073 0.308 F15 0.022 0.027 0.021 0.016 0.058 F16 0.015 0.027 0.040 0.041 0.774 Average 0.219 0.218 0.213 0.187 0. 001 We next compare the reliability estimated by using our method with that from Musa s Basic execution model and the logarithmic Poisson (LP) model [20]. The reason for chosen these two models are given in Appendix B. Since we know the real reliability S after debugging, we first compare S 0 S , where S is an estimate by wharever the methods we are interested. For the 30 block, decision, and all uses cases tested and debugged, the ....

J. D. Musa, A. Iannino, and K. Okumoto, "Software Reliability Measurement Prediction Application, " McGraw-Hill, New York, 1987.

....(ffl i1 t) Gammaffl i2 , where ffl i0 , ffl i1 and ffl i2 are constants. Hence, we have for the testing time: D i = ffl i0 i ffl i2 Gamma ffl i1 : The Pareto class of failure rate distributions is useful because it is a generalization of the exponential, Weibull and gamma classes [11, 14]. One can show that the first derivative is less than zero, and the second derivative is greater than zero, provided ffl i0 , ffl i1 and ffl i2 are all positive. Hence, taking the partial derivative of D i w.r.t. i , we get in step 2 of the algorithm (K = N in the first iteration) Gamma ffl ....

J. Musa, A. Iannino, and K. Okumoto, "Software Reliability: Measurement, Prediction, Application," McGraw-Hill, 1987.

....cases such that each possible outcome from each decision point occurs. For OTS software consumers, white box testing techniques will be of little help (however nothing precludes OTS component developers from using them during development) Blackbox testing (according to the operational profile [4] caused by S) will be our technology for determining stand alone component quality. It may be true that the OTS supplier has already done testing of their components, but how much, and according to what generic profile should not be left to chance. Black box testing is not without criticism, ....

J. D. MUSA, A. IANNINO, AND K. OKUMOTO. Software Reliability Measurement Prediction Application. McGraw-Hill, 1987. ISBN 0-07-044093-X.

....Figure 1: Comparison of the Squeeze Play model and the TQR dependability model Squeeze Play is similar to the more common software reliability estimation models but distinct. Software reliability is the probability that the software will not fail in a fixed environment for a fixed period of time [9]. For example, if a program fails once in 100 test cases, its reliability is roughly 0.99, and most software reliability models will provide a score close to that. This is quite different from a confidence that the software is correct. In contrast, our metric not only considers the number of test ....

J. D. MUSA, A. IANNINO, AND K. OKUMOTO. Software Reliability Measurement Prediction Application. McGraw-Hill, 1987. ISBN 0-07-044093-X.

....into a Weibull failure detection model. Weibull type model using time as exposure was considered by, for example, Wagoner [Wag73] although not in the context of non operational profile testing. Also, the Shick Wolverton model can be interpreted as a special case of the Weibull model class [Shi73, Mus87]. Our models were originally developed and verified using the data from a multi university Research supported in part by NASA Grant No. NAG 1 983 Sep 92 2 multi version NASA sponsored program [Eck91, Vou90, Kel88] Recently an attempt was made to use the models during the early testing stages ....

J.D. Musa, A. Iannino, and K. Okumoto, Software Reliability: Measurement Predictions, Application, McGraw-Hill Book Co., 1987.

.... reliability models to answer the question: what is the probability that this code will fail Our testability asks a different question: what is the probably this code will fail if it is faulty Musa labels a similar measurement as the fault exposure ratio, K, in his reliability formulae [6]. The empirical methods for estimating testability are distinct from Musa s techniques, however. Our research has emphasized random testing, because of its attractive statistical properties. However, in full generality, software testability could be defined for different types of testing (e.g. ....

JOHN D. MUSA, ANTHONY IANNINO, AND KAZUHIRA OKUMOTO. Software Reliability Measurement Prediction Application. McGraw-Hill, 1987.

....are also useful in supporting management of the software development process. For instance, obtaining reliability estimates early in the development process can help determine if the software system is on track to meet its reliability goals and therefore increase management effectiveness. Musa [9] dedicates a section of his book on software reliability to the use of software reliability measures. However, at this time, the possible benefits of estimating software reliability are not widely acknowledged in the software community. Not all software development organizations use reliability ....

J.D. Musa, A. Iannino and K. Okumoto, "Software Reliability: Measurement, Prediction, Application", McGraw Hill 1987, ISBN 0-07044093 -X.

....reliability was recognized several years ago [3] and ever since has been a major subject of research in software engineering. A large number and variety of models have been proposed to estimate software reliability. Often, these models have been applied to data obtained from working software [10]. The accuracy of these models, as measured by comparing predicted versus actual software failures, has varied from one project to another. Work done in the past takes sets of real life data and applied statistical metrics to rank existing models [8] Such work is restricted by limitations on ....

J. D. Musa, A. Iannino, and K. Okumoto, "Software Reliability: Measurement, Prediction, Application," McGraw-Hill, New York, 1987.

....at random from the operational profile. The operational profile for the software reflects the operational profile of the target environment that the software will be a part of. An operational profile describes the probability that each input will be selected when the software is deployed [12]. dbt provides an analysis of how well behaved the code is when it is executing in operational modes. So for example, if an input value of 100 to the software is likely to occur in the software s target environment, dbt would execute the software using 100 with appropriate system states and ....

J. D. MUSA, A. IANNINO, AND K. OKUMOTO. Software Reliability Measurement Prediction Application. McGraw-Hill, 1987. ISBN 0-07-044093-X.

No context found.

J. D. Musa, A. Ianino, K. Okumuto, Software Reliability Measurement Prediction Application, McGraw-Hill, 1987.

No context found.

John D. Musa, Anthony Iannino and Kazuhira Okumoto. "Software Reliability: Measurement, Prediction, Application". ISBN 0-07-044093-X

No context found.

J. Musa, A. Iannino, and K. Okumoto, "Software Reliability: Measurement, Prediction, Application," McGraw-Hill, 1987.

No context found.

J. D. Musa, A. Iannino, K. Okumoto, "Software Reliability: Measurement, Prediction, Application", McGraw Hill, 1987, ISBN 0-07-044093-X.

No context found.

John D. Musa, Anthony Iannino and Kazuhira Okumoto, "Software Reliability: Measurement, Prediction, Application", ISBN 0-07-044093-X.

No context found.

J. D. Musa, A. Ianino, K. Okumuto, Software Reliability Measurement Prediction Application, McGraw-Hill, 1987.

No context found.

Musa, J. D., A. Iannino, and K. Okumoto, "Software Reliability: Measurement, Prediction, Application", New York, McGraw-Hill, 1987.

No context found.

John Musa et al, "Software Reliability, Measurement, Prediction, Application", McGraw-Hill, New York, 1988. Progressive Software Reliability Prediction

First 50 documents

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