Cost estimation
1 / 9

Cost Estimation - PowerPoint PPT Presentation

  • Uploaded on
  • Presentation posted in: General

Cost Estimation . Van Vliet, chapter 7 Glenn D. Blank. 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.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.

Download Presentation

Cost Estimation

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript

Cost estimation
Cost Estimation

Van Vliet, chapter 7

Glenn D. Blank

Cost estimates when and why
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?

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.”

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?

Bottom up estimates
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

Formal or algorithmic cost models
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)

Cocomo 1981
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

Function point analysis 1979 1983
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

Cocomo 2 1995 1997
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.

  • Login