ALGORITHMIC COST MODELS


To date most work carried out in the software cost estimation field has focused on algorithmic cost modelling. In this process costs are analysed using mathematical formulae linking costs or inputs with metrics to produce an estimated output. The formulae used in a formal model arise from the analysis of historical data. The accuracy of the model can be improved by calibrating the model to your specific development environment, which basically involves adjusting the weightings of the metrics. There are a variety of different models available, the best known are Boehm's COCOMO [BOEHM-81], Putman's SLIM, and Albrecht's' function points [ALBR-83]. On an initial instinct you might expect formal models to be advantageous for their 'off-the-shelf' qualities, but after close observation this is regarded as a disadvantage by cost estimators due to the additional overhead of calibrating the system to the local circumstances. However, the more time spent calibrating a formal model the more accurate the cost estimate should be. A distinct disadvantage of formal models is the inconsistency of estimates, [KEMERER] conducted a study indicating that estimates varied from as much as 85 - 610 % between predicated and actual values. Calibration of the model can improve these figures, However, formal models still produce errors of 50-100%.

In terms of the estimation process , nearly all algorithmic models deviate from the classical view of the cost estimation process.

Figure 1. Classical view of the algorithmic cost estimation process


An input requirement of an algorithmic model is to provide a metric to measure the size of the finished system. Typically lines of source code are used, this is obviously not known at the start of the project. SLOC is also very dependant on the programming language and programming environment, this is difficult to determine at an early stage in the problem especially as requirements are likely to be sketchy. Despite this SLOC has been the most widely used size metric in the past, but current trends indicate that it is fast becoming less stable. This is probably due to the changes in software development process in recent years highlighted with a tendency to use prototyping, case tools and so forth. An alternative is to use function points proposed by [ALBRECHT], which are related to the functionality of the software rather than its size. A more recent approach is to use object points. This is in comparison a new methodology and has not been publicised in the same depth as function points and SLOC. In essence the method is very similar to function points but counts objects instead of functions. Its recent rise has been prompted by the interest in the object orientation revolution.

Algorithmic models generally provide direct estimates of effort or duration. As shown in figure 1 the main input is usually a prediction of software size. Effort prediction models take the general form :

effort = p*S

(1/productivity rate)

where p is a productivity constant and S is the size of the system.

Once the value for p is known. E.g. productivity = 450 source lines of code per month, making p = 0.0022 and the size of the system has been estimated at 8500 KLOC.

 

effort = 0.0022 * 8500

effort = 18.7 person moths

 

The example above assumes that the relationship between effort and size is a linear one. Most models allow for non-linear relationships by introducing economies or dis-economies of scale. The general formula being:

effort = p * Se

A study published by [WALSTON & FELIX] which consisted of 60 projects at IBM federal systems division concluded that effort could be modelled as :

effort = 5.2 KLOC 0.91

This is an example of economies of scale. As the exponent 0.91 is less than 1. Walston and Felix observed the following results:

Table 1.0

Effort (PM)

Size(KLOC)

KLOC/PM

42.27

79.42

182.84

343.56

2792.57

10

20

50

100

1000

0.24

0.25

0.27

0.29

0.36

These findings indicate that there is greater productivity when building large software systems as opposed to small systems. However, the results can be justified as it is expected that larger teams can specialise and the overheads are of a relatively fixed size.

A publication by [BANKER & KEMERER] discuss the existence of either economies and diseconomies of scale, for more information about this I strongly recommend reading this paper.