Reducing software rework via architecture and risk resolution: Analysis of
project defect tracking cost-to-fix data (a major source of rework costs) showed that 20% of the defects accounted for 80% of the rework costs, and that these 20% were primarily due to inadequate architecture definition and risk resolution.
For example, in TRW Project A in Figure 1, most of the rework was the result of
development of the network operating system to a nominal-case architecture, and finding that the systems engineering of the architecture neglected to address the risk that the operating system architecture would not support the project requirements of successful system fail-over if one or more of the processors in the network failed to function.
Once this was discovered during system test, it turned out to be an “architecture-breaker” causing several sources of expensive rework to the alreadydeveloped software. A similar “architecture-breaker,” the requirement to handle extralong messages (over 1 million characters), was the cause of most of the rework in Project B, whose original nominal-case architecture assumed that almost all messages would be short and easy to handle with a fully packet-switched network architecture.
Replaced/Superseded by document(s)
|File||MIME type||Size (KB)||Language||Download|
This paper presents quantitative results on the return on investment of systems engineering (SE-ROI) from an analysis of the 161 software projects in the COCOMO II database. The analysis shows that, after normalizing for the effects of other cost drivers, the cost difference between projects doing a minimal job of software systems engineering – as measured by the thoroughness of its architecture definition and risk resolution – and projects doing a very thorough job was 18% for small projects and 92% for very large software projects as measured in lines of code.