17.3 Costing an Increment

Estimating the cost of one increment is considered in the context of the cost for multiple increments . Each increment's cost is allocated a portion of the estimated final system size , which essentially establishes a "size budget" for each increment because size is strongly related to effort, which contributes to cost. Size allocations for each RSS increment were determined as part of the consensus profile and are shown in Figure 16-14.

When using an incremental development strategy to build a system, it is important to start follow-on increments at an appropriate time. For example, if the ensuing increment is started prematurely, late changes from the completing increment may have an adverse effect on cost and schedule. Ideally, each increment should start after the previous increment's software development has completed. Figure 17-2 illustrates the RSS incremental development strategy. While an increment's software is undergoing integration and testing, the next increment's software is undergoing an architectural review and detailed design. This minimizes unnecessary rework resulting from unplanned changes from a previous increment. If the overlap is increased, the cost for an increment will increase.

Figure 17-2. Incremental life cycle

The size of the software to be developed depends on the functionality to be implemented (shown in Figure 17-1) and on a growth factor that takes into account the growth of the system because of requirements evolution. The two sources of functionality in RSS are the functionality embedded in the legacy code and the adapters required by the modernization strategy. Even though the adapters are not in the final system, they represent work that is a source of cost.

LEGACY SYSTEM SIZE

The existing system is assumed to be representative of the majority of RSS functionality. One approach to estimating the size for the new system in this situation is to use the legacy system's size as a basis of estimation. The estimate of size for the new system depends on a conversion ratio based on the differences in implementation languages between the legacy and modern systems.

In our case study, the legacy language is COBOL and the target language is Java. A conversion ratio of 1 COBOL SLOC to 0.58 Java SLOC can be used to estimate the new system size. This is based on ratios for converting COBOL and Java into unadjusted function points (UFPs). One UFP is equal to 91 COBOL SLOC or 53 Java SLOC [Boehm 00b]. Dividing the Java ratio by the COBOL ratio gives a ratio of 1 COBOL SLOC to 0.58 Java SLOC.

Increment size depends on the budget available and the amount of functionality to be converted from the legacy system to the new system. A rough estimate of the final size of the system is based on the size of the legacy system, which is about 1,230,300 executable COBOL SLOC. The estimated equivalent new-system size would be about 713,600 Java SLOC. Be mindful that this conversion ratio is based on the conversion ratios of COBOL and Java to UFP. All conversion ratios are averages and have some amount of error when applied in practice. As each increment is completed, data should be collected to update the ratios used to convert size from the legacy system to the new system.

ADAPTERS

Increment size is further increased as a result of the construction of adapters, as described in Section 13.6. Each incremental release of the system creates new adapters and discards existing adapters that are no longer needed. The sum of the sizes for all new adapters to be developed in a given increment must be estimated. Also, if regression testing is required for functionality where adapters have been discarded, a sizing factor may be assigned to this code as well.

One approach for estimating the size of adapters is to build a prototype of representative adapters and measure their sizes. In RSS, we prototyped both a regular adapter and an inverse adapter. These prototypes also provide an opportunity to collect data to estimate a productivity ratio for adapter development.

The size of these prototypes can be used for initial planning until actual data can be collected. It is important to collect size data on each adapter at the end of each increment for each class of adapter used. This data is used to improve the estimate for the next increment.

MAINTENANCE COSTS

In each ensuing increment, the portion of the legacy system that has not yet been replaced , as well as code already modernized, needs to be maintained. Unlike development costs, which occur only once, maintenance costs are recurring. Maintenance costs can also be expected to vary in proportion to the number of lines of code being maintained .

Because they are usually well known, legacy system maintenance costs can be used to estimate the cost of maintaining the recently modernized code. The cost of maintaining the legacy code is determined by dividing legacy system maintenance costs by the legacy code size, producing a cost per KLOC value. This value can then be used to estimate the cost of maintaining the modernized code by multiplying it against the estimated total lines of code to be completed at the end of each increment, including code from the previous increment. This rough estimate needs to be recalibrated using actual maintenance costs. Periodic maintenance costs should be collected and used to refine the model.

GROWTH FACTOR

A final consideration for estimating the size for one increment is a growth factor. A growth factor takes into account the system growth resulting from requirements evolution. There may be some enhancement of business processes as the system is modernized. A growth factor of 25 percent of the new increment's code size is not unreasonable.