Software Cost Estimation COMP 3663 D L Silver

Software Cost Estimation COMP 3663 D. L. Silver, Ph. D. Portions from slides by Ian Sommerville, Software Engineering, 6 th edition. Chapter 23 Slide 1

Software Cost Estimation § Predicting the resources required for a software development process Portions from slides by Ian Sommerville, Software Engineering, 6 th edition. Chapter 23 Slide 2

Topics covered § § § Feasibility Analysis Productivity measures Estimation techniques Algorithmic cost modelling Project duration Portions from slides by Ian Sommerville, Software Engineering, 6 th edition. Chapter 23 Slide 3

Feasibility Analysis Feasibility – the measure of how beneficial or practical an information system will be to an organization. Feasibility analysis – the process by which feasibility is measured. Portions from slides by Ian Sommerville, Software Engineering, 6 th edition. Chapter 23 Slide 4

Three Tests For Feasibility Technical feasibility – a measure of the practicality of a technical solution and the availability of technical resources and expertise. Economic feasibility - a measure of the costeffectiveness of a project or solution. Operational feasibility – a measure of how well a solution will work or be accepted in an organization. Portions from slides by Ian Sommerville, Software Engineering, 6 th edition. Chapter 23 Slide 5

Economic Feasibilty = Cost-Benefit Analysis Costs: § Development costs are one time costs that will not recur after the project has been completed. § Operating costs are costs that tend to recur throughout the lifetime of the system. Such costs can be classified as: § Fixed costs — occur at regular intervals but at relatively fixed rates. § Variable costs — occur in proportion to some usage factor. Benefits: § Tangible benefits are those that can be easily quantified. § Intangible benefits are those benefits believed to be difficult or impossible to quantify. Portions from slides by Ian Sommerville, Software Engineering, 6 th edition. Chapter 23 Slide 6

Three Popular Techniques to Assess Economic Feasibility § Payback Analysis § Return On Investment § Net Present Value The Time Value of Money is a concept that should be applied to each technique. The time value of money recognizes that a dollar today is worth more than a dollar one year from now. Portions from slides by Ian Sommerville, Software Engineering, 6 th edition. Chapter 23 Slide 7

Software cost components § Hardware and software costs § Travel and training costs § Personnel costs (the dominant factor in most projects) § § salaries of people involved in the project benefits and insurance costs § Must also take project overhead into account § § § costs of building, heating, lighting costs of networking and communications costs of shared facilities (e. g library, staff restaurant, etc. ) Portions from slides by Ian Sommerville, Software Engineering, 6 th edition. Chapter 23 Slide 8

Costs for a Proposed System Portions from slides by Ian Sommerville, Software Engineering, 6 th edition. Chapter 23 Slide 9

Fundamental estimation questions § How much effort is required to complete an activity? § How much calendar time is needed to complete an activity? § What is the total cost of an activity? § Project estimation and scheduling are interleaved management activities Portions from slides by Ian Sommerville, Software Engineering, 6 th edition. Chapter 23 Slide 10

Costing and pricing § Estimates are made to discover the cost, to the developer, of producing a software system § There is not a simple relationship between the development cost and the price charged to the customer § Broader organisational, economic, political and business considerations influence the price charged Portions from slides by Ian Sommerville, Software Engineering, 6 th edition. Chapter 23 Slide 11

Productivity measures § 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 Portions from slides by Ian Sommerville, Software Engineering, 6 th edition. Chapter 23 Slide 12

Lines of code § What is a line of code? § Productivity measures will vary from language to language – consider difference between lines of code in assembler versus Java § Relationship to functionality must be based on past efforts in the same language Portions from slides by Ian Sommerville, Software Engineering, 6 th edition. Chapter 23 Slide 14

Productivity estimates - LOC System Category LOC/person-month Real-time embedded systems 40 -160 Systems programs 150 -400 Commercial applications 200 -800 Portions from slides by Ian Sommerville, Software Engineering, 6 th edition. Chapter 23 Slide 15

Productivity estimates – Function points § 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 § The function point count is computed by multiplying each raw count by the weight and summing all values Portions from slides by Ian Sommerville, Software Engineering, 6 th edition. Chapter 23 Slide 16

Function points § § Function point count modified by complexity of the project FPs can be used to estimate LOC depending on the average number of LOC per FP for a given language § § § LOC = AVC * number of function points AVC is a language-dependent factor varying from 200 -300 for assemble language to 2 -40 for a high-level languages FPs are very subjective. They depend on the estimator. § Automatic function-point counting is impossible Portions from slides by Ian Sommerville, Software Engineering, 6 th edition. Chapter 23 Slide 17

Factors affecting productivity Portions from slides by Ian Sommerville, Software Engineering, 6 th edition. Chapter 23 Slide 18

Quality and productivity § All metrics based on volume/unit time are flawed because they do not take quality into account § Productivity may generally be increased at the cost of quality § It is not clear how productivity/quality metrics are related § If change is constant then an approach based on counting lines of code is not as meaningful Portions from slides by Ian Sommerville, Software Engineering, 6 th edition. Chapter 23 Slide 19

Estimation techniques § There is no simple way to make an accurate estimate of the effort required to develop a software system § § § Initial estimates are based on inadequate information in a user requirements definition The software may run on unfamiliar computers or use new technology The skills of people working on the project may be unknown § Project cost estimates may be self-fulfilling § The estimate defines the budget and the product is adjusted to meet the budget Portions from slides by Ian Sommerville, Software Engineering, 6 th edition. Chapter 23 Slide 20

Estimation techniques § § § Expert judgement Estimation by analogy Parkinson's Law Pricing to win Algorithmic cost modelling Portions from slides by Ian Sommerville, Software Engineering, 6 th edition. Chapter 23 Slide 21

Expert judgement § One or more experts in both software development and the application domain use their experience to predict software costs. Process iterates until some consensus is reached. § Advantages: Relatively cheap estimation method. Can be accurate if experts have direct experience of similar systems § Disadvantages: Very inaccurate if there are no experts! Portions from slides by Ian Sommerville, Software Engineering, 6 th edition. Chapter 23 Slide 22

Estimation by analogy § The cost of a project is computed by comparing the project to a similar project in the same application domain § Advantages: Accurate if project data available § Disadvantages: Impossible if no comparable project has been tackled. Needs systematically maintained cost database Portions from slides by Ian Sommerville, Software Engineering, 6 th edition. Chapter 23 Slide 23

Parkinson's Law § The project costs whatever resources are available (typically used within an organization) § Advantages: No overspend § Disadvantages: System is usually left unfinished Portions from slides by Ian Sommerville, Software Engineering, 6 th edition. Chapter 23 Slide 24

Pricing to win § The project costs whatever the customer has to spend on it § Advantages: You get the contract § Disadvantages: Costs do not accurately reflect the work required. Either: § § The customer does not get the desired system, or The customer overpays. Portions from slides by Ian Sommerville, Software Engineering, 6 th edition. Chapter 23 Slide 25

Pricing to win § This approach may seem unethical and unbusiness -like § However, when detailed information is lacking it may be the only appropriate strategy § The most ethical approach: § § The project cost is agreed on the basis of an outline proposal and the development is constrained by that cost A detailed specification may be negotiated or an evolutionary approach used for system development Portions from slides by Ian Sommerville, Software Engineering, 6 th edition. Chapter 23 Slide 26

Top-down and bottom-up estimation § Any of these approaches may be used top-down or bottom-up § Top-down § Start at the system level and assess the overall system functionality and how this is delivered through sub-systems § Bottom-up § Start at the component level and estimate the effort required for each component. Add these efforts to reach a final estimate Portions from slides by Ian Sommerville, Software Engineering, 6 th edition. Chapter 23 Slide 27

Top-down estimation § Can be used without knowledge of the system architecture and the components that might be part of the system § Takes into account costs such as integration, configuration management and documentation § Can underestimate the cost of solving difficult low-level technical problems Portions from slides by Ian Sommerville, Software Engineering, 6 th edition. Chapter 23 Slide 28

Bottom-up estimation § Usable when the architecture of the system is known and components identified § Accurate method if the system has been designed in detail § May underestimate costs of system level activities such as integration and documentation Portions from slides by Ian Sommerville, Software Engineering, 6 th edition. Chapter 23 Slide 29

Estimation methods § Each method has strengths and weaknesses § Estimation should be based on several methods § If these do not return approximately the same result and the differences cannot be reconciled, there is insufficient information available § Some action should be taken to find out more in order to make more accurate estimates Portions from slides by Ian Sommerville, Software Engineering, 6 th edition. Chapter 23 Slide 30

Experience-based estimates § Estimating is primarily experience-based § However, new methods and technologies may make estimating based on experience inaccurate § § § Object-oriented rather than function-oriented development Client-server systems rather than mainframe systems Many off-the-shelf components Component-based software engineering Use of new CASE tools and program generators Portions from slides by Ian Sommerville, Software Engineering, 6 th edition. Chapter 23 Slide 31

Algorithmic cost modelling § A formulaic approach based on historical cost information and which is generally based on the size of the software § Cost is estimated as a mathematical function of product, project and process attributes whose values are estimated by project managers Portions from slides by Ian Sommerville, Software Engineering, 6 th edition. Chapter 23 Slide 32

Algorithmic cost modelling § Effort in PM = A ´ Size. B ´ M § A is depends in on the type of software that is being developed (simple, moderate, embedded) [will vary 2. 43. 5] § Size is an estimate of the code size or other functional assessmemt [thousands of lines of code, ie. 5, 400 LOC 5. 4] § B reflects the disproportionate effort for large projects over small projects [typically 1. 0 -1. 5] § M is a multiplier reflecting a combination of product, process and people attributes (e. g. desired reliability, reuse required, personnel capability and expereince, support facilities) [will vary up from 1. 0] PM = person months Portions from slides by Ian Sommerville, Software Engineering, 6 th edition. Chapter 23 Slide 33

Estimate uncertainty: As the project progresses the probablilty of a difference in actual to estimate decreases Actual personmonths x = estimated person-months Portions from slides by Ian Sommerville, Software Engineering, 6 th edition. Chapter 23 Slide 35

COCOMO § § § Constructive Cost Model An empirical model based on project experience Well-documented, ‘independent’ model which is not tied to a specific software vendor Long history from initial version published in 1981 (COCOMO-81) through various instantiations to COCOMO 2 takes into account different approaches to software development, reuse, etc. Can be used as a sanity check Portions from slides by Ian Sommerville, Software Engineering, 6 th edition. Chapter 23 Slide 36

COCOMO 81 Effort (PM) = A * Size. B * M PM = person-months KDSI = thousand of delivered software instructions Portions from slides by Ian Sommerville, Software Engineering, 6 th edition. Chapter 23 Slide 37

Basic COCOMO Formulae (Boehm) Effort in Person-months = a KLOC b Duration in Months = c Effort d Where c = labour estimate, d = complexity of project type These values are selected from a table such as the one below. Software Project a b Organic 2. 4 1. 05 2. 5 0. 38 Semidetached 3. 0 1. 12 2. 5 0. 35 Embedded 3. 6 1. 20 2. 5 0. 32 (See page 105 of text) Portions from slides by Ian Sommerville, Software Engineering, 6 th edition. Chapter 23 c d Due to Boehm [Bo] Slide 38

Computing COCOMO Case Study Models Portions from slides by An Ian. Object-Oriented Sommerville, Perspective Softwareby Engineering, edition. 23 Adapted from Software Engineering: Eric J. Braude 6 th (Wiley 2001), Chapter with permission. Slide 39

Workshop § § § Estimate Actual 80 60 , 1 error 52. 5 44 , 1 error? ? 70 50 , 100% correct 37. 5 45 , 1 error Portions from slides by Ian Sommerville, Software Engineering, 6 th edition. Chapter 23 Slide 40