Software Contingency Estimation Models

Risk events bring adverse monetary consequences that cause shortfalls in estimated costs of software projects [DM03] [KU02]. Contingency resources provide a buffer against such cost shortfalls and safeguard software projects against risk events [KI03] [JN00] [BN08]. Therefore, software project managers need appropriate contingency resources in order to better manage the organizational resources. Contingency estimation plays a fundamental role in defining management policies to deal with risk events, as adverse effects of risk events are managed through appropriate allocation of contingency resources. Researchers have attempted to estimate contingency resources needed for the development of software projects.

Contingency estimation is about effective cost estimation [AL08] [TI06],as well as risk management involving risk identification and risk assessment mechanisms [BE94]. Contingency planning ensures proper understanding of the risk associated with software projects, and this risk awareness brings confidence and professionalism to software projects [TO88].

Contingency resources are represented either in man-months or in monetary units of cost which are required to complete a software project. The effort and cost are directly related as man-months translate into monetary values of cost [FA95].

The estimation and allocation of contingency resources allow software organizations to take calculated risks, which influence the scope, schedule, quality, and cost of software projects. Therefore, estimation and management of contingency resources is vital for the successful development of software projects.

Chapter -2 Literature Review 40 Estimated contingency resources for software projects are not always fully utilized, since some risk events may not occur during any development phase of software projects. Therefore, the contingency resources are best managed and utilized for a portfolio of software projects, since few projects of the portfolio may necessitate the use of contingency reserves [BN08][KI03].

Kitchenham et al. [KI97] define the source of uncertainty in the cost estimation, assumptions and tools as a risk to software projects. They suggest the deployment of contingency resources to deal with uncertainties of software projects. This contingency estimation model focuses on the risk associated with the uncertainties in the estimations, tools, and processes, while the other forms of risk events are not considered; hence, the model has a limited and specific focus.

Kansala’s [KK97] contingency estimation model is based on a single-value quantification of risk, which is used to estimate the contingency resources. The estimated contingency resources are added to the estimated cost of the software project. The single- value representations of risk and estimated cost of software projects produce unreliable estimates [KI97]. Hence, contingency estimates based on unreliable risk and cost estimates produce unreliable contingency estimates.

Jantzen et al. [JT06] model the impact of risk events using percentages between the ranges of 1% to 5%; this percentage refers to the proportion a risk event increasing the estimated cost of the software project. The probability of the risk event is selected from five possible values ranging from 15% to 85%, and the contingency resources are defined as the product of the impact and probability of risk events. This model takes into account a few chosen values of impacts and probabilities of risk events; furthermore, this model focuses on a single project. In addition, the estimated contingency is added to the estimated cost of the software project.

Armstrong et al. [GI01] represent the estimated cost of a software project as a Gaussian distribution, segmented into four zones labeled as impossible, optimistic, probable, and

conservative. Only the conservative cost estimates of the software project are dealt with

regarding contingency resources. Armstrong et al. suggest that the scope of the software project and risk events shifts the software cost distribution into the conservative cost zone. Risks to the software project are profiled based on their impact and probability, and contingency is allocated based on the risk event having a severe impact with a high

Chapter -2 Literature Review 41 probability of occurrence. The boundaries of risk severity and probability are left to the software project manager to define, depending on the risk thresholds of the organization.

Fairley [FA95] defines contingency as a percentile of the distribution of the estimated cost of a software project, whereas the cost distribution is estimated using the Constructive Cost Model (COCOMO). The COCOMO cost drivers are treated as the risk events of the software project, where some cost drivers are modeled with probability distributions. The Monte Carlo simulation selects samples of software project size, along with the impacts of the risk events from the respective distributions, and constructs the distribution of the estimated cost of the software project. Then, the contingency estimate is a certain percentile of the estimated cost distribution. This model suffers from the fact that percentile values taken from skewed probability distributions provide misleading estimates; this problem will be further elaborated upon in section 4.3. Fairley noted that software practitioners fund software projects with 70% probability of the estimated cost and commit up to 90% probability of the estimated cost, whereas 20% of the difference comes from the contingency reserves set aside for the software project.

Kitchenham et al. [KI03] presented a contingency estimation model for software projects based on an insurance premium model where the contingency resources are represented with a probability distribution. They suggest using the contingency resources to handle risk events that are unknown and not included in the software project plan; however, when the nature and impact of risk events are unknown, the amount of contingency resources required to handle such risk events cannot be justified.

Boukendour [BU05] presented a model based on stock option theory for estimating contingency resources needed for software projects. The model is based on the notion that more accurate software cost estimates require less contingency resources. Boukendour demonstrated that reducing risks of a software project contributes to the reduction in the overall contingency resources of the software project. This model is based on a single point cost and contingency estimates; hence, is most likely to provide unreliable contingency estimates [KI97].

Briand et al. [BR98] presented a hybrid model that consists of cost estimation, risk assessment, and cost overhead estimation models for software projects. The cost overhead is defined as the additional percentage of the cost required in addition to the estimated

Chapter -2 Literature Review 42 cost; the estimated overhead cost is added to the estimated cost of the software project. The impacts of risk events and cost overhead estimations are mapped onto a triangular distribution where the mean of the triangular distribution determines risk impacts and cost overheads. Triangular distribution suffers from sympatric bias and produces large means when the maximum of the distribution is large [DV08]. This fact is obvious from their case study, where the triangular distribution estimates 214% of cost overhead. They suggest that the estimates are pessimistic, which means the estimates are more than the actual value; however, this argument contradicts the choice of triangular distribution. Furthermore, when the estimated cost overhead is added to the software project cost, it makes this approach unusable for a portfolio of software projects because adding large amounts of estimated cost overhead for each software project to the cost of the portfolio would produce unrealistic estimates, since not all software projects within the portfolio may require cost overhead.