Int J Syst Assur Eng Manag DOI 10.1007/s13198-014-0326-2
ORIGINAL ARTICLE
Software defects estimation using metrics of early phases of software development life cycle Chandan Kumar • Dilip Kumar Yadav
Received: 6 June 2014 The Society for Reliability Engineering, Quality and Operations Management (SREQOM), India and The Division of Operation and Maintenance, Lulea University of Technology, Sweden 2014
Abstract An estimation of software defects can be obtained in the later phase of software testing. However, with the aim of cost-effectiveness and timely management of resources, the software defects estimation in the early phases of software development life cycle (SDLC) is one of the major research areas. In this paper, a software defect estimation model is proposed using Bayesian belief network (BBN) and reliability relevant metrics of early phases of SDLC (e.g., requirement analysis, design and coding phases). The causal relationship of software metrics is modeled using BBN. The qualitative value of software metrics and expert assessment of software defects is used for developing the proposed model. The defects estimation accuracy of the proposed model is examined using qualitative data set of ten real software projects. The defects estimation results are compared with the existing model and found more accurate. Keywords Software defect estimation Software metrics Causal relationship Qualitative data Bayesian belief network
1 Introduction Nowadays, software systems have been increased in complexity and thereby the residual defects in the delivered
C. Kumar (&) D. K. Yadav Department of Computer Applications, National Institute of Technology, Jamshedpur, India e-mail:
[email protected] D. K. Yadav e-mail:
[email protected]
software have also been increased. Software failure occurs frequently. Safety–critical software should be highly reliable as failure of this software may cause injury or death of human beings. Software industries have a big challenge to develop defect free software. The delivery of unreliable or less reliable software in the market may be dangerous for the society and also for the software companies. Therefore, the defect estimation of software is a major area of research. An estimate of software defects can be obtained only in the later phase of software testing. However, with the aim of cost-effectiveness and timely management of resources, the defects estimation of software in the early phases of software development life cycle is one of major area of concern. Here, the term ‘early’ is being used to represents the early phases of the software development life-cycle (e.g., requirement analysis, design, and coding phases). Residual defects of software are one of the major indicators for software reliability and quality. Therefore, early software defects estimation provides early identification of cost overruns, software development process issues, optimal development strategies, and a reliable forecast of the end quality of the software being developed in terms of product suitability. A number of analytical models have been proposed for assessing the reliability of a software system (Goel 1985). In early software reliability prediction literature, there are many approaches and model studied like ESRA (Early Software Reliability Assessment) approach (Mohanta et al. 2010, 2011), ERAT (Early Reliability Analysis Technique) (Tripathi and Mall 2005; Cheung et al. 2008), ERPM (Early Reliability Prediction Model) (Smidts et al. 1998), UML based software models (Cortellessa et al. 2002), Enhanced Model (Saravana and Mishra 2008), Decision
123
Int J Syst Assur Eng Manag
Tree Based Model in combination of K-means clustering as preprocessing technique (Sandhu et al. 2010), Fuzzy time series approach (Yadav et al. 2012). There is not any models and approaches common for all possible software projects. The issue of finding a common model for all possible software projects is yet to be solved. The selection of a particular model is very important in software defect estimation because both the release date and the resource allocation decision can be affected by the accuracy of estimation. Catal and Diri (2009), Catal (2011) provided a systematic review of various software defects estimation models with focus on software metrics. However, causal relationships among reliability relevant metrics are missing in the early software defects estimation literature. The causal relationships among reliability relevant software metrics can be established by BBN. The uncertainty of a system can be modeled using BBN. Bayesian Belief Network enables us to incorporate qualitative factors and it can also be used where some values of metrics or variables are not given (Netica). The estimation result of the BBN is in the form of probability value rather than point value. Over the last few decades many software quality and reliability modeling techniques have been developed and used in software quality and reliability estimations like Fenton and Neil (1996, 1996, 1999), Fenton et al. (2002) developed some causal model using BBN for software quality and risk modeling. Neil and Fenton (1996) proposed explicitly how BBN could be used for estimating the software quality by taking some factors implicit in defect prevention, detection and complexity. Fenton and Neil (1999) developed a prototype BBN model to show the efficacy of BBN and illustrate its useful properties. They found that the models which consider only size and complexity metrics are not sufficient for estimating defects accurately. The better estimation of defects can be achieved by considering the metrics of development process, problem complexity, defect detection processes and design complexity. Fenton et al. (2002) used BBN for defect, quality and risk estimation of software systems. Amasaki et al. (2003), proposed BBN model to predict the quality of a software system. To generate a BBN, they use certain metrics collected during the software development phase like product size, effort, detected faults, test items, and residual faults. They concluded that the proposed model estimate the residual defects of the software more accurately. Pe´rez-Min˜ana and Gras (2006), use BBN to predict the level of fault injection or detection during the phases of a software development process. Pai and Dugan (2007), use Bayesian networks to analyze the effect of object oriented metrics on the number of defects and defect proneness using KC1 project data from the NASA metrics data repository. They have found that SLOC (source lines
123
of code), CBO (coupling between object classes), WMC (weighted methods per class), and RFC (response for class) are the most significant metrics to determine fault content and fault proneness. Fenton et al. (2007) review different techniques for software defect estimation and concluded that traditional statistical approach like regression alone is not enough. Instead they believe that causal models are needed for more accurate estimation. They describe a Bayesian network to estimate the software defects in the varying software development life cycle. In another study, Fenton et al. (2008) proposed to use Bayesian networks to estimate software defects and software reliability. They concluded that using dynamic discretization algorithms while generating Bayesian networks leads to significantly improved accuracy for defects and reliability estimation. Fenton et al. (2008) discussed an experiment to develop a causal model (Bayesian net) for predicting the number of residual defects that are likely to be found during independent testing or operational usage. They presented a causal model for defect estimation that is a revised version of the MODIST model (MODIST 2003). The main feature that distinguishes it from other defect estimation models is the fact that it explicitly combines both quantitative and qualitative factors. Mohanta et al. (2010, 2011) proposed a bottom–up approach to predict the reliability of object-oriented systems during the early stages of the product development. This approach first predicts the reliabilities of the classes in an object-oriented system using product metrics extracted from the UML specifications of a software system. The reliability of the overall system is estimated based on operational profile and reliabilities of classes. The proposed approach uses a Bayesian network and its underlying forward inference propagation algorithm to compute the reliability from the design metrics. Okutan and Yildiz (2014) proposed a novel method using Bayesian networks to explore the relationships among software metrics and defect proneness. They used Bayesian networks to model the relationships among metrics and defect proneness on multiple data sets. They introduced a new metric ‘‘Lack of Coding Quality (LOCQ)’’ that can be used to predict software defects. Yadav et al. (2012), Yadav and Yadav (2013, 2014) proposed a model for software defects prediction using fuzzy logic. They considered uncertainty associated with the software metrics for estimating software defects and quality. Dejaeger et al. (2013) compare 15 different Bayesian network classifiers with famous defect estimation methods on 11 data sets. They concluded that simple and comprehensible networks with fewer nodes can be constructed using Bayesian network. In the literature, it is observed that the most of the models have not considered the causal relationships of reliability relevant metrics. The reliability relevant software metrics play a major role in
Int J Syst Assur Eng Manag
estimating the quality and reliability of a software (Chidamber and Kemerer 1991); Zhang and Pham 2000; Li and Smidts 2003; Kitchenham 2010; Danijel et al. 2013. Therefore, in this paper, a BBN model is proposed for software defects estimation using reliability relevant metrics of early phases of SDLC. The rest of the paper is arranged as follows. Bayesian belief network is described in Sect. 2. The proposed methodology is explained in Sect. 3. Section 4 describes the case studies for ten real software projects. The model validation is done in Sect. 5. Section 6 presents the conclusion of this research work.
BBN is defined as the set of {R, C, P}, where. R is a set of random variables, R = {R1, R2,…,Rn}. Each Ri in R can either be discrete or continuous. C is a set of conditional probability distributions, C = {p(R1|Parents(R1)),…,p(Rn | Parents(Rn))},where, Parents(Ri) denotes all the parent nodes for Ri, p(Ri | Parents(Ri)) is the conditional distribution of Ri with respect to its parent nodes. P is the set of probability distribution of the random variables. P = {p(R1),…, p(Rn)} where p(Ri) represents the probability distributions of random variable Ri.
2 Bayesian belief network 3 Proposed methodology Bayesian belief network is based on Bayes theorem developed by the Rev. Thomas Bayes, an eighteenth century mathematician (Jensen 1996; Netica 2010), and it is expressed as: PðR=SÞ ¼
PðS=RÞPðRÞ ; PðSÞ
ð1Þ
where P (R/S) is the posterior probability of hypothesis; P (S/R) is the likelihood of observed data; P (R) is the prior probability of hypothesis. Equation (1) is the basic form of Bayes rule. The rule is interpreted in terms of updating the belief about a hypothesis R in the light of new evidence S. So the posterior belief P (R/S) is calculated by multiplying the prior belief P (R) by the likelihood P (S/R) that S will occur if R is true. A BBN is a directed acyclic graph (DAG) as shown in Fig. 1, in which the nodes represent the system variables and the arcs represent the dependencies or the cause–effect relationships among the variables. A probability is associated to each state of the node. This probability is defined, a priori for a root node and computed by inference for the others. In short, BBN is a combined approach of graph theory and probability theory.
The architecture of the proposed model is shown in the Fig. 2. Four metrics of requirement analysis phase and seven metrics of design and coding phase are used to develop the proposed model. The causal relationships of these metrics are shown in Fig. 2. The total number of residual software defects is estimated with the help of probability values of software residual defects (i.e., output of BBN model) and qualitative values of software residual defects obtained from domain expert. 3.1 Model details The steps applied to our proposed methodology are as follow: Step 1 Step 2 Step 3
Select the reliability relevant software metrics. Construct the causal relationships of selected metrics. Develop BBN model. Following are the sub-steps for developing the BBN model: (i) (ii)
(iii) Step 4
Construct the BBN based on the selected metrics and their causal relationships. Construct the node probability table from the experimental observations or by the domain expert. Compile the BBN.
Obtain probabilistic value of residual software defects. (i)
(ii)
Input the qualitative value of the software metrics (evidence) in the compiled BBN. Get the probabilistic value for Low, Medium and High level of software defects.
Fig. 1 Example of BBN
123
Int J Syst Assur Eng Manag Fig. 2 Proposed model
Step 5
Calculate residual software defects.
3.1.1 Selection of reliability relevant software metrics Software metrics contribute directly to the reliability of the software. Zhang and Pham (2000) presented thirty two reliability relevant software metrics in the SDLC. Li and Smidts (2003) selected software metrics which influence software reliability and ranked with respect to their ability in predicting software reliability through an expert opinion elicitation process. In our proposed BBN model, eleven top reliability relevant software metrics are selected from the early phases of SDLC (i.e., requirements analysis, design and coding phases) based on studies by (Li and Smidts 2003; Fenton et al. 2008). These software metrics are shown in Table 1. The software metrics shown in Table 1 are described below: (1)
(2)
Software complexity (DC1) Software complexity metric represents the cyclomatic complexity, data flow complexity, and system design complexity. It represents the degree to which a software requirement, design and implementation are difficult to understand and verify. The increased complexity lead to misinterpretation about the software features. Requirement stability (RA1) Requirement stability depends on requirement specification change request. Requirement stability is high if requirement specification change request is low in later phases. The lesser value of requirement stability lead to misinterpretation about the software features.
123
Table 1 Reliability relevant software metrics Name of early phases
Software metrics
Requirements Analysis
Requirement stability (RA1) Experience of requirement team (RA2) Review effort of software requirement specification document (RA3) Quality of software requirement specification document (RA4)
Design and Coding
Software complexity (DC1) Experience of design and development team (DC2) Review effort of software design (DC3) Review effort of software coding (DC4) Quality of software design (DC5) Quality of software coding (DC6) New functionality implemented (DC7)
(3)
(4)
Experience of requirement team (RA2) Review, inspection and walkthroughs metric depends on the experience of requirement team. It measures the relevant experience and skill set of team members for executing the project during the requirements analysis phase of SDLC. The lesser value of experience of requirement team is more prone to errors and omissions. Experience of design and development team (DC2) It measures the relevant design and development experience, motivation, programmer capability during the design and development phase of SDLC. The design defect density, code defect density, and fault density depends on experience of design and
Int J Syst Assur Eng Manag
(5)
(6)
(7)
development team. The experience of design and development team having less experience, motivation and less programmer capability are more prone to errors and omissions. Review effort (RA3, DC3, and DC4) Review effort is assessed in terms of the person hours. Requirement compliance and requirement traceability depends on review effort on software requirement specification document, review effort on design, and review effort on coding. The better effort spent in the review of the software requirement specification document, design phase and coding phase extracts out the faults from the software. Quality of specification requirement document (SRD), design and code (RA4, DC5, and DC6) It is the degree to which a software system meets the specified requirements, design and coding. Man hour per major defect detected and number of faults remaining (error seeding) depends on quality of software requirement specification document, quality of design and quality of coding. The better defined process followed lead to good quality of software requirement specification document, design and coding. New functionality implemented (DC7) It measures the extent of working on new functionality rather than just enhancing the older functionalities of software. It is assessed in terms of new development or new feature that happened in a software development.
development team (DC2), review effort of code (DC4) and quality of design (DC5). The residual software defect metric depends on quality of software requirement specification document (RA4), quality of design (DC5), quality of code (DC6) and new functionality implemented (DC7). 3.1.3 BBN model development and analysis The BBN model development and analysis part is shown in Fig. 3. The node probability table of these nodes is constructed from the experimental observations and by the domain expert. The compiled mode of the proposed model is produced after designing the node probability table.
4 Case studies Total ten case studies are illustrated to explain the proposed methodology. Data sets of ten real software projects are taken from (Fenton et al. 2008) for case studies and are reproduced in Table 2 where H, M and L represent to high, medium and low respectively. 4.1 Model illustration: case study 1 Software project 1 is considered to explain the proposed model in this case study. Following are the steps for finding the total number of software defects for project 1. Step 1 Step 2
3.1.2 Construction of causal relationships of selected metrics The Fig. 2 shows the causal relationship of reliability relevant metrics. Requirement stability (RA1), experience of requirement team (RA2), software complexity (DC1), experience of design and development team (DC2) and new functionality implemented (DC7) are independent metrics. Review effort of software requirement specification document (RA3), review effort of design (DC3) and review effort of code (DC4) metrics depend on requirement stability (RA1). Quality of software requirement specification document (RA4) metric depends on experience of requirement team (RA2), review effort of software requirement specification document (RA3) and software complexity (DC1) metrics. Quality of design (DC5) depends on quality of software requirement specification document (RA4), software complexity (DC1), experience of design and development team (DC2) and review effort of design (DC3) metrics. Quality of code (DC6) depend on software complexity (DC1), experience of design and
Step 3
Select the reliability relevant software metrics Construct the causal relationships of selected metrics The constructed causal relationships of selected metrics is shown in Fig. 2. BBN model development and analysis. (i)
(ii)
(iii) Step 4
Based on the selected metrics and their causal relationships, the BBN graph model constructed. The node probability table (NPT) is constructed for all the nodes from the experimental observations or by the domain expert (Zhou et al. 2014; Kitchenham 2010). For example, the NPT of RA3 metric is shown in Fig. 4. The BBN Compilation mode is shown in Fig. 3.
Obtain probabilistic value of software residual defects. (i)
Input the qualitative value of the software metrics shown in Table 1 to the developed BBN model.
123
Int J Syst Assur Eng Manag Fig. 3 Compile mode of proposed model
Table 2 Qualitative value of software metrics Project no.
Software project (Fenton et al. 2008)
Qualitative value of software metrics Req. analysis phase
Design and coding phase
RA1
RA2
RA3
RA4
DC1
DC2
DC3
DC4
DC5
DC6
DC7
1
2
H
H
M
H
L
L
H
H
H
H
L
2
3
H
H
H
H
H
H
H
H
H
H
H
3
6
H
H
H
M
M
M
M
M
H
H
M
4
8
H
M
H
M
M
H
M
M
H
H
L
5
9
H
H
H
H
L
H
H
H
H
H
L
6
11
H
H
H
M
H
H
H
H
H
H
H
7
14
H
H
H
H
H
H
H
H
H
H
H
8
16
M
H
L
H
L
H
H
H
H
H
M
9
17
M
H
H
H
L
H
H
H
H
H
L
10
29
H
H
M
M
L
M
H
H
M
M
L
shown in Table 3. The constructed causal relationships of selected metrics is shown in Fig. 2. Step 5
Calculate residual software defects.
Residual software defects are calculated using the probabilistic value of software defects obtained from the BBN model and qualitative value of software defects obtained from domain expert. Result is shown in Table 4. Similarly, based on the above steps the proposed model has been experimented for other case studies.
Fig. 4 NPT of RA3
4.2 Estimation results (ii)
123
The probabilistic value for low, medium and high level of software residual defects is found from Fig. 5 which is
The estimated value of software defects for ten real software projects is shown in Table 5.
Int J Syst Assur Eng Manag Fig. 5 Experimented result of case study 1
Table 3 Probability value of residual software defects for case study 1 Case study
1
Residual software defects probability L (best case)
M (average case)
H (worst case)
0.70
0.20
0.10
Table 5 Estimated value of software defects Actual and predicted number of defects before testing Project no.
Software project (Fenton et al. 2008)
Actual defects
Defect estimated by Fenton et al. (2008)
Proposed model
1
2
31
52
28
Table 4 Estimated value of software defects for project 1
2
3
209
254
198
Project no.
Estimated defects
3
6
167
123
173
Fenton et al. (2008)
Proposed model
4
8
53
48
55
5 6
9 11
17 71
57 51
15 76
52
28
7
14
672
674
609
8
16
109
145
96
9
17
688
444
667
10
29
91
116
95
1
Software project (Fenton et al. 2008)
2
Actual defects
31
5 Model validation 5.1 Evaluation measures To validate the proposed model, following commonly used and suggested evaluation measures (Fenton et al. 2008; Chulani et al. 1999; Kitchenham et al. 2001; Stensrud et al. 2002) have been taken: (1)
Mean magnitude of relative error (MMRE) MMRE is the mean of absolute percentage errors and a measure of the spread of the variable z, where z = estimate/actual. n 1X jyi y^i j MMRE ¼ ; yi n i¼1
(2)
where yi is the actual value and y^i is the estimated value of variable of interest. Balanced mean magnitude of relative error (BMMRE) MMRE is unbalanced and penalizes overestimates more than underestimates. For this reason, a balanced mean magnitude of relative error measure is also considered which is as follows: BMMRE ¼
n 1X jyi y^i j n i¼1 Minðyi ; y^i Þ
The lesser value of MMRE and BMMRE indicates better accuracy of the estimation.
123
Int J Syst Assur Eng Manag Table 6 Compared values of model evaluation measures Evaluation measures
Dataset for validation Projects \10 KLOC
10 KLOC C projects \ 30 KLOC
Projects C 30 KLOC
All projects
(n = 4)
(n = 3)
(n = 3)
(n = 10)
Fenton et al. (2008) model
Proposed model
Fenton et al. (2008) model
Proposed model
Fenton et al. (2008) model
Proposed model
Fenton et al. (2008) model
Proposed model
MMRE
0.85160
0.08065
0.28949
0.06639
0.19098
0.05897
0.48478
0.06986
BMMRE
0.88167
0.08716
0.32091
0.07177
0.25595
0.06350
0.52572
0.07544
n is the number of projects
5.2 Validation results It can be observed from Table 6 that the MMRE and BMMRE for the proposed model are 0.06986 and 0.07544 respectively whereas for Fenton et al. (2008) model their values are 0.48478 and 0.52572 respectively. It can also be observed that the estimation accuracy of the model expressed by different measures increases with the size of the project for both models. The measures based on relative error (MMRE, BMMRE) decrease significantly as project size increases for both the models.
6 Conclusion In this paper, a software defects estimation model is proposed using BBN and metrics of early phases of SDLC. Bayesian belief network is very useful where sufficient objective data are not available. At the early stage of software development life cycle, the software metrics are difficult to measure due to their associated uncertainties. The proposed model takes into account the uncertainty associated with the reliability relevant software metrics of requirement analysis, design and coding phases of SDLC. Furthermore, 10 real software project data sets have been employed to illustrate the applicability and usability of the proposed approach. It has been observed that the estimation accuracy of the proposed model is much better than that of the Fenton et al. (2008). The proposed model is very useful for software testing team. Test manager knows in advance the defects contains of the software which helps him for optimal planning of the testing resources.
References Amasaki S, Takagi Y, Mizuno O, Kikuno T (2003) A bayesian belief network for assessing the likelihood of fault content.
123
Proceedings of 14th international symposium on software reliability engineering (ISSRE), 215–226 Catal C (2011) Software fault prediction: a literature review and current trends. Expert Syst Appl 38:4626–4636 Catal C, Diri B (2009) A systematic review of software fault predictions studies. Expert Syst Appl 36:7346–7354 Cheung L, Roshandel R, Medvidovic N, Golubchik L (2008) Early prediction of software component reliability. Proceedings of the 30th international conference on software engineering (ICSE), 111–120 Chidamber SR, Kemerer CF (1991) A metrics suite for object oriented design. IEEE Trans Softw Eng 20:476–493 Chulani S, Boehm B, Steece B (1999) Bayesian analysis of empirical software engineering cost models. IEEE Trans Softw Eng 25:573–583 Cortellessa V, Singh H, Cukic B (2002) Early reliability assessment of UML based software models. Proceedings of the 3rd international work-shop on software and performance (WOSP), 302–309 Danijel R, Marjan H, Richard T, Ales Z (2013) Software fault prediction metrics: a systematic literature review. Inf Softw Technol Inf Softw Techno 55:1397–1418 Dejaeger K, Verbraken T, Baesens B (2013) Toward comprehensible software fault prediction models using bayesian network classifiers. IEEE Trans Softw Eng 39:237–257 Fenton NE, Neil M (1996) Predicting software quality using Bayesian belief networks. Proceedings of 21st annual software engineering workshop, 217–230 Fenton NE, Neil M (1999a) A critique of software defect prediction models. IEEE Trans Softw Eng 25:675–689 Fenton NE, Neil M (1999) Software metrics and risk, Proceedings of 2nd European software measurement conference (FESMA), 39–55 Fenton NE, Krause P, Neil M (2002) Software measurement: uncertainty and causal modeling. IEEE Softw 19:116–122 Fenton NE, Neil M, March W, Hearty P, Marquez D, Krause P, Mishra R (2007) Predicting software defects in varying development lifecycles using bayesian nets. Inf Softw Technol 49:32–43 Fenton NE, Neil M, March W, Hearty P, Radlinski L, Krause P (2008) On the effectiveness of early life cycle defect prediction with Bayesian nets. Empir Softw Eng 13:499–537 Goel AL (1985) Software reliability models: assumptions limitations, and applicability. IEEE Trans Softw Eng 11:1411–1423 Jensen FV (1996) An introduction to bayesian networks. SpringerVerlag New York, Inc., Secaucus. ISBN 0387915028 Kitchenham B (2010) What’s up with software metrics?—A preliminary mapping study. J Syst Softw 83:37–51
Int J Syst Assur Eng Manag Kitchenham BA, Pickard LM, MacDonell SG, Shepperd MJ (2001) What accuracy statistics really measure. IEE Proc Softw 148:81–85 Li M, Smidts CS (2003) A ranking of software engineering measures based on expert opinion. IEEE Trans Softw Eng 29:811–824 Mohanta S, Vinod G, Ghosh AK, Mall R (2010) An approach for early prediction of software reliability. ACM SIGSOFT Softw Eng Notes 35:1–9 Mohanta S, Vinod G, Mall R (2011) A technique for early prediction of software reliability based on design metrics. Int J Syst Assur Eng Manag 2:261–281 Netica Version 4.16 (2010). Available at http://www.norsys.com/ Okutan, Yıldız OT (2014) Software defect prediction using Bayesian networks. Empir Softw Eng 19:154–181 Pai Ganesh J, Dugan Joanne B (2007) Empirical analysis of software fault content and fault proneness using Bayesian methods. IEEE Trans Softw Eng 33:675–686 Pe´rez-Min˜ana E, Gras J-J (2006) Improving fault prediction using bayesian networks for the development of embedded software applications, software testing, verification & reliability—UKTest 2005: the Third U.K. Workshop Softw Test Res 16:157–174 Sandhu PS, Brar AS, Goel R, Kaur J, Anand S (2010) A model for early prediction of faults in software systems. Proceedings of 2nd international conference on computer and automation engineering (ICCAE), 281–285 Saravana K, Mishra RB (2008). An enhanced model for early software reliability prediction using software engineering metrics. Proceedings of 2nd international conference on secure system integration and reliability improvement, 177–178 Smidts C, Stutzke M, Stoddard RW (1998) Software reliability modeling: an approach to early reliability prediction. IEEE Trans Reliab 47:268–278
Stensrud E, Foss T, Kitchenham B, Myrtveit I (2002) An empirical validation of the relationship between the magnitude of relative error and project size. Proceedings of 8th IEEE symposium on software metrics, 3–12 Tripathi R, Mall R (2005) Early stage software reliability and design assessment. Proceedings of the 12th Asia-Pacific software engineering conference (APSEC) Yadav DK, Charurvedi SK, Mishra RB (2012a) Early software defects prediction using fuzzy logic. Int J Perform Eng 8(4):399–408 Yadav DK, Chaturvedi SK, Misra RB (2012) Forecasting timebetween-failures of software using fuzzy time series approach. In: IEEE proceeding of North American fuzzy information processing society (NAFIPS), Berkley, USA, 6–8 August, pp 1–8 Yadav HB, Yadav DK (2013) A fuzzy logic approach for software quality modeling. Proceedings of the second international conference on computing sciences (ICCS-2013), Lovely Professional University, Elsevier Publication, Punjab, India, 15–16 Nov pp. 32–39 Yadav HB, Yadav DK (2014) A multistage model for defect prediction of software development life cycle using fuzzy logic. In: Proceedings of the third international conference on soft computing for problem solving (SOCPROS-2013), IIT Roorkee, 26–28 Dec 2013, Advances in Intelligent Systems and Computing, Vol 259. India, Springer India Publication, pp 661–671 Zhang X, Pham H (2000) An analysis of factors affecting software reliability. J Syst Softw 50:43–56 Zhou Y et al. (2014) Bayesian network approach to multinomial parameter learning using data and expert judgments. International journal of approximate reasoning. (in press) http://dx.doi. org/10.1016/j.ijar.2014.02.008
123
