Cost Estimation

1. Cost Estimation Van Vliet, chapter 7 Glenn D. Blank

2. Cost estimates: when and why • When does a contractor estimate costs for building a house? • Before construction begins, let alone payment • Takes into account subcontracts for foundation, framing, plumbing, electrical, etc. • Hierarchy, modularity and abstraction support estimates • Who benefits from these cost estimates? • Can cost estimates have similar advantages for software projects? • On the other hand, can cost estimates for software projects be as accurate as for house contracts? • Why or why not?

3. Person-months • Most software cost estimates assume cost = effort • Effort = man-month, i.e., a person’s work for a month • Usually ignores cost of hardware or cost of maintenance • Fred Brooks, The Mythical Man-Month, 1975: • “Cost does indeed vary as the product of the number of men and the number of months. Progress does not. Hence the man-month as a unit for measuring the size of a job is a dangerous and deceptive myth. It implies men and months are interchangeable.” • “Men and months are interchangeable commodities only when a task can be partitioned among many workers with no communication among them. This is true of reaping wheat or picking cotton; it is not even approximately true of systems programming.” • “Adding manpower to a late project makes it later.”

4. LOC/KLOC • LOC: lines of code • KLOC: kilo lines of code, or (lines of code) / 1000 • Still regarded as most accurate way to measure labor costs • What are some uncertainties about measuring LOC? • Should comment lines count? Or blank lines for formatting? • How do we compare lines of assembly language vs. high-level language like C++ or Java? • How do you know how many LOC the system will contain when it’s not implemented or even designed yet? • How do you account for reuse of code?

5. Bottom up estimates • Estimate the cost for each module or unit of code • Sum the cost of the modules • Add an estimate of integration costs • Assumes that design is far enough along that all modules are defined • Another bottom-up estimate: • Break the work into subtasks small enough to estimate • Person responsible for performing the subtask estimates the effort required • Software architectural design work must be done before such an estimate is possible

6. Formal or algorithmic cost models • Goal: compute the cost of a software project, with formulas and constant factors called “cost drivers” • Formal cost models are thought to be the best way we have to predict the software development costs • But for many projects it’s not possible to gather the input data needed • At best, formal cost models yield estimates that are at most 25% off, 75% of the time, for the projects used to derive the model • May imply more uncertainty for new projects (the ones we want to estimate)

7. COCOMO (1981) • COCOMO – COnstructive COst Model • Basic formula is: Effort = bKLOCc • where b, c are constants whose values depend on the project characteristics • Basic COCOMO distinguishes three classes of projects: • Organic: small teams develops software in known environment, so developers can contribute early: b=2.4, c=1.05 • Embedded: Environment is inflexible and constrained, i.e., air traffic control or embedded weapons systems, b=3.6, c=1.20 • Semidetached: Team members have varying levels of experience working on larger projects, b=3.0, c=1.12 • Intermediate COCOMO – factors in 15 additional cost drivers, i.e., complexity of software, documentation needs, etc. • E.g., if complexity is low, adjust this factor by 0.85 (40*0.84=34 months) What do you think of measuring cost factors this way? • Detailed COCOMO – phase sensitive, uses separate multipliers for each project phase, from requirements through integration

8. Function Point analysis(1979, 1983) • Rather than counting LOC, count data structures (“function points”) • Intended to be a user-oriented measure of system function • Particularly suitable for business applications • Less well suited for systems such as compilers, real-time systems, etc. • Key inputs are number of: • Input types, output types, inquiry types, logical internal files, interfaces • May also apply corrections for differences in complexity of data types • After computing the function points, map them to LOC • Formula depends on the particular programming language to be used • Based on older, batch-oriented systems • Object Point analysis may be more suitable for interactive, screen-oriented systems • Note: objects are screens, reports and 3GL modules, not OOP classes

9. COCOMO 2 (1995, 1997) • Tuned to applications and life-cycle practices of 90’s and 2000’s • Three different models applied at different life cycle stages: • Application Composition model • Intended for prototypes, using components or CASE tools • Similar goal as for Function Point analysis • Based on counting Object Points (instead of function points) • Early Design model • For the architectural design phase • Incorporates some aspects of Function Point analysis • Post-Architecture model • For the development stage • Most detailed • Similar to the original COCOMO model • Adds many new cost drivers: • Personnel capabilities, use of software tools, multi-site development, etc.