Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 1 4/19/2003 Day...

Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, 4/19/2003

Day 2, Part 2 Estimating Software Effort &

Cost Section 1 – Fundamental Issues


Outline

• Measures of Effort• Inputs to the Effort Estimate• Effort Estimation Steps• Estimation based on Historical

Productivity• Wideband Delphi for Effort

Estimation• Bottom Up Estimating


The Overall Planning Cycle

AnalyzeJob

Manage Risks

Execute

GenerateDetailed Plans

GenerateInitial Plans

Measure, Manage Productivity and Quality


Detailed Planning - Processes

EstimateSize

EstimateEffort and

Cost

EstimateSchedule

Evaluate

Source InformationStatement of Work

RequirementsConstraintsStandardsProcesses

Historyetc.

WBS Size

Effort &

Cost

Schedule

OKCompleteDetailedPlanning

Revise &Negotiate

Not OK


Measures of Effort


Effort Is ...… the amount of labor required for the

project• It is typically measured in staff-

months, staff-days or staff-hours A month (or calendar-month) is a

measure of time A staff-month is a measure of effort

If three people complete a job in 1 calendar-month, it is a 1 calendar-month job that requires 3 staff-months of

effort

If three people complete a job in 1 calendar-month, it is a 1 calendar-month job that requires 3 staff-months of

effort


Effort Is Not Defined Precisely

• There are no generally accepted, precise definitions for terms like staff-month or staff-day

• And people are known to “fudge” the definitions in their own favor


Two Executives on the Golf Course

We do 50 LOC per staff month - you do only

40!

How do you measure staff

months?


Staff-Hours, Staff-Days, or Staff-Months

• There are many ways to measure these• And these three are NOT necessarily

related in a simple manner• Because of this, comparisons can be

very misleading

Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 2, Part 2, 4/19/2003

How Many Hours per Day?

• 1 staff-hour = 1 person working for 1 hour

• 1 staff-day = 1 person working for 1 day

• How many staff-hours per staff-day?– 7? 7.5? 8.0? 8.5? 9.5? ???– How do you handle paid overtime?– How do you handle unpaid overtime?– How do you handle breaks, lunch hours,

etc.?


• How many productive staff-days per staff-month?– 30? 21? 19? ???– Does it depend on

which month?

The underlined value is the default assumed by many U.S. companies and

many estimating models (this value allows for average number of vacation days and

holidays in the U.S.)

The underlined value is the default assumed by many U.S. companies and

many estimating models (this value allows for average number of vacation days and

holidays in the U.S.)

How Many Days per Month?


How Many Hours per Month?

144? 148? 152? 160? 175? 184? ???Factors that can affect this:

– Which month is it?– What is the length of the work day?– How do you handle overtime?– Vacations and holidays– Sick days– What country you are in?– How do you allocate management overhead


Linesof code

per staff

month

Objects Tested

per staff hour

Consistency is the Most Important Factor

• If you measure effort consistently, you can understand what it costs, compare different projects, and predict future performance


Consistency Allows Reasonable Comparisons With

Past History

• Like software size, there are many ways to measure effort and many arguments why each is good or bad

• You cannot make meaningful evaluations if each project measures effort differently


Projects Often Hide Actual Effort Data

• You cannot tell what really happened on a previous project if you don’t know how they measured effort

How many

hours did you

really spend?

We don’t know - we

didn’t count unpaid

overtime


• There tend to be fewer variations in how a staff-hour is measured

• But many organizations use staff-months -- so you need to know how to convert properly in your organization

Measure Hours if you Can


The Relationship Between Time and Effort


What Does a “Staff-month” Mean?

• If it requires 12 staff-months, does this mean– 12 people for 1 month? – 1 person for 12 months? – 3 people for 4 months?– does it depend on the people?

• Too often, scheduling and estimating tools make the assumption that all of these are equivalent


vs

How Flexible is a Staff-Month?

• There is some flexibility, but only so much

• Brooks (see references: “The Mythical Man-Month”) explored this issue in considerable detail


Cost of Adding More People

CC = (N * (N-1))/2Where ...N = Number of peopleCC = Communication

Complexity (extra overhead of managing N people)

Brooks’ Equation for Intercommunication Effort

0

20

40

60

80

100

120

1 3 5 7 9 11 13 15

People

Management

Overhead


You Cannot Just AllocatePeople Arbitrarily

staff-days

required to do the

work

Calendar Time Allocated for the Work

Optimal Schedule

COCOMO MODEL OF TIME VS EFFORT


The Optimal ScheduleDepends on Many Factors

• Process, people, nature of task, tools, management approach, environment, …

• Different cost estimating models make different assumptions about these matters and how they affect the results


• Until we have a better theoretical foundation, the only way to determine the optimal is through experience

• The various estimating models represent the experience of their originators and thus may predict different “optimal” schedules

Your Experience Counts More Than Any Model


Your Actual High Level Schedule May be Determined

by Other Factors• In early planning, your project’s

overall goals and milestones may define constraints

• Product deadlines may determine schedule dates

• Reviews may have to occur at times convenient to others– Customers– Managers


Compare the Actual and the Optimal Schedule to Gauge

the Schedule Risk• If the optimal is significantly different

from the actual, you have schedule compression, which means a significant expectation of – increased cost, and – schedule risk

Optimal vs. actual schedule information may help you determine cost impact (see

“cost drivers,” later in this part)

Optimal vs. actual schedule information may help you determine cost impact (see

“cost drivers,” later in this part)


Typical Inputs to the Effort Estimate


Tasks to be Performed Are a Major Input to Effort Estimation• Typically these are found in the WBS

– Software development tasks (design, code, test)

– Additional development tasks (requirements, system integration)

– Support tasks (CM, QA, management)– Tasks requiring additional labor

(documents, audits, etc.)– Additional dollar costs (travel,

equipment, etc)


Other Inputs to Effort Estimate

• Estimated software size • Historical data on effort & productivity• High level schedule• Process and methods• Programming language• Operating system for target system• Tools to be used• Staff experience level


Effort Estimating Steps

1) Summarize and document the requirements for each task– Basis of estimate

– WBS dictionary

2) Quantify the magnitude of each task– Size & complexity for software

– # of pages, # of trips, # of whatever for other things


Effort Estimating Steps

3) Estimate effort for software development tasks

4) Estimate again with an alternative method

5) Resolve discrepancies between the two methods (repeat from step 1, as required)

6) Add effort estimates for other tasks (such as support tasks)


In Other Words ...

WBS

EstimateSize and

ThenEffort

Estimate Costs Directlyor as % of

Development Costs

Software Development Tasks

• requirements

• design• code• ...

Other Tasks and Costs

• management

• travel• training• overhead• facilities• equipment• software• …

Convertto$

TotalCost

Estimate

TotalCost

Estimate

Estimate Development Costs

Then Estimate Other Costs


Notes for Effort Estimation• Accuracy of estimate depends on

– Experience – Historical data– Availability of information– & LUCK!

• At the start of a project, you are lucky to be within 20% unless you have very good historical data– It is not unusual to be 100% off


Good History Data

Good historical data are essential for

accurate estimating.

Good historical data are essential for

accurate estimating.


Architecture of Spreadsheet

Model BasedEstimate

Other EffortEstimates ...

HistoricalSize Estimate

SoftwareReuse

Analysis

Size / Reuse Effort

Final EffortEstimate

ProductivityBased Effort

Estimate

Other SizeEstimates ...

Final SizeEstimate

DelphiSize Estimate

Schedules

Generic Schedule

Effort Schedule

0

5

10

15

20

25

M1 M2 M3 M4 M5 M6

Total

Build 1

Build 2


Effort Estimation with Historical Productivity Data


Effort Can Be Estimated From Size and Productivity

Effort = Size * Historical ProductivityExamples:

– Staff Days = Lines of Code*Staff Days/LOC– Staff Days = Modules*Staff Days/Module– Staff Days = Function Points*Staff Days/FP

Whatever unit you measure, if you have good historical data, this method can be

fast and effective

Whatever unit you measure, if you have good historical data, this method can be

fast and effective


Typical values forProductivity Rates

• 2-15 LOC/day for high order languages• 3-25 LOC/day for assembly language• Lower values for constrained projects

– real time/ safety critical systems etc.

• Higher numbers for commercial applications with few constraints

• Even higher numbers can be achieved if you use 4GLs, high levels of reuse, etc.


Example

• In the past, we have had the following productivity:– 4 LOC/sd for complex software– 8 LOC/sd for simple software

• For the new “8000 LOC”, “complex” software, it should take

8000/4 = 2000 staff days

…But how accurate is this?


Historical Data (Typical)

0

1

2

3

4

5

6

7

1998 1999 2000 2001 2002 2003 2004

History

Proposed

LOC Developed per Staff-day


Historical Data are Seldom Precise or Consistent

Example:Effort for complex software varies from 2 to 6 LOC per staff day, with a mean of 4 LOC per staff dayThe expected effort for an 8000 SLOC program might be

• As low as 1334 staff days or ...• As high as 4000 staff days!


In Other Words

• Historical Data usually gives a RANGE of values, not a precise estimate

Based on past experience,this project should take from

100 to 125 staff months


Three Risk Management Approaches

• Use multiple estimating methods– They will help improve the bounds on

your estimate– Each new method will identify issues

that other methods overlook• Set aside a “reserve” amount based

on the level of risk in your estimate• Plan to update your estimates

– You will have better information in the future


What Do Multiple Methods Tell You?

• They help you understand the degree of uncertainty and/or confidence in your estimate - so you can manage more effectively

• They force you to ask hard questions about what facts each method overlooks

• They help you learn


Statistical Variances and Uncertainties

TrueCost?

Method 1

Method 3Method 2

Region of Likely Costs


Beware of Averages

• Significant differences in estimates usually mean significant differences in assumptions or facts considered

• In such cases, averages may be meaningless

XXX XX X X

Average is MeaninglessAverage is Meaningless


Wideband Delphi• Wideband Delphi can be

used to estimate effort as well as size– On small projects this is often

the most effective way to estimate effort

– Also useful for estimating other costs, such as

management overhead, tools,support functions etc.

I assume it will take 3 people for 2 months.

x xx x x


Bottom Up Estimating


Bottom Up Estimating• This method may take a lot of time• It may or may not be based on size

estimates• This method has several benefits

– Each part of the project is estimated by someone who knows that part well

– Individuals “buy in” to the estimate because it was based on their expertise

– It is easy to compare actual results with estimates and determine if and where you went wrong


Bottom Up Estimating Process1) Break the software down into

components -- as detailed as you can– Break down until the individual parts

are small enough for an individual to develop in a short time (1 week to 1 month perhaps)

– If you do not know, make a reasonable estimate of how you could break each part of the software into smaller parts

2) Estimate each part3) Combine estimates


Sample Breakdown

Database I/F

ErrorProcessor

Sort Module

Synchro-nizer

CommandProcessor

TableInterface

Joe Mary &

Jim

Bert &

Sally

Joe Bert Sally

ParserCode

GeneratorFile

SystemRun TimeSystem

UserInterface

ManageSoftware

Development

Build “C”Compiler

Build TestSuite

WriteDocumentation

WriteInstallationSoftware

Software for“C” Compiler


Sample Estimate

6 SW6 SW 1 SW1 SW4 SW4 SW 5 SW5 SW3 SW3 SW 4 SW4 SW

Joe Mary &

Jim

Bert &

Sally

Joe Bert Sally

12 SW 28 SW23 SW 14 SW18 SW

18 SW95 SW 33 SW 12 SW 22 SW

180 SW


For an Object Oriented DesignYou May Break it Up

Differently

Class“Query”

Subclass“User

Response”

Class“ErrorCode”

Class“Response”

Subclass“System

Response”

Subclass“Maintenance

Response”


Day 2, Part 1Estimating Effort and Cost

Section 2 - Estimation as a Series of Schedules


A Fundamental Issue in Estimation

• How do you “put it all together”?– Size – Effort– Cost– Schedule– Staffing levels

• How do you “keep it all together” as you revise and update the estimates?


A General Process for Documenting & Updating

Estimates• The process to be described is a

framework for estimating• You can use any estimating

methods you choose• The process allocates estimated

effort and cost across a schedule• And by using a spreadsheet, you

can easily update all estimates



Model BasedEstimate



SoftwareReuse

Analysis

Size / Reuse Effort Schedules



Estimate

Generic Schedule

Effort Schedule


Final SizeEstimate

DelphiSize Estimate

0

5

10

15

20

25

M1 M2 M3 M4 M5 M6

Total

Build 1

Build 2


Some Features of This Estimating Process

• The process allows you to evaluate:– Staffing and shopload– Resource requirements (equipment,

people, money, …)– Cash flow

• It serves as a basis for managing– It provides initial estimates of many

quantities you will want to track against actuals during project execution


Revised Effort Schedule

Top Level Schedule

Generic Schedule

Effort Schedule Effort

Cost Schedule Cost

S, SA

P

AL

WBS costcategories

AD

Initial Plannin

gProcess Model

Additional Labor

The Estimation Sequence


Code Category Aff ects ExamplesS Sof tware

DevelopmentCost &

ScheduleSof tware Design, Sof twareCoding, Sof tware Testing

SA Additional Sof twareDevelopment

Cost &Schedule

Sof tware Requirements,System Testing

P Sof tware Support Cost Sof tware Management, SQA,Config Management

AL Additional Labor Cost Project Management,Document Generation

AD Additional Dollars Cost Travel, Development Tools,Special Equipment,

Cost Categories for WBS Tasks

Each category is used at a different point in the estimating process

Each category is used at a different point in the estimating process



Top Level Schedule

Generic Schedule

Effort Schedule

Cost Schedule

S, SA

P

AL

WBS costcategories

AD

Initial Planning

Process Model


EffortEstimate

Additional Labor

Cost


The Generic Schedule is ...… a mapping of “the process” to the

top level schedule– It indicates what portion of the

schedule will be devoted to each phase of the process

… the schedule control mechanism for the estimating spreadsheet– If you change your schedule or your

process, you adjust the generic schedule and the rest of the schedules will automatically adjust


The Generic Schedule Tells You ...

• Where you will perform each process phase, in relation to the overall project schedule

Phase Percentage Eff ortM1 M2 M3 M4 M5 M6 .

Rqmts 25% 25% 25% 15% 10%

P Des 15% 25% 30% 20% 10%

D Des etc etc

C&UT etc

I nteg.

REVIEWS SRR PDR


Typical Generic Schedule forWaterfall Model Lifecycle

Phase M1 M2 M3 M4 M5 M6 … TOTRqmts 25% 25% 25% 15% 10% 100%

P Des 15% 30% 20% … 100%

D Des … 100%

C&UT … 100%

I nteg. … 100%

REVIEWS SRR PDR

Process Schedule


Phase M1 M2 M3 M4 M5 M6 . TOTRqmts 25% 5% 5% 25% 5% 100%P Des 30% 5% 10% 20% 100%D Des 25% 10% etc 100%C&UT 5% 25% 5% 100%I nteg. 10% 20% 100%CYCLE 1 1 1 1 1/ 2 2 2

Typical Generic Schedule forIncremental Model Lifecycle


Generic Schedule Notes• You can do a separate generic

schedule for each separate software item– And add them together to form a generic

schedule for the total software project– This method is recommended if their

processes or schedules are different

• Or you may combine all software items into one generic schedule– This method is recommended if their

processes and schedules are the same



Top Level Schedule

Generic Schedule

Effort Schedule

Cost Schedule

S, SA

P

AL

WBS costcategories

AD

Initial Planning

Process Model


EffortEstimate

Cost

Additional Labor


The Effort Schedule is ...

… a mapping of the estimated effort to the process phases and the schedule– It indicates how much effort will be spent each

month on each phase of the process


You Need to Partition Estimated Effort by PhasePhase of Process Percent of Adjusted

Base Eff ortRequirements 9.5%

Preliminary Design 14.3%

Detailed Design 23.8%

Coding & UnitTest 23.8%

I ntegration 28.6%

SA

SA

S

S

S

Cost Category


The Effort Vector is Adjusted Base Effort Partitioned by Process Phase

Phase of Process Percent of Adj .Base Eff ort

Eff ort

Requirements 9.5% 200

Preliminary Design 14.3% 300

Detailed Design 23.8% 500

Coding & UnitTest 23.8% 500

I ntegration 28.6% 600

(Estimated) Adjusted Base Effort = 2100 staff-days

Effort Vector

SA

SA

S

S

S

Cost Category


Effort Schedule Matrix Equation

Effort Schedule

Effort Vector

Generic Schedule

= *


Typical Initial Effort SchedulePhase Eff ort M1 M2 M3 M4 M5 Mn TOTRqmts 200 50 50 50 30 20 0 200

P Des 300 0 0 0 45 90 etc 300

D Des 500 0 0 0 0 0 etc 500

C&UT 500 0 0 0 0 0 0 500

I nteg 600 0 0 0 0 0 0 600

SUB-TOTAL 2100 50 50 50 75 110 etc 2100

Sub-total = Adjusted Base Effort

(S tasks plus SA tasks)


To Produce the Effort Schedule

• Multiply each cell in the Generic Schedule by the effort to be spent on the corresponding phase of the process (from the effort vector)

• The result is the corresponding cell in the Effort Schedule

• An example is found in the spreadsheet supplied with the course materials


Support (“P”) Tasks Must be Added On, Usually Based on a

Flat Percentage• Example:

– Support tasks will add about 300 staff-days of effort, which is 1/7 (14.3%) of the estimated effort

– So we add 14.3% to each number in the sub-total line as “add-ons”


Typical Final Effort Schedule(Total Effort)

Phase Eff ort M1 M2 M3 M4 M5 Mn TOTRqmts 200 50 50 50 30 20 0 200

P Des 300 0 0 0 45 90 etc 300

D Des 500 0 0 0 0 0 etc 500

C&UT 500 0 0 0 0 0 0 500

I nteg 600 0 0 0 0 0 0 600

SUB-TOTAL 2100 50 50 50 75 110 etc 2100

ADD-ONS 300 7 7 7 11 16 etc 300

TOTALEFFORT

2400 57 57 57 86 126 etc 2400


The Effort Schedule Tells You ...

… how much total effort will be expended each month, for basic software development & support

… what will be going on each month in terms of process phases


How Many People?

• Head count (number of people) can be calculated by dividing the total effort by the availability (effort available per person per month)– This tells you how many people you will

need each month• Example: if there are 57 staff-days

of effort required and each person works 19 days per month, then you need:

57/19 = 3 people.


Head CountPhase Eff ort M1 M2 M3 M4 M5 Mn TOTRqmts 200 50 50 50 30 20 0 200

P Des 300 0 0 0 45 90 etc 300

D Des 500 0 0 0 0 0 etc 500

C&UT 500 0 0 0 0 0 0 500

I nteg 600 0 0 0 0 0 0 600

SUB-TOTAL 2100 50 50 50 75 110 etc 2100

ADD-ONS 300 7 7 7 11 16 etc 300

TOTALEFFORT

2400 57 57 57 86 126 etc 2400

Head Count 3.0 3.0 3.0 4.5 6.6


The Head Count Tells You About Additional Risks

• Unrealistic staff growth• Grossly uneven staffing needs

0

20

40

60

80

100

Start Month

1

Month

2

Month

3

Month

4

Month

5

Month

6

Total Staff


Typical Head Count Graph

0

2

4

6

8

M1 M2 M3 M4 M5 M6 M7 M8

Planned

Data taken directly from effort schedule


You Can Track ActualsDuring Execution

0

2

4

6

8

M1 M2 M3 M4 M5 M6 M7 M8

Planned Actual



Top Level Schedule

Generic Schedule

Effort Schedule

Cost Schedule

S, SA

P

AL

WBS costcategories

AD

Initial Planning

Process Model


EffortEstimate

Cost

Additional Labor


The Revised Effort Schedule ...• Incorporates labor for tasks beyond

basic software development– Special audits– Validation steps– Special documents to be produced– Tasks beyond the usual process

• It is prepared by adding a row to the effort schedule that shows additional labor, and then a grand total row


Revised Effort SchedulePhase Eff ort M1 M2 M3 M4 M5 Mn TOT… … … … … … … … …

SUB-TOTAL 2100 50 50 50 75 90 etc 2100

ADD-ONS 300 7 7 7 11 13 etc 300

Total Eff ort 2400 57 57 57 86 126 etc 2400

AdditionalLabor

300 19 19

Grand TotalEff ort

2700 57 57 76 105 126 …

Head Count 3.0 3.0 4.0 5.4 6.6 126



Top Level Schedule

Generic Schedule

Effort Schedule

Cost Schedule

S, SA

P

AL

WBS costcategories

AD

Initial Planning

Process Model


EffortEstimate

Cost

Additional Labor


The Cost Schedule is ...

… three rows added to the effort schedule1 Effort converted to dollars (*)2 Additional money required (for travel,

equipment, and other non-labor costs)3 Grand Total cost (#1 + #2)

… the cells indicate dollars rather than effort

(*) Multiply “Grand Total Effort” cells by average cost per labor hour

(*) Multiply “Grand Total Effort” cells by average cost per labor hour


Cost SchedulePhase Eff ort M1 M2 M3 M4 M5 Mn TOT Grand Total Eff ort

2700 57 57 76 105 126

Dollars $280K 6K 6K 8K 11K 13K … …

Additional Dollars

$150K 88K

22K 14K

Grand Total Cost

$430K 94K

6K 30K 25K 13K …

Head Count 3.0 3.0 4.0 5.4 6.6 126


The Cost Schedule Indicates

• How much money will be spent each month

• And it incorporates money for costs not measured in units of labor (e.g., travel)


A Typical Cost Schedule

0

1

2

3

4

5

6

M2 M3 M4 M5 Ms

Month

K$


The Cost Schedule HasMany Uses

• Cost of the project• How much money you need each

month• Inflation can be adjusted for longer

projects• Interest information may be

incorporated if money must be borrowed



Top Level Schedule

Generic Schedule

Effort Schedule Effort

Cost Schedule Cost

S, SA

P

AL

WBS costcategories

AD

Initial Planning

Process Model

Additional Labor




Model BasedEstimate



SoftwareReuse

Analysis



Estimate


Final SizeEstimate

DelphiSize Estimate


Generic Schedule

Effort Schedule

0

5

10

15

20

25

M1 M2 M3 M4 M5 M6

Total

Build 1

Build 2


Day 2, Part 1Estimating Effort and Cost

Section 3 - Estimation Models & Negotiation


Outline

• Developing an estimation model• Calibrating and validating a model• Cost drivers• The Cocomo model• Other estimation models • Bottom-up estimating• Estimating cost• Negotiating



Model BasedEstimate



SoftwareReuse

Analysis



Estimate


Final SizeEstimate

DelphiSize Estimate


Generic Schedule

Effort Schedule

0

5

10

15

20

25

M1 M2 M3 M4 M5 M6

Total

Build 1

Build 2


Effort Estimating Models ...

… help us predict effort and cost, given many facts about the software

(The principal facts are the estimated size and complexity of the software)

These are similar to the size models we discussed before, in general concept

These are similar to the size models we discussed before, in general concept


Developing an Estimation Model


An Effort Estimation Model is ...

… an algorithm or equation or set of equations that produces an estimate of the effort, given inputs that describe the software to be written

EstimationModel

Description of

Software

Estimate of

Effort


A Very Simple Model

Examples:– Staff Days = Lines of Code*Staff Days/LOC– Staff Days = Modules*Staff Days/Module– Staff Days = Function Points*Staff Days/FP

The first estimation method is, in fact, a very simple estimating model

The first estimation method is, in fact, a very simple estimating model

Effort = Size * Productivity


A Graph of the Model

Effort

Size

Effort = Size * Constant


But We Know That ...

• Effort usually grows faster as size increases due to management overhead and other such factors

• So the graph ought to curve up rather than being a straight line


Perhaps Something like This

Size

Effort


One Model That ProducesSuch a Curve

a and b are constants that depend on the software development organization and the type of software

Size

Effort

Effort = a * Size b

Many organizations find that their software effort fits this model for effort as a function of software

size

Many organizations find that their software effort fits this model for effort as a function of software

size


“b” Is Called the“Economy of Scale” Factor

• On most software projects, especially large ones, we observe a diseconomy of scale (b > 1) because of the additional communication and management overhead of larger projects (as shown on previous slides)

• This causes the curve to turn up


Economy of Scale Is Possible

• We could see economy of scale (b<1), especially on small projects, such as:– when fixed start-up costs are amortized

as size increases– or when something about the nature of

the approach allows you to be more productive for larger software projects

• See next slide for an illustration


Economy of Scale(b < 1)

Size

Effort


How to Determine the Curve

• By observing organizational experience over a period of time, you can – collect enough data to determine

whether this curve fits your data, and– calculate typical values of a and b

• One such model is called “Cocomo”– we will discuss Cocomo in subsequent

slides


Does This Apply to My Project?

• Some argue that models like this only make sense for large projects using traditional software development methods

While such models are more commonly used for large projects and traditional software development methods, there are many principles applicable to small

projects and to newer development methods

While such models are more commonly used for large projects and traditional software development methods, there are many principles applicable to small

projects and to newer development methods


Basic Cocomo Model

• Size is in thousands of lines of code

• Effort is in staff months, assuming 19 staff days per staff month

Effort = 3 * Size 1.12

This is the least detailed version of the Cocomo model. It is often used for making sanity checks on results of estimates from

other methods

This is the least detailed version of the Cocomo model. It is often used for making sanity checks on results of estimates from

other methods


How to Use on Your Projects

• Basic Cocomo was derived from a set of about 50 projects at TRW corporation from the late 1970’s

• To use this on your projects, you could estimate with the Basic Cocomo model, compare that with actual results or past experience, and adjust to more accurately reflect your experience.


Calibration

• Over time, you would calibrate your experience on projects to the equation and determine the values of “a” and “b” that fit your data the best.

• For example, your version of the model might turn out to be:

Effort = 2.7 * Size 1.24


Cocomo II Extension• In Cocomo II, the latest version of the

model, the exponent, b, can be estimated based on a series of “scale drivers” which address such factors as:– experience with similar projects– flexibility of development process– maturity of design approach– team cohesion– process maturity (on SEI CMM scale)


Calibrating & Validating a Model


Validation ...

… is the process of evaluating or proving that the model accurately predicts what you want it to predict– Does your data typically fit the curve?– Is this the right curve?– What was the basis for the equation(s)

used in the model?• What assumptions were made?• What type of application is intended?


For Example, the Cocomo Model...

• Is calibrated from relatively large programs (more than 10,000 lines of code)

• Assumes a relatively formal development process based on the waterfall lifecycle

• Was derived from about 50 programs developed by TRW corporation in the late 1970’s


Validating Suitability of a Model

• Look at data from your programs– Does the data tend to fit the same kind

of curve?

• Compare your assumptions with those of the model– If the assumptions do not match, you

may need to investigate further to see if the model still fits


Calibration ...… is the process of adjusting the key

constants or other model factors so the results tend to approximate your data– For example, a and b in Cocomo

… usually accomplished by statistical methods such as regression analysis

Often you need to calibrate differently for different kinds of software or different application

types

Often you need to calibrate differently for different kinds of software or different application

types


Calibrating a Model

Estimating

Model

Your Data

Your Experien

ce

Your

Model

Your Insigh

t

adjust


Cost Drivers


Nominal Effort

• When we apply a model, the “nominal” effort is the effort predicted by the model under typical or nominal circumstances– Nothing unusual or out of the ordinary– Something we know how to do


But Not All Projects Are Typical

• It is very common to have factors that make the effort for a particular project higher or lower than normal– Experience of staff– Complexity of products– Strength of tools


Factors that Affect Effort

• Such factors influence the effort estimate & hence cost -- and thus are termed “Cost Drivers”

• Cost drivers are often included as parameters to effort estimating models

• We will examine the cost drivers used in more advanced versions of Cocomo– Similar drivers are used in other models


Cost Drivers - I The Nature of the Job to be

Done1) Required Reliability

– Applies mainly to real time applications

2) Data Base Size– Applies mainly to data processing apps

3) Product Complexity

4) Execution Time Constraints– When processor speed is barely sufficient


Cost Drivers - I (continued)

5) Main Storage Constraints– Applies when memory size is barely

sufficient

6) Target Machine Volatility– Includes hardware and operating system

7) Development Machine Volatility– Unstable OS, compilers, CASE tools, etc.


Cost Drivers - II The Practices & Tools

1) Modern Programming Practices– Structured Analysis or OO

2) Modern Programming Tools– e.g., CASE tools, good debuggers, test

generation tools

3) Schedule Compression (or expansion)– Note -- deviation from ideal can never

help, but shorter is worse than longer


Cost Drivers - III The People Who Will Do It

1) Analyst Capability

2) Application Experience

3) Programmer Capability

4) Virtual Machine Experience– Includes operating system and hardware

5) Programming Language Experience– Includes tools and practices


Cost Drivers - IV Additional Drivers Often Used

1) Requirements volatility– A little change in requirements is

expected, but too much can have a strong effect on project cost

2) Security requirements

3) Access to data– Sometimes very difficult


Cost Drivers - IV(continued)

4) Impact of standards and imposed methods

5) Impact of physical surroundings

6) A need to design software to be reusable

7 …) You can add whatever others make sense in your situation


Example of Applying aCost Driver

• You need to train the new people• You need to allow them time to gain

experience or “get up to speed” (this is known as “climbing the learning curve”)

• They will be less productive than experienced people would be on the same job

“Nominal” estimate with experienced staff is 60 staff-weeks (3 people, 20 weeks)

Suppose we have an inexperienced staff -- what can we estimate?


How You Might Factor In This Cost Driver

With inexperienced people, you plan:• A training period - 1 week per person or

3 staff-weeks total• Lower productivity - 66.7% of normal effort

(estimate based on your experience)• Thus estimate for effort is 60/66.7% = 90

staff-weeks + 3 staff-weeks of training= 93 staff-weeks total (3 people, 31

weeks)

“Nominal” estimate with experienced staff is 60 staff-weeks (3 people, 20 weeks)


How Do You Handle Multiple Cost Drivers?

• Some cost drivers have a multiplicative effect on effort

• For such cases, you can define an effort multiplier for each cost driver

• For example, if high complexity tends to make effort about 12% higher, than you can define a “high complexity” effort multiplier of 1.12


Effort Multipliers

•Determine an effort multiplier for each cost driver–multiplier = 1 means the driver does not apply–multiplier > 1 means the driver increases cost–multiplier < 1 means the driver decreases cost

Effort = Nominal * Product of All Multipliers


Applying Multiple Cost Drivers

Table of Effort Multipliers

Driver Normal High VeryHigh

Complexity 1.0 1.15 1.30

Reliability 1.0 1.15 1.40

Experience 1.0 .91 .82

etc. etc. etc. etc.

Suppose:

• Nominal is 200 staff months

• Complexity is very high

• Staff experience is high

Then:

Estimated effort = 200 * 1.30 * .91

= 236.6

The table represents your organization’s collective experience of the impact of

various factors or cost drivers.

The table represents your organization’s collective experience of the impact of

various factors or cost drivers.


Intermediate Cocomo1

Where where EAF = E1*E2*...*En

Eis are effort multipliers corresponding to a set of common cost drivers. – The nominal value of each Ei = 1.

– Ei = 1 implies the cost driver does not apply

– Ei > 1 implies increased cost

– Ei < 1 implies decreased cost

Effort = EAF * a * Size b

1) This model is often known as Cocomo 811) This model is often known as Cocomo 81


Effort Multipliers• Typical values range between 0.6 &

1.5• Preset values are established for

each factor• All Cocomo multipliers together can

affect cost and schedule estimates by 10 times or more!


Typical Table ofEffort Multipliers

Value Low Nominal High Very High

Extremely High

Complexity .85 1.0 1.15 1.30 1.65

Language Experience

1.07 1.0 .95 .86

…


EAFEffort Adjustment Factor

• EAF is the product of the effort multipliers

• A value of 1 would represent a relatively easy software effort, perhaps with no cost drivers


EAFEffort Adjustment Factor

(continued)

• A value of 1 - 1.5 is typical today for a commercial software effort

• A value of 1.5 - 2.0 is typical today for a real-time effort or a government project


EAF Has ImprovedOver the Years

• The values typically reported by software projects were once a lot larger (in the 3-4 range), but due to improvements in practices and processes, they have gotten a lot better.


Intermediate Cocomo - “a” & “b”

The “mode” is the

general type of

software

The “mode” is the

general type of

software

Effort = EAF * a * Size b

Mode a b

Organic 3.2 1.05

Semi-Detached

3.0 1.12

Embedded 2.8 1.20


Cocomo Software Types (Modes)

Organic – Fairly easy software– software development team is familiar

with application, language, and tools.– Typically from 2-50 KLOC

Semi-Detached– Average software, average team– Typically 50-300 KLOC


Cocomo Software Types (Modes) (continued)

Embedded – Severe constraints, real time, etc.– No stated size range, but model is

known to fail under 10KLOC

NOTE: the origin of the names is obscure, and not considered

significant, even by Barry Boehm, who invented Cocomo.

NOTE: the origin of the names is obscure, and not considered

significant, even by Barry Boehm, who invented Cocomo.


Cocomo II Extension

• In Cocomo II, there are formulas based on characteristics of the application that allow you to estimate the “a” and “b” values more precisely.

• But the best way is always to calibrate to your own data


Cocomo Tool Information

CoCo ProAvailable through ICONIX Software

Engineering Inc.

For more information on CoCoPro:

HTTP://WWW.ICONIXSW.COM/Spec_Sheets/CoCoPro.html

For more information on CoCoPro:

HTTP://WWW.ICONIXSW.COM/Spec_Sheets/CoCoPro.html


Cocomo Tool Information (continued)

REVIC - A free toolAvailable through USAF Cost Analysis

AgencySOFTEST - an updated version

For more information on REVIC or SOFTEST:

http://sepo.nosc.mil/estimation.html

For more information on REVIC or SOFTEST:

http://sepo.nosc.mil/estimation.html


Cocomo Tool Information (continued)

• SOFTCOST-R• Available through Resource

Calculations Inc.

For more information on SOFTCOST-R:

http://www.softstarsystems.com

For more information on SOFTCOST-R:

http://www.softstarsystems.com


Additional Cocomo II Information

Under development at University of Southern California, Cocomo II project.

For More Information on Cocomo II:HTTP://SUNSET.USC.EDU/

research/COCOMOII/index.html

For More Information on Cocomo II:HTTP://SUNSET.USC.EDU/

research/COCOMOII/index.html



Model BasedEstimate



SoftwareReuse

Analysis




Estimate

Generic Schedule

Effort Schedule


Final SizeEstimate

DelphiSize Estimate

0

5

10

15

20

25

M1 M2 M3 M4 M5 M6

Total

Build 1

Build 2


Other Estimation Models


• Cocomo only accounts for the main tasks of software development.

• It also includes certain amounts of management, CM, and QA

• In Cocomo II, the latter amounts are larger than in older versions

SystemAnalysis

SoftwareRequirements

SystemInt &Test

SoftwareDesign

SoftwareCode

SoftwareInt &Test

<---- Cocomo Includes ---->

Tasks Included in Cocomo


• Cocomo does not include– System level tasks– Software requirements definition and analysis– System integration and test

• Including software support of this activity

– Management above the software project level

SystemAnalysis

SoftwareRequirements

SystemInt &Test

SoftwareDesign

SoftwareCode

SoftwareInt &Test

<---- Cocomo Includes ---->

Tasks Excluded From Cocomo


Other Popular Cost/Schedule Estimation Models

• Putnam’s Model -- (SLIM)

• Shen and Conti -- (COPMO)

• Lockheed/Martin -- (Price-S)

• Galorath, Inc -- (SEER-SEM)


SLIM (1)

Size is measured in lines of code (or can be thousands if Ck is adjusted)

Effort is measured in staff-years

Ck is a “state of technology” constant, reflecting use of modern practices, team experience, and software development tools. Compare with Cocomo adjustment factors.

t is the development time, in years.(1) Putnam, IEEE Trans. on SW Engineering, July, 1978.

Size = Ck*Effort1/3*t4/3


SLIM Information

• EFFORT is for entire life cycle, including maintenance

• Development Effort = .39 * EFFORT, according to Putnam

For more information on SLIM:

HTTP://WWW.QSM.COM

For more information on SLIM:

HTTP://WWW.QSM.COM


Copmo (1)

Effort = Programming Effort + Coordination Effort

The values of the constants a, b, c, and d must determined by regression analysis on actual project data

The important issue here is the impact of staff size on management/coordination effort

(1) Conte, S.D., et. al. Software Engineering Metrics and Models.

Effort = a + b*Size + c*(Staff)d


Price-S• This is a very complex, proprietary

model, based on extensive analysis of many kinds of software projects

• The parameters are similar to Cocomo’s adjustment factors, but can be very sensitive

• For example, experience level of personnel can affect estimates by 5 times or more


Price-S Additional Information

Now supplied by PRICE Systems, a Martin-Lockheed Company

The product is called the PRICE S Software Estimating Suite

For more information on PRICE-S:

HTTP://WWW.PRICESYSTEMS.COM

For more information on PRICE-S:

HTTP://WWW.PRICESYSTEMS.COM


SEER-SEM• This is a proprietary model, sold by

Galorath, Inc., based on analysis of many kinds of software projects

• The model also has elements for size estimation and project management

• For example, one can use SEER tools to track progress and risks


SEER-SEM Additional Information

Galorath, IncorporatedEl Segundo, California310-414-3222

For more information on SEER-SEM:

HTTP://www.galorath.com/

For more information on SEER-SEM:

HTTP://www.galorath.com/


Software Maintenance Estimating

• Usually this is done in a “bottom up” manner, such as:– Estimated number of changes *

average cost per changeor– Level of effort (“n” people per year for

“m” years -- total cost = n*m)

• Sometimes it is done on a “cost per transaction” basis


Don’t Treat Maintenance as Reuse

• Generally speaking, maintenance affects only a small portion of the software

• If you model the unchanged part as “reused” you will get much too large a number for the estimated effort


Process, Methods, and Tools

Tools

COSTAR, REVICSLIM

SOFTCOSTMethods (Models)

COCOMO,PUTNAM,ET. AL.

Process (Purpose)

EFFORT ESTIMATING



Model BasedEstimate



SoftwareReuse

Analysis




Estimate

Generic Schedule

Effort Schedule


Final SizeEstimate

DelphiSize Estimate

0

5

10

15

20

25

M1 M2 M3 M4 M5 M6

Total

Build 1

Build 2


Compare Results and Judge

Method Productivity Cocomo Bottom Up

Final Estimate

Eff ort 376 402 358 360

Productivity 1.1 .9 1.2 1.2

Schedule 12.8 14.2 12 12


An Issue with Effort Estimating Methods based on

Size• How can you know the size before

you have designed the software -- and maybe before you even know its requirements?


Dealing with Uncertain Size Estimates

• Generally speaking, you can predict better after design than you can before it

• So re-estimation is a MUST for effective risk management

• Methods not based on size, such as wideband delphi or “bottom up” effort estimating, should be considered to supplement size-dependent methods


Grady, Robert B. and Deborah L. Caswell, Software Metrics: Establishing a Company-Wide Program.

An Issue with AllEffort Estimating Methods

• You can manipulate the method to get any answer you want– Grady and Caswell report that typical

estimates are 20-25% optimistic, even for experienced estimators

– So you need to record your results, learn from your mistakes, and do better the next time


You Need to Track ………………

Actuals vs. Estimates

0

20

40

60

80

100

120

140

1 2 3 4 5 6 7 8 9 10

Estimate

Actual


You Need to Track and Adjust

Actuals vs. Estimates

0

20

40

60

80

100

120

140

1 2 3 4 5 6 7 8 9 10

Estimate

Actual

Revised Estimate


Use Several Methods

• At the very least, using several methods will increase your chances of being close to the right answer

X X X


Remember the Goals of Estimating

• Knowledge and insight are the real benefits of using different methods

• Comparing the results of several methods will force you to resolve the discrepancies – This forces you to think about the

issues


Estimating Cost


There are Many CostsOther Than Software

Development

WBS

EstimateSize and

ThenEffort

Estimate Costs Directlyor as % of

Development Costs

Software Development Tasks

• requirements

• design• code• ...

Other Tasks and Costs

• management

• travel• training• overhead• facilities• equipment• software• …

Convertto$

TotalCost

Estimate

TotalCost

Estimate


Turning Effort into Cost

• Turning effort estimates into cost estimates depends on many factors that depend on your specific company– Overhead rates– Cost of borrowing money– Methods of calculating profit margin– Allocations of management and support

expenses– Costs of capital equipment– etc.


One Way to Convert Effort to $

Category % of Total Salary Rate#

Requirements 10% $65/hourDesign 10% $50/hourCode 30% $40/hourTest 30% $30/hourOther 5% $15/houretc. etc.

# use rate per hour if effort is measured in staff-hours use rate per day if effort is measured in staff-days etc.

# use rate per hour if effort is measured in staff-hours use rate per day if effort is measured in staff-days etc.


Multiply the Effort by the Percentages to get the Labor

Distribution and $10,000 hours:

1000 hours - requirements x $65 = $65,000

1000 hours - design x $50 = $50,000

3000 hours - code x $40 = $120,000

3000 hours - test x $30 = $90,000

etc.

Total: $xxx,xxx


A Note About theSalary Rate Chart

• Be sure to correlate the percentages with the “experience level” factors assumed in your effort estimate

>> It is tempting to cut costs estimates by boosting the percentage of lower cost staff -- check what this does to the cost drivers first!!! <<

>> It is tempting to cut costs estimates by boosting the percentage of lower cost staff -- check what this does to the cost drivers first!!! <<


Negotiation



EstimateSize

EstimateEffort and

Cost

EstimateSchedule

Evaluate



Historyetc.

WBS Size

Effort &Cost

Schedule


Revise &Negotiate

Not OK


If the Plan is Not Feasible

• DO examine assumptions and data– initial cost estimates are often very

conservative

• Do examine risk/cost tradeoffs to see if you can accept a higher risk

• Do make a list of barriers that must be removed in order to make the estimate fit the constraints


“The quickest way to make a project uneconomical is by doubling the resources needed and using the cover story that you need to prevent failures.”

Adams, The Dilbert Principle

“The quickest way to make a project uneconomical is by doubling the resources needed and using the cover story that you need to prevent failures.”

Adams, The Dilbert Principle

If the Plan is Not Feasible

• DO NOT “cave in” & lower everything to meet a target cost or schedule


The Negotiation Process

We MUST havethe lowest bid!!!

We will, boss!!!

Management will try to trim the budget by sending an army of low-ranking, clueless budget analysts to interview you and ask “insightful” questions. Adams, The Dilbert Principle

Management will try to trim the budget by sending an army of low-ranking, clueless budget analysts to interview you and ask “insightful” questions. Adams, The Dilbert Principle


Re-think key factors

Spreadsheet for estimating

This will never satisfy the cost

goal!???!


Identify Opportunities and Barriers

Barriers

Opportunities to Cut


Negotiate

If they will cut back on the reviews

and ...

Well, I’ll think about

it


Beware ... Estimates are Never

Perfect


Estimating Accuracy vs. Phase

0

0.5

1

1.5

2

2.5

3

3.5

4

4.5

Feasibility Plans Design DetailedDesign

CodeandTest

Release

Upper LimitActual

Lower Limit

• Typical Estimates

• • • • • • •

•


Some Opportunities to Consider

• Plan to re-estimate after important milestones

• Prioritize requirements and promise to deliver the top ones by the deadline – Incremental deliveries

• Put a high cost on requirements changes

• Look at each “adjustment factor” in Cocomo as an opportunity

• Get training for everyone


Some Typical Barriers to Faster Schedule or Lower Cost• Lack of adequate resources

– Software, tools, people, etc.• Slow approval cycles for required

resources• Poor coordination with other

disciplines, other companies, etc.• Customers, peers in other disciplines,

and managers who don’t understand software development very well


Some Difficult Barriers to Faster Schedule or Lower Cost

• Irascible and irrational customers & managers

• Intentional barriers– Competitors, etc

– Political constraints


Negotiating Tip . . .

• The more facts you have, the better off you are during negotiation

• Get decision makers to review your estimate – Sometimes they don’t bother

• Be well prepared to explain it



EstimateSize

EstimateEffort and

Cost

EstimateSchedule

Evaluate



Historyetc.

WBS Size

Effort &Cost

Schedule


Revise &Negotiate

Not OK


Several Iterations are Likely• That’s why you should use a spreadsheet or

an estimation tool!• Identify the factors that affect the cost and

schedule– Experience levels, stability levels, etc.

• Examine sensitivity of the results to various factors

• Examine historical data to make a better picture of probable events

• Don’t put too much faith in the accuracy of models


SummaryEffort & Cost Estimation

(continued)• Effort can be measured in many ways

– The specific measurement can have a significant effect on the numbers computed during an estimate

• Effort and Schedule Length are interdependent– Time and effort can be traded off to

some extent, but not completely - there are “infeasible” combinations


• Effort estimates can be made through historical experience or through models derived from historical experience

• Beware of averages• Cost is derived through several steps• The estimating process shown enables

you to tie it all together and make updates

Summary Effort & Cost Estimation

(continued)


• Models are often helpful to estimate effort– All are based on historical experience– All should be calibrated to your specific

experience– And validated to be sure that they are

right for your application– Most have additional parameters that

allow you to “fine tune” to your specifics


(continued)


• Cocomo is a widely used method that is fairly successful when calibrated to your experience

• Like most models, Cocomo covers only some of the tasks of software development

• It is best to use multiple models/ methods to improve the quality of an estimate


(concluded)


1. Boehm, “Software Engineering Economics”, Prentice-Hall, 1981.

2. Boehm, et. al., Cost Models for Future Software Life Cycle Processes: Cocomo 2.0, Technical Report, USC Center for Software Engineering, Draft 2.0, September 6, 1994.

3. Brooks, Fred, “The Mythical Man-Month”, 1975 / 1995.

4. Conte, S.D., et. al. Software Engineering Metrics and Models. Benjamin Cummings, 1986, p314.

ReferencesEffort & Cost Estimation


4. Grady, Robert B. and Deborah L. Caswell, Software Metrics: Establishing a Company-Wide Program. Englewood Cliffs, N.J., Prentice-Hall, Inc., 1987.

5. Putnam, Lawrence H., “A General Empirical Solution to the Macro Software Sizing and Estimating Problem,” IEEE Transactions on Software Engineering, July, 1978, p345.

6. Tausworthe, R.C. Software Specifications Document, DSN Software Cost Model, Jet Propulsion Laboratory, JPL Publication 81-7 (1981).

ReferencesEffort & Cost Estimation

(continued)


SoftwareDevelopment

Plan

Execute

Measure

EngineerQuality

Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 1 4/19/2003 Day...

Documents

Transcript of Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 2, Part 2, Page 1 4/19/2003 Day...