The software estimating process consists of a series of activities that include estimating the size of the software to be developed, modified, or reused; applying estimating models and techniques; and analyzing, crosschecking, and reporting the results. The following steps should be considered as part of any Software Size Estimating process: [1]

• Develop a notional architecture for the system, and identify program requirements likely to be satisfied by software.
• Identify potential Commercial off-the-Shelf (COTS), Government off-the-Shelf (CGOTS), and other sources of Non-Developmental Items (NDI) software.
• Identify existing software that will be modified, including the size of the overall software as well as the size of the expected modifications.
• Identify software that will be newly developed for this program to provide functionality not available from existing software, or to adapt/integrate all the necessary software components.
• Obtain software size information for all software elements, where size is carefully defined and measured in one of the two standard software size measures: non-comment Source Lines of Code (SLOC) or function points.
• Assess the uncertainty in the new and modified software sizes, based on historical data (if available) and engineering judgment.
• Assess the uncertainty associated with the reusability of existing software (COTS, GOTS, and NDI) in the context of the program. Estimate the trade studies, familiarization, and the integration and testing efforts required to accommodate the unmodified reused code.
• Account for software complexity and the proposed development approach/processes, and assess any overlaps in software builds.
• Be realistic about expected software productivity and any assumption of significantly higher than historical productivity due to applying the best people, improved/more efficient processes, or new and improved development tools. Past performance, where actual size, cost, and productivity data is available at the same developer facility for the same program or a very analogous program, should be heavily weighted. It is rare to have the A-team people for a long-duration embedded system development, and new processes and tools often fall short of expectations.
• Apply growth factors to new/modified and reuse software, based on past experience and the level of uncertainty.
• Account for all remaining uncertainties as estimate risks (see section 3.2.2).
• Ensure the estimate includes software support to systems engineering, system and sub-system requirements definition, configuration management, quality assurance, program management, system integration, and system test as appropriate.
• Address the software development life-cycle from software requirements analysis through software-related system integration and testing. The chosen modeling/estimation approach may not address the entire software effort since some commercial parametric models focus on the period starting with the baseline set of software requirements and ending with a fully integrated and tested subsystem / functional software product ready for software / hardware integration and test. Estimate and include any additional effort required to develop, allocate, and analyze the subsystem and software requirements; perform software to hardware (subsystem) integration and test; and perform system integration and test.
• Crosscheck estimate results with other methods such as other models, expert advice, rules of thumb, and historical productivity.
• Improve the estimate over time.

AcqTips:

• Analyze similar, past projects to generate the historical data needed to estimate the size of new software projects. Relying on memory is not effective and leads to poor estimates.
• Include data gathered from software and test team members. Early project team involvement, not only serves to improve the accuracy of the estimate, but also prepares the team for the eventual project start date.
• Keep in mind that experience is the key to effective software size estimation. The larger the project, the more experience required to make a good estimate.
• Use multiple estimation techniques. During the initial estimation stage, the comparative results of different estimation techniques provides the best estimate.
• Revise the initial size estimate as new information becomes available. During the design phase as the major software pieces come into focus, each module can be estimated separately, the sum of which reflects a revised, more accurate estimate.

AcqLinks and References:

• [1] USAF Weapons Systems Software Management Guide – Section 3
• SMC Software Acquisition Guidebook – Software Size Estimate
• Chapter 13: Software Estimation, Measurement, and Metrics – GSAM Version 3.0
• Software Size Estimation Challenges by Larry Putnam, Sr. of Quantitative Software Management, Inc.
• Software Estimation – Appendix C
  

Updated: 8/6/2021