Alfred Bröckers, University of Kaiserslautern, Computer Science Department
Boehm defines the term risk exposure as the product of the probability of an unsatisfactory outcome and the loss that is associated with this outcome [2]. Translated to software projects, satisfactory means producing the required software on budget, within schedule, and within the required product quality. The ability of an organization to perform a software project successfully (i.e. yielding a satisfactory outcome) is highly correlated with the ability to produce the quality of individual software artifacts (for example module specifications, design documents), and thus with the quality of individual software development activities that produce the artifacts. Since defects in development artifacts are an important quality factor that significantly influences the performance and success of a software project, the ability to prevent, detect, and remove them determines a large portion of the project risks.
Current state-of-the-practice analysis techniques such as RISCOMO [5] or PERT [6,7] neglect defect-related aspects of individual software artifacts and individual software development activities. Berny and Townsend divide risk analysis techniques into micro-level techniques and macro-level techniques [1]. State-of-the-practice micro-level techniques neglect product and process quality (except for development activity duration) while macro-level techniques are limited to a black-box view of the software development process.
Defect and cost data represent a retrospective view of the efficiency and effectiveness of the development activities of an organization. Furthermore, these data are an important source of information for predicting the efficiency and effectiveness of future instantiations of development activities. In this regard, efficiency and effectiveness are defined in terms of cost and provided product quality (i.e., number of defects that are introduced or detected).
To analyze the effects of defects on the performance of the overall project, it is necessary to view the defect data in the context of the software development process. A clear understanding of the development process' responses to defects (such as the kind of rework that is required) is a prerequisite for obtaining valid risk analysis results.
A software process model [4] describes how a class of software development processes is expected to be performed. In addition to document and control flow among software development activities, software process models can include information on decision alternatives, constraints, and quality attributes (such as the number of defects detected while inspecting a code module) that control the development process. Therefore, software process models can provide the process context information that is required to analyze defect-related risks.
I present an approach to risk analysis [3] that is based on explicit software process models and stochastic (statistical) quality models that are built from quality data (such as cost and defect data). Stochastic means that the quality model includes information on the expected stochastic distribution of the attribute in question. The quality models provide information on the expected quality of individual tasks and activities. Example qualities include cost, duration, number of defects introduced into artifact A, and detected percentage of defects of type B. The process model provides information on the responses of the software process to the quality aspects of development artifacts as a result of individual tasks and activities. Typical examples for these responses are all kinds of rework (for example, re-code module A, re-design module B, or re-design the whole system) as responses to defects of various defect classes. Both the software process model and the quality model are represented formally so that Monte Carlo simulation can be applied to analyze quality-related project risks quantitatively.
Since defects determine a significant portion of the risks a software project is exposed to, successful risk management has to deal with them explicitly. Combining software process models and quality models that are built from defect and cost data provides a sufficient basis for the analysis of defect-related risks. Formal representation of both process and quality models allows for applying formal, quantitative analysis techniques.
Successful management of project risks depends on gathering as much information on risk causes and effects as possible. Combining software process models and measurement data (for example, data on defects and cost) to predict project risks is a step in this direction.