The development phases that are most directly affected by adopting a reusable software architecture are the design and system integration and test phases. The adoption of a reusable product architecture should also lead to greatly enhanced reuse and/or automatic generation of source code, and standard document outlines and documentation procedures. Where a common understanding of product line requirements (often called a domain model) exists among your customer base, reuse can occur in the requirements phase as well. An architecture-based approach can thus address 80-90% or more of the development activities.
Typically about 70% of the total life cycle cost of software occurs after initial acquisition. Much of this is functional enhancement and product upgrade rather than defect removal. A product that has a reusable and easily modified software architecture, coupled with tools to automate product reconfiguration, is significantly easier to upgrade. A software product over its lifetime resembles a family of products, namely the sequence of upgraded releases, which is exactly the situation in which a reusable software architecture can achieve significant benefits. We will assume that maintenance activities are roughly comparable to development activities in the tools and techniques used, and that an architecture-based approach thus addresses 80-90% or more of the overall life cycle effort.
Where either reuse or automation can be applied to a particular task, experiences that exhibit aspects of this technology suggest the results can be dramatic, reducing the effort required for that task by factors of 2 to 10 or more.
However, estimates based on automation and reuse alone fail to take into account other important savings. Our approach also leads to significant reductions in defects and rework. Our approach also leads to improvements in other activities beyond those traditionally associated with the software development process and less duplication of effort.
The figures below do not show how much of the effort expended during development is devoted to significant redesign or rework. The fact that most maintenance effort is devoted to significant product enhancements and upgrades is suggestive, however. Providing accurate and early analysis, and a capability to easily reconfigure a system, can significantly reduce redevelopment effort. Common folklore is that many large software products end up being built twice, and specific examples of duplicate effort can be found in product development efforts. There should be significant effort reductions due to doing it once and getting it right the first time.
Our multi-disciplinary approach achieves savings in development steps that may not normally be thought of as part of the software development process. For example, software development often starts with a requirements specification provided by the control or systems engineers, and much time and effort are expended interpreting and responding to changes in this document. These specifications are commonly implemented once for simulation purposes, a second time for the flight software, and often a third time for a real-time testbed or training simulation. In our approach, the software development process is more tightly integrated into the overall systems engineering process, and savings can be achieved during systems engineering as well as software engineering activities. (Our approach addresses the system design and software requirements phases in the AGARD data shown below.)
Although these effects have not been as well quantified through study as the effects of reuse and automation, we feel an additional factor of 2 reduction in effort in all phases of the life cycle should be achievable due to eliminating rework and addressing a broader range of the system life cycle effort.
Applying a factor of improvement of 2 to all life cycle phases due to the elimination of rework, then an additional factor of improvement of 2 to 10 to the 80-90% of the life cycle that automation and reuse can be applied to, yields an estimated overall factor of improvement of about 3 to 10.
Concept Definition 5% Development 20%
System Design 12% Installation 5%
Software Requirements 14% Defect Removal 2%
Software Design 15% Enhancement 58%
Coding 10% Functional Redesign 15%
Software Unit Test 12%
Integration Test 7%
System Test 10%
Documentation 15%
From AGARD Advisory Report 292
Requirements Analysis 6% Annual Maintenance Cost=
Preliminary Design 8% 10-35% of Acquisition Cost
Detailed Design 16%
Implementation 45%
System Testing 20%
Acceptance Testing 5%
From NASA Manager's Handbook for Software Development
Requirements Analysis 4% Development 30%
Prototyping 3% Maintenance 70%
Requirements Tracing 4%
Design 12%
Coding and Unit Test 15%
Integration and Test 14%
Documentation 15%
Configuration Management 5%
Management 15%
Other 12%
From DoD Software Technology Strategy