Software effort estimation techniques

Barry Boehm, in his classic work on software effort models, identified the main ways of deriving estimates of software development effort as:

• algorithmic models - which use 'effort drivers' representing characteristics of the target system and the implementation environment to predict effort;

• expert judgement - where the advice of knowledgeable staff is solicited;

• analogy - where a similar, completed, project is identified and its actual effort is used as a basis for the new project;

• Parkinson - which identifies the staff effort available to do a project and uses that as the 'estimate';

• price to win - where the 'estimate' is a figure that appears to be sufficiently low to win a contract;

• top-down - where an overall estimate is formulated for the whole project and is then broken down into the effort required for component tasks;

• bottom-up - where component tasks are identified and sized and these individual estimates are aggregated.

Clearly, the 'Parkinson' method is not really an effort prediction method, but a method of setting the scope of a project. Similarly, 'price to win' is a way of deciding a price and not a prediction method. On these grounds, Boehm rejects them as prediction techniques although they might have some value as management techniques. There is, for example, a perfectly acceptable engineering practice of 'design to cost' which is one example of the broader approach of 'design by objectives'.

We will now look at some of these techniques more closely. First we will examine the difference between top-down and bottom-up estimating.

See B. W. Boehm 'Software Engineering Economics' in C. F. Kemerer (ed.) Software Project Management, Irwin, 1997.

Bottom-up estimating

Estimating methods can be generally divided into bottom-up and top-down approaches. With the bottom-up approach, the estimator breaks the project into its component tasks and then estimates how much effort will be required to carry out each task. With a large project, the process of breaking down into tasks would be a repetitive one: each task would be analysed into its component sub-tasks and these in turn would be further analysed. This is repeated until you get to components that can be executed by a single person in about a week or two. The reader might wonder why this is not called a top-down approach: after all you are starting from the top and working down! Although this top-down analysis is an essential precursor to bottom-up estimating, it is really a separate one - that of producing a Work Breakdown Structure (WBS). The bottom-up part comes in adding up the calculated effort for each activity to get an overall estimate.

The bottom-up approach is most appropriate at the later, more detailed, stages of project planning. If this method is used early on in the project cycle then the estimator will have to make some assumptions about the characteristics of the final system, for example the number and size of software modules. These will be working assumptions that imply no commitment when it comes to the actual design of the system.

Where a project is completely novel or there is no historical data available, the estimator would be well advised to use the bottom-up approach.

Exercise 5.2 Brigette at Brightmouth College has been told that there is a requirement, now that the payroll system has been successfully installed, to create a subsystem that analyses the staffing costs for each course. Details of the pay that each member of staff receives can be obtained from the payroll standing data. The number of hours that each member of staff spends teaching on each course can be obtained from standing files in a computer-based time-tabling system.

What tasks would have to be undertaken to implement this requirement? Try to identify tasks that would take one person about 1 or 2 weeks.

Which tasks are the ones whose durations are most difficult to estimate?

The top-down approach and parametric models

The top-down approach is normally associated with parametric (or algorithmic) models. These may be explained using the analogy of estimating the cost of rebuilding a house. This would be of practical concern to a house-owner who needs sufficient insurance cover to allow for rebuilding the property if it were destroyed. Unless the house-owner happens to be in the building trade it is unlikely that he or she would be able to work out how many bricklayer-hours, how many carpenter-hours, electrician-hours and so on would be required. Insurance companies, however, produce convenient tables where the house-owner can find an estimate of rebuilding costs based on such parameters as the number of storeys and the floor space that a house has. This is a simple parametric model.

The effort needed to implement a project will be related mainly to variables associated with characteristics of the final system. The form of the parametric model will normally be one or more formulae in the form:

effort = (system size) x (productivity rate)

For example, system size might be in the form 'thousands of lines of code' (KLOC) and the productivity rate 40 days per KLOC. The values to be used will often be matters of subjective judgement.

A model to forecast software development effort therefore has two key components. The first is a method of assessing the size of the software development task to be undertaken. The second assesses the rate of work at which the task can be done. For example, Amanda at IOE might estimate that the first software module to be constructed is 2 KLOC. She might then judge that if Kate undertook the development of the code, with her expertise she could work at a rate of 40 days per KLOC and complete the work in 2 x 40 days, that is, 80 days, while Ken, who is less experienced, would need 55 days per KLOC and take 2 x 55 that is, 110 days to complete the task.

Some parametric models, such as that implied by function points, are focused on system or task size, while others, such are COCOMO, are more concerned with productivity factors.

Having calculated the overall effort required, the problem is then to allocate proportions of that effort to the various activities within that project.

The top-down and bottom-up approaches are not mutually exclusive. Project managers will probably try to get a number of different estimates from different people using different methods. Some parts of an overall estimate could be derived using a top-down approach while other parts could be calculated using a bottom-up method.

At the earlier stages of a project, the top-down approach would tend to be used, while at later stages the bottom-up approach might be preferred.

Students on a course are required to produce a written report on an IT-related topic Exercise 5.3 each semester. If you wanted to create a model to estimate how long it should take a student to complete such an assignment, what measure of work content would you use? Some reports might be more difficult to produce than others: what factors might affect the degree of difficulty?

Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook

Post a comment