1. Software Estimation How hard can it be? Peter R Hill

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

3. A quick introduction to the International Software Benchmarking Standards Group (ISBSG) The global and independent source of data and analysis for the IT industry

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

5. The Importance of Software Size

6. 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 Feasibility Requirement s Design Build TestImplement EstimatingUncertainty + traditional ‘Task- based’ estimating Detailed Functional sizing Approx. Functional sizing When can we establish software size ?

7. Software Estimation What we can estimate: – Size – Effort – Duration – Cost

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

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

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

11. Establishing Functional Size

12. Establishing functional size Panic! “I don’t use functional sizing, should I leave now?” No! You can “cheat” !

13. Estimating Functional Size from Use Cases

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

15. Use Case Sizing & Conversion Go to http://www.codeproject.comhttp://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.

16. Estimating Functional Size from a Logical Data Model

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

18. Function Point Breakdown

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

20. 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.comwww.totalmetrics.com o Software Risk Master – Functional Size Patterns – Capers Jones

21. So now we have a size, what can we do with it?

22. Median Project Delivery Rates

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

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

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

26. Macro Estimating Techniques

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

28. Estimation using Equations

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

30. 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)

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

32. Equation example Ok Let’s have a go: Software project: –Midrange platform –3GL language type –Size of 460 function points

33. Equation example - using tables Project Delivery RatePDR RE = 126.3  Size –0.435 = 126.3  460 –0.435 = ~ 9 hours per function point Project Work EffortPWE RE = 126.3  Size 0.565 = 126.3  460 0.565 = ~ 4,050 hours

34. ISBSG Early Estimate Checker

35. Estimation using Comparison

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

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

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

39. Example comparison estimate Project Delivery RatePDR AC = average of category median project delivery rates = 11 hours per fp Project Work EffortPWE AC = PDR AC  Functional Size = 11  460= 5,060 hours

40. Example comparison estimate using ISBSG tool

41. Estimation using Analogy

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

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

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

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

46. 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 81mth per 100-200hrs 800 - 2000 3 to 75 2000 – 32004 to 97 3200 – 200008 to 1210 > 20000 >1424

47. Team Size One of the most important factors in estimating

48. Team size productivity

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

50. Role Effort Ratios

51. Rule of Thumb! – Work Effort Ratios Work Effort Breakdown – New Developments

52. Cost - Rules of Thumb Supporting the Project Team, (data base Administration etc.), typically costs about 15% of the total development team costs.

53. 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/ http://www.codeproject.com/ Agile Estimating & Planning – Mike Cohn

54. Software Estimation Do we make it too hard?