Using Software Non-Functional Assessment Process to Complement Function Points for Software Maintenance

Context: Most widely used cost models use source lines of code (SLOC) as the software size input measure, due to its quantifiability and high correlation with effort. Estimating the SLOC of a project is very difficult in early stages of the software lifecycle, especially for software maintenance tasks. Depending on the reuse model being used, one would need to size the existing code that needs modifications and the size of the changes being made in SLOC. Functional size measures, such as Function Points (FPs) and the Software Non-functional Assessment Process (SNAP), have been developed to improve the ability to estimate project size early in the lifecycle for both development and maintenance projects. While FPs represent software size by functions; SNAP complements FPs by sizing non-functional requirements, such as data operations and interface design. Goal: SNAP complements Function Points by sizing non-functional requirements, such as data operations and interface design. Through an empirical analysis, the authors want to determine whether SNAP might be an effective software size measure individually or in conjunction with FPs to improve effort estimation accuracy. Method: The empirical analysis will be run on Unified Code Count (UCC)'s dataset, a software tool maintained by University of Southern California (USC). Results: The analyses found that separating projects adding new functions from those modifying existing functions resulted in improved estimation models using SNAP. The effort estimation model for projects modifying functions in UCC had high prediction accuracy statistics, but less impressive results for projects adding existing functions to UCC. The effort estimation accuracy were satisfactory when using SNAP in conjunction with FPs for both groups of projects. Conclusions: SNAP, indeed, complements FPs in terms of the requirements that are considered and sized. Both size metrics should be treated as individual metrics, but can be used together for acceptably accurate cost models in UCC's development environment.