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 = bKLOC c 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.