software estimation how hard can it be? peter r hill
Post on 31-Dec-2015
215 Views
Preview:
TRANSCRIPT
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.
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 ?
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
Panic!
“I don’t use functional sizing, should I leave now?”
No!
You can “cheat” !
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.
Establishing functional size
By using the known relationships between FP components - if you have a logical data model, you can derive an estimated size
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
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%.
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
• 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
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
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
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.
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
top related