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 approaches have been proposed to solve this problem. Most of them dealt only with one of either estimating effort or quality. Our aim is to develop a causal model capturing both of these and enabling trade-off analysis between the functionality, effort and quality. This model incorporates several quantitative and qualitative factors influencing the software development process and product. One of the key challenges is to be able to use some prior knowledge about the productivity and defect rates in the model. This knowledge can be obtained from the literature, a company’s data about past projects or assessed by an appropriate software project management expert. In this paper we present the results of an analysis which we performed using mainly ISBSG database of software projects. We also compared them with analyses available in the literature. These results are incorporated in our model for more accurate 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 models 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 productivity model [10] which extends the Bayesian net (BN) models developed in the MODIST project [9]. The models in MODIST had to be extended because empirical data about productivity and defect rates (PDR) were ‘hard coded’ into the model in such a way that it was difficult to use any new, more relevant prior data (the ‘priors’ were effectively biasing the 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 units delivered, • effort – expressed in both project duration and number 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 relationships between the variables. For example, it can answer questions like: ‘what effort will we need do develop software of some specific functionality (size) given that it must 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, stability etc.), and process and people quality (staff experience, following defined processes or CMM level etc.). A core component of the model is the idea that all project effort is devoted either to writing new code (which determines the productivity as defined by code delivered) or to other activities which are lumped together as ‘quality assurance’. The greater the percentage of effort spent on ‘quality’ (getting the code right) the less effort is available for producing new 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 between the current project compared with a ‘typical’ past project. The prior rates reflect their 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