1 / 18

Cost Estimation

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. Dimensions. “Men do not equal months” (Brooks) Consider calendar time vs number of people

serena
Télécharger la présentation

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 • 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 • Estimate KDSI • Select product's Development Mode (straightforward, embedded, etc.) • Calculate Person-Months as F(KDSI, DM) • 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 Take the nominal effort and multiply by 15 effort multipliers:

  12. Lines of code • 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?

  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

More Related