- By
**jun** - Follow User

- 120 Views
- Uploaded on

Download Presentation
## PowerPoint Slideshow about 'Cost Estimation' - jun

**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 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

- 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

- 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 – 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)

- 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)

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

- Application Composition model

Download Presentation

Connecting to Server..