Bayesian Decision Making of an Imperfect Debugging Software Reliability Growth Model with Consideration of Debuggers’ Learning and Negligence Factors

Abstract

In this study, an imperfect debugging software reliability growth model (SRGM) with Bayesian analysis was proposed to determine an optimal software release in order to minimize software testing costs and also enhance the practicability. Generally, it is not easy to estimate the model parameters by applying MLE (maximum likelihood estimation) or LSE (least squares estimation) with insufficient historical data. Therefore, in the situation of insufficient data, the proposed Bayesian method can adopt domain experts’ prior judgments and utilize few software testing data to forecast the reliability and the cost to proceed with the prior analysis and the posterior analysis. Moreover, the debugging efficiency involves testing staff’s learning and negligent factors, and therefore, the human factors and the nature of debugging process are taken into consideration in developing the fundamental model. Based on this, the estimation of the model’s parameters would be more intuitive and can be easily evaluated by domain experts, which is the major advantage for extending the related applications in practice. Finally, numerical examples and sensitivity analyses are performed to provide managerial insights and useful directions for software release strategies.

1. Introduction

Software reliability is an essential component of the software development process because unreliable computer systems might result in significant economic losses or unexpected disasters after a failure. Accordingly, the issue of software reliability is a considerable challenge for all technological paradigms that have a direct impact on the human life, i.e., the Internet of Things, Internet of Vehicles, smart cities, and healthcare, among several others, wherein software failure could immediately put the human lives at risk. Moreover, for software testing/debugging costs to be managed effectively, software testing staff have to understand the fluctuations between software reliability and testing costs at any given time. In software development teams, software reliability is a key determinant of the decisions they make. Traditionally, research on software reliability has assumed that perfect debugging is possible, which allows errors to be immediately removed or corrected whenever they occur. However, debugging teams may not be able to completely eliminate errors when an error is removed, and new errors may appear as a result. In recent years, the issue of imperfect debugging has elicited research interest. Furthermore, debuggers who repeatedly perform software error removal may experience learning effects that can affect the efficiency of detecting or/and removing errors. Additionally, most of the software reliability growth models (SRGMs) usually applied the non-homogeneous Poisson process (NHPP) in describing their statistical process [1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30].

Moreover, the majority of related studies were based on scenarios of perfect debugging. However, such an assumption seems to be simplified and unrealistic. Actually, the software testers and debuggers may make mistakes again when they correct defective codes. Accordingly, in recent years, the related studies have turned to focus on imperfect debugging SRGMs. Pievatolo et al. [31] utilized a Markov chain to describe the imperfect debugging process. Since the introduction of bugs is a process that cannot be observed, hidden Markov models can be created to incorporate this property. In their model, the imperfect debugging scenario is used to allow the potential introduction of new bugs during the development phase. Aktekin and Caglar [32] proposed a model that is able to predict the fluctuation of the error detection rate during testing, and the model could explain the occurrence of imperfect debugging in practice. Peng et al. [16] took the issue of testing-effort allocation into consideration for proposing an imperfect debugging SRGM. In order to investigate the influence of different testing efforts, they used three testing-effort functions (logistic, Weibull, and constant) to present the software developer with allocated testing resources during the testing period. Wang et al. [17] proposed a log-logistic function to describe a fault introduction process, and they used the log-logistic function to propose the imperfect debugging SRGM. Chatterjee and Shukla [33] designed a fault reduction factor using a Weibull function, and they took this factor to integrate with their proposed imperfect debugging SRGM. This was done since the environment of operation could be uncertain or/and varied in testing projects, and therefore debugging and test coverage might not be perfect [34]. Accordingly, they proposed an imperfect SRGM that used randomly distributed variables to describe the uncertainty of the operating environment. Inoue and Yamada [35] utilized a Markovian modeling approach to propose an SRGM under an imperfect-debugging and change-point environment. They assumed that the process of software testing can be regarded as the transitions of Markovian states, and decision-makers can use this to predict software reliability in the future. Saraf and Iqbal [36] took two types of imperfect debugging and change-point environments into consideration to propose the decision model for a better software release. Verma et al. [37] proposed a cost model for optimizing software release decisions with consideration of an imperfect debugging environment. They suggested that the length of the software warranty should be carefully decided since the trade-off is always between the increased debugging cost and the customers’ satisfaction. Li et al. [38] proposed an imperfect debugging SRGM. In their model, the issues of testability growth effort and rectifying delay were considered to analyze the performance of goodness-of-fit. The above studies had successfully taken imperfect debugging into different issues to extend applications of SRGMs with efficiency. However, most of the studies only assumed that the new software errors are simply introduced with testing time. Accordingly, in this study, the software error correction process and staff negligence are considered. We consider that the new errors introduced should be derived from staff negligence and insufficient experience, and the factor of negligence can be measured to estimate the efficiency of software debugging. It is different from the general idea of most traditional imperfect debugging SRGMs. Based on the above discussion, the study will propose an imperfect debugging SRGM with consideration of staff negligence and learning factors.

Furthermore, most of the SRGMs need sufficient historical data to proceed with the analysis of software reliability and costs because they require the data to estimate the unknown value of models’ parameters by using MLE (maximum likelihood estimation) or LSE (Least Squares Estimation) method. In other words, once the requirement of sufficient historical data is not satisfied, the software manager cannot utilize traditional statistical methods to estimate the models’ parameters. Accordingly, in such a scenario, the method of Bayesian statistical analysis could be a feasible solution because it can proceed with few data and expert evaluations. Recently, some studies have utilized Bayesian statistical analysis to develop their SRGM. Bai et al. [39] considered that Bayesian network analysis is powerful and can be applied to the estimation of software reliability. The study indicated that the Bayesian analysis presented a better ability to adapt to problems that involve complex variant factors. Melo and Sanchez [40] also used the Bayesian network to deal with the issue of software maintenance projects, and their prediction was majorly based on specialists’ experience. Pievatolo et al. [31] proposed a Bayesian hidden Markov model for the imperfect debugging process. They assumed a Gamma distribution as the prior distribution to estimate the model’s parameters. Aktekin and Caglar [32] utilized Markov chain Monte Carlo and Bayesian approaches to estimate and analyze the error detection rate. Lian et al. [41] proposed the method of an objective Bayesian inference to estimate the parameters of the Jelinski Moranda model. Zhao et al. [42] proposed a Bayesian SRGM for the issue of perfect and imperfect debugging to deal with the uncertainty of software reliability. Wang et al. [43] applied an entropy Markov method for the prediction of real-time reliability in a software system. In their model, the conditional probabilities were estimated by the proposed Bayesian method. Insua et al. [44] proposed the designs of optimal Bayesian life test and accelerated life test for software reliability. In their study, a software warranty was taken into consideration to propose a cost model for pursuing optimal software release decisions. Zarzour and Rekab [45] proposed a sequential procedure to proceed with the allocation of software testing cases to minimize the related costs. Accordingly, the Bayesian method can allow a manager to take advantage of the previous information to obtain a better estimation of software reliability. However, the above studies did not integrate the related testing costs into a software release decision with consideration of the opportunity cost and the minimum reliability requirement. Based on this, the study will extend the Bayesian method to the software release decision with practical considerations.

Based on the above discussion, our study provides the following contributions compared with the existing literature: (i) the above models’ parameters are less meaningful and intuitive so that such parameters may not be easily evaluated by domain experts. However, our proposed model can improve this by using human staff factors (debuggers’ learning, negligence, and autonomous ability). (ii) Our model can explain the reason for imperfect debugging, and it can be transformed into a coefficient to estimate easily. (iii) The study proposed the software release model with consideration of the requirement of software reliability in the prior and posterior analyses. Such a model can devise various testing alternatives with adequate manpower to evaluate the testing costs in a more reliable way. The rest of this paper is organized as follows: Section 2 presents the development of the proposed model, the parameters estimation, and the model’s verification and comparison. Section 3 provides Bayesian analysis for the proposed model and the decision model for the optimal software release. Section 4 presents the application and numerical analysis. Finally, Section 5 gives the conclusion and future works.

2. Imperfect Debugging Software Reliability Growth Model with Consideration of Debuggers’ Learning and Negligence Factors

2.1. Basic Model Development

In recent decades, statistical and stochastic methods have been applied in reliability engineering for both hardware and software. The NHPP (non-homogenous Poisson process) is one of the effective methods, and therefore, numerous software reliability growth models have been developed based on this. The NHPP is the derivative of the HPP (homogeneous Poisson process); however, the major difference between the two stochastic processes is that the expected number of failures can be allowed to vary with time. For the purposes of ensuring quality when the system is released to the market, it is important to test and debug the software system in advance. The software department or company can design and prepare several feasible alternatives, and the decision maker’s role is to choose the best one to proceed with software testing work. Accordingly, it is important for managers to understand and be capable of managing the efficiency of improving system reliability under different resource allocations to maintain a balance between system stability and related costs.

According to the assumption of NHPP, the process of software reliability growth can be described by mathematical functions as a counting process, $\left\{N\left(t\right), t\ge 0\right\}$. Therefore, the probability of $N\left(t\right)$ can be given as:

$$\mathrm{Pr}\left(N\left(t\right)=k\right)=\frac{{\left[M\left(t\right)\right]}^k{e}^{-M\left(t\right)}}{k!}, k=0,1,2,\dots$$

(1)

Here, $M\left(t\right)$ denotes the mean value function of the cumulative number of the detected errors within the time range $\left[0,t\right]$ in a system or software, and it can be related to the intensity function $\lambda (·),$ which can be described as follows:

$$M\left(t\right)={{\displaystyle \int }}_0^t\lambda \left(x\right)dx$$

(2)

Pham and Zhang (2003) suggested an indicator for measuring the reliability of a system, and software developers can use this to handle the system’s condition and quality during the software development process. The indicator of software reliability was defined as

$$R(x | t)=e^{-\left[M\left(t+x\right)-M\left(t\right)\right]}$$

(3)

The indicator represents the probability that no error is detected within the time range $\left[t,t+x\right]$, and $x$ is the operating time for the requirements of stability in practice. Please note that increasing the operating time will decrease the indicator of reliability. Furthermore, the software reliability will approach 1 (perfect system) when the testing time is close to the infinity ($\underset{t\to \infty }{\lim }R(x | t)\to 1$). However, it is unrealistic to pursue a perfect system because the testing time and cost are limited in practice.

The notations in

Table 1. The notations.

$\alpha$: the autonomous errors-detected factor

$\beta$: the learning factor

$\gamma$: the negligent factor

$f\left(\alpha ,\beta ,\gamma \right)$: the joint prior distribution for $\alpha$,$\beta$,$\gamma$

$L\left(D^{\left(n\right)}|\alpha ,\beta ,\gamma \right)$: the likelihood function regarding NHPP with the collected dataset

$D^{\left(n\right)}=\left\{t_1,t_2,..,t_n\right\}$

$g\left(\alpha ,\beta ,\gamma ,D^{\left(n\right)}\right)$: the posterior distribution for $\alpha$,$\beta$,$\gamma$

$a$: the initial number of all potential errors in the software system

$A\left(t\right)$: the function of the total errors at time $t$ in the software system

$M\left(t\right)$: the mean value function, which represents the accumulated number of software errors detected during the time interval (0,$t$)

$\lambda \left(t\right)$: the intensity function that denotes the number of the errors detected at time $t$

$D\left(t\right)$: the function of the error detection rate

will be used throughout the study.

The framework of the study can be divided the three parts: (1) model inference, (2) Bayesian analysis, and (3) cost analysis. Please refer to Figure 1, which illustrates the framework of the study. The model inference will be introduced in the subsequent paragraphs of this subsection. Bayesian analysis is developed in Section 3.1, and the model of the cost analysis will be presented in Section 3.2. Firstly, the model inference presents the basic idea and mathematical inference of the study. In the proposed model, we assume that the three main factors influence the velocity of errors detected, which include testing staffs’ autonomous errors-detected factor $\alpha$, learning factor $\beta$ and negligent factor $\gamma$. The interaction and logical concept among the three factors can be seen in the model inference in Figure 1. It can be seen that the factor $\alpha$ directly affects the number of errors detected, but the factor $\beta$ can also affect the number of errors detected by learning from the pattern of the cumulative errors $M\left(t\right)$. The factors $\alpha$ and $\beta$ can bring a positive influence on the efficiency of errors detected, but the negligent factor $\gamma$ can bring a negative influence on the efficiency, and it will lead to the new errors increased. Nonetheless, the estimation of these factors may be difficult under the lack of historical data because the statistical influence for model parameters needs enough historical data to proceed. Accordingly, a Bayesian analysis will be helpful in the situation of scarce data. It is the second part of the study framework. A software developer can take the domain experts’ opinion to process with a prior analysis. If a software developer wants to get a more convincing result, he/she can collect the present data to proceed with a posterior analysis to amend the prior analysis. The cost analysis is crucial for making software testing alternatives, and therefore any software developer has to take all the related costs into consideration to ensure that the reliability growth is under the project’s budget. That is the third part of the study framework.

With regard to the mathematical inference of the main model, it is supposed that the number of the total software errors can be set as a function of testing time ($A\left(t\right)$). It includes the initial error number $a$ and the increment of new errors due to negligent factor $\gamma$. Therefore, the number of the total software errors will be increased by testing time $t$, and it can be described as the following equation:

$$A\left(t\right)=a+\gamma M\left(t\right)$$

(4)

Moreover, the detection rate can be used to measure the velocity of errors detected in practice, and it can be defined as the following differential equation:

$$D\left(t\right)=\frac{dM\left(t\right)}{A\left(t\right)-M\left(t\right)}=\alpha +\beta F\left(t\right)$$

(5)

where $F\left(t\right)$ denotes the cumulative fraction of the errors detected within the time range $\left[0, t\right]$, and $A\left(t\right)-M\left(t\right)$ is the remaining and undetected errors at time $t$. Please note that the factors $\alpha$ and $\beta$ in Equation (5) must be greater than or equal to zero to ensure that the effect is positive in the testing process. This implies that the learning effect exists in the testing process, and it is also affected by the value of $F\left(t\right)$. Due to the cumulative fraction of the original detected pattern $F\left(t\right)=\frac{M\left(t\right)}{a}$ and the function of the total errors number $A\left(t\right)=a+\gamma M\left(t\right)$, Equation (5) can be rewritten as $D\left(t\right)=\frac{dM\left(t\right)}{a-\left(1-\gamma \right)M\left(t\right)}=\alpha +\left(\frac{\beta }{a}\right)M\left(t\right)$. Therefore, the mean value function $M\left(t\right)$ can be inferenced by differential equation methods as the following process:

$$dM\left(t\right)=\left(a-\left(1-\gamma \right)M\left(t\right)\right)\left(\alpha +\left(\frac{\beta }{a}\right)M\left(t\right)\right)$$

(6)

$$\Rightarrow \frac{dM\left(t\right)}{\left(\alpha +\left(\frac{\beta }{a}\right)M\left(t\right)\right)\left(a-\left(1-\gamma \right)M\left(t\right)\right)}=1.$$

(7)

We take the integral of both sides of the equation. The result can be obtained as follows:

$${\displaystyle \int }\frac{dM\left(t\right)}{\left(a-\left(1-\gamma \right)M\left(t\right)\right)\left(\alpha +\left(\frac{\beta }{a}\right)M\left(t\right)\right)}dt={\displaystyle \int }1dt$$

(8)

$$\Rightarrow \frac{\ln \left(a+\left(\gamma -1\right)M\left(t\right)\right)-\ln \left(a\alpha +\beta M\left(t\right)\right)}{\alpha \left(\gamma -1\right)-\beta }=t+constant..$$

(9)

In order to get the math form of $M\left(t\right)$, we need to solve Equation (9) for $M\left(t\right)$ firstly, and the form of $M\left(t\right)$ with the unknown constant can be obtained as follows:

$$M\left(t\right)=\frac{a\alpha e^{\alpha \gamma \left(t+constant\right)}-a{e}^{\left(\alpha +\beta \right)\left(t+constant\right)}}{\left(\gamma -1\right)e^{\left(\alpha +\beta \right)\left(t+constant\right)}-\beta e^{\alpha \gamma \left(t+constant\right)}}.$$

(10)

Due to the fact that the initial condition $M\left(0\right)=0$ is given (no error detected at testing time $t=0$), Equation (10) can be solved by giving the initial condition to eliminate the unknown constant. Therefore, Equation (10) can be rewritten as follows:

$$M\left(0\right)=\frac{a{e}^{\left(\alpha +\beta \right)constant}-a\alpha e^{\left(\alpha \gamma \right)constant}}{\left(1-\gamma \right)e^{\left(\alpha +\beta \right)constant}+\beta e^{\left(\alpha \gamma \right)constant}}=0.$$

(11)

When solving Equation (10) for the unknown constant, it can be obtained as follows:

$$constant=\frac{\ln \left(\alpha \right)}{\beta +\left(1-\gamma \right)\alpha }.$$

(12)

Substituting the constant into Equation (10), the complete form of $M\left(t\right)$ can be obtained as follows:

$$M\left(t\right)=\frac{a{e}^{\left(\alpha +\beta \right)\left(t+\ln \alpha )/\left(\left(1-\gamma \right)\alpha +\beta \right)\right)}-a\alpha e^{\alpha \gamma \left(t+\ln \left(\alpha \right)/\left(\left(1-\gamma \right)\alpha +\beta \right)\right)}}{\beta e^{\alpha \gamma \left(t+\ln \left(\alpha \right)/\left(\left(1-\gamma \right)\alpha +\beta \right)\right)}+\left(1-\gamma \right)e^{\left(\alpha +\beta \right)\left(t+\ln \left(\alpha \right)/\left(\left(1-\gamma \right)\alpha +\beta \right)\right)}}.$$

(13)

This is the original form of the mean value function, and it can be used to estimate the number of cumulative errors detected in average cases. Due to $e^{\ln \left(\alpha \right)}=\alpha$, the math form of $M\left(t\right)$ can be furtherly simplified as follows:

$$M\left(t\right)=\frac{a{\alpha }^{\frac{\alpha +\beta }{\left(1-\gamma \right)\alpha +\beta }}\left(e^{\alpha \gamma t}-e^{\left(\alpha +\beta \right)t}\right)}{\beta {\alpha }^{\frac{\alpha \gamma }{\left(1-\gamma \right)\alpha +\beta }}{e}^{\alpha \gamma t}+\left(1-\gamma \right){\alpha }^{\frac{\alpha +\beta }{\left(1-\gamma \right)\alpha +\beta }}{e}^{\left(\alpha +\beta \right)t}}.$$

(14)

Software managers may want to know the number of the errors detected at time $t$ for handling the situation during the software testing phase. Accordingly, the intensity function of the mean value $\lambda \left(t\right)$ needs to be obtained for software managers. Taking the first derivative of $M\left(t\right)$, the math form of $\lambda \left(t\right)$ can be obtained as follows:

$$\lambda \left(t\right)=\frac{dM\left(t\right)}{dt}=\frac{a{\alpha }^{\frac{\alpha +\beta }{\left(1-\gamma \right)\alpha +\beta }}\left(\left(1-\gamma \right)\alpha +\beta \right)\left(\left(1-\gamma \right){\alpha }^{\frac{\alpha +\beta }{\left(1-\gamma \right)\alpha +\beta }}+\beta {\alpha }^{\frac{\alpha \gamma }{\left(1-\gamma \right)\alpha +\beta }}\right)e^{\left(\left(1+\alpha \right)\gamma +\beta \right)t}}{{\left(\left(1-\gamma \right){\alpha }^{\frac{\alpha +\beta }{\left(1-\gamma \right)\alpha +\beta }}{e}^{\left(\alpha +\beta \right)t}+\beta {\alpha }^{\frac{\alpha \gamma }{\left(1-\gamma \right)\alpha +\beta }}{e}^{\alpha \gamma t}\right)}^2}$$

(15)

The intensity function of the mean value $\lambda \left(t\right)$ can represent the number of errors detected at time $t$, and the software managers can use this formation to measure what time the peak is for errors detected. Moreover, software managers want to investigate the debugging efficiency during a testing period, and therefore, they need an indicator for measuring debugging efficiency in practice. Yamada et al. (1984) had given the definition of the detection rate as $D\left(t\right)=\frac{dM\left(t\right)}{a-M\left(t\right)}$. However, in this study, the remaining errors in the system at testing time $t$ have been changed as $A\left(t\right)-M\left(t\right)$, and therefore the error detection rate can be defined as follows:

$$D\left(t\right)=\frac{dM\left(t\right)}{A\left(t\right)-M\left(t\right)}=\frac{\left(\left(1-\gamma \right)\alpha +\beta \right){\alpha }^{\frac{\alpha +\beta }{\left(1-\gamma \right)\alpha +\beta }}}{\left(1-\gamma \right){\alpha }^{\frac{\alpha +\beta }{\left(1-\gamma \right)\alpha +\beta }}+\beta {\alpha }^{\frac{\alpha \gamma }{\left(1-\gamma \right)\alpha +\beta }}{e}^{\left(\alpha \gamma -\left(\alpha +\beta \right)\right)t}}$$

(16)

Please note that the error detection rate is a strictly increasing function, and it implies that the debugging efficiency will improve with testing time.

2.2. Parameter Estimation and Models Validation

Generally, the least-square estimation method (LSE) has been widely used to estimate the parameters of the mean value function. It is a standard approach in statistics for estimating a model’s parameters by minimizing the sum of the squares of the errors, and the present study utilizes it to demonstrate the fitting performance among the proposed model and other existing models. Here, $\left(t_0,M_0\right),\left(t_1,M_1\right),\left(t_2,M_2\right),\dots ,\left(t_n,M_n\right)$ denote a set of $n$ pairs of observed data, and $M_i$ denotes the total number of detected errors. Therefore, the sum of the squares of the errors for a testing dataset can be given as

$$Er\left(\alpha ,\beta ,\gamma \right)={{\displaystyle \sum }}_{i=1}^n{\left(M_i-M\left(t_i\right)\right)}^2.$$

(17)

Taking the first-order derivative of Equation (17) for each parameter and letting them be equal to zero, the estimated values of the parameters $\alpha$, $\beta$ and $\gamma$ can be obtained by solving the following simultaneous equations:

$$\frac{\partial Er\left(\alpha ,\beta ,\gamma \right)}{\partial \alpha }=\frac{\partial Er\left(\alpha ,\beta ,\gamma \right)}{\partial \beta }=\frac{\partial Er\left(\alpha ,\beta ,\gamma \right)}{\partial \gamma }=0.$$

(18)

To investigate the goodness of fit of the proposed SRGM, the source of the open datasets is used in this analysis. Moreover, the proposed SRGM is also compared with the other imperfect debugging SRGMs for measuring the models’ fitting performance.

Table 2. The source of the open datasets.

Dataset	Reference	Source
(1)	Zhang & Pham (2006) [46]	Failure data of telecommunication system
(2)	Wang et al. (2016) [47]	Medium-scale software project
(3)	Peng et al. (2014) [16]	Testing data for the Room Air Development Center
(4)	Singpurwalla & Willson (1999) [48]	Failure data of NTDS system

gives the source of the four open datasets for the models’ validation, and

Table 3. Mean value functions and error detection rate functions for the imperfect debugging SRGMs.

Imperfect Debugging SRGMs	$\mathrm{Functions} \mathrm{of} \mathrm{Mean} \mathrm{Value} {M}\left({t}\right)$$\mathrm{and} \mathrm{Detection} \mathrm{Rate} {D}\left({t}\right)$
Pham et al. (1999) [3]	$M\left(t\right)=\frac{a\left(1-e^{-bt}\right)\left(1+\alpha t+\frac{\alpha t}{b}\right)}{1+e^{-bt}\beta }$$\mathrm{and} D\left(t\right)=\frac{b}{1+\beta e^{-bt}}$.
Kapur et al. (2008) [9]	$M\left(t\right)=\frac{a\left(1-e^{-bp\left(1-\alpha \right)t}\right)}{1-\alpha }$$\mathrm{and} D\left(t\right)=\frac{\left(1-\alpha \right)bp}{1-\alpha e^{-bpt\left(-1+\alpha \right)}}$.
Wang et al. (2015) [17]	$M\left(t\right)=\frac{a{\left(\alpha t\right)}^d}{1+{\left(\alpha t\right)}^d}+C\left(1-e^{-bt}\right)-ad{\left(\alpha t\right)}^d{e}^{-bt}\left(\frac{1}{d}+\frac{bt}{1+d}+\frac{b^2{t}^2}{2\left(2+d\right)}\right)$  $\mathrm{and} D\left(t\right)=b$.
Proposed model	$M\left(t\right)=\frac{a{\alpha }^{\frac{\alpha +\beta }{\left(1-\gamma \right)\alpha +\beta }}\left(e^{\alpha \gamma t}-e^{\left(\alpha +\beta \right)t}\right)}{\beta {\alpha }^{\frac{\alpha \gamma }{\left(1-\gamma \right)\alpha +\beta }}{e}^{\alpha \gamma t}+\left(1-\gamma \right){\alpha }^{\frac{\alpha +\beta }{\left(1-\gamma \right)\alpha +\beta }}{e}^{\left(\alpha +\beta \right)t}}$  $\mathrm{and} D\left(t\right)=\frac{\left(\left(1-\gamma \right)\alpha +\beta \right){\alpha }^{\frac{\alpha +\beta }{\left(1-\gamma \right)\alpha +\beta }}}{\left(1-\gamma \right){\alpha }^{\frac{\alpha +\beta }{\left(1-\gamma \right)\alpha +\beta }}+\beta {\alpha }^{\frac{\alpha \gamma }{\left(1-\gamma \right)\alpha +\beta }}{e}^{\left(\alpha \gamma -\left(\alpha +\beta \right)\right)t}}$.

presents the mean value functions and the error detection rate functions for these imperfect debugging SRGMs.

In this study, mean square error (MSE) and R-squared (R-sq) are the two criteria for measuring the four models’ fitting performance. Figure 2, Figure 3, Figure 4 and Figure 5 present the fitting results and the estimations of the corresponding parameters for the four models with the open datasets. The estimated parameters’ value and asymptotic standard deviation are also presented in the figures. Furthermore, the dashed lines around the curve of $M\left(t\right)$ are the 95% confidence intervals. As can be seen in Figure 5, the proposed model can well handle the trend in such nonlinear regression analyses. In most cases, our proposed model presented superior fitting results to other models, and the R-sq values are 99.31%, 97.22%, 99.83% and 99.20% in cases 1–4, respectively. Pham’s model also shows a good validity of fitness in average cases, according to Figure 2, since Pham’s model can adapt to S-shaped or concave datasets. However, Kapur’s model may be weak for adapting to S-shaped datasets, according to Figure 3, and it seems that Kapur’s model can only adapt to exponential or concave type datasets. Nonetheless, the Kapur model is still good to adapt in the datasets (2) and (3). With regard to Wang’s model, as can be seen in Figure 4, it outperformed the fitting ability in datasets (1) and (2), and the R-squared value reached 99.43% and 98.81%. Wang’s model has five parameters, but the other models only use four parameters, and therefore, Wang’s model can present more flexibility and adaptability than the other models. However, it is important to note that the number of model parameters can influence the ability to fit. Generally, adding more model parameters can increase a model’s flexibility and adaptability. Accordingly, the proposed model may not be inferior to Wang’s model on fitting ability because the proposed model used a reduced number of parameters for curve fitting. According to the above discussion, our model presents the best validity of fitness in average cases. Furthermore, as our proposed model’s parameters are easy to comprehend and evaluate, the managers can use them to adjust or modify the values to increase the accuracy of the testing scenario that may change in the future.

3. Bayesian Analysis for SRGM and Optimal Decision of Software Release

3.1. Bayesian Analysis under Insufficient Historical Data

If there are no sufficient historical data that can be used to estimate the value of the unknown parameters $\alpha$, $\beta$ and $\gamma$ when performing debugging on a new project, a manager needs to seek another way to estimate these parameters’ value so that the test efficiency and cost of a new project can be evaluated in advance for his/her software release plan. Furthermore, a manager may also devise a variety of testing alternatives based on different human resources and allocation, and such testing alternatives cannot refer to the similar historical datasets to estimate the unknown parameters’ value. Accordingly, the method of LSE cannot be applied to these scenarios. Fortunately, a Bayesian statistical method would be helpful to deal with such scenarios because this method allows domain experts to provide their judgment on the parameters’ values and then utilize collected data to amend the previous judgment. Based on this, Bayesian analysis can be divided into two parts: (1) prior analysis and (2) posterior analysis. A decision maker can proceed with a prior analysis in advance; however, if he/she wants to get a more precise estimation, he/she can proceed with a posterior analysis with collected data.

In order to proceed with the prior analysis, a suitable joint prior distribution needs to be assured to model the uncertain states of the parameters $\alpha$, $\beta$ and $\gamma$ in nature. Suppose that the parameters $\alpha$, $\beta$ follow a bivariate gamma distribution $f\left(\alpha ,\beta \right)$ and the parameter $\gamma$ follows a uniform distribution $f\left(\gamma \right)$. The bivariate gamma distribution was proposed by Schucany et al. [49], and we applied it to the joint prior distribution for $\alpha$, $\beta$ and $\gamma$ as follows:

$$f\left(\alpha ,\beta ,\gamma \right)=\frac{\left({\alpha }^{{\theta }_{\alpha }-1}{e}^{-\frac{\alpha }{{\xi }_{\alpha }}}\right)\left({\beta }^{{\theta }_{\beta }-1}{e}^{-\frac{\beta }{{\xi }_{\beta }}}\right)\left(3{\rho }_{\alpha ,\beta }\left(\frac{2\Gamma \left[{\theta }_{\alpha },0,\frac{\alpha }{{\xi }_{\alpha }}\right]}{\Gamma \left[{\theta }_{\alpha }\right]}-1\right)\left(\frac{2\Gamma \left[{\theta }_{\beta },0,\frac{\beta }{{\xi }_{\beta }}\right]}{\Gamma \left[{\theta }_{\beta }\right]}-1\right)+1\right)}{\left({\gamma }_{UB}-{\gamma }_{LB}\right)\left({\xi }_{\alpha }{}^{{\theta }_{\alpha }}\Gamma \left[{\theta }_{\alpha }\right]\right)\left({\xi }_{\beta }{}^{{\theta }_{\beta }}\Gamma \left[{\theta }_{\beta }\right]\right)}$$

(19)

Since $f\left(\alpha ,\beta \right)$ is independent to $f\left(\gamma \right)$, the joint prior distribution $f\left(\alpha ,\beta ,\gamma \right)$ will be the product of $f\left(\alpha ,\beta \right)$ and $f\left(\gamma \right)$. ${\rho }_{\alpha ,\beta }$ denotes the correlation coefficient of $\alpha$ and $\beta$. Due to the fact that the good debugging skill ($\alpha$) would usually have good learning ability ($\beta$), the correlation coefficient ${\rho }_{\alpha ,\beta }$ is positive in most cases. Figure 6 illustrates the joint probability distribution $f\left(\alpha ,\beta \right)$ under different correlation coefficients ${\rho }_{\alpha ,\beta }$. In this figure, we can see the impact of different correlation coefficients of the two parameters on the shape of the joint distribution.

However, if the parameters $\alpha$ and $\beta$ are independent of each other, the joint prior distribution for $\alpha$, $\beta$ and $\gamma$ will be degraded as follows:

$$f\left(\alpha ,\beta ,\gamma \right)=\frac{\left({\alpha }^{{\theta }_{\alpha }-1}{e}^{-\frac{\alpha }{{\xi }_{\alpha }}}\right)\left({\beta }^{{\theta }_{\beta }-1}{e}^{-\frac{\beta }{{\xi }_{\beta }}}\right)}{\left({\gamma }_{UB}-{\gamma }_{LB}\right)\left({\xi }_{\alpha }{}^{{\theta }_{\alpha }}\Gamma \left[{\theta }_{\alpha }\right]\right)\left({\xi }_{\beta }{}^{{\theta }_{\beta }}\Gamma \left[{\theta }_{\beta }\right]\right)}$$

(20)

The joint prior distribution can satisfy the characteristics of a general probability distribution like ${{\displaystyle \int }}_0^{\infty }{{\displaystyle \int }}_0^{\infty }{{\displaystyle \int }}_{{\gamma }_{LB}}^{{\gamma }_{UB}}f\left(\alpha ,\beta ,\gamma \right)d\gamma d\beta d\alpha =1$. Moreover, please note that the forms of gamma and incomplete gamma functions are $\Gamma \left[z\right]={{\displaystyle \int }}_0^{\infty }{x}^{z-1}{e}^{-x}dx$ and $\Gamma \left[z_0,z_1,z_2\right]={{\displaystyle \int }}_{z_1}^{z_2}{x}^{z_0-1}{e}^{-x}dx$, respectively. The scale parameters of $\alpha$ and $\beta$ are denoted as ${\theta }_{\alpha }$ and ${\theta }_{\beta }$, and the shape parameters are denoted as ${\xi }_{\alpha }$ and ${\xi }_{\beta }$. Although these scale and shape parameters cannot be directly evaluated in practice, the expert can use the statistical characteristics ($\alpha$ and $\beta$’s mean and standard deviation) to estimate them. Therefore, the scale and shape parameters can be obtained by the equations ${\theta }_{\alpha }=\frac{E{\left[\alpha \right]}^2}{\sigma {\left[\alpha \right]}^2}$, ${\xi }_{\alpha }=\frac{\sigma {\left[\alpha \right]}^2}{E\left[\alpha \right]}$, ${\theta }_{\beta }=\frac{E{\left[\beta \right]}^2}{\sigma {\left[\beta \right]}^2}$ and ${\xi }_{\beta }=\frac{\sigma {\left[\beta \right]}^2}{E\left[\beta \right]}$ according to the experts’ judgment for $E\left[\alpha \right]$, $\sigma \left[\alpha \right]$, $E\left[\beta \right]$ and $\sigma \left[\beta \right]$. Furthermore, the estimation of $\gamma$ is more intuitive to the expert; he/she can directly evaluate the upper and lower limits of $\gamma$ (${\gamma }_{UB}$ and ${\gamma }_{LB}$) for the prior analysis.

The mean value of the total errors detected $M\left(T\right)$ and the expected conditional software reliability $R(x|T)$ in the prior analysis can be calculated by the following equations:

$$E\left[M\left(T\right)\right]={{\displaystyle \int }}_0^{\infty }{{\displaystyle \int }}_0^{\infty }{{\displaystyle \int }}_{{\gamma }_{LB}}^{{\gamma }_{UB}}M\left(T\right)f\left(\alpha ,\beta ,\gamma \right)d\gamma d\beta d\alpha$$

(21)

and

$$E\left[R\left(x\right|T)\right]={{\displaystyle \int }}_0^{\infty }{{\displaystyle \int }}_0^{\infty }{{\displaystyle \int }}_{{\gamma }_{LB}}^{{\gamma }_{UB}}R\left(x\right|T)f\left(\alpha ,\beta ,\gamma \right)d\gamma d\beta d\alpha .$$

(22)

Managers might be unconvinced of the results of the prior analysis; therefore, they will collect extra testing data for amending the prior analysis. In order to calculate the mean value and the software reliability in the posterior analysis, we need to deduce the posterior distribution in advance. According to the property of natural conjugate distribution, the posterior distribution is in the same probability distribution family as the prior probability distribution. Therefore, the posterior distribution can be inferred as follows:

$$\begin{gathered} g\left(\alpha ,\beta ,\gamma ,D^{\left(n\right)}\right)\propto f\left(\alpha ,\beta ,\gamma \right)L\left(D^{\left(n\right)}|\alpha ,\beta ,\gamma \right) \\ =Kf\left(\alpha ,\beta ,\gamma \right)L\left(D^{\left(n\right)}|\alpha ,\beta ,\gamma \right). \end{gathered}$$

(23)

$L\left(D^{\left(n\right)}|\alpha ,\beta ,\gamma \right)$ denotes the likelihood function regarding NHPP with the collected dataset $D^{\left(n\right)}=\left\{t_1,t_2,..,t_n\right\}$, and it can be calculated as

$$L\left(D^{\left(n\right)}|\alpha ,\beta ,\gamma \right)={\displaystyle \prod }_{i=1}^n\lambda \left(t_i\right)e^{-M\left(t_n\right)}.$$

(24)

Moreover, in order to ensure that the posterior distribution is summed up to 1, $K$ can be a normalizing factor, and it needs to be evaluated in advance, which is as follows:

$$K=\frac{1}{{{\displaystyle \int }}_0^{\infty }{{\displaystyle \int }}_0^{\infty }{{\displaystyle \int }}_{{\gamma }_{LB}}^{{\gamma }_{UB}}f\left(\alpha ,\beta ,\gamma \right)L\left(D^{\left(n\right)}|\alpha ,\beta ,\gamma \right)d\gamma d\beta d\alpha }.$$

(25)

Accordingly, the mean value $M\left(T\right)$ and the software reliability $R(x|T)$ in the posterior analysis can be calculated by

$$E’\left[M\left(T\right)\right]={{\displaystyle \int }}_0^{\infty }{{\displaystyle \int }}_0^{\infty }{{\displaystyle \int }}_{{\gamma }_{LB}}^{{\gamma }_{UB}}M\left(T\right)g\left(\alpha ,\beta ,\gamma ,D^{\left(n\right)}\right)d\gamma d\beta d\alpha$$

(26)

and

$$E’\left[R\left(x\right|T)\right]={{\displaystyle \int }}_0^{\infty }{{\displaystyle \int }}_0^{\infty }{{\displaystyle \int }}_{{\gamma }_{LB}}^{{\gamma }_{UB}}R\left(x\right|T)g\left(\alpha ,\beta ,\gamma ,D^{\left(n\right)}\right)d\gamma d\beta d\alpha ,$$

(27)

respectively. Please note that it will take time to calculate the values $E’\left[M\left(T\right)\right]$ and $E’\left[R(x|T)\right]$ due to the multidimensional numerical integration. Accordingly, it will be needed to utilize a computation engine to assist the manager in obtaining the results.

In order to incorporate the cost functions to perform the prior analysis and obtain the corresponding testing cost, software reliability and optimal release time, the software engineers will devise multiple alternatives for the project manager to evaluate the best one according to his/her managerial requirement. Therefore, the parameters of the related costs and model parameters need to be investigated and evaluated in advance, and then the project manager can choose the best alternative with minimal cost to carry out the prior analysis. Moreover, the managers might be less confident about the results of the prior analysis, and therefore, they may collect an extra dataset from the current testing alternative to amend their prior judgement. Accordingly, the posterior analysis will be carried out, and the managers can adjust the current alternative to change the software release in the market. Figure 7 illustrates the decision process of the Bayesian analysis in detail.

3.2. Cost Models for Optimal Decision of Software Release

Generally, the manager of software development would be interested in knowing the best time to stop the testing work so that the related costs can be minimized under a specific managerial requirement of software quality. It is generally believed that the longer a software is tested, the more reliable it becomes. Nevertheless, a longer testing period will result in higher costs and missed opportunities for commercialization. To accomplish this, the manager of software development should carefully make his/her software release decision.

In this study, the source of the total expected cost consists of the following: the setup cost, the routine cost, the errors corrected cost, the risk cost, and the opportunity cost. In order to proceed with the prior and posterior analyses, the two programming models are proposed as follows:

$$\begin{gathered} Min E\left[TC\left(T\right)\right]=S{C}_p+G{C}_{p}T+E{C}_{p}E\left[t_r\right]E\left[M\left(T\right)\right] \\ +RC{\left(E\left[A\left(T\right)-M\left(T\right)\right]\right)}^{{\kappa }_1}+OC\left(T\right) \\ Subject to: E\left[R\left(x|T\right)\right]\le R_{mr} \end{gathered}$$

(28)

and

$$\begin{gathered} Min E’\left[TC\left(T\right)\right]=S{C}_p+G{C}_{p}T+E{C}_{p}E\left[t_r\right]E’\left[M\left(T\right)\right] \\ +RC{\left(E’\left[A\left(T\right)-M\left(T\right)\right]\right)}^{{\kappa }_1}+OC\left(T\right) \\ Subject to: E’\left[R\left(x|T\right)\right]\le R_{mr}. \end{gathered}$$

(29)

$S{C}_p$ denotes the setup cost, and it includes the initial cost for the alternative $p$ and the related preparation works. $G{C}_{p}T$ is the routine cost during the testing period $\left[0,T\right]$. The calculation of the errors corrected cost is the multiplication of the cost per unit time for correction $E{C}_p$, the expected time for correcting an error $E\left[t_r\right]$, and the expected number of errors detected $E\left[M\left(T\right)\right]$. Note that $E\left[t_r\right]$ can be calculated by the record of debugging with consideration of a probability distribution. $RC{\left(E\left[A\left(T\right)-M\left(T\right)\right]\right)}^{{\kappa }_1}$ is the risk cost, and it is related to the number of remaining errors with the risk aversion factor ${\kappa }_1$. $OC\left(T\right)$ is the opportunity cost, which can be defined as $OC\left(T\right)={\omega }_0{\left({\omega }_1+T\right)}^{{\omega }_2}$. ${\omega }_0$, ${\omega }_1$ and ${\omega }_2$ denote the scale coefficient, the intercept value and the increasing degree of opportunity loss over time, respectively. The manager also needs to consider the constraint on the minimum software reliability $R_{mr}$ for satisfying his/her managerial or client’s requirement. Based on the above, the manager can utilize the two programming models to evaluate what the best timing is for software release in the prior and posterior analyses.

4. Application and Numerical Analysis

Suppose that a software company developed an industrial engineering software. After finishing the coding phase, the manager is going to make a software testing plan and decide the best timing to release the software product. However, since numerous potential errors exist and hide in the codes, the manager has to arrange testing resources and staff to proceed with the debugging work. In this scenario, the number of software errors can be estimated using an error seeding method. Furthermore, in order to avoid or reduce the compliance from users, the minimal requirement of software reliability is set to 0.8, and the manager must ensure the software quality is above the level before releasing it to the market. The software engineers devised three testing alternatives for the manager. The manager will evaluate each alternative’s cost and reliability to choose the best one to proceed with. However, due to the lack of historical data for evaluating the parameters, the manager asks the domain experts to evaluate the parameters by giving the values of $E\left[\alpha \right]$, $\sigma \left[\alpha \right]$, $E\left[\beta \right]$, $\sigma \left[\beta \right]$, ${\gamma }_{UB}$, and ${\gamma }_{LB}$ for each alternative. After the investigation and evaluation from the software engineers and domain experts, the detailed information of the three candidate alternatives can be seen in

Table 4. Related debugging costs and parameter estimation of the three alternatives.

Alternative 1	Alternative 2	Alternative 3
Low-Intensity Testing Resource	Medium-Intensity Testing Resource	High-Intensity Testing Resource
$\widehat{a}=1840$$, R_{mr}=0.8$$, E\left[t_r\right]=2.4$$, RC$$=\$280, {\kappa }_1=1.1$$, {\mathsf{\omega }}_0$$=1800, {\mathsf{\omega }}_1=1.5$$, {\mathsf{\omega }}_2$ = 1.9
$E\left[\alpha \right]=0.2$$, \sigma \left[\alpha \right]=0.1$ $E\left[\beta \right]=0.25$$, \sigma \left[\beta \right]=0.26$ ${\rho }_{\alpha ,\beta }=0.15$ ${\gamma }_{UB}=0.12$$, {\gamma }_{LB}=0.04$	$E\left[\alpha \right]=0.3$$, \sigma \left[\alpha \right]=0.1$ $E\left[\beta \right]=0.38$$, \sigma \left[\beta \right]=0.15$ ${\rho }_{\alpha ,\beta }=0.2$ ${\gamma }_{UB}=0.19$$, {\gamma }_{LB}=0.11$	$E\left[\alpha \right]=0.35$$, \sigma \left[\alpha \right]=0.2$ $E\left[\beta \right]=0.42$$, \sigma \left[\beta \right]=0.15$ ${\rho }_{\alpha ,\beta }=0.3$ ${\gamma }_{UB}=0.08$$, {\gamma }_{LB}=0.02$
$S{C}_p=\$5000$ $G{C}_p=\$\mathrm{15,000}$ $E{C}_p=\$60$	$S{C}_p=\$6000$ $G{C}_p=\$\mathrm{15,000}$ $E{C}_p=\$60$	$S{C}_p=\$8000$ $G{C}_p=\$\mathrm{15,000}$ $E{C}_p=\$60$

.

Three alternatives represent the three different forms of staffing arrangement. The team would be more efficient if there were more experienced members, but the salary costs would also be higher. As a result, the manager must determine which staffing arrangement is most beneficial. Based on the prior analysis of the three alternatives, alternative 2 appears to be the most viable option, and the manager should make the decision on the testing time for 5.4 weeks; the total cost will be USD 516,007. However, if the manager wants to raise the software reliability over 0.9, he/she has to prolong the testing time for 6.4 weeks, and the expected cost will be about USD 526,167. The detailed information regarding the three alternatives on the related costs, reliability and detection rate can be seen in

Table 5. $E\left[M\left(T\right)\right]$, $E\left[TC\left(T\right)\right]$, $E\left[RC\left(T\right)\right]$ and $E[R(x|T)]$ of alternatives 1, 2, and 3.

Time T	$\mathit{E}\left[\mathit{M}\left(\mathit{T}\right)\right]$			$\mathit{E}\left[\mathit{T}\mathit{C}\left(\mathit{T}\right)\right]$			$\mathit{E}\left[\mathit{R}\mathit{C}\left(\mathit{T}\right)\right]$			$\mathit{E}[\mathit{R}(\mathit{x}|\mathit{T})]$
	1	2	3	1	2	3	1	2	3	1	2	3
4	1223	1575	1592	$667,547	$540,660	$570,689	$417,191	$212,092	$202,653	0.556	0.650	0.698
4.2	1260	1608	1622	$655,754	$533,214	$565,149	$394,921	$193,977	$186,180	0.574	0.681	0.730
4.4	1296	1637	1649	$645,163	$527,293	$560,886	$373,985	$177,704	$171,304	0.591	0.710	0.760
4.6	1329	1663	1673	$635,707	$522,756	$557,778	$354,302	$163,094	$157,865	0.609	0.737	0.787
4.8	1360	1687	1695	$627,323	$519,473	$555,717	$335,798	$149,983	$145,719	0.627	0.763	0.812
5	1390	1709	1716	$619,948	$517,324	$554,605	$318,399	$138,221	$134,737	0.645	0.787	0.835
5.2	1418	1729	1734	$613,527	$516,201	$554,354	$302,037	$127,670	$124,801	0.663	0.809	0.855
5.4	1445	1746	1751	$608,000	$516,007	$554,885	$286,643	$118,205	$115,807	0.681	0.829	0.873
5.6	1470	1762	1766	$603,316	$516,652	$556,128	$272,156	$109,714	$107,659	0.698	0.847	0.889
5.8	1494	1777	1780	$599,428	$518,059	$558,021	$258,518	$102,094	$100,275	0.715	0.864	0.903
6	1516	1790	1793	$596,289	$520,155	$560,507	$245,675	$95,255	$93,578	0.732	0.879	0.916
6.2	1537	1802	1805	$593,857	$522,876	$563,535	$233,574	$89,114	$87,499	0.748	0.893	0.927
6.4	1558	1812	1815	$592,090	$526,167	$567,061	$222,167	$83,597	$81,978	0.763	0.905	0.937
6.6	1577	1822	1825	$590,953	$529,975	$571,044	$211,410	$78,638	$76,961	0.778	0.916	0.945
6.8	1595	1830	1834	$590,409	$534,257	$575,448	$201,260	$74,180	$72,397	0.792	0.926	0.953
7	1612	1838	1842	$590,427	$538,970	$580,240	$191,680	$70,168	$68,243	0.806	0.935	0.959
7.2	1628	1845	1850	$590,976	$544,081	$585,393	$182,631	$66,556	$64,460	0.819	0.943	0.965
7.4	1644	1852	1856	$592,028	$549,555	$590,880	$174,081	$63,303	$61,011	0.831	0.949	0.969
7.6	1658	1858	1863	$593,558	$555,366	$596,678	$165,999	$60,370	$57,866	0.843	0.955	0.974
7.8	1672	1863	1868	$595,540	$561,487	$602,766	$158,353	$57,725	$54,995	0.854	0.961	0.977
8	1685	1868	1874	$597,952	$567,896	$609,125	$151,119	$55,337	$52,373	0.864	0.966	0.980

and Figure 8. Although alternative 3 can shorten the testing time to 4.8 weeks and the reliability can satisfy the minimal reliability (0.812), the total cost ($555,717) is much more than that of alternative 2. With regard to the detection rate, alternative 3 is higher than alternative 2, but the mean value (the expected number of errors detected) of alternative 2 is obviously not less than alternative 3. Therefore, it may not substantially increase the effect of debugging work when the testing resource and staff are increased. To sum up, increasing testing resources and staff may not substantially increase the effect of debugging, and the manager needs to consider the balance between testing cost and software quality.

It is possible that the domain experts’ judgement may be not accurate enough. Therefore, in such a situation, if the former testing plan was not to be revised, the manager would proceed with the distorted plan and never get the real optimum. To obtain a more reliable decision analysis, it is suggested to proceed with the posterior analysis to adjust the former testing plan by the prior analysis. As a result, the manager will need to collect the current testing data at the initial testing stage. In this case, the manager was not convinced of the result of the prior analysis, and he/she, therefore, used the currently collected data $D^{\left(n\right)}$= {0.007, 0.018, 0.027, ...} from the initial testing stage to proceed with the posterior analysis. After the posterior analysis, the manager found that the result of the prior analysis might be too optimistic, but the debugging efficiency was lower than expected in reality. Figure 9 presents the difference between the prior and posterior analyses on the total testing cost and the number of errors detected. The manager needs to prolong the testing time from 5.4 weeks to 6.4 weeks, and the expected total cost should be changed to $568,989.

Since the domain experts might misjudge the parameters’ values $E\left[\alpha \right]$, $\sigma \left[\alpha \right]$, $E\left[\beta \right]$, $\sigma \left[\beta \right]$, ${\gamma }_{UB}$, ${\gamma }_{LB}$ in the prior analysis, the manager has to perform sensitivity analyses to investigate the possible influences. After performing the sensitivity analyses, the impacts of the model’s parameters and the related costs on the mean value of error detected, the total testing cost and the detection rate can be seen in Figure 10. Since the impacts of changing $E\left[\alpha \right]$ or $E\left[\beta \right]$ on the total cost and the mean value are more significant than the others, the domain experts should carefully evaluate them to prevent the possible loss of the misjudgment and improper actions. From another perspective, increasing the on-job-training or hiring more experienced staff can effectively raise the value of $E\left[\alpha \right]$ and $E\left[\beta \right]$ But it also causes expenditure on the testing work. For this reason, the manager should consider the balance between the benefit and the burden to decide how to improve $\alpha$ and $\beta$ or not. Moreover, the correlation between $\alpha$ and $\beta$ is also able to promote the debugging efficiency. As can be seen in the upper-left part of Figure 10, increasing the value of ${\rho }_{\alpha ,\beta }$ can effectively increase the number of errors detected. The value of the negligent factor $\gamma$ is relatively small in this case, so the detection rate is almost unchanged at different variations. With regard to the influence of the related parameters of the testing cost, it can be found that the most sensitive is the cost per unit time for correcting an error ($E{C}_p$), and the manager should estimate the value with caution. Moreover, the size of the parameters’ standard deviation will also influence the estimation of the total testing cost. In this study, we utilized a Monte Carlo method to simulate the occurrences of the total testing cost under the different values $\sigma \left[\alpha \right]$ and $\sigma \left[\beta \right]$. This method can help the manager identify the risk of the uncertainty of the parameters. Figure 11 presents the scatter plots of $TC\left(T\right)$ under different $\sigma \left[\alpha \right]$ and $\sigma \left[\beta \right]$. It can be easily found that the range of the scattered points in the middle stage would be larger, and it brings more uncertainty to the manager. Nevertheless, if the manager knew the size of the range in advance, he/she could make the appropriate preparation for it. Moreover, we also found that the scatter range from $\sigma \left[\alpha \right]$ is larger than that from $\sigma \left[\beta \right]$ even though the scale of $\beta$ is larger than that of $\alpha$. This implies that the uncertainty of the estimation of testing cost majorly relies on $\sigma \left[\alpha \right]$ instead of $\sigma \left[\beta \right]$.

5. Conclusions and Future Works

The main purpose of software reliability studies is to develop effective strategies for detecting and correcting software bugs to make the developed software more reliable. In recent years, there have been many studies focusing on software testing strategies and software reliability measurements. Most software reliability studies relied on sufficient historical data to estimate their model’s parameters. However, in some situations, the software developers or managers may not have sufficient historical data, and therefore, LSE or MSE statistical methods could not be applied to estimate the parameters’ value of their model. Accordingly, in practice, the software developers or managers have to find another method to estimate the parameters’ value. Bayesian analysis is an effective method for dealing with the estimation under insufficient historical data. In this study, an imperfect debugging software reliability growth model with consideration of learning and negligent factors was proposed. The estimation of the learning and negligent factors in our model would be more intuitive and can be easily evaluated by domain experts. Based on this, our proposed model will be easily integrated with Bayesian analysis, and therefore, it can bring the advantage of extending the related applications in practice.

Moreover, according to the study analysis results, raising the value of the model’s parameters $\alpha$ and $\beta$ requires more on-the-job training or hiring more senior testing staff, but the testing project also needs an increased budget for these costs. Accordingly, the software developer has to consider the trade-off to make a balanced decision. Additionally, the size of the parameters’ standard deviations will influence the estimation of the cost and the reliability. The study’s result indicated that the estimation uncertainty of testing cost majorly relies on the autonomous errors-detected factor, and the software manager must pay attention to the uncertainty of the parameter and make appropriate preparation for dealing with this. Furthermore, in proceeding with the testing plan under the prior analysis, the software manager may perceive or recognize the difference between the actual and the forecasted values. If the prediction error is too large, the manager has to proceed with the posterior analysis to adjust the former testing plan.

Finally, three directions can be considered for future studies: (1) a NHPP with covariates can be integrated with the software reliability growth model. The method of NHPP with covariates can use the extra failure data (testing effort, testing resource…etc.) for adjusting the original prediction, and as such, the model can raise the accuracy of prediction. (2) The time delay issue can be considered in developing the software reliability growth model. In the past, most of the studies assumed the error correction time would not influence the testing process. However, such an assumption is unrealistic. The future study will revise the unrealistic assumption to develop a new model. (3) The study can be extended to a change-point model, i.e., a change in the factors affecting software debugging, resulting in variable software error intensity functions. The extended model can adapt to more situations with changing testing environments.