1. Cost Estimation What is estimated? –resources (humans, components, tools) –cost (person-months) –schedule (months) Why? –Personnel allocation –Contract bids –Go/No-Go decisions –Make vs Buy decisions

2. Dimensions “Men do not equal months” (Brooks) Consider –calendar time vs number of people –total effort vs number of people –total effort vs calendar time allowed? “Adding people to a late project usually makes it later” (Brooks) Note: people requirements usually uneven

3. Software pricing factors

4. Difficulties –“outside” pressure –lack of historical info –poor specifications –moving target –unstable environment “a software cost estimation approach is doing well if it can estimate costs within 20%, 70% of the time, on its own turf” - Boehm 1981

5. Risks Cost of under estimation –lose $$ –pressure/stress/hangovers/domino Cost of over estimation –tie up resources –miss out on other projects Cost of no estimation –no historical data or experience is gained

6. Preparation Determine Scope - function- performance - constraints- interfaces - reliability Determine (estimate) resources - people- software- environment Reliable historical information

7. Methods Reality? –Parkinson’s Law –Pricing to win Expert judgment by analogy –Decomposition –Delphi Algorithmic Models …

8. Algorithmic Models Simple formulas –usually a function of size estimate Allows calibration GIGO Outputs vary, even within a model - effort- time - stages COCOMO in 1981 was the classic model

9. Constructive Cost Model, B. Boehm, 1981 Basic Model 1.Estimate KDSI 2.Select product's Development Mode (straightforward, embedded, etc.) 3.Calculate Person-Months as F(KDSI, DM) 4.Calculate Dev. Time as F(PM, DM) Intermediate –Rank project and process on 15 categories (reliability, programmer's capabilities) to obtain ‘effort multipliers’ –Can analyze tradeoffs Advanced - Involves subsystems and subtasks.

10. COCOMO 81 Basic

11. COCOMO 81 Intermediate Cost DriversVLowLowNomnlHighVHighEHigh Required reliability0.750.881.001.151.40 Database size0.941.001.081.16 Product complexity0.700.851.001.151.301.65 Execution time constraint 1.001.111.301.66 Analyst capabilities1.461.191.000.860.71 Applications experience1.291.131.000.910.82 Language experience1.141.071.000.95 Tool use1.241.101.000.910.83 Take the nominal effort and multiply by 15 effort multipliers:

12. What's a line of code? –The measure was first proposed when programs were typed on cards with one line per card. –How does this correspond to statements as in Java which can span several lines or where there can be several statements on one line? –Do you include comments, data declarations, library modules? –Is this really what you want to base “productivity” on? Lines of code

13. Function points Includes external inputs/outputs, user interactions, external interfaces, files used by the system 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 4GL FPs are very subjective. They depend on the estimator. –Automatic function-point counting is impossible

14. Object points Object points are an alternative function-related measure to function points when 4Gls or similar languages are used for development Object points are NOT the same as object classes 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 3GL modules that must be developed to supplement the 4GL code

15. Object point estimation Object points are easier to estimate from a specification than function points as they are simply concerned with screens, reports and 3GL modules They can therefore be estimated at an early point in the development process. At this stage, it is very difficult to estimate the number of lines of code in a system

16. COCOMO II (1996) Hierarchy –analysis stage model –design stage model –post architecture model Sizing options –LOC –function points –object points (don’t worry about this)

17. COCOMO 2 levels COCOMO 2 is a 3 level model that allows increasingly detailed estimates to be prepared as development progresses Early prototyping level –Estimates based on object points and a simple formula is used for effort estimation Early design level –Estimates based on function points that are then translated to LOC Post-architecture level –Estimates based on lines of source code

18. Estimate uncertainty