Budgetting and cost estimation.ppt

7/28/2019 Budgetting and cost estimation.ppt

1/24

Budgeting and cost estimation

Project Management

Lesson 7


2/24

Fundamental estimation

questions

How much effort is required to

complete an activity?

How much calendar time is needed tocomplete an activity?

What is the total cost of an activity?

Project estimation and scheduling areinterleaved management activities.


3/24

Software cost components

Hardware and software costs.

Travel and training costs.

Effort costs (the dominant factor in mostprojects)

The salaries of engineers involved in theproject;

Social and insurance costs.

Effort costs must take overheads intoaccount

Costs of building, heating, lighting.

Costs of networking and communications.

Costs of shared facilities (e.g library, staffrestaurant, etc.).


4/24

Costing and pricing

Estimates are made to discover the cost, to

the developer, of producing a software

system.

There is not a simple relationship between

the development cost and the price charged

to the customer.

Broader organisational, economic, politicaland business considerations influence the

price charged.


5/24

Software pricing factors

Market

opportunity

A development organisation may quote a low price because it

wishes to move into a new segment of the software market.

Accepting a low profit on one project may give the opportunity

of more profit later. T he experience gained may allow new

products to be developed.

Cost est imate

uncertainty

If an organisation is unsure of its cost estimate, it may increase

its price by some contingency over and above its normal profit .

Contractual terms A c ust omer may be willing to allow the developer to retain

ownership of the source code and reuse it in ot her projects. T he

price charged may then be less than if the software source code

is handed over to the customer.

Requirements

volatility

If the requirements are likely to change, an organisation may

lower its price to win a contract. After the contract is awarded,high prices can be charged for changes to the requirements.

Financial health Developers in financial difficulty may lower their price to gain

a c ontract. It is bet ter to make a smaller than normal profit or

break even than to go out of business.


6/24

A measure of the rate at which individual

engineers involved in software development

produce software and associated

documentation.

Not quality-oriented although quality

assurance is a factor in productivity

assessment.

Essentially, we want to measure useful

functionality produced per time unit.

Software productivity


7/24

Size related measures based on

some output from the software

process. This may be lines ofdelivered source code, object code

instructions, etc.

Function-related measures based on

an estimate of the functionality of the

delivered software. Function-points

are the best known of this type of

measure.

Productivity measures


8/24

Estimating the size of the measure

(e.g. how many function points).

Estimating the total number ofprogrammer

months that have elapsed.

Estimating contractor productivity (e.g.documentation team) and

incorporating this

estimate in overall estimate.

Measurement problems


9/24

What's a line of code?

The measure was first proposed whenprograms were typed on cards with one

line per card; How does this correspond to statements

as in Java which can span several lines orwhere there can be several statements onone line.

What programs should be counted as part ofthe system?

This model assumes that there is a linearrelationship between system size and

volume of documentation.

Lines of code


10/24

Project planning process

Software scope - determination of function andperformance

Resources - estimation of required resources

Project estimation - quantitative analysis of cost and

duration Risk analysis - risk identification, assessment and

solution

Scheduling - production of software development timetables

Decision making - selection of cost-effective designmethods

Organisational planning - organisation of softwareteams


11/24

Software scope and

resources

Scope

Well-bounded specification of software function

Well-bounded specification of interfaces

Well-bounded specification of constraints

Resources

Human resources: selection of skills required forsoftware development

Hardware resources: determination of thedevelopment system, target machine, and otherhardware devices

Software resources: determination of CASE

(computer-aided software engineering) tools


12/24

Project estimation

techniques

Algorithmic cost modelling based on historical

information

Static models such as COCOMO

Dynamic models such as Putnam

Expert judgement based on expert's experience

Estimation by analogy based on similar completed

projects Pricing to win based on availability of customer's

budgets

Bottom-up estimation based on costs of software

components


13/24

Algorithmic cost modelling

Cost is estimated as a mathematicalfunction of product, project and process

attributes The function is derived from a study of

historical costing data

Most commonly used product attribute for

cost estimation is LOC (code size) Most models are basically similar but with

different attribute values


14/24

Values Domain characteristics

Number of user inputs Distinct application-oriented data given to software

Number of user outputs Application-oriented information produced to the userNumber of user inquiries On-line inputs which result in on-line outputs

Number of files Logical master filesNumber of external interfaces All machine-readable interfaces

Estimation of code size

Number of lines of code

Estimation based on source code files

Major advantage: easy measurement based on

programs

Major weakness: programming-language and design-

detail dependencies

Function points

Information domain characteristics and values


15/24

0 1 2 3 4 5no influence incidental moderate average significant essential

Complexity adjustment values

Fi :

1. Does the system require reliablebackup and recovery?

2. Are data communicationsrequired?

3. Are there distributed processingfunctions?

4. Is performance critical?

5. Will the system run in an existing,heavily utilised operationalenvironment?

6. Does the system require on-linedata entry?

7. Does the on-line data entry requireinput transactions to be built over

multiple screens?

8. Are the master files updated on-line?

9. Are the inputs, outputs, files or inquirescomplex?

10. Is the internal processing complex?

11. Is the code designed to be reusable?

12. Are conversion and installation

included in the design?13. Is the system designed for multiple

installations in different organisations?

14. Is the application designed to facilitatechange and ease of use by the user?


16/24

Estimating code size using

function points

Computation of function points

Where wi: weighting factors determined

empirically 0.65 and 0.01: constant values determined

empirically

Weakness and advantage

Subjective assessment of the complexity factors

Early size prediction and language independence

)totalcomplexity01.065.0(totalcountpointsfunction

)numberw(totalcount i

5

1=i

i 14

1=i

iFtotalcomplexity


17/24

Estimation example

Number of user inputs 32 W1 4

Number of user outputs 60 W2 5

Number of user inquiries 24 W3 4

Number of files 8 W4 10

Number of external interfaces 2 W5 7

Count total = (32 x 4) + (60 x 5) + (24 x 4) + (8 x 10) + (2 x 7) = 618

Assume all complexity adjustment values are average

complexity total = 3 x 14 = 42

function points = 618 x (0.65 + (0.01 x 42)) = 661.26

Assume the complexity total = 50

function points = 618 x (0.65 + (0.01 x 50)) = 710.7

Assume assume that one point is 100 lines of C code

Difference = (710.7 661.26) x 100 = 4944 LOC


18/24

COCOMO (COnstructive

COst MOdel)

COCOMO can be applied in threeincreasing sophisticated ways:

Basic COCOMO

a function of program size

Intermediate COCOMO

a function of program size and a set of "costdrivers"

Advanced COCOMO extension of the intermediate model with

regard to the cost driver's impact on eachstep of the software development


19/24

Basic COCOMO

Classes of software projects

Organic mode projects: small teams, familiar

working environment and well understoodapplications

Semi-detached mode projects: teams of

experienced and inexperienced staff, limited

experience of related systems, and unfamiliarity

with some aspects of the systems being

developed

Embedded mode projects: tight hardware,

software, and operational constraints


20/24

Basic COCOMO

yempiricalldeterminedaluesconstant v,wherecodeoflinesthousandofnumberwhere

months-personin)(effortprojectofEstimation

bb

b

b

ba

KLOC

KLOCaE

E

b

05.14.2

ismodelorganictheexample,For

KLOCEorganic

Software project ab bb

organic 2.4 1.05

semi-detached 3.0 1.12embedded 3.6 1.20


21/24

COCOMO estimated effort

0

200

400

600

8001000

1200

1400

1600

0 20 40 60 80 100 120 140KLOC

Effort(PM

)

Organic

Semi-detached

Embedded

Basic COCOMO

Comparison ofthe models

Example:assuming thatan embeddedprojectconsists of128000delivered

sourceinstructions,the projecteffort is

p.m.12161283.6= 1.20 embedded

E


22/24

Basic COCOMO

Software project cb dborganic 2.5 0.38

semi-detached 2.5 0.35

embedded 2.5 0.32

yempiricalldeterminedaluesconstant v,where

monthsin)(t timedevelopmenofEstimation

bb

d

b

dc

EcD

D

b

35.05.2

ismodeldetached-semitheexample,For

EDdetachedsemi


23/24

Basic COCOMO

Development

schedule

Example: the effort

of the embedded

project is 1216 p.m.

people51

24

1216

months2412165.2 32.0

N

Dembedded

Development time

0

5

10

15

20

25

30

0 20 40 60 80 100 120 140

KLOC

Month

s

Semi-detached


24/24

The End

Zainudin Johari

B Sc. (Hons) Computer Science, UPM

M Sc. Computer Science (Information Systems) UPM

Budgetting and cost estimation.ppt

Documents