1 / 18

CSC 395 – Software Engineering

CSC 395 – Software Engineering. Lecture 33: Planning & Estimation -or- How Much for the Program using Windows. Estimating Duration & Cost. Accurate estimations crucial Companies need to make $$$ Customers want reasonable & reliable prices Estimates depends on many, many variables

linh
Download Presentation

CSC 395 – Software Engineering

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. CSC 395 –Software Engineering Lecture 33: Planning & Estimation -or-How Much for the Program using Windows

  2. Estimating Duration & Cost • Accurate estimations crucial • Companies need to make $$$ • Customers want reasonable & reliable prices • Estimates depends on many, many variables • Many are unpredictable (e.g., human factors) • Programmers quit or “get hit by bus” • Get freak Oct. snow storm that shuts down city • Programmer pairs differ in effectiveness & productivity (up to 28x) • General models impossible to create

  3. Planning and Process • Estimates improve as more details known • Anyone confused by this point, give up

  4. Planning and Process • Properly engineered, estimate stays static as range shrinks • Start of requirements, estimate is $1 million • Likely actual cost is in $0.25M - $4M range • After requirements, estimate stays $1 million • Actual cost range shrunk to $0.5M - $2M • After analysis, estimate still $1 million • But cost range reduced to $0.67M - $1.5M • This is also when contract is finalized!

  5. Estimating Product’s End Size • Several metrics commonly relied upon • Use measurable quantities for simple calculations • Computed early in life cycle for use writing contracts • Includes “fudge factors” that can be tweaked • Factor unique to each group and situation • Tracking allows more precise estimates over time • FFP for medium-sized data processing projects • Function points used in many places

  6. FFP Calculation • Counts files (Fi), flows (Fl), & processes (Pr) • Size (S) estimated as S = Fi + Fl + Pr • Cost (C) estimated with S & efficiency factor b C = b  S

  7. Function Points Metric • Expressed in units of “function points” • Calculated using several inputs: • Number of inputs (Inp) • Number of outputs (Out) • Number of Inquiries (Inq) • Count of master files (Maf) • Interfaces in system (Inf) FP = 4 •Inp + 5 •Out + 4 •Inq + 10 •Maf + 7 •Inf

  8. Complex FP Calculation • Classify each of the individual components (e.g., each Inp, Out, Inq, Maf, Inf) • Assign appropriate number of function points • Sum is UFP (unadjusted function points)

  9. Complex FP Calculation • Compute DI (degree of influence) • Sum of 14 factors ratings • Each rating will be integer between 0 (“not present”) & 5 (“strong influence throughout”)

  10. Complex FP Calculation • Compute TCF (total complexity factor) TCF = 0.65 + 0.01 DI • FP (number of function points) is: FP = UFPTCF

  11. Analysis of Metrics • Amazingly, FP often calculated correctly • Moreover, cost-per function point meaningful! • Maintenance can cause inaccuracies • Major changes possible without changing Fi, Fl, Pr, Inp,Out, Inq,Maf, Inf

  12. Cost Estimation Techniques • Expert judgment by analogy • Compare target product to completed products • Provides a WASG (wild *** scientific guess) • Studies show large groups eerily accurate • Bottom-up approach • Split into smaller components (e.g., classes) • Estimate costs for each component • Algorithmic cost estimation models • Most commonly used approach

  13. COCOMO • Set of estimation models developed in 1981 • Updated in 1995 for modern development tools • Both contain 3 models differing in complexity • Original design consists of three models: • Macro-estimation model for whole product • Intermediate COCOMO • Micro-estimation model examining product details

  14. Intermediate COCOMO • Estimate product length in KDSI • Estimate of 1000s of source instructions • Select development mode • Development mode determines coefficients used

  15. Intermediate COCOMO • Compute development (nominal) effort • Effort computed as person-months Effort = a ´ (KDSI)b • Compute C(effort adjustment factor) • Equals the product of up to 15 cost-drivers • Development time (in person-months) is: Effort ´ C

  16. COCOMO Cost Drivers

  17. Using COCOMO • Revision (COCOMO II) calculated similarly • But much, much more complex • Estimated time then used to compute: • Development costs & schedules • Phase and activity distributions • Maintenance costs after delivery • Ultimately based upon initial size estimate • End result only as good as initial estimate

  18. For Next Lecture • Consider maintenance of code • Ultimately where the real money is made or lost • Where majority of time in project is spent • But least interesting for software engineering • Much determined by decisions in development

More Related