This document discusses software reliability and fault discovery probability analysis. It begins by defining software reliability as consisting of error prevention, fault discovery and removal, and reliability measurements. A beta distribution model is proposed to analyze the probability of discovering faults during software testing. The document evaluates different parameter estimation methods for the beta distribution model like variance, sum of squares, and maximum likelihood estimation. It analyzes the performance of these parameter estimation methods using sample programs. The document concludes that estimating failure rates from different faults under different testing measures can provide a prior evaluation of a model's parameters and predict testing effort required to achieve quality goals.

1. IOSR Journal of Computer Engineering (IOSR-JCE)
e-ISSN: 2278-0661,p-ISSN: 2278-8727, Volume 18, Issue 1, Ver. III (Jan – Feb. 2016), PP 97-100
www.iosrjournals.org
DOI: 10.9790/0661-181397100 www.iosrjournals.org 97 | Page
Fault Discovery Probability Analysis for Software Reliability
Estimation
K.Venkata SubbaReddy1
, Prof.I.Ramesh Babu2
1
Assistant professor, Department of Computer Science and Engineering,
Muffakham Jah College of Engineering and Technology, Hyderabad, Telangana, India
2
Professor and Head, Department of Computer Science and Engineering,
Acharya Nagarjuna University, Guntur, Andhra Pradesh, India
Abstract: Software reliability approximation and testing gauge how efficiently software works and meet up the
end-user necessities. Software reliability assurance that users can enter the correct information on a day-to-day
basis, errors can be correctly reprocessed and appropriate action will be taken on software reports. Herein this
publication an effectual beta distribution dependent probability study is anticipated to test the consistency of
software .This paper also examines the testing efficiency for the proposed model and accomplishes a preceding
distribution assessment.
Keywords: Effectiveness, Beta distribution, Flaw Identification, Reliability.
I. Introduction
Reliability of software has been analyzed using mathematical models often termed as software reliability
models. All through the previous decades stochastic models also known as software reliability models (SRMs)
that examine the software fault exposure probability have been lengthily discussed in research literature [1]
[2].The reliability of software is based on fault discovery and rectification procedure. The key purpose of
enhancing reliability is to get rid of faults with a large amount of grave penalty. The second purpose is to
eliminate faults that are encountered frequently by users.
Software reliability consists of three actions [3]
a) Error deterrence
b) Fault discovery and elimination
c) Measurements to progress reliability
The error deterrence methodologies used in the software production environment are premeditated by
coding standards, monitoring systems, agreed bug tracking systems, perfect programming and traditions of
growth. As the number of error avoidance methodologies executed in the project augments; it denotes that the
project is closer to achieve monitoring systems, coding standards, coherent and comprehensive error avoidance
program. Testing phase is carried out for fault discovery and elimination. Testing is carried out in various phases
starting from integration inclusive of testing individual components in module testing phase. System testing is
implemented keeping in mind the objectives with which software was built. It facilitates in validating whether or
not the end objectives are being met. At the last step acceptance testing is executed to make sure that end
objectives promised to the customer are met. Numerous methodologies are used in various phases of testing
starting from selection, design and acceptance testing that lead to fault discovery and elimination.
Software fault forbearance is an essential parameter that needs to be met with better consistency as an
end objective. It is means of reducing anonymous and erratic hardware and software faults, by facilitating a group
of functionally comparable software components developed by diverse teams. The supposition is the design
multiplicity of software, which itself is complex to attain. Software testing is a means to gauge and enhance
software reliability. It plays a noteworthy position in the design, execution, justification and discharge stages. It is
not an established field. Any advancement in this domain will have huge influence on the software industry.
Software defects are drastically dissimilar than the ones occurring in other components of the system:
they are typically design defects, and majority is associated with tribulations in pattern. Whatever testing
methodologies one uses developing bug free software is not possible and if one has set an objective to develop
bug free software then it is extremely infeasible. And the software bugs that are unidentified cause a lot of
societal and lawful concerns. And the very approach to develop bug free software is not the right approach.

2. Fault Discovery Probability Analysis for Software Reliability Estimation
DOI: 10.9790/0661-181397100 www.iosrjournals.org 98 | Page
Figure 1: Block diagram of Software Reliability Assessment
Figure.1. denotes the Software Reliability Assessment procedure. The first step in the procedure is to test
the necessary Software. The second step is to gather the result subsequent to testing; In the third step depending
upon the composed results the reliability model is built. In the fourth step, the validity of the model is checked. If
the model accomplishes validity then the Model is deployed in the procedure and the test model is deployed. If
the model is unacceptable then depending upon the results a new model is built.
II. Related Work
Research in testing domain started in 1970’s [4]. It was accepted as quality prototype in 1990’s. A lot
of software testing definitions exist in the real world. IEEE describes it as “the degree to which a system or
component facilitates the organization of test criterion and performance of tests to decide whether those criterion
have been met”. ISO [4] defines it as “features of software that bear on the pains needed to authenticate the
software product.”
Numerous researchers projected their own definitions such as “to proceed with examination, such as,
controllability, forecast of the tendency for failures to be observed during random black box testing when faults
are presented”. These definitions mirror the character of testability from diverse points of view, but also begin
chaos of understanding on testability. One of the key areas in which research can be carried out in software
domain is compositionality [6]. It is also the same for testability scrutiny. There is no complete or proper way to
obtain system's testability metric from its component's. According to a few on hand testability investigation
model, e.g. DRR metric, the system might be extra testable than its parts, which means we might merge two un-
testable subprograms into a testable one.
Researchers commence to initiate more strongly interpretative methodologies to examine software
testability [5]. Following the IEEE definition, we recommend to use distribution to point to software testability
.Numerous considerations are linked with Software Reliability Growth Models; Table: 1 mentions few of these
assumptions.

3. Fault Discovery Probability Analysis for Software Reliability Estimation
DOI: 10.9790/0661-181397100 www.iosrjournals.org 99 | Page
Table 1: Considerations for Software Reliability Growth Models
III. Proposed Framework
Let us suppose be the likelihood of malfunction and signify the prior distribution of as  (a, b) .
When the prior and posterior distribution belongs to the identical parametric family distributions then it denotes
the homogeneity, beta distribution is a excellent applicant conjugate distribution family.
The Software reliability can be articulated as a failure rate (0) and equivalent confidence level and the
reliability goal should suit the subsequent criterion
This quality of testing is determined by parameters a, b assessed based on the accomplished reliability when
testing denotes zero fault [7].When implementing lively test and inert information into the software model can
generate a more precise result. To authenticate the suitable beta distribution for a precise testing criterion the
subsequent steps need to be followed.
 Defining appropriate testing for measuring efficiency.
 To pioneer criterion efficiency information into the model.
 To establish that while implementing the efficiency information, the allocation can provide an inference of
quality
Testing criterion effectiveness measure Fault detection probability:
This is a software criterion that can give a more steady and comprehensive view of testing. In theory,
there are endless numbers of suites fulfilling few testing criterion. In reality, when the suite number is adequate,
we can get first-class faulty detection probability estimation for diverse faults incorporated in the plan. The
quality of testing is decided by parameters a, b. The Table 2 shows three parameter estimation analysis methods
Table 2: Parameter Inference Result Analysis
RANDOM TESTING
 2
s2 MLE
(Maximum Likelihood Estimation)
Program a b a b a b
Schedule-1 0.4550 1.85 0.465 1.54 0.6712 2.5
Schedule-2 2.1 23.1 1.98 21.9 1.09 11.5
Print Token-1 0.87 3.2 0.76 2.7 1.04 3.82
Print Token-2 2.55 3.15 2.21 2.78 2.34 3.05
Replace 1.07 2.92 1.02 2.75 1.08 2.78
Tcas 0.95 6.5 0.909 16.37 0.96 6.8
S.NO ASSUMPTIONS REALITY
1. Discovered defects are repaired
Test time may be falsely collated if a uncorrected
fault prevents further defects from being detected.
These are not corrected instantly but sensibly
adjusted.
2. Defect correction is ideal
Correction of defects creates more novel defects
andthese are less likely to be revealed.
3.
No novel code is introduced allthrough
QA testing
Novel code is introduced all through the complete
test period. There are methodologies to explain for
preamble of novel code.
4.
The Testing group will report the
defects
Numerous groups of people will represent the
testing; this can be adjusted by stopping defects
those revealed by QA.
5. Every unit of time is alike
This is untrue for calendar time. For
implementation time. “Corner” tests at times are
extra probable defects .Nevertheless as long as the
test sequences are rationally reliable from release
to release;this can be accountedas learning’s from
previous releases.
6. Operational profile depiction
Customers run numerous applications under
diverse configurations which is trickyto describe a
suitable profile.
7. Autonomy of failure
This is practically satisfactory when there is a part
of codethat has not beentested. Test run alongside
this piece of code might discover embezzle divide
of defects.

4. Fault Discovery Probability Analysis for Software Reliability Estimation
DOI: 10.9790/0661-181397100 www.iosrjournals.org 100 | Page
Table 2 shows three parameter estimation analysis methods like 2
, s2
and MLE. The programs
schedule-1, schedule-2 print Token-1, print token-2, Replace and Tcas are considered for testing.
Figure 2 denotes the performance of parameter assessment. The result shows that the disparity started
from three belief methodology is small. According to the arithmetical property of beta distribution, `1' is the
threshold. Any parameters vary from less than to larger than `1 'will alter the outline of the distribution. For
haphazard testing of program printtoken1 and branch coverage testing of schedule-2,  2
and S 2
methodologies
have the values less than 1 and MLE bigger. So when program, standard is more testable, it needs less test
endeavor to accomplish reliability goal. When program, condition is less testable, it asks for extra test endeavor.
Figure 2: Performance of Parameter Estimation
Traditional statistical software reliability appraisal methodology is a 'blind' method to an assured degree.
Occasionally it overestimates the test outcome.
IV. Conclusion
From theoretical investigation and experimental substantiation, a deterred testability signal of software
and condition pair is reached. From another point of view, software failure results from a dissimilar fault that
gets integrated in the software. This paper has accomplished several initial results; diverse faults have diverse
test problems. If the failure rate caused by diverse faults under diverse testing measure is forecasted initially, the
prior evaluation of the model's parameters is attained, i.e. a prior indication of software testability, and forecast
essential testing effort for specific software quality is accomplished.
References
[1]. M. Lyu,“Handbook of Software Reliability Engineering”, McGraw Hill, New York, 1996.
[2]. J. D. Musa, A. Iannino, and K. Okumoto. “Software Reliability Measurement, Prediction, Applications”,McGraw-Hill, New York,
1987.
[3]. Rosenberg Linda, Hammer Ted& Shaw Jack,“Software Matrices and Reliability”, ISSRE, 1998.
[4]. N.P.Edwards,”The effect of certain modular design principles on software testability”, ACN SIGPLAN NOTICES, 10(6):401-410,
April 1975.
[5]. ISO/IEC. ISO/IEC 9126,”Software Engineering Product quality”, ISO Press, Geneva, Switzerland, 1991.
[6]. A. Finkelstein and J. Kramer,”Software engineering: A roadmap”, In Proc. of the Future of Software Engineering 2000, pages 3-22.
ACM Press, April 2000.
[7]. LiangZhao,” A new approach for software testability analysis“, ICSE, May-2006.