程序代写代做代考 assembly algorithm finance Java c++ assembler 17spm_L11

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.