1 / 41

CS352 – Software Engineering II Lecture 2 3 : SW Estimation

CS352 – Software Engineering II Lecture 2 3 : SW Estimation. Outline. Why Estimation? Estimating Size Estimating Effort Agile Estimation. 1. Why Estimation?. An accurate estimate of software size is an essential element in the calculation of Estimated project costs

shiner
Télécharger la présentation

CS352 – Software Engineering II Lecture 2 3 : SW 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. CS352 – Software Engineering IILecture 23: SW Estimation

  2. Outline • Why Estimation? • Estimating Size • Estimating Effort • Agile Estimation

  3. 1. Why Estimation? • An accurate estimate of software size is an essential element in the calculation of • Estimated project costs • Estimated project schedule • Basis for bidding and contracting

  4. Why Estimation? • Estimation is needed early on in the project (often while a contract bid is being prepared) • This makes it a very difficult task. • Initial size estimates are typically based on the known system requirements. • You must know every detail of the proposed system, and use these details to develop and validate the software size estimates.

  5. When is estimation most accurate? Bad News Estimates can be totally off When the project is done

  6. Estimation can improve with process improvement PI (e.g., CMMI) Good News, it can be improved very much with PI effort

  7. 2. Estimating Size • Why estimating size ? • So we can estimate effort • And hence, we can estimate cost • And schedule • What unit should we use to estimate size ? • ……………. ? • ……………. ?

  8. 2. Estimating Size • SLOC • Use Case Points • Expert’s Opinion • Combining Estimates

  9. How many LOC? 2.1 Source Lines Of Code • How many lines of code are in this program? /* S1 and S2 should be a string, Compare the two, returning true if they are equal, and if they are equal set *START_PARAM to point to the argument in S2. */ static int eqin (s1, s2, start_param) char *s1, *s2; char **start_param; { /* While there is more characters */ while (*s1) { /* check if it is the same characters in both strings */ if (*s1++ != *s2++) /* If not return*/ return (false); } *start_param = s2; return (true); } 21 Lines 13 LOC 6 Comment Lines 2 Empty Lines

  10. Why? 2.1 Source Lines Of Code • How many lines of code are in this program? /* S1 and S2 should be a string, Compare the two, returning true if they are equal, and if they are equal set *START_PARAM to point to the argument in S2. */ static int eqin (char *s1, char *s2, char **start_param) { /* While there is more characters */ /* check if it is the same characters in both strings */ /* If not, return false */ while (*s1) if (*s1++ != *s2++) return (false); *start_param = s2; return (true); } 16 Lines 8 LOC (or 6 or 5?) 6 Comment Lines 4 Empty Lines

  11. Counting Source Lines Of Code • Only Source lines that are delivered as part of the product are included • Test drivers and other support software is excluded • Source lines are created by the project staff • Code created by applications generators is excluded • One instruction is one line of code • Declarations are counted as instructions • Comments are not counted as instructions • How about brackets???

  12. 2.1 Source Line Of Code • A count of the instruction statements in a program (excluding comments, include statements, etc.), • The basis of LOC is that program length is a predictor of program characteristics like effort and ease of maintenance.

  13. Problems with Source Line Of Code ?? • Which statements to count ? • Language dependent? • All lines of code are not created equal. • It characterises only one specific view of size, namely length, it takes no account of functionality or complexity • How to estimate upfront ?

  14. 2.2 Use Case Points • Use Case Points (UCP) is a software estimation technique used to forecast the software size for software development projects that use UML. • The concept of UCP is based on the requirements for the system being written using use cases with factoring to account for technical and environmental considerations. • The UCP for a project can then be used to calculate the estimatedeffort for a project.

  15. UCP Method • Unadjusted Use Case Weight (UUCW) – the point size of the software that accounts for the number and complexity of use cases. • Unadjusted Actor Weight (UAW) – the point size of the software that accounts for the number and complexity of actors. • Technical Complexity Factor (TCF) – factor that is used to adjust the size based on technical considerations. • Environmental Complexity Factor (ECF) – … http://en.wikipedia.org/wiki/Use_Case_Points

  16. UUCW

  17. UAW

  18. TCF • Assign a score 0-5 to each of the 13 technical factors. • Multiply the score by weighted value for each factor. • The total is the technical factor (TF). • TCF = 0.6 + (TF/100)

  19. ECF • As • previous • one.

  20. Use Case Points Example1

  21. Use Case Points Example2

  22. Use Case Points Example3

  23. 2.3 Expert’s Opinion • Guessing: • Experienceddevelopers make good estimates due to experience with similar projects. • Usually use Work Breakdown Structure** • Previous Project Experience: • Serves as an educated guess. • By using data stored in the metrics database for similar projects, you can more accuratelypredict the size of the new project. • Break the system into components, and estimated independently. **http://www.hyperthot.com/pm_wbs.htm **http://en.wikipedia.org/wiki/Work_breakdown_structure

  24. 2.4 Combining Estimates • A good method for improving the accuracy of estimates is to estimate several ways, and then calculate a weighted average of the estimates. • For example,

  25. 3. Effort Estimation in Industry

  26. Effort Estimation with COCOMO II • It is an interesting mathematical model for calculating software project schedule and effort. • We will not cover it, but I recommend you have a look at it. It is not in exam. • In the following, I included some slides on it. • A tool that supports it is available here • http://csse.usc.edu/tools/COCOMOII.php

  27. COCOMO [B. Boehm] • COnstructive COst MOdel • empirical method • hierarchy of COCOMO models (parameters) • basic: prg size • intermediate: prg size & cost drivers • advanced: prg size & cost drivers per phaseCost Drivers: Personnel/Team Capability, Product Complexity, Req. Reliability, Problem Domain Experience, Development practices, Tools, Language Experience, etc. • for each project type

  28. COCOMO - Parameters • prg size: LOCS (lines of code) • “cost drivers” • evaluate: • product, hardware, personnel, project • measured on a 6 point scale • allow for derivation of an EAF • (Effort Adjustment Factor)

  29. COCOMO - Project Types • organic mode: • relatively small and simple • small team of skilled developers • semi-detached: • intermediate in size and complexity • mixed skill levels on the team • embedded: • hard constraints for HW, SW, operation

  30. Basic COCOMO - The Functions person-month = a*(KLOC)b duration-in-month = c*(person-month)d KLOC ... kilo lines of code a, b, c, d depend on the project type

  31. Basic COCOMO - Tables project type: a b c d organic 2.4 1.05 2.5 0.38 semi-detached 3.0 1.12 2.5 0.35 embedded 3.6 1.20 2.5 0.32

  32. Basic COCOMO - Example • You must decide on: • LOCS: 50,000 lines of code • project type: semi-detached • person-month: 3.0*(50)1.12 ~ 240 • duration-in-month: 2.5*(240)0.35 ~ 17 • number of people: 240 / 17 ~ 14

More Related