Modelling Prior Productivity and Defect Rates in a Causal Model for Software Project Risk Assessment

Estimating effort and quality of developed software has been a demanding task for project managers. Many models based on different ap pro ches have been proposed to solve this problem. Most of them dealt only with one of e ith r estimating effort or quality. Our aim is to develop a causal model capturing both of thes e and enabling trade-off analysis between the functionality, effort and quality. This model i ncorporates several quantitative and qualitative factors influencing the software develo pment process and product. One of the key challenges is to be able to use some prior knowledg e about the productivity and defect rates in the model. This knowledge can be obtained from the li erature, a company’s data about past projects or assessed by an appropriate software pro j ct management expert. In this paper we present the results of an analysis which we perform ed using mainly ISBSG database of software projects. We also compared them with analy ses available in the literature. These results are incorporated in our model for more accu rate predictions especially when software companies do not have appropriate data about their past projects. Causal model for software project risk assessment Much effort has been spent in developing models for estimating software size, development effort and delivered quality. These mod els rarely attempted to capture all these variables. Our ultimate aim is to include them in a single causal model together with other factors affecting them. Figure 1 illustrates schematic view of the producti vity model [10] which extends the Bayesian net (BN) models developed in the MODIST pr oject [9]. The models in MODIST had to be extended because empirical data about pro ductivity and defect rates (PDR) were ‘hard coded’ into the model in such a way that it w as difficult to use any new, more relevant prior data (the ‘priors’ were effectively biasing t he model too much). The key part of the new model is the trade-off component (at the bottom of the figure) between: • functionality – expressed in number of software uni ts delivered, • effort – expressed in both project duration and num ber of people, which are then adjusted by a ‘Brooks factor’ [1], • quality – expressed as number of defects. Figure 1. Schematic view of the productivity model This trade-off component enables us to analyse rela tionships between the variables. For example, it can answer questions like: ‘what ef fort will we need do develop software of some specific functionality (size) given that it mu st not exceed more than some specific number of defects? ’. These relationships are influenced by productivity and defect rates which are estimated by the model and which depend on inherent project factors (complexity, novelty etc.), requirements quality (completeness, stabilit y etc.), and process and people quality (staff experience, following defined processes or CMM leve l etc.). A core component of the model is the idea that all project effort is devoted eith r to writing new code (which determines the productivity as defined by code delivered) or to ot her activities which are lumped together as ‘quality assurance’. The greater the percentage of ff rt spent on ‘quality’ (getting the code right) the less effort is available for producing n ew code. Hence we have the node ‘percentage difference of effort devoted to quality’ and prior defect and productivity rates. Except for the prior rates, these factors reflect the difference b etween the current project compared with a ‘typical’ past project. The prior rates reflect the ir values for a ‘typical’ past project. They can be either: Factors influencing prior rates Prior defect rate Prior productivity rate Adjusted defect rate Adjusted productivity rate