Estimating and Costing

1
Estimating and Costing
Rick Dewar (and Brian Palmer)
2
Aims of Topic

• The group project did not have to take account of
  real costs, and estimates were probably
  guestimates.
• This topic will address those missing components
• estimating how long things will take
• calculating how much things will cost

3
Learning Objectives

• Discuss and apply COCOMO and Albrecht Function
  Point Analysis to software estimation.
• Explain issues pertaining to project evaluation
  in terms of strategic, technical and economic
  criteria.
• Appraise projects by applying cash flow, return
  on investment, payback and decision tree
  techniques, as well as evaluating risk.

4
PM Revision

• You should now know about
• WBS (work breakdown structure) CBS (cost
  breakdown structure)
• Gantt Charts
• PERT charts
• Resource Planning
• Slack/Float Critical Path
• These are just some tools that support management
  of the project lifecycle.

5
Big bits missing...

• Initial Idea Feasibility Study
• Evaluating Risk
• Estimating Task Durations
• Justifying the Project
• Executing the Project
• Winding Up
• Supporting the Deliverables

Project Life-Cycle
6
Software Estimation

• It is difficult to estimate how long a
  programming task might take.
• Yet we need to estimate to give our customers a
  clue about TCQ (time cost quality).
• Programming is a creative act, not a repeatable
  manual skill.
• If programming were simply repetition then wed
  probably just cut and paste, call a function, use
  an API, etc. Or we'd get computers to write our
  programs for us.

7
Quotes from Lord Kelvin (1824-1907)

• To measure is to know.
• If you can not measure it, you can not improve it.

8
More quotes from Lord Kelvin

• X-rays will prove to be a hoax
• Radio has no future
• I can state flatly that heavier than air flying
  machines are impossible (1895)
• There is nothing new to be discovered in physics
  now (1900)

9
Quote from Albert Einstein

• Not everything that can be counted counts, and
  not everything that counts can be counted

10
Software Estimation - Need for historical data

• Nearly all estimating methods need information
  about how projects have been implemented in the
  past
• Care needs to be taken in applying these data to
  the estimator's own circumstances, because of
  potential differences in environmental factors
  (e.g. programming languages used, standards
  enforced, experience of staff, organisational
  model)

11
Software Estimation Measure of work

• It is not normally possible to calculate directly
  the actual cost or time required to implement a
  project. The time taken to write a program may
  vary according to the competence or experience of
  the programmer. Implementation time may also vary
  because of environmental factors such as the
  software tools available
• The usual practice is to express the work content
  of the system to be implemented independently of
  effort, using a measure such as source lines of
  code (SLOC) or thousands of lines of code (KLOC)

12
About lines of code as an indicator

• SLOC is very imprecise. Do you include comments
  or data declarations?
• It is also very difficult to use for modern 4th
  generation languages which often use tables or
  diagrams to record programming rules, or CASE
  tools/IDEs with code generation facilities.
  Different measures of size are needed, such as
  function points, which we will discuss later.

13
Code complexity

• Given that 2 programs have the same length, it
  does not follow that each would take the same
  amount of time to write, even if done by the same
  programmer in the same environment. One may be
  more complex.
• Because of this, SLOC estimates have to be
  modified to take complexity into account, but it
  is difficult to find objective measures of
  complexity and estimates often depend on the
  subjective view of the estimator. Objective, as
  we know, is good and reliable subjective is bad
  and unreliable.

14
Estimation Methods

• Can generally be divided into bottom-up and
  top-down approaches.
• Bottom-Up estimation involves dividing the
  project into its constituent tasks (Work
  Breakdown Schedule/Structure) until you get to
  activities that can be executed by a single
  person in a week or two of effort, then
  calculating the effort for each of these
  activities and summing them to produce an overall
  estimate
• better for use in the later stages of projects
• use in early stages will involve assumptions
  about characteristics of finished system

15
Top-Down Estimating

• This is normally associated with parametric
  models, where the costs associated with the
  development of a project are determined by a
  standard formula, incorporating parameters
  describing variables associated with the
  characteristics of the final system
• model will normally be one or more formulae of
  the form
• effort (parameter value) x constant
• once the overall effort is calculated, it is
  allocated to individual activities within the
  project
• quite often top-down and bottom-up models will be
  used in concert

16
COCOMO

• Parametric model
• Boehms COnstructive COst MOdel
• Originally based on a study of 63 projects
• Based around the formula p c(kdsi)k
• where p person months, kdsi thousands of
  delivered source instructions, and c and k are
  constants
• Looks mathematical and, as such, of course,
  reliable
• We first need to estimate the kdsi

17
Cocomo constants

• the constants c and k can be determined from the
  table below according to whether the project can
  be classified as
• Organic - relatively small team developing
  software in a highly-familiar in-house
  environment, the system under development being
  small with flexible interface requirements
• Embedded - product being developed has to operate
  within very tight constraints, changes to the
  system are very costly
• Semi-detached - combines elements of the organic
  and embedded, or has characteristics which fall
  between the two

18
A Cocomo calculation

• A project requiring 20,000 lines of code,
  developed in Semi-detached mode will take
• p 3.0(20)1.12 3.0 x 28.652 85.956 person
  months, precisely
• All these numbers look precise (and should please
  Lord Kelvin) but the kdsi is a guess, and the
  constants are empirical approximations.

19
Basic Cocomo too simple

• Boehm found his Basic Cocomo to be a poor
  predictor of effort required. In other words, it
  didn't work.
• He still thought it was on the right lines, and
  went on to develop Intermediate Cocomo
• a nominal estimate for effort (pnom) is developed
  using Basic Cocomo
• the nominal estimate is then adjusted by a
  development effort multiplier (dem)
• (pest) (pnom) x (dem)

20
Factors in dem (more guessing)

• required software reliability
• data base size
• product complexity
• execution time constraints
• main storage constraints
• virtual machine volatility
• computer turnaround time
• analyst capability

• application experience
• programmer capability
• virtual machine experience
• programming language experience
• use of modern programming practices
• use of software tools
• required development schedule

21
Alternatives to Cocomo

• Expert Judgement
• Price to win and Design to Cost
• Estimating by analogy
• Albrecht Function Point Analysis, which we shall
  look at next

22
Albrecht Function Point Analysis

• This is based on the argument that computer-based
  information systems comprise five major
  components (or external user types)
• external input types
• external output types
• logical internal file types
• external interface file types
• external enquiry types

23
More guesswork

• The user calculates the number of each of these
  types in the system and weights them according to
  a table of values similar to the Cocomo model, to
  calculate the information processing size of the
  project
• This figure is adjusted by a technical complexity
  adjustment (TCA) based on 14 factors which can
  influence technical complexity
• It is suggested that 106 lines of Cobol, 150
  lines of C or 64 lines of Basic are needed to
  implement a function point

24
OO Metrics

• Cocomo and function point analysis are not well
  suited to OO designs.
• Various metrics have been suggested, but little
  work has been carried out to validate them.
• At the moment, these metrics concentrate on
  assessing achieved systems.

25
OO Metrics

• Candidate metrics to measure size, complexity
  and quality
• Numbers/ratios of classes and methods
• Depth of inheritance/number of children
• Coupling and cohesion
• Attribute/method hiding
• Polymorphism

26
Web Metrics

• Unusual in that there may be multiple languages
• JavaScript - client-side
• Perl/Java - server side
• Middleware - between legacy and Web applications.
• And multiple specialisms
• OO versus procedural programmers
• Graphic designers
• Architects looking at middleware, capacity
  planning, security, protocols
• Little formal consideration of all this yet.

27
Project Evaluation

• Once we have estimates of time, which might allow
  us to calculate some costs, we need to be able to
  assess the project against competing ideas,
  benchmarks and proposals.
• Let us consider a mini case study (caselet).

28
Widower Life Caselet

• One of the UK's largest life assurance,
  investment and pensions companies.
• Established in the early nineteenth century, it
  has 100 billion of funds under management and
  employs 3,000 people.
• Handles pensions for one million people and life
  assurance for further one million.

29
Widower Life Caselet

• Multi-channel sales capability, utilising
  independent financial advisers, a direct sales
  team and the branch network of a leading UK bank

30
Widower Life Caselet

• The company classifies development projects into
  one of three categories
• Discretionary - lowest priority and can only
  proceed if they can produce a return on
  investment (typically within two years) and if
  the necessary resources are available
• Strategic - Strategic projects have a higher
  priority and are those that directly support the
  company's strategic goals - for instance entry
  into a new market or improving a brand image.
  Expected returns on such investments are often
  allowed to take longer (perhaps five or more
  years) than for discretionary projects.
• Essential - carry the highest priority and are
  those projects that must go ahead for the company
  to continue to trade. For instance, if the UK
  government changed tax rates, the company's
  systems must be amended to comply with this by a
  certain date. Another example has been Y2K.

31
Widower Life Caselet

• Within each category, projects can be
• small costs less than 20k,
• medium costs less than 250k
• large.
• Various factors (including size) determine
  whether a project rates high, medium or low in
  respect of risk and in respect of complexity.
• Payback and RoI (Return on Investment) also help
  the company assess competing projects.

32
Project Evaluation

• The appropriate selection of projects to
  undertake based on
• strategic criteria
• technical criteria
• economic criteria
• Techniques used in Project Evaluation normally
  comprise
• cost-benefit evaluation techniques to choose
  between competing project proposals
• risk evaluation techniques for cost minimisation
• Well see these later

33

• Strategic Assessment
• The development of the information system is
  assessed against the organisations strategic
  plan
• Objectives
• does the system contribute to organisational
  objectives?
• improved productivity/market share
• Information System Plan
• does the proposed system fit into an overall IS
  Plan?
• which existing systems does it replace/improve/aff
  ect?
• legacy issues?
• is it future-compatible with planned later
  developments?
• Organisational Structure
• will the new system have impact on departmental
  or organisational structure?
• will new functionality overlap/replace/affect
  existing, especially management and control,
  structures?

34

• Strategic Assessment
• Management Information System
• what information will the system provide/need and
  at what levels in the organisation?
• will it complement or enhance existing management
  information systems?
• Personnel
• how will the proposed system affect staffing
  levels and the existing employee skill-base?
• what implications are there for organisational
  policy on staff development?
• Image
• how will the proposed system affect
  customer/supplier attitudes to the organisation?

35

• Strategic Assessment
• Third party developers must also carry out
  strategic and operational assessments of project
  proposals, to determine whether taking on a
  project conflicts with their own strategic plans.
• Where a well-defined information systems strategy
  does not exist, system development and the
  assessment of project proposals are likely to be
  based on a more piecemeal approach. In such cases
  it is likely that economic assessment will have
  more bearing on the outcome of the proposal.

36

• Technical Assessment
• evaluate the required functionality against the
  hardware and software available.
• Where an organisation has a strategic information
  systems plan this is likely to place limitations
  on the nature of the solutions that might be
  considered.
• The cost of the solution, incorporating any
  constraints imposed by strategic plans, will also
  influence the economic assessment.
• ? if project re-scoped, what are technical
  consequences?

37

• Economic Assessment
• The most common way of carrying out an economic
  assessment of a proposed information system, or
  other development, is by comparing the expected
  costs of the development and the operation of the
  system with the benefits of having it in place.
• Assessment is based upon the question of whether
  the estimated costs are exceeded by the estimated
  income and other benefits.

38

• Economic Assessment
• The standard way of evaluating the economic
  benefits of any project is to carry out a
  cost-benefit analysis, which consists of two
  steps
• (1) Identifying and estimating all of the costs
  and benefits of carrying out the project
• development costs
• operating costs
• new equipment costs
• technical costs
• training and back-fill
• cost of capital
• efficiency benefits
• increased sales/productivity benefits
• organisational benefits
• tangible and intangible benefits...

39

• Economic Assessment
• (2) Expressing these costs and benefits in common
  units
• We must evaluate the net benefit, which is the
  difference between the total benefit and total
  cost.
• Development Costs - salaries and other employment
  costs of the staff involved in the development
  project and all associated costs.
• Setup Costs - costs of putting system in place,
  include new hardware, ancillary equipment, file
  conversion, recruitment, staff training, etc.
• Operational Costs - costs of operating the new
  system, to be offset against the costs of the
  existing system.

40

• Economic Assessment
• Benefits are often quite difficult to quantify in
  monetary terms even once they have been
  identified. They can be categorised as
• Direct Benefits - accrue directly from the
  operation of the new system, could include
  reduction in salary bill.
• Assessable indirect benefits - secondary
  benefits, could include increased accuracy of
  data input/error reduction resulting in cost
  reduction.
• Intangible Benefits - generally longer term,
  difficult to quantify, for example increased
  staff job interest and/or satisfaction may lead
  to reduced staff turnover and thereby lower
  recruitment costs. Or, improved customer
  perception and brand awareness. Or, preparedness
  for future projects.

41

• Any project that shows an excess of benefits over
  costs is clearly worth considering for
  implementation. However, this is not the full
  picture. We may not be able to afford the costs
  there may be better or less risky projects.
• Cash Flow Forecasting
• As important as estimating the overall costs and
  benefits of a project is the forecasting of the
  cash flows that will take place and their timing.
  A cash flow forecast will indicate when
  expenditure and income will take place.
• Accurate cash flow forecasting is not easy as it
  generally needs to be done early in the projects
  life-cycle and many items to be estimated may be
  some years in the future.
• When estimating future cash flows it is usual to
  ignore the effects of inflation.

42

• Cost-Benefit Evaluation Techniques
• Net Profit
• Difference between total costs and total profit
  over the life of a project.
• Payback Period
• The time taken for a project to break even or pay
  back the initial investment.
• Normally a project with a shorter payback period
  will be selected on the basis that an
  organisation wishes to minimise the period that
  it is in debt.
• Advantages - simple to calculate, not sensitive
  to small forecasting errors.
• Disadvantages - ignores overall profitability of
  project once it has broken even.

43

• Cost-Benefit Evaluation Techniques
• Return on Investment (ROI)
• Also known as the accounting rate of return (ARR)
• ROI (average annual profit/total investment)
  100
• Advantages - simple, easy to calculate
• Disadvantages - takes no account of timing of
  cash flows, not directly comparable to bank
  interest rates, can be sensitive to errors in
  predictions.

44
Simple Cash Flow Forecast

• We can use this table to illustrate Payback and
  Return on Investment (RoI).

45
Return on Investment

• One measure of RoI is Net Present Value (NPV).
• This is a project evaluation technique that takes
  into account the profitability of a project and
  the timing of the cash flows that are produced
• based on the principal that 100 today is worth
  more than 100 in x years time
• the difference is calculated by discounting the
  value at an appropriate interest rate
• present value value in year t/(1discount
  rate)t
• NPV is obtained by discounting each cash flow,
  both negative and positive, and summing the
  discounted values.

46

• The higher the NPV, the more viable the project.
• Allows comparison with other options and projects
• The main problem with using NPV for project
  selection is selecting an appropriate discount
  rate. This can be achieved by
• organisational standard rate
• current interest rates and borrowing costs
• use discount rate as target rate of return

47
Payback Period

• Use the discounted accumulated cash flow to
  determine when the project breaks even (pays
  back).
• Calculate graphically or via linear
  interpolation.
• Answer Payback 2.7 years after project start!

48

• Internal Rate of Return (IRR)
• IRR discount rate to give zero NPV.
• The higher the IRR, the more viable the project.

49

• IRR
• a project showing an estimate IRR of 10 would be
  worthwhile if the capital could be borrowed for
  less than 10 or if the capital could not be
  invested elsewhere for a return of greater than
  10
• One deficiency of IRR is that it does not
  indicate the size of the return, thus a project
  with a NPV of 100,000 and an IRR of 15 may be
  more attractive than a project with a NPV of
  10,000 and IRR of 38.
• Therefore, mixed methods and thresholds are often
  used.

50
Decision Trees

• This cost-benefit analysis approach will result
  in a set of cash flow forecasts, each with an
  associated probability of occurring. The value of
  the project is then calculated by summing the
  cost or benefit for each possible outcome,
  weighted by its probability

51

• Decision Trees
• essentially about risk management (which weve
  talked about already).
• Decision trees allow us to consider the effects
  of taking action to overcome risks in terms of
  the future profitability of the project.
• If we consider the following scenario
• a company wishes to decide whether to extend
  their existing invoicing system or replace it
  altogether, this decision largely resting on the
  rate at which the business expands
• their main competitor is rumoured to be bankrupt,
  so market share may increase significantly,
  requiring the replacement of the existing system
  within 2 years. Not replacing the system in time
  will mean lost revenue through inability to
  handle invoicing demand. Replacing it
  immediately, however, will be expensive as it
  will mean canceling other, already scheduled,
  projects.

52

• The calculation is that extending the existing
  system will have a NPV of 75,000, although this
  becomes a loss with NPV of -100,000 if the
  market expands significantly.
• If the market does expand, replacing the system
  has a NPV of 250,000 due to the benefits of
  being able to handle increased sales and better
  management information. However, if the sales
  dont increase the benefits will be greatly
  reduced, resulting in a NPV of -50,000

NPV ()
Expansion
0.2
-100,000
Extend
No Expansion
75,000
0.8
D
Expansion
0.2
250,000
Replace
-50,000
0.8
No Expansion
53

• the company estimate the likelihood of the market
  increasing significantly at 20, hence the
  likelihood of no significant increase is 80
• from the decision tree shown on the previous
  slide we can calculate the expected benefit of
  each path that might be taken, which is
  calculated by the sum of the value of each
  possible outcome multiplied by its probability
• so we can calculate that the expected value of
  extending the existing system is (75,000 x 0.8 -
  100,000 x 0.2) 40,000
• set against this is the expected value of
  replacing the existing system (250,000 x 0.2 -
  50,000 x 0.8) 10,000
• one of the great advantages of using decision
  trees is the ease with which they can be extended
  to introduce further decision points
• So the decision is..

54
EXTEND!!!!
NPV ()
Expansion
0.2
-100,000
Extend (40,000)
75,000
No Expansion
0.8
D
0.2
250,000
Expansion
Replace (10,000)
-50,000
0.8
No Expansion
55
Conclusions

• So weve
• estimated project effort
• jumped through the strategic, technical and
  economic hoops
• with respect to economics, done cost-benefit
  analysis
• weve even managed some risk along the way.
• If the project is funded it might just succeed!