Gompertz Software Reliability Growth Model ◾ 341
e model predicts current reliability as 0.975 and suggests the presence of five
residual defects. e model indicates that another 4 weeks of testing is required to
reach a reliability level of 99%.
How to Implement Gompertz
Model in Software Testing
To begin with, one must acknowledge cautions suggested by Faqih in implement-
ing any SRGM. e concerns of Stringfellow and Andrews are also valid. ese
ideas have been already cited in this chapter in the Building a Reliability Growth
Curve section.
Further care and preparations are required for implementing Gompertz SRGM
in real life.
Gompertz is an organic model, a characteristic well seen in the way it fits the
growth of sharks. Gompertz, the discoverer of the model, uses the organic force
of life to drive the equation to predict mortality. Testing must be performed in an
organic manner. at means that testing must be a well-coordinated and homo-
geneous process. ere must be a visibly great understanding between testers and
developers. e arrival of components for tests must follow a systematic pattern
without ad hoc breaks. Testing must be performed with great sincerity. Defects
must be logged promptly without delay.
λ = 0.108
α = 0.043
A = 197
Relative mean absolute error = 2.48%
R
2
= 0.9927
Data
Ohishi Gompertz model
0
0
50
100
150
200
250
5 10 15
Testing week
Cumulative defects
20 25
F(t) = A 1 – e
(1 – e
αt
)
λ
α
—
Figure 21.6 Ohishi’s version of Gompertz reliability growth model.
342 ◾ Simple Statistical Methods for Software Engineering
Often there is an uncertainty in the exact time of defect discovery. e
logged time could dier from the discovered time. e authenticity of time
stamp is questionable. is uncertainty will distort data and introduce
unnatural ripples into data.
To make the model more effective, test cases must be developed early, as soon
as requirements are clear. All possible usage scenarios should be identified and con-
sidered during requirements collection. Requirement coverage and code coverage
must be high enough.
To get better Gompertz t, the test processes must be streamlined. Better
Gompertz t is not merely the result of statistical manipulation but presup-
poses testing process improvement.
Swaminathan [12] observed that proper test management and cooperation among
teams are critical to the success of the Gompertz model. Some customers insist on
Gompertzian testing; they expect establishment of the Gompertz model as part of the
testing process and use it for prediction in an appropriate manner. Swaminathan noted,
Customers are expecting software vendors to give an assurance on the
quality of the delivered product. ey insist that this assurance be backed
up by a valid statistical model and mere verbal assurances would not do.
How do we give this assurance to the customer?
It is not just for the customers. Even for the software vendors, who
have to make decisions on the size of the team for the support phase,
they need to know by when the software would reach a certain matu-
rity and thereby when they could reduce/stop testing.
How can software vendors know when their product will reach a
90% maturity or 99% maturity?
is has become an important aspect to address for both the cus-
tomers and the vendors.
On his experience with building a live Gompertz model and running it,
Swaminathan indicated,
We started building a tool based on excel.4. e input to the tool
was the number of defects found every week and the output was the
predicted defects for the future weeks and the maximum number of
defects that were likely to be found.
Making the excel tool as per the details given was relatively simple. But
the bigger challenge was to make it work for a particular team context.
As the test data started flowing from the team, we started using the
data to predict the maximum number of defects for the product under test.
Gompertz Software Reliability Growth Model ◾ 343
e tools predictions turned out to be different from the intuitive
predictions of the software team. When we tried to understand the
reason, we found that the testing was done quite randomly.
Table 21.1 gives an example. Defects found during six weeks of test-
ing are tabulated. Test cases executed have been included in the table to
set the context and environment. Figure 21.7 contains the cumulative
plot of defects. Apparently, the curve is not Gompertzian. ere is a
hike in the number of test cases executed that corresponds to the hike
in the defects discovered.
In the tool, we were looking at only the week number and number
of defects. We had ignored very crucial data in number of test cases
executed. So, instead of looking at the absolute number of defects, we
started looking at the defects in the context of the test cases executed
every week. Even after this change, the predictions did not match with
Table 21.1 Test Results
Week No.
No. of Test
Cases Executed
No. of Defects
Found
Cumulative
Defects Found
1 100 10 10
2 10 0 10
3 50 3 13
4 75 0 13
5 30 2 15
6 100 5 20
0
0
5
10
15
20
25
1 2 3 4
Week number
Cumulative defects
5 6 7
Figure 21.7 Cumulative defects found in the course of testing.
344 ◾ Simple Statistical Methods for Software Engineering
what the Project Manager expected. When we investigated the reason,
it turned out that the software was not completely developed.
We learned that the Gompertz model can only be used in the test–
analyze–fix cycle and not when full-fledged software development is in
progress. We also learned that the model should not be used for predic-
tion at the early stages of the test–analyze–fix cycle. e product under
test has to reach a certain maturity before we start using the data for
predicting.
As a Gompertzian rule of thumb, until inflection is visible, the model should
not be used for prediction. It takes time and sufficient data to reach the inflection
point. e model is to be kept dormant until such a time.
Gompertz Curve versus GO NHPP Model
e two-parameter GO model is discussed in Chapter 12. is original model has
been criticized because it is concave and lacks the flexibility of the S curve. A third
parameter c was added by Goel to this model to make it reflect real-life testing. e
model is known as the generalized GO model, (NHPP: non homogeneous poisson
process) as shown in Figure 21.8.
is model can be compared with the Gompertz curve for ready reference, also
shown in Figure 21.8. e two curves shown are representative samples from the
generalized GO family and the Gompertz family.
Both are S curves; the similarity is interesting coming from two different
domains, one from computer science and the other from actuarial studies. Both
the models, generalized GO and Gompertz curve, are capable controlled inflection.
However, the Gompertz curve is a wee bit more practical and flexible.
0
0
10
20
30
40
50
60
70
80
90
100
2 4 6
Time
m(t) = a(1 – e
–bt
)
Cumulative defects fixed
8 10
b = 0.8, c = 1
0
0
0.2
0.4
0.6
0.8
1
1.2
10
5 15 20
Time
y = e
–Be
–Ct
Growth
25 30
General Goel model
Gompertzian growth
Figure 21.8 Gompertz curve versus GO NHPP model.
Gompertz Software Reliability Growth Model ◾ 345
Review Questions
1. On what principle is the Gompertz curve grounded?
2. How many parameters control the original Gompertz curve?
3. How many parameters control the modified Gompertz curve?
4. Compare the Gompertz curve with the generalized GO SRGM.
5. What precautions must be taken before implementing the Gompertz SRGM?
Exercises
1. Calculate the inflection point reliability for a Gompertz curve with A = 123.
2. Download Dimitry Kucharavy and De Guio’s [1] paper and find the formula
for inflection time in Equation 20. Using this formula, calculate inflection
time if A = 123, B = 0.01, and C = 0.5.
3. Predict the remaining defects in an application if the testing process has just
crossed the peak discovery rate and at the inflection point 25 defects have
been discovered.
References
1. D. Kucharavy and R. De Guio, Application of S shaped curves, TRIZ—Future
Conference 2007: Current Scientic and Industrial Reality, Frankfurt, Germany, 2007.
2. K. M. S. Faqih, What is hampering the performance of software reliability models?
A literature review, Proceedings of the International MultiConference of Engineers and
Computer Scientists, Vol. I, IMECS 2009, Hong Kong, March 18–20, 2009.
3. C. Stringfellow and A. Amschler Andrews, An Empirical Method for Selecting Software
Reliability Growth Models, Empirical Software Engineering, 7(4), 319–343, 2002.
4. D. Kececioglu, S. Jiang and P. Vassiliou, e modified Gompertz reliability growth
model, Proceedings Annual Reliability and Maintainability Symposium, 1994.
5. K.-M. Liu, C.-P. Lin, S.-J. Joung and S.-B. Wang, Age and growth estimates of the
blacktip sawtail catshark Galeus sauteri in northeastern waters of Taiwan, Zoological
Studies, 50(3), 284–295, 2011.
6. B. Zeide, Analysis of growth equations, Forest Science, 39(3), 594–616, 1993.
7. D. Swamydoss and G. M. Kadhar Nawaz, An enhanced method of LMS parameter
estimation for software reliability model, International Journal of Innovative Research in
Science, Engineering and Technology, 2(7), 2667–2675, 2013.
8. S. Arif, I. Khalil and S. Olariu, On a versatile stochastic growth model, Mathematical
Biosciences and Engineering. Available at http://www.cs.odu.edu/~sarif/Growth-model
-MBE-rev-10-12-11.pdf, 2009.
9. M. Anjum, Md. A. Haque and N. Ahmad, Analysis and ranking of software reli-
ability models based on weighted criteria value, International Journal of Information
Technology and Computer Science, 5(2), 1–14, 2013.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.