Software Estimation How hard can it be Peter

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

When can we establish software size ? In practice we need to estimate size before we have all the detail needed for a full functional size measurement Approx. Functional sizing + traditional ‘Task. Detailed Functional sizing based’ estimating Estimating Uncertainty Design Requirement s Feasibility Build Test Implement We therefore need a method of producing an approximate size from less detail. Source: B. Boehm, USC

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 estimating Based upon Statistical Analysis: Ø The most influential factors are: o Primary Programming Language o Platform MF, MR, PC, multi-platform o Team Size Ø For detailed analysis – ISBSG Subscription Service Ø Consider these most influential factors when estimating

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 ~35 fp (The overall range is from 15 fp to 75 fp) Examples: Application of 1, 500 fp ~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 also good tools available to establish an estimated size: o SCOPE™ - www. totalmetrics. com o 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 ~9 fp) • 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. 4 m

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%.

Macro Estimating 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 – 3 GL 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 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 Business type Financial Median delivery speed hrs per FP Language -Cobol Median PDR FP per mth ~15 51. 2 ~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: 540 FPs X the Analogue’s PDR of 14. 8 hrs per FP = 7, 992 hrs project work effort divide by the Analogue’s speed of delivery: 30. 1 FPs 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 100 - 800 - 2000 – 3200 – 20000 > 20000 Duration Mths 1 to 8 3 to 7 4 to 9 8 to 12 >14 Mths Av. 1 mth per 100 -200 hrs 5 7 10 24

Team Size One of the most important factors in estimating

Team size productivity Team Size Impact on Productivity 18 16 14 Hours to produce one FP 12 10 8 6 4 2 0 1 2 3. . 4 Size of team 5. . 8 >8

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