1. 1 COST ESTIMATION Basics, COCOMO, FP

2. 2 What is estimated? TIME MONEY TIME: –duration, chronological weeks, months, years –effort, person-month (man-month) – unit is typically month (year)

3. 3 Basic Relation person-month / nbr-of-people = duration example: –36 person-month, 1 developer, 36 month –36 person-month, 2 people, 18 month –36 person-month, 12 people, 3 month Beware of the “million monkey” syndrome [Brooks]

4. 4 Basic Principles - Decomposition It is easier to estimate time & cost for a smaller unit than to estimate time & cost for the complete system. Estimation by decomposition: –Decompose your system or development process, estimate time & cost for the parts and summarize.

5. 5 Basic Principles - Empirical Knowledge Find parameters which characterise your system and derive time & cost based on a documented case history. Empirical model: time = function (parameters) You rely on a correlation between time & cost and the set of independent parameters

6. 6 Typical Parameters number and complexity of functions number and complexity of modules number of lines of code (LOCS) number and duration of steps in your development process skills and technologies involved

7. 7 When to do your estimate the later the more accurate your parameters early estimate: –you need to estimate your parameters –divide an conquer strategy –garbage in => garbage out keep your estimate up-to-date

8. 8 COCOMO [B. Boehm] COnstructive COst MOdel empirical method hierarchy of COCOMO models (parameters) –basic: prg size –intermediate: prg size & cost drivers –advanced: prg size & cost drivers per phase Cost Drivers: Personnel/Team Capability, Product Complexity, Req. Reliability, Problem Domain Experience, Development practices, Tools, Language Experience, etc. for each project type

9. 9 COCOMO - Parameters prg size: LOCS (lines of code) “cost drivers” evaluate: product, hardware, personnel, project measured on a 6 point scale allow for derivation of an EAF (Effort Adjustment Factor)

10. 10 COCOMO - Project Types organic mode: –relatively small and simple –small team of skilled developers semi-detached: –intermediate in size and complexity –mixed skill levels on the team embedded: –hard constraints for HW, SW, operation

11. 11 Basic COCOMO - The Functions person-month = a*(KLOC) b duration-in-month = c*(person-month) d KLOC... kilo lines of code a, b, c, d depend on the project type

12. 12 Basic COCOMO - Tables project type:abcd organic2.41.052.50.38 semi-detached3.01.122.50.35 embedded3.61.202.50.32

13. 13 Basic Cocomo - Example You must decide on: –LOCS: 50,000 lines of code –project type: semi-detached person-month: 3.0*(50) 1.12 ~ 240 duration-in-month: 2.5*(240) 0.35 ~ 17 number of people:240 / 17 ~ 14

14. 14 Function Points (FP) Based on the number and complexity of the system functions to be delivered to the customer Steps: –(1) Categorize the functions according to type (input, output, database, interface, etc.) and complexity (simple, moderate, average, complex, highly complex) –(2) Derive the number of function points: multiply the number of functions in each category by the appropriate complexity weights and total the number of PF –(3) Determine the total Project Influence Factors (PIF): PIF types (distributed processing,multiple development sites, etc.), and levels of difficulty ( from 0-no difficulty, to 3-average difficulty, to 5- great difficulty) –(4) Compute the Total Effort: PM =.036 * FP * PIF

15. 15 FP: Example (1&2) PF (3) PIF (4) Total Effort FunctionDiff. LevelNumber ComplexityFP Input DB Output 2 4 4 M A S Total 3 10 3 6 40 12 58 Total PIFDifficulty Level Data performance objectives Multiple sites 2 5 7 PM = 0.036*58*7 = 14.616 All values from FP tables.

16. 16 Function Points: Evaluation Tightly coupled with Functional Requirements (see SRS) - works well with DFDs Intuitive Method - makes intuitive sense to the customers Notice: A rough estimate of the functional requirements will yield ONLY a very rough estimate of total effort

17. 17 “3 Time Programming” Rule Estimate the number of software modules/programs and their complexity Estimate the effort required to complete coding and debugging of each module and the total programming effort Total Project Effort = (Estimated Programming Effort) * 3 This includes Management, Documentation, Design, …. => Helpful ONLY to experienced programmers => Corrects at least the OPTIMISTS A “Rough Guess” is better than a “Wild Guess” or “No Estimate”

18. 18 It Couldn’t be More Simple: