17spm_L11
Cost Estimation
SPM 2017 © Ron Poet Lecture 11 1
Introduction
Difficult
� Cost estimation is notoriously difficult.
o Academic: what is a reasonable length summer project
� Many projects run over budget and are delivered late.
� We have to estimate the costs at the start of the process, when things
SPM 2017 © Ron Poet Lecture 11 2
are most uncertain.
� The total amount of time is called the effort. It is the sum of all the
time spent on the project.
� Elapsed time is the time between the start of the project and the
delivery date.
� There will be a minimum elapsed time that cannot be shortened by
adding more people.
Example
� If the estimate of the effort is 30 worker-months and the elapsed time
is 1 year, then on average 2.5 people are working on the project.
o 2.5 x 12 = 30.
� The elapsed time is important because this is when the customer is
expecting to receive the product.
SPM 2017 © Ron Poet Lecture 11 3
expecting to receive the product.
o They will have made other plans based on this delivery date.
� If the project takes more effort then expected, say 60 worker-months
then increase the effort to 5 people working on the project on average.
(But see later)
How Long is a Worker – Month?
� This will be roughly 20 working days, after holidays have been taken
into account.
� There will be 8 working hours in each day.
� BUT, not all of these hours will be productive!
o Time is spent in meeting, answering emails etc.
� Only about 4 hours per working day will be spent in productive work.
� Early cost estimates assumed 8 hours of productive work per day,
leading to project overruns of about a factor 2.
o No management style is able to improve on a long term average of
4 hours per day.
SPM 2017 © Ron Poet Lecture 11 4
Developer Cost
� The cost of a developer is more than just their salary.
� Add in the cost of the office space, hardware and software.
� Add in the cost of non-productive workers: secretaries, cleaners, HR,
finance, management etc.
SPM 2017 © Ron Poet Lecture 11 5
o They are non-productive in the sense that they do not produce any
software.
o They are essential to the functioning of the organisation.
� This is called the burdened cost, or full economic costing.
Some Statistics
� The average project exceeds its budget by 90%.
� The average elapsed time is exceeded by 120%.
� Over 30% of project are cancelled before completion.
� Cost estimation is difficult!
SPM 2017 © Ron Poet Lecture 11 6
� This is partly caused by tendering for contracts.
� A low cost project will be preferred over one that is costed accurately.
� Caused by customers assuming all projects will bid low.
Divide and Conquer
� Estimate the cost of the whole project by estimating the costs of all the
components.
o The manufacturing cost of a car is the cost of the engine, gearbox,
etc, plus assembly cost.
� How far do we sub-divide?
SPM 2017 © Ron Poet Lecture 11 7
� How far do we sub-divide?
o If we include very small components then rounding errors will be a
significant part of the final sum.
� Make sure we do not miss anything.
� Make sure that we include integration costs.
Include All Activities
� Don’t forget experiments, prototypes etc.
� Don’t forget time spent with customers.
� Don’t forget management (team leader) activities.
� Don’t forget writing documentation, training users etc.
SPM 2017 © Ron Poet Lecture 11 8
Use Past Experience
� Predict the future by analogy with the past.
� Divide and conquer will help.
o The project as a whole may be unique but components will be
similar to other components.
SPM 2017 © Ron Poet Lecture 11 9
� Approach 1: use the judgement of experts in your team.
o Good if your experts have worked on similar projects.
� Approach 2: use an algorithm based on past industry experience.
o Good for new projects but may be too general.
o It is hard to get reliable industry data.
Algorithms
� A typical algorithm is a formula of the form:
o E = a + bNc
� Where E is the effort, N is some measure of the ‘size’ of the code and
a, b, c are constants.
SPM 2017 © Ron Poet Lecture 11 10
� The exponent c is typically not 1, leading to non-linear effects.
� If c < 1 then we have economies of scale. If we double the ‘size’ of the code, the extra effort is less than twice as much. � Unfortunately, c > 1 in most software production.
� a includes the fixed costs which have to be paid even if N = 0.
COCOMO II
� Constructive Cost Model, version II, is a well know algorithm with the
above formula.
� A typical value of c is 1.26.
o Bigger projects require proportionally more effort.
SPM 2017 © Ron Poet Lecture 11 11
� N can be
o Lines of code (LOC)
o Number of classes
o Number of use cases.
o Number of distinct requirements.
Function Point Analysis
� This is a more complicated way of estimating the ‘size’ N before it is
plugged into the a, b, c formula.
� There are several different measures of ‘size’, rather than just one.
o They are called features.
SPM 2017 © Ron Poet Lecture 11 12
� The total size N is the weighted sum of the feature counts.
o Some features are more important than others, so they have higher
weights.
� N = W1F1 + W2F2 + W3F3 + …
Differences From Past Projects
� We must consider differences between projects when extrapolating
from the actual costs of past projects.
� Different levels of software development skills.
o A much quoted industry figure is that the best developers are 10
times as efficient as the worst.
SPM 2017 © Ron Poet Lecture 11 13
times as efficient as the worst.
� Different development processes.
� Different maturity of the development team.
� Different types of customers and users.
o Is the customer involved, are users involved?
Differences (2)
� Different scheduling demands.
� If a project is under a lot of pressure, it may cut corners and work less
efficiently, taking longer.
o Continually pulling all-nighters to meet an unrealistic deadline.
SPM 2017 © Ron Poet Lecture 11 14
o Also does not work well for exam preparation!
� But some pressure is necessary.
Differences (3)
� Some technology is harder to work with than others.
� Some programming languages are more productive than others.
o Assembler is unproductive but leads to fast code.
o Java is reasonably productive, but gives you the power to shoot
SPM 2017 © Ron Poet Lecture 11 15
o
yourself in the foot.
o C++ can be very productive with an experienced and careful
developer, but you can blow your whole leg off if you are not
careful.
Differences (4)
� Different technical complexity of the requirements.
� This should be taken into account in the COCOMO II and Function
Point Analysis formulae.
� There are other factors that are harder to count
SPM 2017 © Ron Poet Lecture 11 16
o Needs greater reliability.
o Is distributed.
o Different levels of requirement stability.
� “Not everything that counts can be counted. Not everything that can
be counted counts.”
Contingency Planning
� The main cost estimation can be called the “Happy Day Scenario”.
o Everything goes according to plan.
o The ‘project planning’ use case!
� Be aware of all the things that might go wrong.
SPM 2017 © Ron Poet Lecture 11 17
o Experienced staff leave, new staff disappoint.
o Work out contingency plans.
� Some things will go better than planned, but this will not cause you
problems!
o Make optimistic, likely and pessimistic estimates.
Independent Estimates
� Using more than one technique to estimate the costs will give you
some idea of the uncertainty involved.
o One estimates based on experts opinions.
o One estimate based on COCOMO II.
SPM 2017 © Ron Poet Lecture 11 18
� If they broadly agree, you can be fairly confident.
� If they differ by a large amount then you need to find out why.
Continuous Cost Estimation
� Requirements change as a project progresses.
� The same is true of cost estimates.
� The more we work on the project, the more we know what we really
have to do.
SPM 2017 © Ron Poet Lecture 11 19
� Continually adjust the cost estimate.
� If our estimate keeps rising, we can add developers early and avoid
experiencing Brooks Law first hand.
� Do not keep reporting that the project is on time and on budget until a
week before delivery date and then announce it will be ‘slightly late’ at
every meeting for the next year.