1 / 67

CHAPTER 9

Object-Oriented and Classical Software Engineering Sixth Edition, WCB/McGraw-Hill, 2005 Stephen R. Schach srs@vuse.vanderbilt.edu. CHAPTER 9. PLANNING AND ESTIMATING. Overview. Planning and the software process Estimating duration and cost Components of a software project management plan

mvalencia
Download Presentation

CHAPTER 9

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. Object-Oriented and Classical Software EngineeringSixth Edition, WCB/McGraw-Hill, 2005Stephen R. Schachsrs@vuse.vanderbilt.edu

  2. CHAPTER 9 PLANNING AND ESTIMATING

  3. Overview • Planning and the software process • Estimating duration and cost • Components of a software project management plan • Software project management plan framework • IEEE software project management plan • Planning testing • Planning object-oriented projects • Training requirements • Documentation standards • CASE tools for planning and estimating • Testing the software project management plan

  4. Planning and Estimating • Before starting to build software, it is essential to plan the entire development effort in detail • Planning continues during development and then postdelivery maintenance • Initial planning is not enough • Planning must proceed throughout the project • The earliest possible time that detailed planning can take place is after the specifications are complete

  5. 9.1 Planning and the Software Process • The accuracy of estimation increases as the process proceeds Figure 9.1

  6. Planning and the Software Process (contd) • Example • Cost estimate of $1 million during the requirements workflow • Likely actual cost is in the range ($0.25M, $4M) • Cost estimate of $1 million in the middle of the analysis workflow • Likely actual cost is in the range ($0.5M, $2M) • Cost estimate of $1 million at the end of the analysis workflow (earliest appropriate time) • Likely actual cost is in the range ($0.67M, $1.5M)

  7. Planning and the Software Process (contd) • This model is old (1976) • Estimating techniques have improved • But the shape of the curve is likely to be similar

  8. 9.2 Estimating Duration and Cost • Accurate duration estimation is critical • Accurate cost estimation is critical • Internal, external costs • There are too many variables for accurate estimate of cost or duration

  9. Human Factors • Sackman (1968) measured differences of up to 28 to 1 between pairs of programmers • He compared matched pairs of programmers with respect to • Product size • Product execution time • Development time • Coding time • Debugging time • Critical staff members may resign during the project

  10. 9.2.1 Metrics for the Size of a Product • Lines of code (LOC, KDSI, KLOC) • FFP • Function Points • COCOMO

  11. Lines of Code (LOC) • Alternate metric • Thousand delivered source instructions (KDSI) • Source code is only a small part of the total software effort • Different languages lead to different lengths of code • LOC is not defined for nonprocedural languages (like LISP)

  12. Lines of Code (contd) • It is not clear how to count lines of code • Executable lines of code? • Data definitions? • Comments? • JCL statements? • Changed/deleted lines? • Not everything written is delivered to the client • A report, screen, or GUI generator can generate thousands of lines of code in minutes

  13. Lines of Code (contd) • LOC is accurately known only when the product finished • Estimation based on LOC is therefore doubly dangerous • To start the estimation process, LOC in the finished product must be estimated • The LOC estimate is then used to estimate the cost of the product — an uncertain input to an uncertain cost estimator

  14. Metrics for the Size of a Product (contd) • Metrics based on measurable quantities that can be determined early in the software life cycle • FFP • Function points

  15. FFP Metric • For cost estimation of medium-scale data processing products • The three basic structural elements of data processing products • Files • Flows • Processes

  16. FFP Metric (contd) • Given the number of files (Fi), flows (Fl), and processes (Pr) • The size (S), cost (C) are given by S=Fi + Fl + Pr C=b  S • The constant b (efficiency or productivity) varies from organization to organization

  17. FFP Metric (contd) • The validity and reliability of the FFP metric were demonstrated using a purposive sample • However, the metric was never extended to include databases

  18. Function Points • Based on the number of inputs (Inp), outputs (Out), inquiries (Inq), master files (Maf), interfaces (Inf) • For any product, the size in “function points” is given by FP = 4  Inp + 5  Out + 4  Inq + 10  Maf + 7  Inf • This is an oversimplification of a 3-step process

  19. Function Points (contd) • Step 1. Classify each component of the product (Inp, Out, Inq, Maf, Inf) as simple, average, or complex • Assign the appropriate number of function points • The sum gives UFP (unadjusted function points) Figure 9.2

  20. Function Points (contd) • Step 2. Compute the technical complexity factor (TCF) • Assign a value from 0 (“not present”) to 5 (“strong influence throughout”) to each of 14 factors such as transaction rates, portability Figure 9.3

  21. Function Points (contd) • Add the 14 numbers • This gives the total degree of influence (DI) TCF = 0.65 + 0.01  DI • The technical complexity factor (TCF) lies between 0.65 and 1.35

  22. Function Points (contd) • Step 3. The number of function points (FP) is then given by FP = UFP  TCF

  23. Analysis of Function Points • Function points are usually better than KDSI — but there are some problems • “Errors in excess of 800% counting KDSI, but only 200% in counting function points” [Jones, 1987]

  24. Analysis of Function Points • We obtain nonsensical results from metrics • KDSI per person month and • Cost per source statement • Cost per function point is meaningful Figure 9.4

  25. Analysis of Function Points • Like FFP, maintenance can be inaccurately measured • It is possible to make major changes without changing • The number of files, flows, and processes; or • The number of inputs, outputs, inquiries, master files, and interfaces • In theory, it is possible to change every line of code with changing the number of lines of code

  26. Mk II function points • This metric was put forward to compute UFP more accurately • We decompose software into component transactions, each consisting of input, process, and output • Mark Ii function points are widely used all over the world

  27. 9.2.2 Techniques of Cost Estimation • Expert judgment by analogy • Bottom-up approach • Algorithmic cost estimation models

  28. Expert Judgment by Analogy • Experts compare the target product to completed products • Guesses can lead to hopelessly incorrect cost estimates • Experts may recollect completed products inaccurately • Human experts have biases • However, the results of estimation by a broad group of experts may be accurate • The Delphi technique is sometimes needed to achieve consensus

  29. Bottom-up Approach • Break the product into smaller components • The smaller components may be no easier to estimate • However, there are process-level costs • When using the object-oriented paradigm • The independence of the classes assists here • However, the interactions among the classes complicate the estimation process

  30. Algorithmic Cost Estimation Models • A metric is used as an input to a model to compute cost, duration • An algorithmic model is unbiased, and therefore superior to expert opinion • However, estimates are only as good as the underlying assumptions • Examples • SLIM Model • Price S Model • COnstructive COst MOdel (COCOMO)

  31. 9.2.3 Intermediate COCOMO • COCOMO consists of three models • A macro-estimation model for the product as a whole • Intermediate COCOMO • A micro-estimation model that treats the product in detail • We examine intermediate COCOMO

  32. Intermediate COCOMO (contd) • Step 1. Estimate the length of the product in KDSI

  33. Intermediate COCOMO (contd) • Step 2. Estimate the product development mode (organic, semidetached, embedded) • Example: • Straightforward product (“organic mode”) Nominal effort = 3.2 ´ (KDSI)1.05 person-months

  34. Intermediate COCOMO (contd) • Step 3. Compute the nominal effort • Example: • Organic product • 12,000 delivered source statements (12 KDSI) (estimated) Nominal effort = 3.2 ´ (12)1.05 = 43 person-months

  35. Intermediate COCOMO (contd) • Step 4. Multiply the nominal value by 15 software development cost multipliers Figure 9.5

  36. Intermediate COCOMO (contd) • Example: • Microprocessor-based communications processing software for electronic funds transfer network with high reliability, performance, development schedule, and interface requirements • Step 1. Estimate the length of the product • 10,000 delivered source instructions (10 KDSI) • Step 2. Estimate the product development mode • Complex (“embedded”) mode

  37. Intermediate COCOMO (contd) • Step 3. Compute the nominal effort • Nominal effort = 2.8 ´ (10)1.20 = 44 person-months • Step 4. Multiply the nominal value by 15 software development cost multipliers • Product of effort multipliers = 1.35 (see table on next slide) • Estimated effort for project is therefore 1.35 ´ 44 = 59 person-months

  38. Intermediate COCOMO (contd) • Software development effort multipliers Figure 9.6

  39. Intermediate COCOMO (contd) • Estimated effort for project (59 person-months) is used as input for additional formulas for • Dollar costs • Development schedules • Phase and activity distributions • Computer costs • Annual maintenance costs • Related items

  40. Intermediate COCOMO (contd) • Intermediate COCOMO has been validated with respect to a broad sample • Actual values are within 20% of predicted values about 68% of the time • Intermediate COCOMO was the most accurate estimation method of its time • Major problem • If the estimate of the number of lines of codes of the target product is incorrect, then everything is incorrect

  41. 9.2.4 COCOMO II • 1995 extension to 1981 COCOMO that incorporates • Object orientation • Modern life-cycle models • Rapid prototyping • Fourth-generation languages • COTS software • COCOMO II is far more complex than the first version

  42. COCOMO II (contd) • There are three different models • Application composition model for the early phases • Based on feature points (similar to function points) • Early design model • Based on function points • Post-architecture model • Based on function points or KDSI

  43. COCOMO II (contd) • The underlying COCOMO effort model is effort = a(size)b • Intermediate COCOMO • Three values for (a, b) • COCOMO II • b varies depending on the values of certain parameters • COCOMO II supports reuse

  44. COCOMO II (contd) • COCOMO II has 17 multiplicative cost drivers (was 15) • Seven are new • It is too soon for results regarding • The accuracy of COCOMO II • The extent of improvement (if any) over Intermediate COCOMO

  45. 9.2.5 Tracking Duration and Cost Estimates • Whatever estimation method used, careful tracking is vital

  46. 9.3 Components of a Software Project Management Plan • The work to be done • The resources with which to do it • The money to pay for it

  47. Resources • Resources needed for software development: • People • Hardware • Support software

  48. Use of Resources Varies with Time • Rayleigh curves accurately depict resource consumption • The entire software development plan must be a function of time Figure 9.7

  49. Work Categories • Project function • Work carried on throughout the project • Examples: • Project management • Quality control

  50. Work Categories • Activity • Work that relates to a specific phase • A major unit of work, • With precise beginning and ending dates, • That consumes resources, and • Results in work products like the budget, design, schedules, source code, or users’ manual

More Related