Software Estimation

How hard can it be?

Peter R Hill

What we will cover

• Introduction to ISBSG• The importance of Software Size• When can we establish software size?• Estimating software size• Quick and early lifecycle estimation• Macro estimation techniques• Some rules of thumb

A quick introduction to the International Software

Benchmarking Standards Group(ISBSG)

The global and independent source of data and analysis for the IT industry

To deliver the mission

The ISBSG has established and now grows, maintains, and exploits two international repositories of IT history data:

Software Development & Enhancement Over 5,500 projects

Maintenance & Support Over 470 applications

You can use this history to estimate.

The Importance of Software Size

In practice we need to estimate size before we have all the detail needed for a full functional size measurement

We therefore need a method of producing an approximate size from less detail. Source: B. Boehm, USC

FeasibilityFeasibilityRequirementRequirementss

DesignDesignBuildBuild TestTest ImplementImplement

EstimatingEstimatingUncertaintyUncertainty

+ traditional ‘Task-+ traditional ‘Task-based’ estimatingbased’ estimatingDetailed Functional sizingDetailed Functional sizing

Approx. Functional sizingApprox. Functional sizing

When can we establish software size ?

Software Estimation

What we can estimate:

– Size– Effort– Duration– Cost

What are we estimating the size of?

The Effort to deliver Functional (User) Requirements.

We are sizing the software, not the project.

Does not cover the effort needed for:• Technical Requirements• Training• People change management• Build requirements• Etc.

Rule of Thumb! - Requirements Growth

• Systems tend to grow at a rate of about 2% per month during the development cycle. (Capers Jones)

• So for example if you start with functionality that requires an effort 50,000 hours then in 12 months that will grow to ~63,000 hours

• You must manage this growth.

Influential factors when estimatingInfluential factors when estimating

Based upon Statistical Analysis:Based upon Statistical Analysis:

The most influential factors are:The most influential factors are:o Primary Programming LanguagePrimary Programming Languageo Platform MF, MR, PC, multi-platformPlatform MF, MR, PC, multi-platformo Team SizeTeam Size

For detailed analysis – ISBSG Subscription For detailed analysis – ISBSG Subscription ServiceService

Consider these most influential factors when Consider these most influential factors when estimatingestimating

Establishing

Functional

Size

Establishing functional size

Panic!

“I don’t use functional sizing, should I leave now?”

No!

You can “cheat” !

Estimating Functional Size from

Use Cases

Rule of Thumb! – Use Cases

Each use case will represent an average of ~35fp

(The overall range is from 15fp to 75fp)

Examples:Application of 1,500fp

~75,000 Java statements

~42 Use cases

Capers Jones

Use Case Sizing & Conversion

• Go to http://www.codeproject.com• Look up Project Estimation with Use Case

Points• Size your Use Cases using Use Case Points• Divide your use USE Case Points by 1.25 to

provide a rough estimate of Function Points• Now you have a rough size in FP for the

software you can use the ISBSG history data or tools to estimate effort, duration etc.

Estimating Functional Size from a

Logical Data Model

Establishing functional size

By using the known relationships between FP components - if you have a logical data model, you can derive an estimated size

Function Point Breakdown

Quick estimation of size

Example:

• A logical data model has 40 logical tables, these relate to approximately 40 Internal Logical Files (ILFs).

• The mean score attributed to ILFs across all projects is ~9 function points.

• Based upon the above, 40 (ILFs) x 9 = 360 FPs

• From the pie chart it can be seen that the Internal Logical Files component of the function point count is typically around ~25%.

• ∴ Estimated size = 360 FPs x 4 = ~1,440 FPs

Functional Sizing Tools

The biggest obstacle to the use of functional sizing is the time and cost of counting functional units.

As we have seen there are quick and easy ways to approximate a size.

There are also good tools available to establish an estimated size:

o SCOPE™ - www.totalmetrics.como Software Risk Master – Functional Size Patterns

– Capers Jones

So now we have a size,

what can we do with it?

Median Project Delivery Rates

Quick early estimating

In three steps:

1. Estimate Application Size (FPs)• Count Logical Files (each worth ~9fp)• Extrapolate for total application size (files ~25% of total)

2. Estimate Project Work Effort (PWE)• Select median Project Delivery Rate for ‘language’ (hrs/fp)

» this should be checked against median PDR for ‘application type’

• Calculate effort days (or hours)

3. Estimate Developer Cost• multiply PWE (days effort) by Developer estimated daily cost

Example

…for a C development in a mainframe environment with a data model of 40 logical files

1. Application Size = 360 FPs x 4 = ~1,440 FPs

2. Project Work Effort = 1,440 x 14 = 20,160 hrs

3. Developer Cost = 20,160 x $120 = ~$2.4m

Rule of Thumb! – Logical files/FP

The Rule of the "Thirties”

One logical file equals "thirty something" unadjusted function points.

The range is between 31 to 35 function points per logical file. So a system with 40 logical files can be very roughly sized as follows: 40 x 35 = 1,400 function points. This sort of rough estimate should have an allowance of + or - 30%.

MacroEstimating Techniques

Project Estimation Techniques

The ISBSG Repository data can be used to estimate software project metrics using three macro-estimating techniques:– regression equations– comparison– analogy

Estimation

using

Equations

Estimation Using Equations

• Used to produce an initial very rough estimate

• Based on regression equations• ISBSG Practical Project Estimation

– Details in appendix• ISBSG Early Estimation Check

Using equations

• The ISBSG provides regression equation tables for:– Productivity (person hours per function point)– Effort (person hours)– Duration (elapsed hours)– Speed of delivery (function points delivered per

elapsed calendar month)

Estimation - Equation approach

• Establish the project size• Establish key attributes (eg. language, platform,

team size)• Select the formula• Look up the equation tables• Select the appropriate table values• Do the calculation

Equation example

Ok Let’s have a go:

• Software project:

– Midrange platform– 3GL language type– Size of 460 function points

Equation example - using tables

• Project Delivery Rate PDRRE =

126.3 Size –0.435 = 126.3 460 –0.435 =

~ 9 hours per function point

• Project Work Effort PWERE =

126.3 Size 0.565 = 126.3 460 0.565 =

~ 4,050 hours

ISBSG Early Estimate Checker

Estimation

using

Comparison

Estimation - Using comparison

Comparison based estimation involves selecting a group of similar completed projects from a project database, then using the average of the median of the effort values.

Estimation Using Comparison

Comparison based estimation:• Define the platform and identify that subset of

ISBSG data • Define the other attributes – language, team

size etc.• For each attribute obtain the median value • Determine the average of the medians for

PDR and delivery rate• Calculate the effort and duration• The result is your estimate

Example table - comparison estimation

Attribute Median Median

PDR delivery

speed

hrs per FP FP per mth

Language -Cobol ~15 51.2

Business type Financial ~7 44.5

Example comparison estimate

• Project Delivery Rate PDRAC = average of category median project delivery rates = 11 hours per fp

• Project Work Effort PWEAC =

PDRAC Functional Size = 11 460 =

5,060 hours

Example comparison estimate using ISBSG tool

Estimation

using

Analogy

Using analogy

Analogy estimation involves selecting from a project database, one completed project that closely matches the attributes of your planned project. Then use this ‘analogue’ as the basis of your estimate.

Analogy process

• Establish the attributes of your planned project

• Search a repository of completed projects

If a suitable analogue is available:

• Use the effort from the analogue as your base

• Compare each attribute and adjust accordingly

Analogue example

Take the actual size of the new project: 540FPs

X the Analogue’s PDR of 14.8hrs per FP

= 7,992hrs project work effort

divide by the Analogue’s speed of delivery: 30.1FPs per month

= 17.9 months duration

Caution !

• The best analogues will normally be found in your own project repository

• The fewer the shared attributes between the analogue project and the target project, the more careful you must be.

Rule of Thumb! - Checking Estimates of Project Duration

• There are some “natural” durations for ranges of project size and effort, confirming that there is a limit to how far you can reduce duration by adding staff.

• The Web Subscription Service provides detailed tables of durations for different project sizes and effort.

Effort Hours Duration Mths Mths Av.

100 - 800 1 to 8 1mth per 100-200hrs800 - 2000 3 to 7 52000 – 3200 4 to 9 73200 – 20000 8 to 12 10> 20000 >14 24

Team

Size

One of the most important factors in estimating

Team size productivity

Rule of Thumb! – Project Size/Team Size

For small teams the ISBSG data reveals that there is a simple relationship between project size and team size:

• Teams of 4 developers, the output range is 60 to 100 FPs per staff member.

• Teams of 10 or more, the range is 20 to 50 FPs per staff member.

Role Effort Ratios

Rule of Thumb! – Work Effort Ratios

Test17%

Impl.9%

Plan6%

Spec20%

Build48%

Work Effort Breakdown – New Developments

Cost - Rules of Thumb

Supporting the Project Team, (data base

Administration etc.), typically costs about 15%

of the total development team costs.

Useful references

• Practical Project Estimation – www.isbsg.org• Estimating Software Costs – Second edition, Capers

Jones• My Life is Failure – Jim Johnson• Practical Risk Assessment for Project Management –

Stephen Grey• Project Estimation with Use Case Points – Roy Clem,

http://www.codeproject.com/• Agile Estimating & Planning – Mike Cohn

Software Estimation

Do we make it too hard?