Budgeting and cost estimation

Project Management

BTECH 2007

Lesson 7

Fundamental estimation questions

How much effort is required to complete an activity?

How much calendar time is needed to complete an activity?

What is the total cost of an activity? Project estimation and scheduling are

interleaved management activities.

Software cost components Hardware and software costs. Travel and training costs. Effort costs (the dominant factor in most

projects) The salaries of engineers involved in the

project; Social and insurance costs.

Effort costs must take overheads into account Costs of building, heating, lighting. Costs of networking and communications. Costs of shared facilities (e.g library, staff

restaurant, etc.).

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, political and business considerations influence the price charged.

Software pricing factors

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

Size related measures based on some output from the software process. This may be lines of delivered 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

Estimating the size of the measure (e.g. how many function points).

Estimating the total number of programmer months that have elapsed.

Estimating contractor productivity (e.g. documentation team) and incorporating this estimate in overall estimate.

Measurement problems

What's a line of code? The measure was first proposed when

programs were typed on cards with one line per card;

How does this correspond to statements as in Java which can span several lines or where there can be several statements on one line.

What programs should be counted as part of the system?

This model assumes that there is a linear relationship between system size and volume of documentation.

Lines of code

Project planning process Software scope - determination of function and

performance 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

time tables Decision making - selection of cost-effective design

methods Organisational planning - organisation of software

teams

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 for

software development Hardware resources: determination of the development

system, target machine, and other hardware devices Software resources: determination of CASE (computer-

aided software engineering) tools

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

Algorithmic cost modelling

Cost is estimated as a mathematical function 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

Values Domain characteristicsNumber of user inputsDistinct application-oriented data given to softwareNumber of user outputsApplication-oriented information produced to the userNumber of user inquiriesOn-line inputs which result in on-line outputsNumber of files Logical master filesNumber of external interfacesAll 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

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

Complexity adjustment values

Fi :1. Does the system require reliable

backup and recovery?2. Are data communications required?3. Are there distributed processing

functions?4. Is performance critical?5. Will the system run in an existing,

heavily utilised operational environment?

6. Does the system require on-line data entry?

7. Does the on-line data entry require input transactions to be built over multiple screens?

8. Are the master files updated on-line?9. Are the inputs, outputs, files or inquires

complex?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 facilitate

change and ease of use by the user?

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=ii

14

1=iiFtotalcomplexity

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 = 42function 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

COCOMO (COnstructive COst MOdel) COCOMO can be applied in three increasing

sophisticated ways: Basic COCOMO

a function of program size Intermediate COCOMO

a function of program size and a set of "cost drivers"

Advanced COCOMO extension of the intermediate model with regard

to the cost driver's impact on each step of the software development

Basic COCOMO

Classes of software projects Organic mode projects: small teams, familiar

working environment and well understood applications

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

Basic COCOMO

yempiricall determined aluesconstant v, wherecode of lines thousandofnumber where

months-personin )(effort project of Estimation

bb

bb

baKLOC

KLOCaE

Eb

05.14.2

is model organic theexample,For

KLOCEorganic

Software project ab bb

organic 2.4 1.05semi-detached 3.0 1.12embedded 3.6 1.20

COCOMO estimated effort

0

200

400

600

800

1000

1200

1400

1600

0 20 40 60 80 100 120 140KLOC

Effo

rt (P

M)

Organic

Semi-detached

Embedded

Basic COCOMO

Comparison of the models

Example: assuming that an embedded project consists of 128000 delivered source instructions, the project effort is p.m. 1216 1283.6 = 1.20 embeddedE

Basic COCOMO

Software project cb db

organic 2.5 0.38semi-detached 2.5 0.35embedded 2.5 0.32

yempiricall determined aluesconstant v, where

monthsin )( t timedevelopmen of Estimation

bb

db

dcEcD

Db

35.05.2

is model detached-semi theexample,For

ED detachedsemi

Basic COCOMO

Development schedule

Example: the effort of the embedded project is 1216 p.m.

people 5124

1216months 2412165.2 32.0

N

Dembedded

Development time

0

5

10

15

20

25

30

0 20 40 60 80 100 120 140

KLOC

Mon

ths

Semi-detached

The End

Zainudin Johari

B Sc. (Hons) Computer Science, UPM

M Sc. Computer Science (Information Systems) UPM