Multistage Growth Model for Code Change Eventsin Open Source Software Development:
An Example using Development of Nagios
Hirohisa Aman

Akiko Yamashita

Takashi Sasaki and Minoru Kawahara

Center for Information Technology
Ehime University
Matsuyama, Japan 790–8577
Email: aman@ehime-u.ac.jp

Department of Computer Science
Ehime University
Matsuyama, Japan 790–8577

Center for Information Technology
Ehime University
Matsuyama, Japan 790–8577

Abstract—In recent years, many open source software (OSS)
products have become popular and widely used in the information
technology (IT) business. To successfully run IT business, it isimportant to properly understand the OSS development status.
Having a proper understanding of development status is necessary
to evaluate and predict the product quality. However, the OSS
development status is not easy to understand, because it is often
concurrently developed by many distributed contributors, and its
developmental structure is complicated. To aid the understandingof the development status, there is an approach that models thetrend of source code change events (evolution) with a growth
curve. Although an application of growth curves seems to bea promising approach, there has been a big issue that a single
growth curve is often unsuitable for modeling the whole evolution
because of its complex evolutionary behavior. This paper proposesa multistage model that divides the whole development period intosome stages, and applies a different growth curve to a different
stage. The empirical investigation in this paper shows that theswitching points of stages have meaningful associations with therelease dates.

I.

I NTRODUCTION

Successful software quality management [1] requires quantitative and useful ways to understand the software development process, status and quality. For instance, in order toevaluate and predict the reliability of software products, many
Software Reliability Growth Models (SRGM’s) [2] have beenstudied and utilized in the software industry [3], [4]. Wellknown models are ones based on Non-Homogeneous Poisson
Process (NHPP), such as the exponential (Goel-Okumoto)model [5] and the delayed S-shaped model [6]. Some trend
curves, such as a Gompertz curve [7] and a logistic curve [8],have also been used as empirical growth models in practice.
Recently, there have been studies applying growth curves
and/or trend curves to the open source software (OSS) development. OSS products have become increasingly popularfor not only personal use but also business use. A successful
business with OSS products requires a useful means forevaluating and predicting the product quality based on a proper
understanding of the OSS development process. Since thedevelopment of OSS products is often concurrently carried out
by many distributed developers, its developmental structuresand processes are likely to be complicated. For a better understanding of complicated OSS development, there has been an

approach that models the occurrence of source code changes(software evolution) with a growth curve [9]. The empirical
work reported in [9] shows an applicability of growth curves
to explain and predict the evolution of OSS products. However,there still remains a difficulty in explaining the whole trend ofcode change events with using a single growth curve; it may
be hard to model the whole evolutionary trend with a single
model because of the complex OSS evolutionary process. In
this paper, we propose a multistage model that uses two or
more growth curves and/or trend curves to explain the wholetrend of OSS evolution. In order to make our model generally
and broadly applicable, we will use only data that are available
from public code repositories and do not require any special
data processing, i.e., data which anyone can easily obtain.
The key contribution of this paper is to propose a novel
multistage growth model for software evolution in OSS development from the perspective of “source code change events.”
The proposed model can be a help in understanding thedevelopment of products and their maturity levels. Althoughdata of failures and/or faults detected in the product present
more definite information, such failure/fault data are often notavailable for people who do not directly contribute to thedevelopment. Since code repositories of most OSS development projects are accessible to the public, and source filechange events are always available from the code repositories,
the proposed model is applicable to wider range of OSS
development projects.
The remainder of this paper is organized as follows. Section
II describes basic growth models and their application to asoftware evolution analysis. Section III proposes our multistage
growth model, and Section IV presents an empirical investigation into the applicability of the proposed model on a popular
OSS product. Finally, Section V concludes this paper.

II.

A PPLICATION OF G ROWTH M ODELFOR C ODE C HANGESThis section introduces basic growth models, and describes
an application of them to source code change events (evolution) in the OSS development.

A. Empirical Growth Model (Trend Curve)
In the software industry, the reliability of software products
is often evaluated by focusing on the number of failures foundduring their testing activities [3], [10]. One of fundamental
evaluating fashions is to model the growth of the cumulative
number of failures over time with a mathematical growthmodel [4], [11], [12]. Some trend curves have been empiricallyused as growth models [13], [14]. Representative trend curves
include Gompertz curves, logistic curves and Weibull curves[15] (see Table I and Fig.1).

Table I presents the equations of these three curves, andFig.1 shows examples of them. For all curves in the table,parameter a signifies the value to which y(t) converges, i.e.,a = y(∞); parameter b decides the initial value of y(t), i.e.,y(0), and it mainly affects the shape of curve in early stages ofgrowth; parameter c gives the rate of growth: a larger value ofc corresponds to a faster growth. Parameter d of Weibull curve
is its shape parameter related to the probability distribution oftarget event occurrence: in simpler terms, d > 0 makes an
S-shaped curve, and d ≤ 0 makes an exponential curve.
B. Non-Homogenous Poisson Process-based Growth ModelIn the field of SRGM study, most approaches adopt thefollowing fashion: a failure (or a fault) detection is regarded
as a stochastic event, and this detection process is modeled by
the Non-Homogeneous Poisson Process (NHPP). Now let h(t)be the failure (or fault) detection rate at time t, and let y(t) be
the expected cumulative number of failures (or faults) foundby time t. We can write the relation between them as
dy(t)
.
(1)
dt
Then, assume that the failure/fault detection rate h(t) depends
on the number of remaining failures/faults ash(t) =dy(t)= b(t) · { a − y(t) } ,(2)dt
where a = h(∞) and b(t) is the proportionality factor at timet.
Equation (2) presents the basic form of NHPP-based models. There are numerous variations of such equation, and a different equation leads to a different model. Fundamental models

R EPRESENTATIVE TREND CURVES .

Model

FormulaGompertz curvey(t) = abc ,t(0 < a,0 < b < 1,

0 < c < 1).

a,
1 + be−ct(0 < a, b, c).

logistic curvey(t) =

Weibull curvey(t) = a − be

−ctd

,

(0 < a, b, c, d).

100

A Gompertz curve is an S-shaped curve which was originally proposed to express the law of human mortality. It has
been applied to various fields of science and technology formodeling biological phenomena, economic phenomena and soon [16]. A logistic curve is an S-shaped curve which wasstudied to model the population growth. It has also been widely
applied to the scientific world as well as Gompertz curves[17]. Since the cumulative number of failures often makes an
S-shaped curve over testing time, a Gompertz curve and/or alogistic curve are fitted to actual data and used for evaluating
the testing activity progress or for predicting the number ofremaining (potential) failures.

80

Weibull

20

40

y(t)

60

Gomertzlogistic
0

A Weibull curve is also useful to model the growth of
cumulative number of failures. It is more flexible curve than
the above two trend curves since Weibull curve has a shapeparameter (d in Table I). Weibull curves can be used formodeling a software reliability growth as well [18], [19].

TABLE I.

0

20

40

60

80

100

t

Fig. 1.

Examples of trend curves shown in Table I.
(a = 100, b = 0.008, c = 0.95 for Gompertz curve)(a = b = 100, c = 0.001, d = 2 for Weibull curve)(a = 100, b = 80, c = 0.1 for logistic curve)

are the exponential (Goel-Okumoto) model, the delayed Sshaped model and the inflection S-shaped model [20]. Table
II gives the formulas of y(t) in these three models, and Fig.2
shows examples of them.
The exponential model is derived from Eq.(2) by lettingb(t) be a constant, i.e., b(t) = b which corresponds toparameter b in Table II. Thus, the growth in the exponential
model constantly slows since the failure detection rate h(t) isdecided by the constant b and the remaining failures (a− y(t))(see Eq.(2)).
The delayed S-shaped model is composed of two exponential models: the first model represents the failure detection
process which is the same as the exponential model, and thesecond one corresponds to the fault recognition process. In the
delayed S-shaped model, a failure detection event and a fault
recognition event are distinguished, and the fault recognition
is considered to be doable after the corresponding failure was
detected. The formula of delayed S-shaped model is derived
from another version of Eq.(2) asm(t) = a(1 − e−bt ),
(3)
dy(t)
= b · { m(t) − y(t) } ,dtwhere m(t) and y(t) signifies the expected cumulative numberof detected failures and the expected cumulative number ofrecognized faults, respectively. The fault recognition rate isdecided by the number of remaining unrecognized (alreadydetected, but not recognized) faults (m(t) − y(t)), whose
concept is the same as the exponential model.

TABLE II.

F UNDAMENTAL NHPP- BASED GROWTH MODELS .
Model

FormulaExponential modely(t) = a(1 − e−bt ),C. Growth Model for Code Change Events
The growth models described in Sections II-A and II-B
have been used for modeling the growth of the cumulative
number of failures (or faults). Such models can also be applied
to other types of data by focusing on software development
events other than failure detection. One of the most interesting
events is “source code change” that reflects the evolutionof software products. OSS development is often concurrently
carried out by many distributed developers, so timings of whencode changes are made depend on individual developers. Since
it is difficult to model individual developers’ behaviors, there
is an approach from the point of view of stochastic events—
regard a code change event as a stochastic event, and model
the occurrence of code changes [9], i.e., a modeling of codechanges (software evolution) with a growth model.

(0 < a, b).
y(t) = a

Delayed S-shaped model

1 − (1 + bt)e−bt,(0 < a, b).
a(1 − e−bt ),1 + ce−bt(0 < a, b, c).

y(t) =

100

Inflection S-shaped model80

exponential

y(t)

60

Figure 3 shows the cumulative number of monthly codechange events occurring in the development of Nagios1 , anda Gompertz curve fitted to the actual data. If a growth model
explains the trend of code changes well, we would be able toevaluate the development status or predict the occurrence ofcode changes (evolution) based on the growth model.

20

40

inflection S−shaped

delayed S−shaped
0

III.
100

Examples of NHPP-based models shown in Table II.
(a = 100, b = 0.05 for exponential model)(a = 100, b = 0.04 for delayed S-shaped model)(a = 100, b = 0.05, c = 2 for inflection S-shaped model)

The inflection S-shaped model is also based on Eq.(2) but
it uses another b(t) which varies over testing time. The model
introduces another parameter l in addition to parameters aand b. Parameter l represents a learning effect in the failure
detection, and define b(t) asb(t) = bl + (1 − l)

y(t)
a


.

Now, we can find temporally (locally) stable states of thegrowth in Fig.3—e.g., around the 40th month and around the100th month. That is to say, they seem to have some cycles between “actively-developed (unstable)” states and “temporally
stable” states (see Fig.4). Based on this idea, we propose toswitch our growth models in which we encounter temporally(4)

If l → 1 then b(t)  b, so the model is almost identical withthe exponential model. If l → 0 then b(t)  y(t)/a, i.e., b(t) isapproximately proportional to the ratio of detected failures bytime t. The formula of the inflection S-shaped model in Table
II is derived from Eq.(2) and Eq.(4), where c = (1 − l)/l and0 < l < 1.
The exponential model shows a growth curve which isconvex upward, while the delayed S-shaped model draws an
S-shaped curve as shown in Fig.2. Although the inflection Sshaped model also draws an S-shaped curve, it can be a curve
similar to the exponential model when c  0. For all models,parameter a signifies the value to which y(t) converges, andparameter b corresponds to the growth rate. Parameter c of theinflection S-shaped model can be a shape parameter which islike the one of Weibull model. These models have been widely
known as useful ways to evaluate the testing activities in thesoftware industry [3], [13], [21].

8000 10000

Fig. 2.

While the previous work applied a growth model tocode change events (software evolution), notice that such an
approach assumes the growth model is well-fitted to actual
data and explains the trend of code changes well. Such anassumption may not always apply in reality. For instance, theGompertz curve shown in Fig.3 is not well-fitted to actual
data. Thus, the model does not explain the whole trend ofcode changes well, and it does not work for evaluation andprediction of evolution well.

6000

80

4000

60

t

2000

40

0

20

cumulative frequency of code changes

0

M ULTISTAGE G ROWTH M ODEL

0

20

40

60

80

100

120

140

development period (month)Fig. 3. Gompertz curve fitted to the cumulative frequency of code changes
in the development of Nagios.
1 http://www.nagios.org/. A popular application for monitoring
information infrastructure systems.

TABLE III.

Fig. 4.

E MPIRICAL OBJECT: D EVELOPMENT OF N AGIOS .

Data collection period#code changes

Development language

2/28, 2002 – 9/10, 2013(139 months)

11, 392

C

support forum Web site3 , SNS (including twitter, Facebook
and LinkedIn), mailing lists4 , etc.

Development state changes.

A. Data Collection
stable states; our growth model gets a fresh start at a temporally
stable point. We will call this a “multistage growth model.” Thefollowing Procedure 1 shows our model building steps.
Procedure 1 (Building a multistage growth model):Suppose M growth models yi (t) (for i = 1, . . . , M ) areavailable in our computational environment. Let c(t) be thecumulative number of code change events occurred by the tth month of the development, and suppose we have the actual
data of c(t) for 0 < t ≤ N , where the N -th month is the latest
month in our observation of development. Let the s-th monthbe the switching point at which the growth model gets a fresh
start (restart).
1) Start our model building at the first month: s ← 1.
2) Apply a growth model yi (t) to actual data c(t) for s ≤t ≤ s+x, where x is a natural number which is grater thanor equal to six2 . For all possible x and for all available
growth models, perform the above application of a growthmodel to actual data.
3) Find the best-fitted growth model and the duration, i.e.,
the pair of yi (t) and x such that the following fitness
index φi,s (x) has the minimum value:
φi,s (x) =AICi,s (x),x+1

where AICi,s (x) is the fitness of model yi (t) to theactual data c(t) for s ≤ t ≤ s + x, evaluated by Akaike
information criterion (AIC) [22]. A smaller value signifies
a better fitting. Since AIC values get larger as the numberof data increases, the above index is normalized by the
number of months (the length of stage period).
Then, decide to use the best-fitted model yi (t) for theduration s ≤ t ≤ s + x.
4) If s + x < N , i.e., the (s + x)-th month is not the final
month, s ← s + x + 1 and go back to 2) in order to getanother fresh start of the next stage.
2
IV.

E MPIRICAL I NVESTIGATIONThis section presents an empirical investigation into theapplicability of the proposed model, with using the codechange data of Nagios (see Fig.3 and Table III). Nagios is a
popular application for monitoring information infrastructure
systems, whose core development language is C. It has been
actively developed and maintained for over 10 years withgetting many developers and users involved in, through their
2 We set x ≥ 6 in order to avoid the overfittings. The setting of a proper
lower limit of x will be our future work.

We can observe all source-file-change events tracked ina version control system by checking the working log on
the system. Our data collection is conducted in the following
procedure.
Procedure 2 (Data Collection):
1) Make a local copy of the code repository.
For a public code repository, anyone can make a copy on
their local disk. Such a copying is referred to as “checkingout” or “cloning” of the repository, and it is a common
function among all version control systems. For instance,
we can make a local copy of any Git repository by using“git clone” command. Figure 5 shows the command we
executed to make a copy of code repository of Nagios,
where directory “nagios” is the root of our local copy.
2) Count the numbers of code change events occurred every
month from the working log on the repository.
We can obtain the change history from our local copy of
repository, with using a log-output function which is also
common among version control systems. In the case ofGit, we can get the list of source files changed in specified
month, by using “git log” command. Then, we can countthe number of the changed files with “egrep” command in
Unix/Linux operating system. Figure 6 shows an example
for counting the number of source-file-change eventsoccurred in November, 2010. In the figure, “git log”
command outputs the working logs corresponding to filechange events tracked between November 1st and November 30th, 2010, where the status of changed files are
displayed as “M.” Then, “egrep” counts the corresponding
source files which are matched to the regular expression“ˆM.*\.c\$.”2

git clone

git://git.code.sf.net/p/nagios/nagioscorenagios
Fig. 5.


Making a copy of the code repository of Nagios.


git log – –since=2010–11–01 – –until=2010–11–30– –name–status – –diff–filter=M | egrep –c "ˆM.*\.c\$"

Fig. 6.
Counting the number of source-file-change events occurred in
November, 2010.
3 http://support.nagios.com/forum/
4 http://sourceforge.net/p/nagios/mailman/

Let us consider that the six models shown in Tables I and
II are available, and try to apply our multistage growth modelto the code change events observed in Nagios development.

Nagios had 21 release versions during the data collection
period: “1.0 – 1.4, 2.0 – 2.9, 3.0 – 3.5.” A release is usually
made around or after a timing of when the development
becomes locally stable. Therefore, we can expect that a releasewould be made around a switching time of stages in ourmultistage growth model. Figure 9 shows the numbers of
releases and their gaps from the nearest stage-switching month.
For example, the gap of “−1” in Fig.9 means one month before
the stage switching, and there were 4 releases at this time.
In this case, 17 out of 21 releases were made aroundthe switching month: from −3 to +3. Especially, the time
period of three months before (−3) had the most releases (6releases). Since the switching-month represents the final month

fitted model

9
8
12
15
11
8
17
21
11
7
11
11

Gompertz
Exponential
Gompertz
Weibull
Weibull
Logistic
Gompertz
Logistic
Exponential
Gompertz
Weibull
Weibull

3.2 3.3

3.4

8000

10000

3.0
2.4
2.3 2.6
1.4
2.2
2.1 2.5
2.0

3.5

6000

1.3
1.1

1.2
2.9

4000

1.0

2.8
2.7

0

20

40

60

80

100

120

140

development period (in month)Fig. 8.

Stages, fitted models and release times.

of the local growth model, the development is likely to showa temporally stable state around such a month. Although ourmultistage growth model uses only simple data of when codechanges were made, the stage-switching points seem to reflect
the actual development status.
There were releases that have a bit larger gaps from theswitching month: +6 and −8 in Fig.9. These are corresponding
to the releases of versions 3.1 and 3.2, which were made in

13.5

6

13.0

number of releases

φ1,1(x): mean of AIC

duration (in month)

1st – 9th
10th – 17th
18th – 29th
30th – 44th
45th – 55th
56th – 63rd
64th – 80th
81st – 101st
102nd – 112nd
113th – 119th
120th – 129th
130th – 139th

2000

Let us discuss the applicability of proposed model to thesoftware evolution from the perspective of their release dates.

period (in month)

1
2
3
4
5
6
7
8
9
10
11
12

0

C. Discussion

No.

3.1
cumulative number of code change events(1) Let the first month be the starting point of the stage: s ← 1.
(2) For each of possible x’s, apply each of six growth models
yi (t) (for i = 1, . . . , 6) to actual data c(t) for 1 ≤ t ≤1+x. Figure 7 shows one of these results: values of φ1,1 (x)for Gompertz model with s = 1. In the Gompertz model,
φ1,1 (x) gives the minimum value at x = 8, so the model
fitted to the actual data c(t) in interval [1, 1 + 8] is the bestmodel.
Through our six models, the fitness of Gompertz model tothe actual data was the best5 .
(3) Then, we get a fresh start at the 10th month (starting of
the second stage): s ← s + x + 1 = 1 + 8 + 1 = 10.
(4) Similarly, the exponential growth model applied to interval
10 ≤ t ≤ 17 was the best model in the second stage; thethird stage was started from the 18th month.
(5) By iterating similar steps, the whole period was divided
into 12 stages. Table IV and Fig. 8 show their results.

4

12.5

Mininum at x=8

2

12.0
10

Fig. 7.

S TAGES OF DEVELOPMENT OF N AGIOS , ESTIMATED BYPROPOSED MULTISTAGE GROWTH MODEL .

TABLE IV.

B. Model Building and Results

20

30

40

x: fitting period (in month)50

φs (x) for Gompertz model (s = 1).

0−5

5 We used one of the most popular environment for statistical computing, R(http://www.r-project.org/). The fitting of yi (t) and computing of
AIC values can be done through the function “nls” provided in R.

Fig. 9.

0gap (in month)5

Number of releases vs. gaps from the stage-switching month.

the 8th stage (the 81st month to the 101st month). Although
they are in intermediate points of the growth model, the 8thstage grows at a slower pace, and this is completely stable, so
those releases were made regardless of the stage switching.
Our multistage growth model can flexibly represent thesoftware evolution from the perspective of code changes,
and it would be more useful in evaluating and predicting
OSS development than the conventional model using a single
growth model.
D. Limitation
Our multistage growth model assumes that OSS development has cycles between actively-developed states and temporally stable states (see Fig.4). If we face a project such thatthe development is always active and their code changes areconstantly made, our model may not work well. We would
have to consider another approach for such a project.
As mentioned in Section I, we used only simple data thatanyone can easily obtain. Although richer data from codeanalysis, mailing list analysis and bug tracking system analysis
would produce better explanation models, such rich data may
not always be available or easy to collect. The aim of thispaper is to utilize OSS development data that are available
to anyone, and to offer something useful derived from such
simple data.
V.

C ONCLUSION AND F UTURE W ORKThis paper focused on the source code change events thatare available to anyone and are easy to collect from OSS
development projects. Then it proposed a multistage growthmodel that models the software evolution by using two or
more growth models, and conducted an empirical investigation
into the applicability of the proposed model on the codechange data of a popular OSS product (Nagios). The empiricalinvestigation showed that the proposed model could reflect
the development cycle between actively-developed states andtemporally stable states, and properly explained the timings ofwhen the new versions are released.
In the future, we plan to conduct empirical work forevaluating the quality of OSS products by using our multistage
growth model. Moreover, we will analyze the gap between theactual release time periods and the stage-switching periods
in order to predict the quality of the released version. For
example, the releases of Firefox are scheduled in advance, so
the analysis of their gaps would be interesting findings. The
switching points of growth models can tell changing points ofdevelopmental stages, and such information can be a help inanalyzing the relationships between a product maturity and its
preferred time of release.
ACKNOWLEDGMENT
The authors would like to thank the anonymous reviewers
for their thoughtful comments and helpful suggestions on thefirst version of this paper. This work was partially supported
by JSPS KAKENHI Grant Number 25330083.

R EFERENCES[1] SQuBOK Project Team, “SQuBOK Guide, Guide to the Software
Quality Body of Knowledge,” http://www.juse.or.jp/software/squbokeng.html, 2007.
[2] H. A. Stieber, “A family of software reliability growth models,” in Proc.
31st Annual Int’l Computer Softw. and Applications Conf., vol. 2, 2007,
pp. 217–224.
[3] A. Wood, “Predicting software reliability,” Computer, vol. 29, no. 11,
pp. 69–77, Nov. 1996.
[4] S. Yamada, “Software quality/reliability measurement and assessment:
Software reliability growth models and data analysis,” Journal of
Information Processing, vol. 14, no. 3, pp. 254–266, Jun. 1991.
[5] A. L. Goel and K. Okumoto, “Time-dependent error-detection rate
model for software reliability and other performance measures,” IEEE
Trans. Reliability, vol. R-28, no. 3, pp. 206–211, Aug. 1979.
[6] S. Yamada, M. Ohba, and S. Osaki, “S-shaped reliability growthmodeling for software error detection,” IEEE Trans. Reliability, vol.
R-32, no. 5, pp. 475–484, Dec. 1983.
[7] N. Bowers, Actuarial Mathematics. Illinois: Society of Actuaries, 1997.
[8] R. Stone, “Sigmoids,” Bulletin in Applied Statistics, vol. 7, no. 1, pp.
59–119, 1980.
[9] H. Aman, “A proposal of nhpp-based method for predicting codechange in open source development,” in Proc. the Joint Conf. 21st Int’lWorkshop Softw. Measurement and 6th Int’l Conf. Softw. Process andProduct Measurement (IWSM-MENSURA 2011), Nov. 2011, pp. 38–47.
[10] D. Kececioglu, Reliability Engineering Handbook, Vol.2.
N.J.:
DEStech Publications, 2002.
[11] J. D. Musa, A. Iannino, and K. Okumoto, Software Reliability. New
York: McGraw-Hill, 1987.
[12] S. M. Rafi and shaheda akthar, “Software reliability growth model withgompertz tef and optimal release time determination by improving thetest efficiency,” Int’l Journal of Computer Applications, vol. 7, no. 11,
pp. 34–43, Oct. 2010.
[13] N. Ullah, M. Morisio, and A. Vetro, “A comparative analysis of software
reliability growth models using defects data of closed and open source
software,” in Proc. 35th Annual IEEE Softw. Eng. Workshop, 2012, pp.
187–192.
[14] D. Satoh, “A discrete gompertz equation and a software reliability
growth model,” IEICE Trans. Inf. & Syst., vol. E83-D, no. 7, pp. 1508–
1513, July 2000.
[15] A. Papoulis and S. U. Pillai, Probability, Random Variables andStochastic Processes. Berkshire: McGraw-Hill, 2002.
[16] C. P. Winsor, “The gompertz curve as a growth curve,” in Proc. National
Academy of Sc., vol. 18, no. 1, Jan. 1932, pp. 1–8.
[17] A. Tsoularis and J. Wallace, “Analysis of logistic growth models,”
Mathematical Biosciences, vol. 179, no. 1, pp. 21 – 55, July-Aug. 2002.
[18] S. Yamada, J. Hishitani, and S. Osaki, “Software-reliability growth witha weibull test-effort: a model and application,” IEEE Trans. Reliability,
vol. 42, no. 1, pp. 100–106, Mar. 1993.
[19] N. Ahmad, M. Bokhari, S. Quadri, and M. G. Khan, “The exponentiatedweibull software reliability growth model with various testing-efforts
and optimal release policy: a performance analysis,” Int’l Journal of
Quality and Reliability Management, vol. 25, no. 2, pp. 211–235, Feb.
2008.
[20] M. Ohba, “Inflection s-shaped software reliability growth model,” inStochastic Models in Reliability Theory, ser. Lecture Notes in Economics and Mathematical Systems, S. Osaki and Y. Hatoyama, Eds.
Berlin: Springer, Apr. 1984, vol. 235, pp. 144–162.
[21] S. H. Kan, Metrics and Models in Software Quality Engineering. N.J.:
Pearson Education, 2003.
[22] H. Akaike, “A new look at the statistical model identification,” IEEE
Trans. Automatic Control, vol. 19, no. 6, pp. 716–723, Dec. 1974.