1

COST ESTIMATION

Basics, COCOMO, FP

2

What is estimated?

• TIME <=> MONEY• TIME:

– duration, chronological weeks, months, years

– effort, person-month (man-month)– unit is typically month (year)

3

Basic Relation

• person-month / nbr-of-people = duration• example:

– 36 person-month, 1 developer, 36 month– 36 person-month, 2 people, 18 month– 36 person-month, 12 people, 3 month

• Beware of the “million monkey” syndrome [Brooks]

4

Basic Principles - Decomposition

• It is easier to estimate time & cost for a smaller unit than to estimate time & cost for the complete system.

• Estimation by decomposition:– Decompose your system or development

process, estimate time & cost for the parts and summarize.

5

Basic Principles - Empirical Knowledge

• Find parameters which characterise your system and derive time & cost based on a documented case history.

• Empirical model: time = function

(parameters)• You rely on a correlation between time & cost and

the set of independent parameters

6

Typical Parameters

• number and complexity of functions• number and complexity of modules• number of lines of code (LOCS)• number and duration of steps in your

development process• skills and technologies involved

7

When to do your estimate

• the later the more accurate your parameters• early estimate:

– you need to estimate your parameters– divide an conquer strategy– garbage in => garbage out

• keep your estimate up-to-date

8

COCOMO [B. Boehm]

• COnstructive COst MOdel• empirical method• hierarchy of COCOMO models (parameters)

– basic: prg size– intermediate: prg size & cost drivers– advanced: prg size & cost drivers per phase

Cost Drivers: Personnel/Team Capability, Product Complexity, Req. Reliability, Problem Domain Experience, Development practices, Tools, Language Experience, etc.

• for each project type

9

COCOMO - Parameters

• prg size: LOCS (lines of code)• “cost drivers”

• evaluate: product, hardware, personnel, project

• measured on a 6 point scale• allow for derivation of an EAF

(Effort Adjustment Factor)

10

COCOMO - Project Types• organic mode:

– relatively small and simple– small team of skilled developers

• semi-detached:– intermediate in size and complexity– mixed skill levels on the team

• embedded:– hard constraints for HW, SW, operation

11

Basic COCOMO - The Functions

person-month = a*(KLOC)b

duration-in-month = c*(person-month)d

KLOC ... kilo lines of code

a, b, c, d depend on the project type

12

Basic COCOMO - Tables

project type: a b c d

organic 2.4 1.05 2.5 0.38semi-detached 3.0 1.12 2.5 0.35embedded 3.6 1.20 2.5 0.32

13

Basic Cocomo - Example

• You must decide on:– LOCS: 50,000 lines of code– project type: semi-detached

• person-month: 3.0*(50)1.12 ~ 240• duration-in-month: 2.5*(240)0.35 ~ 17• number of people: 240 / 17 ~ 14

14

Function Points (FP)• Based on the number and complexity of the system functions

to be delivered to the customer• Steps:

– (1) Categorize the functions according to type (input, output, database, interface, etc.) and complexity (simple, moderate, average, complex, highly complex)

– (2) Derive the number of function points: multiply the number of functions in each category by the appropriate complexity weights and total the number of PF

– (3) Determine the total Project Influence Factors (PIF): PIF types (distributed processing,multiple development

sites, etc.), and levels of difficulty ( from 0-no difficulty, to 3-average difficulty, to 5- great difficulty)

– (4) Compute the Total Effort: PM = .036 * FP * PIF

15

FP: Example(1&2) PF

(3) PIF

(4) Total Effort

Function Diff. Level Number Complexity FP

InputDBOutput

24

4

MA

S

Total

3103

6401258

Total

PIF Difficulty LevelData performance objectives

Multiple sites

2

57

PM = 0.036*58*7 = 14.616

All values from FP tables.

16

Function Points: Evaluation• Tightly coupled with Functional Requirements (see

SRS) - works well with DFDs• Intuitive Method - makes intuitive sense to the

customers• Notice: A rough estimate of the functional

requirements will yield ONLY a very rough estimate of total effort

17

“3 Time Programming” Rule• Estimate the number of software modules/programs and their

complexity• Estimate the effort required to complete coding and debugging

of each module and the total programming effort• Total Project Effort = (Estimated Programming Effort) * 3

This includes Management, Documentation, Design, ….

=> Helpful ONLY to experienced programmers=> Corrects at least the OPTIMISTS

A “Rough Guess” is better than a “Wild Guess” or “No Estimate”

18

It Couldn’t be More Simple: