Estimating Reuse FeasibilityAdd to favorites
New systems often involve significant reuse of various software artifacts (i.e., requirements, design, code, and test data). The percentage of software being proposed for reuse has grown from 20%, to 60%, to 80% or more. Some current embedded systems involve nearly 100% reuse of existing systems and software components. This is not in line with Air Force experience, and the classic estimating approaches that rely on an estimate of the size of the software to be newly developed or modified, adjusted for growth, may not be applicable. 
Experience has shown that actual reuse achieved often falls far short of the reuse expected at the outset of an embedded system development program. Part of this is likely due to the late understanding about what is really required from the reuse software, and part is likely due to the growth in software that must be developed to achieve the full expected functionality, or to interface/integrate the reuse software into the rest of the system.
Another problem with dealing with proposed reuse in early estimates is that for new or modified code, offeror software size is normally inflated at some percentage in accordance with technical risk assessments, to account for the software growth that normally occurs during embedded systems software development. Since there can be little, or in some cases almost zero, code being developed or modified when very high levels of reuse are proposed, this inflation/growth technique breaks down.
An alternate approach for assessing risk and determining potential growth in the amount of software to be developed and modified where there is significant proposed reuse is shown in the figure below. This approach considers a number of attributes to assess the risk that additional software will have to be developed. The size of the assumed new development is based on the size of the software to be reused, as well as evaluator confidence in developers‘ reuse claims. Once the assessment of these attributes has determined the associated risk and growth potential, the growth is applied and the estimate can be adjusted accordingly.
AcqLinks and References:
-  USAF Weapon Systems Software Management Guidebook – Appendix G
- Mil-STD-498 “Software Development and Documentation” – 5 Dec 1994
- MIL-STD-498 “Application and Reference Guidebook” – 3 Jan 1996
- Defense Acquisition Guidebook (DAG) – Chapter 4 & 7
- Software Development Plan Information Outline
- Template: Software Development Plan – SPAWAR
- Website: MIL-STD-498 Software Documentation
- Website: DCMA Software Acquisition Management