17.2 Cost Estimation Overview

Cost estimation is based on the simple premise that the more work to be done, the more it will cost. Figure 17-1 shows how project cost is estimated, based on the amount of work associated with developing functionality and the cost of other development tasks .

Figure 17-1. Converting work into cost and duration

FUNCTION-BASED ESTIMATION

The top path in Figure 17-1 shows that overall cost is proportional to the functionality to be developed. This functionality could be new, reused, or replaced . In RSS, almost all the functionality required for the modernized system exists in the legacy system. The work effort to be estimated includes analysis and coding to migrate the functionality from the legacy system to the new system. Replacement, unlike refactoring, also includes redesign and reimplementation.

Functionality can be quantified in various ways. Useful measures of functionality include the number of requirements, function points, ^[1] use cases, and scenarios. Functionality can be used to estimate the size of the software system in lines of code. For example, an organization may determine that one function point is equivalent to 89 source lines of code based on either published sources of conversion ratios or its own historical data.

^[1] The function-point metric is a means of measuring software size and productivity and uses functional, logical entities, such as inputs, outputs, and inquiries, that tend to relate more closely to the functions performed by the software as compared to other measures, such as lines of code.

Many cost estimation models use source lines of code (SLOC) as the software size measure. Design measures, such as design and user interface components , can also be used to estimate source lines of code. The estimated SLOC for business rules and data manipulation algorithms must be estimated from the functionality. In RSS, the size estimate must also account for the cost of developing scaffolding and other intermediate products that are a consequence of the modernization approach.

Function-based cost estimation is possible because software size strongly correlates to the effort expended to produce it. Based on this observed relationship, size estimates can be used to estimate effort. This relationship is expressed as a productivity ratio: staff months per thousands of source lines of code (KSLOC). The accuracy of the effort estimate depends on the accuracy of the size estimate and the productivity ratio. For RSS, no such productivity ratio was available. Hence, data needed to be collected to establish a productivity ratio.

Effort expresses how much labor is required over a period of time to produce required functionality. Effort is a derived measure that factors the number of people working and the time period over which they worked. Effort is expressed as staff hours, staff weeks, or staff months.

Estimated effort is converted to cost by multiplying the number of staff months by the cost of a staff month, that is, the cost of one person working full time for one month. The cost is an average of the cost of each labor category used on the project for one month. Additional fidelity can be added by categorizing effort estimates into labor categories and applying a monthly cost for each category.

Effort can generally be converted into a staffing profile, given the available duration, or converted into the duration needed, given the available staffing. Imagine two projects require the same effort to develop a software product but finish at different times. The reason may be that one project had a large number of staff and took less time to finish. The other project had fewer staff and took longer to finish. Effort, expressed as staff months, represents a staff/time quantity. Reduce one and you need more of the other.

Many projects want to reduce the project duration, or the time it takes to complete the project. This is called schedule compression and generally requires adding staff. The relationship between duration and staffing is not linear. Generally, the schedule can be reduced by 25 percent ”generally the maximum compression possible ”if the staff is doubled . For example, a project requiring 30 person months of effort can be reduced in duration from 10 months to 7.5 months if the staffing is increased from 3 to 6 people, an increase in effort from 30 staff months to 45 staff months.

Factors other than size can influence the effort required to develop software. These factors include the ability of the people working on the project, the development environment, characteristics of the software product, and the host platform. These factors increase or decrease the effort required to produce the software and are used to adjust the productivity ratio.

TASK-BASED ESTIMATION

Another way to estimate effort is to identify development tasks and estimate the effort required for each, as indicated by the bottom path in Figure 17-1. In many cases, such as project management and QA, the support tasks are included as part of the productivity ratio rather than separately estimated tasks. Task-based estimation is used when the tasks do not produce any software ”for example, the migration of data in RSS ”and are not already accounted for as overhead in the productivity ratio. The cost of developing functionality is combined with the cost of these additional development tasks to form the RSS project cost estimate.