Software projects face a unique set of challenges when it comes to scope estimating and this is especially true for new software developments. Research has found that poor cost and schedule estimates are much more detrimental to software projects than any other problem. Typically, estimates are based on historical project information and/or expert opinion, which can be more of an art than a science. The author, William Roetzheim, suggests a more systematic approach to planning estimates for new software projects using research-based techniques.
Based on his experience with software projects, Roetzheim suggests companies take an approach similar to that found in the PMBOK when it comes to life cycle cost estimating accuracies. Initial estimations should be within +/- 50% of the actual cost and the budget should continue to be refined as the project’s requirements are more fully understood.
The first step to estimate scope is to determine metric used as a measure of scope. In software there are numerous options, but the most common is the number of source lines of code (SLOC), which is the number lines of code written by humans and is usually given as thousands of SLOC (KSLOC).
To determine the number SLOC, you can use one of two options: the direct estimating approach and the function points (FPs) with backfiring approach. Using the direct estimating approach, you break the project down into modules and use multiple expert opinions to estimate the number SLOC’s per module. This is called a Program Evaluating and Reviewing Technique (PERT) calculation and is done by obtaining optimistic, pessimistic, and most likely values. The most likely value is weighted times 4 and the mean and standard deviation are calculated and used to create an estimate with a high level of accuracy.
The FPs with backfiring approach uses the estimate of the number of logical internal tables and external inputs, outputs, interface files, and queries to estimate the number of ways the program must interact with the users. Then you multiply the raw data by its FP conversation factor to fund the number of FPs.
Then using backfiring you convert the FPs to SLOC using the function point for the applicable language.
Once you have estimated the number of KSLOC, you take that number and multiply it by the effort required per KSLOC to find the estimate for the project. Researchers have come up with estimates for the effort required per KSLOC based upon different project types. For smaller projects, you would multiply the number of KSLOC by the productivity factor of the applicable project time to find the number of person-months the project requires.
Since research has found that large projects tend to be less productive due to increased time spent communicating and coordinating, you must apply a penalty factor to the above calculation for larger projects. The calculation for the larger project would then = Productivity Factor * KSLOC^Penalty Factor.
The author argues that the calculation above will deliver a reliable person-months estimate feeds into the project’s schedule and budget and that it should continue to be managed as the project moves forward in its lifecycle.
While the author’s presents his methods for estimating scope for a software project, he does make any recommendations on how to utilize them. If your company conducts software projects, does it use SLOC when estimating? Is there a specific process used to calculate time requirements and how does it compare to the process suggested by the author?
Roetzheim, W. (2005) Estimating and Managing Project Scope for New Development. Journal of Defense Software Engineering, 4-7.
