SOFTWARE COST ESTIMATION

1. SOFTWARE COST ESTIMATION Inthira Srivrunyoo & Tianjie Deng CSc 8350, Spring 2007 Georgia State University Department of Computer Science

2. Table of Contents • To introduce the purpose and components of software cost estimation • To describe three methods for software productivity assessment • To describe two major types of cost estimation methods • To describe the principles of some popular algorithmic cost estimation models (COCOMO, COCOMO II) • To analyze the problem of exist algorithmic models • To describe 11 software estimation steps

3. Software Cost Estimation • Overestimate? • Underestimate? • How much effort is required to complete software? • Development effort is the amount of labour used in person-months or person-days. • What is the total cost of software? Software Cost Estimation ---- the process of predicting the effort required to develop a software system.

4. Motivation & Purpose • Budgeting: the primary use. Accuracy of the overall estimate is the most desired capability. • Tradeoff and risk analysis: an important additional capability is to illuminate the cost and schedule sensitivities of software project decisions • Project planning and control: an important additional capability is to provide cost and schedule breakdowns by component, stage and activity. • Software improvement investment analysis: an important additional capability is to estimate the costs as well as the benefits of such strategies as tools, reuse, and process maturity.

5. Software Cost Components • Hardware and software costs. • Travel and training costs. • Effort costs (the dominant factor in most projects, cost estimates mainly focus on this ) • Not only the salaries of engineers but also overhead costs • Cost of providing, heating and lighting office space • Costs of support staff such as accountants, administrators, system managers, cleaners and technicians • Costs of networking and communications • Costs of central facilities such as a library or recreational facilities • Costs of Social Security and employee benefits such as pensions and health insurance

6. Software Productivity • Productivity estimates are usually based on measuring attributes of the software and dividing this by the total effort (like the number of person-hours required to produce them) required for development. • Two types of metric that have been used: • Size related measures based on some output from the software process. This may be lines of delivered source code, object code instructions, etc. • Function-related measures based on an estimate of the functionality of the delivered software. Function-points are the best known of this type of measure.

7. Lines of Code • Lines of source code per programmer-month (LOC/pm) is a widely used software productivity metric • LOC/pm = the total number of lines of source code / the count by the total time in programmer-months required to complete the project. • Problem: • The same functionality takes more code to implement in a lower-level language than in a high-level language. • Measures of productivity based on lines of code suggest that programmers who write verbose code are more productive than programmers who write compact code. Conclusion:If one language requires more lines than another to implement the same functionality, or if the programmers have different preference on the style of the program, productivity estimates will be anomalous.

8. Function Points • Amount of functionality in a system based on a combination of program characteristics • external inputs and outputs; • user interactions; • external interfaces; • files used by the system. • A weight is associated with each of these and the unadjusted function point count (UFC) is computed by multiplying each raw count by the weight and summing all values.

9. Object Points • An alternative function-related measure to function points • The number of object points in a program is a weighted estimate of • The number of separate screens that are displayed; • The number of reports that are produced by the system; • The number of program modules that must be developed to supplement the database code; S = W1F1 + W2F2 +W3F3 + … • Advantages • Object points are easier to estimate from a high-level software specification than function points as they are simply concerned with screens, reports and programming language modules. • They can be estimated at a fairly early point in the development process when it is very difficult to estimate the number of lines of code in a system. • Are used in the COCOMO II estimation model (where they are called application points)

10. Estimation Techniques

11. Algorithmic Models • Use a mathematical formula to predict project costs. A most general form for a algorithmic method: Effort = A*SizeB*M • A: a constant factor that depends on local organizational practices and the type of software that is developed. • Size: code size, function point, object point • B: The value of exponent B usually lies between 1 and 1.5 This exponent is associated with the size estimate. Cost do not normally increase linearly with project size. As the size of the software increases, extra costs are incurred because of the communication overhead of larger teams, more complex configuration management, more difficult system integration. Therefore, the larger the system, the larger the value of this exponent. • M: a multiplier made by combining process, product and development attributes, such as the dependability requirements for the software and the experience of the development team. • Most models are similar but they use different values for A, B and M.

12. Some Popular Algorithmic Models • COCOMO • An empirical model based on project experience called COCOMO 81designed in 1981 by Barry Boehm. • The basic COCOMO equations take the form • E=ab(KLOC)bb • D=cb(E)db • P=E/D E is the effort applied in person-months, D is the development time in chronological months, KLOC is the estimated number of delivered lines of code for the project (expressed in thousands), and P is the number of people required. The coefficients ab, bb, cb and db have different values according to the type of the project.

13. COCOMO II Models • COCOMO 81 was developed with the assumption that a waterfall process would be used and that all software would be developed from scratch. • Since its formulation, there have been many changes in software engineering practice and COCOMO II is designed to accommodate different approaches to software development. • COCOMO II incorporates a range of sub-models that produce increasingly detailed software estimates. • The sub-models in COCOMO II are: • Application composition model. Used when software is composed from existing parts. • Early design model. Used when requirements are available but design has not yet started. • Reuse model. Used to compute the effort of integrating reusable components. • Post-architecture model. Used once the system architecture has been designed and more information about the system is available.

14. Early Design Model • Use when requirements are available but design has not yet started. • Use to evaluate alternative software architectures and concepts of operation • Based on function points E = 2.94* Size*EAF Size in KLOC ( converted from function point) EAF the effort adjustment factor using 7 cost drivers

15. Application Composition Model • Supports prototyping to resolve potential high-risk issues such as user interfaces, software/system interaction • Based on object point: number of screens, report, and 3GL components • Formula is E = ( Object points * (1 - %reuse/100 ) ) / PROD E is the effort in person-months PROD is the productivity.

16. Post-architecture Model • Used once the system architecture has been designed and more information about the system is available. E = 2.55*EAF*Sizeb EAF the effort adjustment factor using 17 cost drivers B the set of 5 scale factors Size the number of lines of new code to be developed

17. COCOMO II Models (cont.) • Inputs -- Software size -- Product attributes: describe the environment in which the program operates -- Platform attributes: describe the relationship between a program and its host or development computer -- Personnel attributes: describe the capability and experience of personnel assigned to the project -- Project attributes: describe selected project management facets of a program -- Scale factors: capture features of a software project that can account for relative economies or diseconomies of scale -- Each of the parameters can be rated on a scale that generally varies from "very low" to "extra high” • Outputs COCOMO II gives a pessimistic, most likely and optimistic estimate for the effort, schedule, and costs. Effort is presented in work-months, schedule in months, and costs in dollars.

18. COCOMO II Models (cont.) Example of COCOMO 2 Output Window

19. Problems of Algorithmic Models Structure of model • constants in empirical formulas perform well in limited environments. • Rapid change in software technology Complexity of cost drivers • many of the cost drivers affect each other. • the cost drivers (B, M) are also extremely subjective. Size Estimation • size is difficult to predict early in the development lifecycle.

20. New approaches Use artificial intelligence techniques • Finnie and Wittig applied artificial neural networks (ANN) and case-based reasoning (CBR) to estimation of effort. • Srinivasan and Fisher used machine learning approaches based on regression trees and neural networks to estimate costs. • Petr Musilek, Witold Pedrycz used fuzzy logic with COCOMO.

21. Software Estimation Steps

22. Example Software Estimate • Project Description • Your team is developing ROM Flight Software (FSW) for a spacecraft flight project. • The software requirements for this project are immature at this point. • Any new code developed will be in C.

23. STEP 1- Gather and Analyze the Software Functional and Programmatic Requirements • The software manager, system analysts, and cognizant software engineers • analyzed the system functional requirements • defined the software functional requirements. • defined the architecture in terms of software segments to be developed • decomposed each segment to the lowest level function possible

24. STEP 2 - Define the Work Elements and Procurements • defined the work elements and procurements for the software project that requires estimation.

25. STEP 3 - Estimate the Software Size • For the new code segments, two methods were used to estimate the size: Analogyand Statistical. • Measure of software size  the number of source lines of code (SLOC) • The first method (Analogy)

26. STEP 3 - Estimate the Software Size • The second method (Statistical) • Result: the mean size estimates for each software segment

27. STEP 4 – Estimate Software Effort • Step 4a - Convert the Software Size to Software Development Effort SW_Development_Effort (work-months)= Size_Estimate(SLOC) / SW_Development_Productivity

28. STEP 4a – Convert the Software Size to Software Development Effort • Adjust the effort estimates by multiplying them by the effort multiplier

29. Step 4b – Extrapolate and Complete the Effort Estimate • Up to this step, we have only covered the Software Development (activities associated with Software System Engineering, Software Engineering, andSoftware Test Engineering) = 50 WM • Step 4b - Effort such as Software Management effort and Software Quality Assurance Effort, are in addition to the Software Development Effort.

30. Step 4b – Extrapolate and Complete the Effort Estimate Estimator #1: FSW Management  50 WM * 12% = 50*12/100 = 6

31. STEP 5 - Schedule the Effort

32. STEP 6 - Calculate the Cost • The software manager input the consensus effort estimates and the cost of procurements into a budgeting tool that incorporates labor rates and institutional burdens to determine the overall cost

33. STEP 7 - Determine the Impact of Risks • Facts: • 55% of software projects exceed budget by at least 90%. • Software projects at large companies are not completed 91% of the time. • Of the projects that are completed, only 42% of them have all the originally • proposed features • The software manager, cognizant engineers, and software estimators met to identify the major risks and estimate their impact on the cost estimate based on the table below:

34. STEP 7 - Determine the Impact of Risks • readjusted their cost estimate based on risk: • $1,012,000 x 1.1526 = $1,166,431

35. STEP 8 - Validate and Reconcile the Estimates • The software manager, software estimators, and engineers performed a model-based estimate (COCOMO II) to validate their primary estimate.

36. STEP 9 - Reconcile the Estimates, Budget, and Schedule • The software manager, software engineers, and software estimators working with the sponsor reviewed the estimates with respect to the project-imposed budget • Total Effort (WM): Margin = [ 72(Budgeted) – 60 (Estimated)] / 72 (Budgeted) = 0.167 = 16.7%

37. STEP 10 - Review and Approve the Estimates • The software engineers that did the estimates, a software engineer with experience on a similar project, and management conducted a review and approved the estimates. • The review included: • Confirming the WBS and the software architecture. • Verifying the methods used for deriving the size, effort, schedule, and cost. • Ensuring the assumptions and input data used to develop the estimates were correct. • Ensuring that the estimates were reasonable and accurate given the input data.

38. STEP 11 - Track, Report, and Maintain the Estimates • check the accuracy of the software estimates over time, and provide the estimates to save for use in future software project estimates. • The following information was recorded with the official software estimates for the project: • Project contextual and supporting information − Project name − Software organization − Platform − Language − Estimation method(s) and assumptions − Date(s) of approved estimate(s) • Estimated and actual size, effort, cost, and cost of procurements by WBS work element • Planned and actual schedule dates of major milestones and reviews • Identified risks and their estimated and actual impacts

39. References • Sunita Chulani. “Software Development Cost Estimation Approaches – A Survey”, The University of Southern California, 1998. • “Strategic Evolution of ESE Data Systems (SEEDS), Survey of Cost Estimation Tools” NewDISS Requirements and Cost Estimation, ESDIS Task 34, NAS5-00154. • Kim Johnson. “Software Cost Estimation: Metrics and Models”, University of Calgary, 1998. • Software Cost Estimation Web-Site (SCEW) [http://www.ecfc.u-net.com/cost/index.htm] • Capers Jones “Software Cost Estimation in 2002” STSC Cross Talk, June 2002 • Karen Lum, Michael Bramble, Jairus Hihn, John Hackney, Mori Khorrani, Erik Monson, “ Handbook for Software Cost Estimation” JPL, California, 2003 • Boehm, B.W., Abts, C., Clark, B., and Devnani-Chulani. S. “COCOMO II Model Definition Manual”, The University of Southern California, 1997.

40. Question ?