A Fault Threshold Policy to Manage Software Development Projects

Abstract

T his paper presents a project management policy in which the appearance of software faults during system construction is used to determine the timing of system integration activities (e.g., team meetings, analyzing modules for interface inconsistencies, system fault correction, and so on). System integration is performed only if a threshold fault count has been exceeded; otherwise, module development is allowed to continue. We derive an expression for calculating fault thresholds and analyze the policy to reveal the presence of three operating regions: (1) a region in which development should continue with no system integration, (2) a region in which system integration occurs if a threshold fault count has been exceeded, and (3) a region in which system integration should always take place. Analytical and numerical results demonstrate how the fault thresholds change with system complexity, team skill, development environment, and project schedule. We also show how learning that occurs during each round of system integration leads to less frequent integration in the future, and lower total construction effort. Simulation experiments reveal that the fault threshold policy can be applied even if several homogeneity assumptions in the model are relaxed, allowing for differences in the propensity among modules to accumulate faults and the effort needed to correct these faults. Finally, the fault threshold policy outperforms a fixed-release policy in which system integration occurs whenever a fixed number of modules has been released.

Accuracy of aggregate data in distributed project settings

“…As shown later, the applicability of our solution is dependent on how "accurate" are the project-status data. Chiang and Mookerjee [2004] present a management policy in which the appearance of software faults during system construction is used to determine the timing of system integration activities. In this article we address the impact of accurate project data on the optimal management of project resources needed to enable integration.…”

A Genetic Algorithm Approach for Optimal Allocation of Software Testing Effort

“…In their paper, the authors developed an SRGM incorporating time delay not only between the two phases but also through the segregation of resources between them and proposed two alternate methods for controlling the testing effort for achieving the preferred reliability or error detection level. Chiang and Mookerjee [5] discussed a development process in which system integration occurs when the number of errors in the system will achieve a certain threshold. Chang [3] proposed the sequential software release policy based on a state space model, considering a Gamma-Gamma-type invariant conditional distribution to define the state space model.…”

Project failureen masse: a study of loose budgetary control in ISD projects

“…Many others have noted the inconsistency and ambiguity associated with the term (Merchant, 1985;Merchant, 1998), none more so than Rathe (1960) who identified 57 variants at a time when management control was said to be a relatively simple concept. The importance of effective project control has been highlighted, both in general (Cicmil, 1997;Avison et al, 2001;Rozenes et al, 2006), and specifically in ISD projects (Henderson & Lee, 1992;Kirsch, 1997;Whittaker, 1999;Schmit et al, 2001;Kirsch et al, 2002;Choudhury & Sabherwal, 2003;Chiang & Mookerjee, 2004;Chow & Cao, 2008), and has been shown to 'play a major role as the cause of project failures' (De Falco & Macchiaroli, 1998).…”

“…Various studies have found that between 40 and 60% of ISD projects fails to meet budget estimates and that the degree of overspend can exceed 200% (Whittaker, 1999;Keil et al, 2000;Robey & Keil, 2001;Chiang & Mookerjee, 2004;Goldfinch, 2007;Bartis & Mitev, 2008). There is no reason to suggest that this trend is improving.…”