17.4 Estimation of Cost and Duration

There are two approaches to estimating the effort, or cost, and duration for an increment: productivity ratios and cost estimation models. We discuss productivity ratios first, followed by cost estimation models.

PRODUCTIVITY RATIO APPROACH

The productivity ratio approach uses KSLOC per staff month to convert estimated size into effort, as shown in Figure 17-3. If a productivity ratio of 300 SLOC per staff month is used, the estimated effort for one fifth of the estimated RSS system size, 143 KSLOC, is 477 staff months, obtained by dividing the estimated increment size by the productivity ratio.

Figure 17-3. Size/effort/duration relationships

The productivity ratio of 300 SLOC per staff month may seem low. A useful productivity ratio is based on total estimated size for an increment and all the effort used in the increment to get the work done. This means that the productivity ratio should include the life-cycle phases that are common to all increments shown; the labor categories that support the development, such as project management, configuration management, and quality assurance; and designing, programming, and testing labor categories.

The RSS duration can be estimated from the estimated effort by using the relationship between effort and duration shown in Figure 17-3. If an increment is estimated to need 477 staff months of effort, the duration is about 22.5 months, or about 21 staff members .

If an increment is scheduled to be 18 months long, the current estimated duration of 22.5 months is too long. Using our rule-of-thumb that reducing the schedule by a quarter requires doubling the staff means that the schedule can be shorted to 75 percent of 22.5 months, or about 17 months, by adding the extra labor at the appropriate time.

The disadvantage of using the productivity approach is not knowing how to adjust the productivity when unexpected things happen on the project, such as the key designer leaving for personal reasons. Another disadvantage is that this method produces a duration and staffing level for the complete increment only, with no insight into what the duration and staffing is for each phase of the increment. This deficiency is critical because the staffing and duration for an incrementally built system need to increase for the integration and testing phase to account for the extra time required to test the new and legacy software.

COST ESTIMATION MODELS

A more powerful and flexible alternative for estimating cost and duration is to use software-cost estimation models. Cost models provide estimates of effort for the software development phases of requirements, architecture, detailed design, code and unit test, and integration and test. Effort is distributed for the activities of requirements analysis, architecture, programming, testing, verification and validation, project office, configuration management, quality assurance and documentation. The models provide estimates of duration by phases and staffing by phases and activities, as shown in Figure 17-4.

Figure 17-4. Cost model distribution of effort and duration

The size parameter for most cost models is source lines of code. The amounts of new code, reused code with modification, and reused code without modification are used to adjust the estimated effort and duration by accounting for the extra work needed to incorporate and test these various sources of code.

One widely used cost estimation model is the Constructive Cost Model II (COCOMO II). COCOMO II addresses nonsequential process models, reengineering work, and reuse-driven approaches [Boehm 00a]. This model consists of two submodels, each offering increased fidelity the farther along one is in the project planning and design process [COCOMOII 02]. The COCOMO II model provides estimates of effort, schedule by phases, and staffing by phases and activities. Size inputs for COCOMO II are adjusted by an input called requirements evolution, or breakage , to account for new or evolving requirements.

Models can also be adjusted to account for software product, software project, host platform, and personnel factors that affect the software development. Software product factors include architecture and risk resolution, required reliability, product complexity, and database size. Software project factors include process maturity, development flexibility, team cohesion, use of software tools, and multisite development. Host platform factors include host platform volatility, time constraints, and storage constraints. Finally, personnel factors include architect/designer capability, programmer capability, personnel continuity, application experience, host platform experience, and language and tool experience.

Recall that RSS requires experience with the legacy system, messaging, wrappers, adapters, a new implementation language, and design tools. Effort is impacted by the capability of the design, code, test, and documentation tools. Cost models can account for these special needs initially and as they change throughout the life of the project.

The most important feature of a cost model is its ability to account for increases and decreases in staffing because of the schedule compression or expansion. Again, the relationship between effort and schedule is nonlinear. Productivity ratios are for projects that have similar staffing and duration characteristics. The rule-of-thumb adjustment mentioned earlier is not accurate in all situations. Models make it easy to explore what happens when the required number of staff is not available or the required duration is longer than the schedule allocated to an increment.

A word of caution: Cost models need to be calibrated. The data required to calibrate a cost model is the actual developed software size, the staffing profile across the increment phases, and the duration of each phase. Calibration captures the differences in the type of work by changing the estimated effort and duration distribution.

Incremental Testing Cost

The RSS incremental deployment plan requires that a fully functional system be deployed after each increment. A deployable system requires end-to-end testing for quality assurance. The cost of testing includes revalidating the legacy system that is still operational, the code modernized in the current increment, and the previously modernized code.

Testing cost can be estimated by a cost model based on an aggregated size input. The size input consists of the new increment, the sum of the previous increments, and the functioning portion of the legacy system converted into the implementation language, using a conversion ratio. This assumes that code is disabled as it is migrated to the modern system.

The cost of testing for each increment can be prohibitive. These costs can be reduced through the use of automated testing using testing tools or nondeliverable testing software. Automated testing can reduce the cost and duration to regression test previously modernized code and the remaining legacy system. The test suite can be continually expanded to detect the recurrence of previously corrected anomalies.