4.1.1 Top-Down Estimation Approach

Although the effort for a project is a function of many parameters, it is generally agreed that the primary factor that controls the effort is the size of the project. That is, the larger the project, the greater is the effort requirement. The topdown approach utilizes this and considers effort as a function of project size. Note that to use this approach, we need to first determine the nature of the function, and then to apply the function, we need to estimate the size of the project for which effort is to be estimated.

If past productivity on similar projects is known, then it can be used as the estimation function to determine effort from the size. If productivity is P KLOC/PM, then the effort estimate for the project will be SIZE/P personmonths. Note that as productivity itself depends on the size of the project (larger projects often have lower productivity), this approach can work only if the size and type of the project are similar to the set of projects from which the productivity P was obtained (and that in the new project a similar productivity can be obtained by following a process similar to what was used in earlier projects).

A more general function for determining effort from size that is commonly used is of the form:

EFFORT = a * SIZE^b,

where a and b are constants [2], and project size is generally in KLOC (size could also be in another size measure called function points which can be determined from requirements). Values for these constants for an organization are determined through regression analysis, which is applied to data about the projects that have been performed in the past. For example, Watson and Felix [81] analyzed the data of more than 60 projects done at IBM Federal Systems Division, ranging from 4000 to 467,000 lines of delivered source code, and found that if the SIZE estimate is in thousands of delivered lines of code (KLOC), the total effort, E, in person-months (PM) can be given by the equation E = 5.2(SIZE).91. In the COnstructive COst MOdel (COCOMO) [12, 13], for the initial estimate (also called nominal estimate) the equation for an organic project is E = 3.9(SIZE)^.91.

Though size is the primary factor affecting cost, other factors also have some effect. In the COCOMO model, after determining the initial estimate, some other factors are incorporated for obtaining the final estimate. To do this, COCOMO uses a set of 15 different attributes of a project called cost driver attributes. Examples of the attributes are required software reliability, product complexity, analyst capability, application experience, use of modern tools, and required development schedule. Each cost driver has a rating scale, and for each rating, a multiplying factor is provided. For example, for the reliability, the rating scale is very low, low, nominal, high, and very high; the multiplying factors for these ratings are .75, .88, 1.00, 1.15, and 1.40, respectively. So, if the reliability requirement for the project is judged to be low, then the multiplying factor is .75, while if it is judged to be very high, the factor is 1.40. The attributes and their multiplying factors for different ratings are shown in Table 4.1 [12, 13].

Table 4.1 Effort Multipliers for different cost drivers

The multiplying factors for all 15 cost drivers are multiplied to get the effort adjustment factor (EAF). The final effort estimate, E, is obtained by multiplying the initial estimate by the EAF. In other words, adjustment is made to the size-based estimate using the rating for these 15 different factors.

As an example, consider a system being built for supporting auctions in a university (some of the use cases of this were discussed in the previous chapter). From the use cases and other requirements, it is decided that the system will comprise a few different modules. The modules and their expected sizes are:

Login 200 LOC
Payment 200 LOC
Administrator interface 600 LOC
Seller functions 200 LOC
Buyer functions 500 LOC
View and bookkeeping 300 LOC
TOTAL 2000 LOC

The total size of this software is estimated to be 2 KLOC. If we want to use COCOMO for estimation, we should estimate the value of the different cost drivers. Suppose we expect that the complexity of the system is high, the programmer capability is low, and the application experience of the team is low. All other factors have a nominal rating. From these, the effort adjustment factor (EAF) is

EAF = 1.15 * 1.17 * 1.13 = 1.52.

The initial effort estimate for the project is obtained from the relevant equations. We have

Ei = 3.9 * 2^.91 = 7.3 PM.

Using the EAF, the adjusted effort estimate is

E = 1.52 * 7.3 = 11.1 PM.

From the overall estimate, estimates of the effort required for the different phases in the projects can also be determined. This is generally done by usingan effort distribution among phases. The percentage of total effort spent in a phase varies with the type and size of the project, and can be obtained from data of similar projects in the past. A general distribution of effort among different phases was discussed in the previous chapter. The effort distribution suggested by COCOMO for one type of software systems is given in Table 4.2.

Table 4.2: Phasewise distribution of effort

It should be noted that to use the top-down approach for estimation, even if we have a suitable function, we need to have an estimate of the project size. In other words, we have replaced the problem of effort estimation by size estimation. One may then ask, why not directly do effort estimation rather than size estimation? The answer is that size estimation is often easier than direct effort estimation. This is mainly due to the fact that the system size can be estimated from the sizes of its components (which is often easier to do) by adding the size estimates of all the components. Similar property does not hold for effort estimation, as effort for developing a system is not the sum of effort for developing the components (as additional effort is needed for integration and other such activities when building a system from developed components).

Clearly for top-down estimation to work well, it is important that good estimates for the size of the software be obtained. There is no known “simple” method for estimating the size accurately. When estimating software size, the best way may be to get as much detail as possible about the software to be developed and to be aware of our biases when estimating the size of the various components. By obtaining details and using them for size estimation, the estimates are likely to be closer to the actual size of the final software.