INF3708 – Software Project Management
Chapter 5
Software effort estimation
5.1 Introduction
A successful project is one delivered ‘on time, within budget and with the required quality’.
Some of the difficulties of estimating arise from the complexity and invisibility of software. Also, the
intensely human activities which make up system development cannot be treated in a purely
mechanistic way.
Subjective nature of estimating – For example, some research shows that people tend to
underestimate the difficulty of small tasks and over-estimate that of large ones.
Political implications – Different groups within an organization have different objectives.
Changing technology – Where technologies change rapidly, it is difficult to use the experience
of previous projects on new ones.
Lack of homogeneity of project experience – Even where technologies have not changed,
knowledge about typical task duration may not be easily transferred from one project to
another because of other differences between projects.
5.2 Where are estimates done?
Estimates are carried out at various stages of a software for a variety of reasons.
Strategic planning – Project portfolio management involves estimating the costs and benefits of
new applications in order to allocate priority. Such estimates may also influence the scale of
development staff recruitment.
Feasibility study – This confirms that the benefits of the potential system will justify the costs.
System specification – Most system development methodologies usefully distinguish between
the definition of the users’ requirements and the design which shows how those are to be
fulfilled. The effort needed to implement different design proposals will need to be estimated.
Estimates at the design stage will also confirm that the feasibility study is still valid.
Evaluation of suppliers’ ’proposals – In the case of the lOE annual maintenance Contracts
subsystem, for example, lOE might consider putting development out to tender. Potential
contractors would scrutinize the system specification and produce estimates as the basis of their
bids.
Project planning – As the planning and implementation of the project becomes more detailed,
more estimates of smaller work components will be made.
5.3 Problems with over-and under-estimates
A project leader will need to be aware that an over-estimate may cause the project to take longer than it
would otherwise.
This can be explained by the application of two ‘laws’.
• Parkinson’ Law ‘Work expands to fill the time available’ – that is, given an easy target staff will
work less hard.
• Brooks’ Law – The effort of implementing a project will go up disproportionately with the
number of staff assigned to the project.
Chapter 5
Software effort estimation
5.1 Introduction
A successful project is one delivered ‘on time, within budget and with the required quality’.
Some of the difficulties of estimating arise from the complexity and invisibility of software. Also, the
intensely human activities which make up system development cannot be treated in a purely
mechanistic way.
Subjective nature of estimating – For example, some research shows that people tend to
underestimate the difficulty of small tasks and over-estimate that of large ones.
Political implications – Different groups within an organization have different objectives.
Changing technology – Where technologies change rapidly, it is difficult to use the experience
of previous projects on new ones.
Lack of homogeneity of project experience – Even where technologies have not changed,
knowledge about typical task duration may not be easily transferred from one project to
another because of other differences between projects.
5.2 Where are estimates done?
Estimates are carried out at various stages of a software for a variety of reasons.
Strategic planning – Project portfolio management involves estimating the costs and benefits of
new applications in order to allocate priority. Such estimates may also influence the scale of
development staff recruitment.
Feasibility study – This confirms that the benefits of the potential system will justify the costs.
System specification – Most system development methodologies usefully distinguish between
the definition of the users’ requirements and the design which shows how those are to be
fulfilled. The effort needed to implement different design proposals will need to be estimated.
Estimates at the design stage will also confirm that the feasibility study is still valid.
Evaluation of suppliers’ ’proposals – In the case of the lOE annual maintenance Contracts
subsystem, for example, lOE might consider putting development out to tender. Potential
contractors would scrutinize the system specification and produce estimates as the basis of their
bids.
Project planning – As the planning and implementation of the project becomes more detailed,
more estimates of smaller work components will be made.
5.3 Problems with over-and under-estimates
A project leader will need to be aware that an over-estimate may cause the project to take longer than it
would otherwise.
This can be explained by the application of two ‘laws’.
• Parkinson’ Law ‘Work expands to fill the time available’ – that is, given an easy target staff will
work less hard.
• Brooks’ Law – The effort of implementing a project will go up disproportionately with the
number of staff assigned to the project.
