Key points are not available for this paper at this time.
This 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.
Chiang et al. (Mon,) studied this question.
Synapse has enriched 5 closely related papers on similar clinical questions. Consider them for comparative context: