1. 1 Topic 5 Planning III – Estimating Software Size

2. Topic 5 Planning IIIEstimating Software Size 2 Lecture Overview 5.1 Background 5.2 Popular Estimating Methods 5.3 Proxy-based Estimating 5.4 The PROBE Size Estimating Method 5.5 Object Categories 5.6 Estimating Considerations 5.7 Summary 5.8 Exercises

3. Topic 5 Planning IIIEstimating Software Size 3 5.1 Background

4. Topic 5 Planning IIIEstimating Software Size 4 5.1 Background 1 Why Estimate Size? Size estimates allow you to make better plans. Plan better for the resources, tasks, and schedule. The quality of a plan depends on that of the size estimate. The more details you have, the more accurate the estimation will be. For a large software job, divide it into separate elements. Size estimates assist you in tracking progress. You can judge when the job scope changes. better measure the work.

5. Topic 5 Planning IIIEstimating Software Size 5 Background 2 Estimating models in other fields have a large historical base. are widely used. generate detailed planning data. require a size estimate as input.

6. Topic 5 Planning IIIEstimating Software Size 6 Project Planning Framework The framework is shown in Figure 5.1. Size estimating: compare the design elements with the historical size data to make estimates. Accurate size estimation will lead to accurate resource estimation.

7. Topic 5 Planning IIIEstimating Software Size 7 Fig. 5.1 Project Planning Framework Customer Need Delivered Product Customer Define the Requirements Produce the Conceptual Design Estimate the Product Size (Topic 5) Estimate the Resources (Topic 6) Produce the Schedule (Topic 6) Develop the Product Process Analysis Resources Available Historical Productivity Database Historical Size Database Tracking Reports Items Tasks Size, Resource, Schedule data Management

8. Topic 5 Planning IIIEstimating Software Size 8 Estimating Experience Studies show that size estimation errors may be as high as 100% or even more. Only 22% professionals make size estimates for cost estimates. For software development, usually people have a larger estimation error percentage (up to 400%) in early phase, and then the percentage declines (25% or less) in later phases. Serious size estimation errors result in poor resource estimates and unrealistic project schedules. Fortunately, the size estimation skill can be learned and improved.

9. Topic 5 Planning IIIEstimating Software Size 9 Size Estimating Criteria A widely used method should be structured and trainable. usable during all development and maintenance phases. usable for all types of software product elements. suitable for statistical analysis. adaptable to the types of your future work. able to judge the accuracy of the estimates.

10. Topic 5 Planning IIIEstimating Software Size 10 Size Estimating Principles 1 Estimating is an uncertain process. No one knows how big the product will be The earlier the estimate, the less is known Estimates can be biased by business and other pressures (sometimes called gutless estimations) Estimating is an intuitive learning process. Ability improves with experience Some people are better at estimating

11. Topic 5 Planning IIIEstimating Software Size 11 Size Estimating Principles 2 Estimating is a skill. Improvement will be gradual You may never get very good The objective, however, is to get consistent -- at least unbiased. You will then understand the variability of your estimates You seek an even balance between under and over estimates

12. Topic 5 Planning IIIEstimating Software Size 12

13. Topic 5 Planning IIIEstimating Software Size 13 Size Estimating Principles 3 The principal advantages of using a defined estimating method are: You have known practices that you can work to improve. It provides a framework for gathering estimating data. By using consistent methods and historical data, your estimates will get more consistent.

14. Topic 5 Planning IIIEstimating Software Size 14 5.2 Popular Size Estimating Methods

15. Topic 5 Planning IIIEstimating Software Size 15 5.2 Popular Size Estimating Methods Four popular methods Wideband-Delphi Fuzzy-Logic Standard-Component Function-Point Their concepts form the foundation of the PROBE (Proxy-based Estimating) method used with the PSP.

16. Topic 5 Planning IIIEstimating Software Size 16 Wideband-Delphi Method 1 Originated by Rand Co. and refined by Boehm. Based on the Delphi process, which usually contains several cycles. Several experts (estimators) and a moderator are involved in the process. Each expert makes an independent estimate and submit it to the moderator in each cycle. The moderator coordinates the estimation process for these experts whose estimates are anonymous to all others. The process runs until experts estimates converge on a consensus result.

17. Topic 5 Planning IIIEstimating Software Size 17 Wideband-Delphi Method 2 The methods process is as follows: 1. A group of experts is each given the programs specifications and estimation forms. 2. They meet to discuss project goals, assumptions, and estimation issues. 3. They then each anonymously list project tasks and estimation size. 4. The estimates are given to the moderator, who tabulates the results and returns them to the experts, as illustrated in Figure 5.2.

18. Topic 5 Planning IIIEstimating Software Size 18 Fig. 5.2 The Chart Used in Wideband-Delphi 0 Project: XYZ Estimator: John Doe Date:4/1/94 Here is the range of estimates from the 1st round: 20406080100 X X* X! XX X - estimates X* - your estimate X! – median estimate Please enter your estimate for the next round: ___SLOC. Please enter explain rationale for your estimate.

19. Topic 5 Planning IIIEstimating Software Size 19 Wideband-Delphi Method 3 5. Only each experts personal estimate is identified; all others are anonymous. 6. The experts meet to discuss the results. They each review the tasks they have defined but not their size estimates. 7. The cycle continues at step 3 until the estimates converge to within an acceptable range.

20. Topic 5 Planning IIIEstimating Software Size 20 Delphi Example 1 3 estimators are asked to estimate the product. Their initial estimates are: A - 13,800 LOC B - 15,700 LOC C - 21,000 LOC The coordinator then Calculates average estimate as 16,833 LOC Returns this with their original estimates to the estimators

21. Topic 5 Planning IIIEstimating Software Size 21 Delphi Example 2 The estimators then meet and discuss the estimates. Their second estimates are A - 18,500 LOC B - 19,500 LOC C - 20,000 LOC The coordinator then Calculates average estimate as 19,333 LOC Asks the estimators if they agree with this as the estimate

22. Topic 5 Planning IIIEstimating Software Size 22 Wideband-Delphi Method 4 Advantages can produce accurate results uses organizations skills works for any size products. Disadvantages relies on a few experts time consuming subject to common biases

23. Topic 5 Planning IIIEstimating Software Size 23 Fuzzy-Logic Method 1 Estimators compare the planned program with prior programs and select the most appropriate size category. Preparing for this method gather sufficient size data on previously developed programs subdivide these data into size categories and subcategories provide a meaningful number of program examples in each size category and subcategory extend the size ranges up or down as you get further data Table 5.1 shows the example.

24. Table 5.1 Example for Fuzzy-Logic Method Subrange Gross Range Very small LOC Small LOC Medium LOC Large LOC Very Large LOC Very small 1,1,481,5142,0002,6303,467 Small 4,5706,0258,00010,47113,804 Medium 18,19723,98832,00041,68754,954 Large 72,44495,499128,000165,958218,776 Very Large 288,403380,189512,000660,693870,964

25. Topic 5 Planning IIIEstimating Software Size 25 Fuzzy-Logic Method 2 Advantages based on relevant historical data easy to use requires no special tools or training provides reasonably good estimates in cases where new work is like prior experience

26. Topic 5 Planning IIIEstimating Software Size 26 A Fuzzy Logic Example 1 You have historical data on 5 programs as follows: a file utility of 1,844 LOC a file management program of 5,834 LOC a personnel record keeping program of 6,845 LOC a report generating package of 18,386 LOC an inventory management program of 25,943 LOC

27. Topic 5 Planning IIIEstimating Software Size 27 A Fuzzy Logic Example 2 You establish 5 ranges, as follows log(1844) = 3.266 log(25,943) = 4.414 the difference is 1.148 1/4th this difference is 0.287 the logs of the five ranges are thus spaced 0.287 apart the limits or these ranges are at 0.1435 above and below the midpoint of each range

28. Topic 5 Planning IIIEstimating Software Size 28 A Fuzzy Logic Example 3 The 5 size ranges are thus: very small - 1,325 to 2,566: file utility small - 2,566 to 4970: no members medium - 4,970 to 9,626: file management and personnel record program large - 9,626 to 18,641: report generator very large - 18,641 to 36,104: inventory management

29. Topic 5 Planning IIIEstimating Software Size 29 A Fuzzy Logic Example 4 Your new program has the following requirements: analyze marketing performance by product line project the likely sales in each product category allocate these sales to marketing regions and time periods produce a monthly report of these projections and the actual results

30. Topic 5 Planning IIIEstimating Software Size 30 A Fuzzy Logic Example 5 In comparing the new program to the historical data you make the following judgments: substantially more complex application than the file management and personnel programs not as complex as the inventory management program. appears to have significantly more function than the report package. You conclude that the new program is in the lower end of very large, or from 18 to 25 KLOC.

31. Topic 5 Planning IIIEstimating Software Size 31 Fuzzy Logic - Summary To make a fuzzy logic estimate: 1 - Divide the historical product size data into size ranges. 2 - Compare the planned product with these prior products. 3 - Based on this comparison, select the size that seems most appropriate for the new product.

32. Topic 5 Planning IIIEstimating Software Size 32 Fuzzy-Logic Method Disadvantages Fuzzy logic estimating requires a lot of data requires that the estimators be familiar with the historically developed programs provides only a crude sizing not useful for new program types not useful for programs that are much larger or smaller than the historical data

33. Topic 5 Planning IIIEstimating Software Size 33 Standard-Component Method 1 Use organizations historical data to determine the typical size of various types of components subsystems, modules, screens, reports, etc. For a new project Judge the number of each type of components will likely be in the project. Also determine the maximum and minimum numbers of each type of components you could image.

34. Topic 5 Planning IIIEstimating Software Size 34 Standard-Component Method 2 Calculate the estimated number of each type with (4*likely number + max. number + min. number) / 6 The estimated size of each type is its estimated number * its typical size from historical data Sum up the estimated size of all types to get the total size.

35. Table 5.2 Example of Component Estimating For modules, its estimated size = 932 * 17.5 = 16310. Standard Component SLOC per Component SML X= (S+4*M+L)/6 SLOC 1 Object Instructions 0.28 Files2,53536106.1715,633 Modules 932111822 17.516,310 Subsystems8,175 Screens 8185921 10.38,453 Report 96726116.175,963 Interactive Programs1,769 Batch Programs3,214 Total46,359

36. Topic 5 Planning IIIEstimating Software Size 36 Standard-Component Method 3 Advantages based on relevant historical data easy to use requires no special tools or training provides a rough estimate range Disadvantages must use large components early in a project limited data on large components hard to visualize component counts early in a project

37. Topic 5 Planning IIIEstimating Software Size 37 Function-Point Method 1 Count the numbers of the 5 types of basic functions that the commercial application program will likely need by reviewing its requirements. Inputs: screens or forms through which to add new data or update existing data in the application Outputs: screens or reports that the application produces Inquires: screens used to ask for interrogation, assistance or information Data files: logical collection of records that the application updates Interface: e.g., files shared with other applications, shared databases, parameter lists, …

38. Topic 5 Planning IIIEstimating Software Size 38 Function-Point Method 2 Each type has a given weight. Calculate the function points of the application multiply the number of each type by its weight. sum them up to get the total (unadjusted). Use historical data on development cost and time per function point to make the estimates.

39. Topic 5 Planning IIIEstimating Software Size 39 Table 5.3 Function-Point Categories Basic Counts Function TypeWeightsTotal Inputs×4×4 Outputs×5×5 Inquiries×4×4 Logical Files×10 Interfaces×7×7 Unadjusted Total

40. Table 5.4 Function-Point Category Example Basic Counts Function TypeWeightsTotal 8Inputs8 ×432 12Outputs12 ×560 4Inquiries4 ×416 2Logical Files2 ×1020 1Interfaces1 ×77 Unadjusted Total 135

41. Topic 5 Planning IIIEstimating Software Size 41 Function-Point Method 3 To improve the estimation, adjust the function points by 14 influence factors. The influence factor values are selected from 0 (very simple) to 5 (very complex) by the judgment of the estimator. Sum up these values. Calculate the complexity multiplier 0.65+0.01*(sum of influence factor values) Calculate adjusted function points complexity multiplier * unadjusted function points The adjustment is between ±35% Table 5.5 shows an example.

42. Topic 5 Planning IIIEstimating Software Size 42 Table 5.5 An Example of Function-Point Influence Factors FactorInfluence Data Communications2 Distributed Functions0 Performance objectives3 Heavily used configuration3 Transaction rate4 On line data entry4 End-user efficiency3 On line update2 Complex processing3 Reusability2 Installation ease3 Operational ease4 Multiple sites5 Facilitate change3 Sum of influence factors =41 0.65+0.01*(sum of Influence Factors)=Complexity Multiplier= 1.06 Function Points=Complexity Multiplier*Unadjusted Function Points=143

43. Topic 5 Planning IIIEstimating Software Size 43 Function-Point Method 4 Advantages a well-documented method usable in the earliest requirements phase independent of programming languages, product designs, development styles having a large body of historical data with an active user group

44. Topic 5 Planning IIIEstimating Software Size 44 Function-Point Method 5 Disadvantages cannot directly count an existing products function point content without historical data, difficult to improve estimating skill not reflect language, design, and style differences designed for estimating commercial data processing applications

45. Topic 5 Planning IIIEstimating Software Size 45 5.3 Proxy-based Estimating (PROBE)

46. Topic 5 Planning IIIEstimating Software Size 46 5.3 Proxy-Based Estimating (PROBE) In stead of direct estimating, a proxy is a substitute to help estimators judge product size. Proxies, for example, can be objects, screens, files, scripts, document chapters, function points, and so on.

47. Topic 5 Planning IIIEstimating Software Size 47 Criteria for a Good Proxy 1 The proxy size measurement (or estimate) should closely relate to the effort required to develop the product. Use the correlation method (see Topic 15) to determine which proxy is a better predictor of product size or development effort.

48. Topic 5 Planning IIIEstimating Software Size 48 Criteria for a Good Proxy 2 The proxy content of a product should be automatically countable. Large amount of proxy data extracted from historical data is needed to define new estimates. The proxy must be a physical entity that can be precisely defined and algorithmically identified.

49. Topic 5 Planning IIIEstimating Software Size 49 Criteria for a Good Proxy 3 The proxy should be easy to visualize at the beginning of a project. The proxy should be customizable to the special need of using organizations. Different product types may use different kind of proxies to estimate. The proxy should be sensitive to any implementation variations that impact development costs or efforts. for example, program languages, design styles, application types

50. Topic 5 Planning IIIEstimating Software Size 50 Objects as Proxies 1 Objects in OO programming languages are a good candidate as proxies because they closely relate to development effort or resources. Figures 5.3 and 5.4 show close correlation between estimated object LOC (=Σobject size ) and actual program LOC. Linear regression formula: (See Topic 15 ) actual program LOC = β 0 + estimate object LOC * β 1 Figures 5.5 and 5.6 show high correlation and significance between estimated object LOC and actual development hours. Linear regression formula: actual development hours = β 0 + estimate object LOC * β 1

51. Topic 5 Planning IIIEstimating Software Size 51 Objects as Proxies 2 The PROBE method uses objects as proxies. The PROBE method requires that estimators have historical data on the sizes of objects they have developed and that these data be divided into categories.

52. Topic 5 Planning IIIEstimating Software Size 52 Fig. 5.3 Estimated Object LOC vs. Actual Program LOC (10 Pascal Programs) 0 100 200 300 400 500 600 700 800 900 1000 2000 1800 1600 1400 1200 1000 800 600 400 200 0 Actual Program LOC Estimated Object LOC

53. Topic 5 Planning IIIEstimating Software Size 53 Fig. 5.4 Estimated Object LOC vs. Actual Program LOC (25 C++ Programs) 0 50 100 150 200 250 300 350 800 Actual Program LOC Estimated Object LOC 700 600 500 400 300 200 100 0

54. Topic 5 Planning IIIEstimating Software Size 54 Fig. 5.5 Estimated Pascal Object LOC vs. Actual Development Hours with Correlation 0.934, Significance < 0.005 0 100 200 300 400 500 600 700 800 900 1000 200 180 160 140 120 100 80 60 40 20 0 Actual Development Hours Estimated Object LOC

55. Topic 5 Planning IIIEstimating Software Size 55 Fig. 5.6 Estimated C++ Object LOC vs. Actual Development Hours with Correlation 0.980, Significance < 0.005 0 50 100 150 200 250 300 350 60 Actual Development Hours Estimated Object LOC 50 40 30 20 10 0

56. Topic 5 Planning IIIEstimating Software Size 56 Estimating Object Size with Fuzzy-Logic Method Judge the size of each object on a per-objects method basis with fuzzy-logic method. 1. decide the category of the object 2. judge how many methods it likely will contain 3. decide the size range it falls into 4. estimated object size = (# of methods) * (LOC of the size range) Table 5.6 shows object category sizes in LOC per- objects method For example, a medium-sized Pascal text object with 4 methods has about 66 (=16.48*4) LOC.

57. Topic 5 Planning IIIEstimating Software Size 57 Table 5.6 Object Category Sizes in LOC per Method C++ Object Size in LOC per Method Category Very Small MediumLarge Very Large Calculati on 2.345.1311.2524.6654.04 Data2.604.798.8416.3130.09 I/O9.0112.0616.1521.6228.93 Logic7.5510.9815.9823.2533.83 Set-up3.885.046.568.5311.09 Text2.758.0017.0736.4177.66 Object Pascal Object Size in LOC per Method Category Very Small MediumLarge Very Large Control4.248.6817.7936.4674.71 Display4.726.358.5511.5015.46 File3.306.2311.7422.1441.74 Logic6.4112.4224.0646.6090.27 Print3.885.8610.1517.5930.49 Text4.638.7316.4831.0958.62

58. Topic 5 Planning IIIEstimating Software Size 58 5.4 The PROBE Size Estimating Method

59. Topic 5 Planning IIIEstimating Software Size 59 5.4 The PROBE Size Estimating Method The PROBE size estimating procedure is shown in Figure 5.7. In the procedure, a size estimating template, shown in Table 5.7, will be used. Use the template to instruct how to estimate program size with the PROBE method and linear regression.

60. Topic 5 Planning IIIEstimating Software Size 60 Fig. 5.7 The Procedure of PROBE Method Start Step 1: Conceptual design Step 3: Calculate projected and modified LOC. Step 4: Estimate program size. Step 5: Calculate prediction interval. Number of methods Object type Relative size Reuse categories Step 2: Identify object Size Estimate

61. Table 5.7 Size Estimating Template and example 1

62. Table 5.7 Size Estimating Template and example 2

63. Topic 5 Planning IIIEstimating Software Size 63 Size Estimating Template 1 Base Program: the program you will enhance and perform any changes to it. Base Size (B): the LOC of the base program LOC Deleted (D): the LOC to be deleted from the base program LOC Modified (M): the LOC to be modified in the base program

64. Topic 5 Planning IIIEstimating Software Size 64 Size Estimating Template 2 Projected LOC (P): includes total base additions LOC (BA) and total new objects LOC (NO) Base Additions: the new functions to be added to the base program New Objects: the new objects to be added to the base program New Reused Objects: a new object planned to develop and general enough to put into the reuse library (Note: mark an * with the new reused objects) Reused Objects (R): the objects taken from the reuse library

65. Topic 5 Planning IIIEstimating Software Size 65 Size Estimating Template 3 Calculations Using actual new and changed LOC and estimated Object LOC (i.e., P+M) from historical data to obtain regression parameters β 0, β 1 Estimated New and Changed LOC (N): use regression parameters to calculate N = β 0 +β 1 * (P + M) Estimated Total LOC (T): the estimated size of the final program

66. Topic 5 Planning IIIEstimating Software Size 66 Size Estimating Template 4 Prediction Range: using t distribution (See Section 15.5.2), a desired prediction interval percent, and the data for linear regression to calculate Lower/Upper Prediction Interval: the interval (N ± Range) within which the actual new and changed LOC is likely to fall Prediction Interval Percent: the percentage that the actual new and changed LOC is likely to fall within the interval

67. Topic 5 Planning IIIEstimating Software Size 67 PROBE Step 1 – Conceptual Design The conceptual design establishes a preliminary design approach and names the expected product objects and their functions. For an accurate estimate, estimators must refine the conceptual design to the level of objects.

68. Topic 5 Planning IIIEstimating Software Size 68 PROBE Step 2 – Identify Objects Determine object type and size if it is a new object, use fuzzy-logic method (see Section 5.3) # of methods (judging size using a per-method basis) object type relative size LOC per method estimated object size = (# of method) * (LOC per method) (Note: mark an * with the new reused objects) if the object is taken from the reuse library, determine reuse object categories object LOC

69. Topic 5 Planning IIIEstimating Software Size 69 PROBE Step 3 – Calculate Projected and Modified LOC Projected LOC (P) = Total Base Additions LOC (BA) + Total New Objects LOC (NO) Using actual new and changed LOC and estimated object LOC (i.e., P+M) from historical data to obtain regression parameters β 0, β 1 Estimated New and Changed LOC (N) = β 0 +β 1 * (P+M)

70. Topic 5 Planning IIIEstimating Software Size 70 PROBE Step 4 – Estimate Program Size Estimated program size = Base Size (B) + Estimated New and Changed LOC (N) + Reused Total LOC (R) – LOC Deleted (D) – LOC Modified (M) LOC Modified (M) is subtracted because it is counted twice: one in Base Size (B) and the other in Estimated New and Changed LOC (N).

71. Topic 5 Planning IIIEstimating Software Size 71 PROBE Step 5 – Calculate Prediction Interval 1 The purpose is to assess the quality of the estimate. Use t distribution, a desired prediction interval percent, and the data for linear regression calculation to get Prediction Range Prediction Interval [LPI, UPI] Within the prediction interval, the actual new and changed LOC is likely to fall with the selected percent.

72. Topic 5 Planning IIIEstimating Software Size 72 PROBE Step 5 – Calculate Prediction Interval 2 Prediction Interval: [LPI, UPI] Lower Prediction Interval (LPI) = Estimated New and Changed LOC (N) - Range Upper Prediction Interval (UPI) = Estimated New and Changed LOC (N) + Range

73. Topic 5 Planning IIIEstimating Software Size 73 PROBE Step 5 – Calculate Prediction Interval 3 Prediction Range: using the data for linear regression calculation in Step 3 Where x i is the estimated object LOC (i.e., P+M) in historical data x avg is the average of x i x k is the estimated object LOC (i.e., P+M) in the new program y i is actual new and changed LOC in historical data

74. Topic 5 Planning IIIEstimating Software Size 74 5.5 Object Categories

75. Topic 5 Planning IIIEstimating Software Size 75 5.5 Object Categories The PROBE method uses objects as proxies. It needs object categories and their sizes to judge the size of the new objects. Table 5.6 shows the example that we want to produce. for C++ and Object Pascal object sizes per method are divided into 5 size ranges: very small, small, medium, large, and very large.

76. Topic 5 Planning IIIEstimating Software Size 76 Object Size Distribution Assume historical object data are normally distributed. Figure 5.8 shows the relation between the normal distribution and the size ranges.

77. Topic 5 Planning IIIEstimating Software Size 77 Fig. 5.8 Normal Distribution with Size Ranges σ

78. Topic 5 Planning IIIEstimating Software Size 78 Approaches Two approaches If the size data are close to normal distribution, use normal distribution in the calculation. Otherwise, use normal distribution of natural log in the calculation.

79. Topic 5 Planning IIIEstimating Software Size 79 Approach I: Procedure with Original Data Use historical data on objects divide them into categories calculate the size range midpoints for each category. use statistical techniques of normal distribution in the calculation The following is the procedure:

80. Topic 5 Planning IIIEstimating Software Size 80 Step 1: Classification Divide objects in historical data into categories. Basic object categories logic, control I/O, files, display data, text, calculation set-up, error handling

81. Topic 5 Planning IIIEstimating Software Size 81 Step 2: Calculating LOC per Method For each category, calculate the LOC per method of each object. Table 5.9 shows the example for 13 objects belonging to the object category, text.

82. Topic 5 Planning IIIEstimating Software Size 82 Table 5.8 Pascal Text Object LOC per Method Object NameNumber of MethodsObject LOCLOC per Method each_line33110.333 each_char3186.000 list_clump48721.750 character38729.000 single_character3258.333 single_read3186.000 list_clp48922.250 char38528.333 single_char33712.333 converter1055855.800 string_manager48220.500 string_builder58216.400 string_decrementer1023023.000

83. Topic 5 Planning IIIEstimating Software Size 83 Step 3: Calculating Standard Deviation For each category, calculate the variance and standard deviation of the values from Step 2. Variance = σ 2 = (1/n) i=1..n (x i – x avg ) 2 Standard Deviation = of Variance =σ where x i = (LOC per method) of each object of one specific category; x avg denotes the average. The following table shows the example.

84. Topic 5 Planning IIIEstimating Software Size 84 Table 5.9 Pascal Text Object Standard Deviation Object Name LOC per Method(LOC-LOC avg ) 2 each_line10.33393.249 each_charr6.000196.072 list_clump21.7503.054 chracter29.00080.954 single_character8.333136.171 single_read6.000196.072 list_clp22.2505.051 char28.33369.402 single_char12.33358.817 converter55.8001281.456 string_manager20.5000.247 string_builder16.40012.978 string_decrementer23.0008.985 Total260.0332142.753 Average20.003 Variance=Total/n=164.827 Standard Deviation =12.839

85. Topic 5 Planning IIIEstimating Software Size 85 Step 4: Calculating Size Range Midpoints For each category, use the average x avg and standard deviation σ to calculate the size range midpoints VL = x avg + 2σ L = x avg + σ M = x avg S = x avg – σ VS = x avg - 2σ

86. Topic 5 Planning IIIEstimating Software Size 86 Negative Size Range Midpoints Table 5.10 shows the example of the size range midpoints and the 13 object sizes per method. However, in this example, the VS midpoint is a negative number, which is not what we want and means that the object data are not normally distributed.

87. Topic 5 Planning IIIEstimating Software Size 87 Table 5.10 Pascal Text Object and Size Ranges Size RangesRange Midpoint LOC Object LOC/Method VS-5.68 6.000 S7.16 8.333 10.333 12.333 16.400 M20.00 20.500 21.750 22.250 23.000 28.333 29.000 L32.84 VL45.68 55.800

88. Topic 5 Planning IIIEstimating Software Size 88 Approach II: Procedure with Natural Log of Original Data The trick to handle the negative size range midpoint is to calculate the natural log of the data. The following is the procedure with the first 2 steps same as the previous procedure.

89. Topic 5 Planning IIIEstimating Software Size 89 Step 3: Calculating the Natural Log and Average For each category, calculate the natural log (ln) of the LOC per method of each object, and the average, avg ln, of these log values. Table 5.11 is the example for object category, text.

90. Topic 5 Planning IIIEstimating Software Size 90 Table 5.11 Pascal Text Object ln (LOC per Method) Object Name LOC per MethodIn (LOC per Method)(In LOC-In LOC avg ) 2 each_line10.3332.3350.2173 each_charr6.0001.7921.0196 list_clump21.7503.0800.0773 chracter29.0003.3670.3201 single_character8.3332.1200.4641 single_read6.0001.7921.0196 list_clp22.2503.1020.0905 char28.3333.3440.2943 single_char12.3332.5120.0836 converter55.8004.0221.4890 string_manager20.5003.0200.0479 string_builder16.4002.7970.0000 string_decrementer23.0003.1350.1115 Total260.03336.4195.2348 Average20.0032.802 Variance164.8270.4027 Standard Deviation12.8390.6346 InVL=2.802+1.2694.071VL=e 4.071 =58.62 InL=2.802+.6353.437L=e 3.437 =31.09 InM=2.8022.802M=e 2.802 =16.48 InS=2.802-.6352.167S=e 2.167 =8.73 InVS=2.802-1.2691.533VS=e 1.533 =4.63

91. Topic 5 Planning IIIEstimating Software Size 91 Step 4: Calculating Standard Deviation For each category, calculate the variance and standard deviation of these log values. Variance = σ 2 = (1/n) i=1..n (x i – x avg ) 2 Standard Deviation = of Variance =σ where x i = ln (LOC per method) of each object of a category.

92. Topic 5 Planning IIIEstimating Software Size 92 Step 5: Calculating the Log of Size Range Midpoints For each category, use average of log values and standard deviation to calculate the log of size range midpoints ln(VL) = avg ln + 2σ ln(L) = avg ln + σ ln(M) = avg ln ln(S) = avg ln – σ ln(VS) = avg ln - 2σ

93. Topic 5 Planning IIIEstimating Software Size 93 Step 6: Calculating the Antilog For each category, calculate the antilog to get the midpoints of the size ranges VL = e ln(VL) V = e ln(L) M = e ln(M) S = e ln(S) VS = e ln(VS) Table 5.12 shows the example of the size range midpoints and the 13 object sizes per method.

94. Topic 5 Planning IIIEstimating Software Size 94 Table 5.12 Pascal Text Objects and Size Ranges Size RangesRange Midpoint LOCObject LOC/Method VS4.63 6.000 8.333 S8.73 10.333 12.333 16.400 M16.48 20.500 21.750 22.250 23.000 28.333 29.000 L31.09 55.800 VL58.62

95. Topic 5 Planning IIIEstimating Software Size 95 5.6 Estimating Considerations

96. Topic 5 Planning IIIEstimating Software Size 96 5.6 Estimating Considerations 1 The PSP estimating objective is to improve your estimating ability by tracking and analyzing your estimates. If your estimating process is stable, the linear regression method, based on the historical data gathered from consistently biased estimates, can make an accurate bias adjustment. While you gain more experience and your process evolves, you should adjust your statistical calculations to include only the newer and more representative data and drop the old ones.

97. Topic 5 Planning IIIEstimating Software Size 97 Estimating Considerations 2 Whenever your linear regression parameters appear unreasonable (e.g., β 1 far from 1.0, large β 0 ), use the averaging method to estimate. This method uses a ratio to adjust size or time based on historical averages. estimated program LOC = estimated object LOC * ratio where ratio = historical average = (final program LOC) / (estimated object LOC)

98. Topic 5 Planning IIIEstimating Software Size 98 Estimating Considerations 3 To use the linear regression method, you must have at least three programs for which you have made object LOC estimates. If you have at least three programs but enough historical estimate data, obtain β 0 and β 1 from your actual size data If you do not have enough historical data but at least one program, use the averaging method

99. Topic 5 Planning IIIEstimating Software Size 99 Estimating Considerations 4 You can learn to reduce the estimating bias by comparing, during postmortem, estimates made at each phase with their actual size. To estimate unprecedented products, the best answer is to resist making firm estimates until you have completed a feasibility study and build some prototypes.

100. Topic 5 Planning IIIEstimating Software Size 100 5.7 Summary

101. Topic 5 Planning IIIEstimating Software Size 101 5.7 Summary 1 Accurate size estimate will help you to make better development plans. Size estimating skill improve with practice. A defined and measured process provides a repeatable basis for improvement.

102. Topic 5 Planning IIIEstimating Software Size 102 Summary 2 With PROBE, estimates are based on one of following four methods: Method A: regression with estimated object LOC Method B: regression with estimated new and changed LOC Method C: size or time adjustment based on historical averages (the averaging method) Method D: engineering judgment

103. Topic 5 Planning IIIEstimating Software Size 103 Summary 3 Method A: regression with estimated object LOC use the relationship between estimated object LOC and actual new and changed LOC actual development time The criteria for using this method are 3 or more data points that are correlated (r 2 > 0.5) Reasonable regression parameters

104. Topic 5 Planning IIIEstimating Software Size 104 Summary 4 Method B: regression with estimated new and changed LOC use the relationship between estimated new and changed LOC and actual new and changed LOC actual development time The criteria for using this method are 3 or more data points that are correlated (r 2 > 0.5) Reasonable regression parameters

105. Topic 5 Planning IIIEstimating Software Size 105 Summary 5 Method C: adjusting size or time based on historical averages. the averaging method easy to use used when linear regression parameters (β 0, β 1 ) appear unreasonable (that is, methods A and B can not be used) assuming that there is no fixed overhead The criteria for using this method are At least one data point is required.

106. Topic 5 Planning IIIEstimating Software Size 106 Summary 6 Method D: engineering Judgment with estimated object LOC used in absence of historical data using judgment from estimated object LOC to estimate actual new and changed LOC actual development time used when methods A, B, and C can not be used

107. Topic 5 Planning IIIEstimating Software Size 107 5.8 Exercises

108. Topic 5 Planning IIIEstimating Software Size 108 Program 3A 1 Use PSP0.1 (see Appendix in Topic 4) to write program 3A. Program 3A Requirements: Write a program to count the total program LOC the total LOC in each object the number of methods in each object If an object-oriented program is not used as the input, count the total program LOC the total LOC in each procedure or function

109. Topic 5 Planning IIIEstimating Software Size 109 Program 3A 2 Use the counting standard produced by report exercise R1. It is acceptable to enhance program 2A or to reuse some of its methods, procedures, or functions in developing this program. Program 3A Testing: Thoroughly test the program. At a minimum, test program 1A, 2A, and 3A. Prepare a test report that includes a table as the format in Table 5.11. Produce a report on the defect fix times for programs 1A, 2A, and 3A.

110. Table 5.11 Test Result Format Program 3A Program number Object NameNumber of Methods Object LOCTotal Program LOC 1AABC386 DEF28 GHI492 212 2A… a) Format for object-oriented program designs Program number Procedure/ Function Name Number of Methods Procedure/ Function LOC Total Program LOC 1AABC186 DEF18 GHI192 212 2A… b) Format for non object-oriented program designs

111. Topic 5 Planning IIIEstimating Software Size 111 Order to Submit Assignment: Cover sheet: Exercise #, Name, SID PSP0.1 Project Plan Summary PIP form, including lessons learned Time Recording Log Defect Recording Log Source program listing Report R1 LOC counting standard (if modified) Report R2 coding standard (if modified) Report R3 defect analysis report Test Results Program 3A 3

112. Topic 5 Planning IIIEstimating Software Size 112 Program 4A 1 Use PSP1 (see Appendix in this topic) to write program 4A. Program 4A Requirements: Write a program to calculate the linear regression size-estimating parameters:

113. Topic 5 Planning IIIEstimating Software Size 113 Program 4A 2 Use the historical data of a set of n programs: object LOC, x i, and new and changed LOC, y i. Enhance the linked list of program 1A to hold the n data records, where each record has 2 real numbers.

114. Topic 5 Planning IIIEstimating Software Size 114 Program 4A 3 Program 4A Testing: Thoroughly test the program. At a minimum, test it with the 3 cases shown in Table 5.12: use the data for estimated object LOC and actual new and changed LOC. use the data for estimated new and changed LOC and actual new and changed LOC. use the data, estimated new and changed LOC and actual new and changed LOC, you have gathered for the programs 2A, 3A and 4A you have developed. Prepare a test report that includes a table as the format in Table 5.13.

115. Table 5.12 Size Estimating Regression Data Program NumberEstimated Object LOCEstimated New and Changed LOC Actual New and Changed LOC 1130163186 2650765699 399141132 4150166272 5128137291 6320355331 795136199 894512061890 9368433788 1096111301601 Sum382846326389 Average382.8463.2638.9

116. Table 5.13 Test Result Format Program 4A TestExpected ResultsActual Results β0β0 Β1Β1 Β0Β0 Β1Β1 Table D8: Estimated Object versus Actual New And Changed LOC -22.551.7279 Table D8: Estimated New and Changed LOC versus Actual New and Changed LOC -23.921.4310 Program 2A, 3A, 4A: Estimated New LOC versus Actual New and Changed LOC NA

117. Topic 5 Planning IIIEstimating Software Size 117 Appendix PSP 1

118. Topic 5 Planning IIIEstimating Software Size 118 Report R3 Requirements

119. Topic 5 Planning IIIEstimating Software Size 119 Requirements for Report 3 The objectives of the defect analysis are to help you understand the Density and type of defects introduced and found while developing programs. Importance of carefully gathering, recording, and reporting process data.

120. Topic 5 Planning IIIEstimating Software Size 120 Report 3 Requirements 1 Analyze the defects found in development the initial programs. Produce a report that includes these table. Defect density Compile and test phase defect density Average defect fix time by phase injected and removed

121. Topic 5 Planning IIIEstimating Software Size 121 Report 3 Requirements 2 To prepare the defect analysis report, you will need the following project plan summary data for programs 1A through 3A. new and changed LOC defect injected and removed for each phase From the defect logs, you will need counts and fix times for all defects. Injected in design and found in compile or test Injected in coding and found in compile or test Injected in design or coding founded in compile or test

122. Topic 5 Planning IIIEstimating Software Size 122 Example Defect Analysis Report 3 Defect DensitiesCompile and Test Defects Program Number New and Changed LOC Total DefectsDefects per KLOC Defects found in compile Compile defects per KLOC Defects found in test Test defects per KLOC 111117153981218 2886686 00 31031097439549 4778104339549 5818990000 612486532400 717524137529211 81179771900 9153161050017 1022415672914 Totals1253121973326119

123. Topic 5 Planning IIIEstimating Software Size 123 Example Defect Analysis Report 3 Defect Fix Times Defects found in compiling Defects found in testing Total defects found Defects injected in designing Total fix time1137256 Total defects1448 Average fix time 1345 Defects injected in coding Total fix time939122 Total defects32361 Average fix time 332 Total defects injected Total fix time94159444 Total defects3311124 Average fix time 3144

124. PSP1 Process Script 1 Phase Number PurposeTo guide you in developing module-level programs Entry Criteria Problem description PSP1 Project Plan Summary form Size Estimating Template Historical estimate and actual size data Time and Defect Recording Logs Defect Type Standard Stop watch (optional) 1Planning Produce or obtain a requirements statement Use the PROBE method to estimate the total new and changed LOC required. Complete the Size Estimating Template. Estimate the required development time Enter the plan data in the Project Plan Summary form Complete the Time Recording Log 2Development Design the program Implement the design Compile the program and fix and log all defects found Test the program and fix and log all defects found Complete the Time Recording Log

125. PSP1 Process Script 2 Phase Number PurposeTo guide you in developing module-level programs 3PostmortemComplete the Project Plan Summary form with actual time and defect data Exit Criteria A thoroughly tested program Completed Project Plan Summary with estimated and actual data Completed Size Estimating Template Completed Test Report Template Completed PIP forms Completed Defect and Time Recording Logs

126. PSP1 Planning Script 1 Phase Number PurposeTo guide the PSP planning process Entry Criteria Problem description PSP1 Project Plan Summary form Size Estimating Template Historical estimate and actual size data Time Recording Logs 1Program Requirements Produce or obtain a requirements statement for the program. Ensure the requirements statement is clear and unambiguous. Resolve any questions. 2Size Estimate Produce a program conceptual design. Use the PROBE method to estimate the new and changed LOC required to develop this program. Estimate the base, added, deleted, modified, and reused LOC. Complete the Size Estimating Template and Project Plan Summary.

127. PSP1 Planning Script 2 Phase Number PurposeTo guide the PSP planning process 3Estimate Resources Based on the time required per LOC on previous programs, make your best estimate of the time required to develop this program. Using the To Date % from the most recently developed program as a guide, describe the development time over the planned project phases. Exit Criteria A documented requirements statement The program conceptual design Completed Size Estimating Template A completed Project Plan Summary with estimated program size and development time data Completed Time Recording Logs

128. PSP1 Development Script 1 Phase Number PurposeTo guide the Development of small programs Entry Criteria Requirements statement Project Plan Summary with planned program size and development time Time and Defect Recording Logs Defect Type Standard and Coding Standard 1Design Review the requirements and produce a design to meet them Record time in Time Recording Log 2Code Implement the design following Coding Standard Record in the Defect Recording Log any requirements or design defects found Record time in Time Recording Log 3Compile Compile the program until error free Fix all defects found Record defects in the Defect Recording Log Record time in Time Recording Log

129. PSP1 Development Script 2 Phase Number PurposeTo guide the Development of small programs 4Test Test until all tests run without error. Fix all defects found. Record defects in the Defect Recording Log. Record time in Time Recording Log. Complete a Test Report Template on the tests conducted and results obtained. Exit Criteria A thoroughly tested program that conforms to the Coding Standard Completed Test Report Template Completed Defect and Time Recording Logs

130. Phase Number PurposeTo guide the PSP postmortem process Entry Criteria Problem description and requirements statement Project Plan Summary form with planned program size and development time Completed Test Report Template Completed Time Recording Logs Completed Defect Recording Log A tested and running program that conforms to the Coding Standard 1Defects Injected Determine from the Defect Recording Log the number of defects injected in each PSP1 phase Enter this number under Defects Injected – Actual on the Project Plan Summary 2Defects Removed Determine from the Defect Recording Log the number of defects removed in each PSP1 phase Enter this number under Defects Removed – Actual on the Project Plan Summary 3Size Count the LOC in the completed program. Determine the base, reused, deleted, modified, added, total, total new and changed, and new reused LOC. Enter these data on the Project Plan Summary. PSP1 Postmortem Script 1

131. Phase Number PurposeTo guide the PSP postmortem process 4Time Review the completed Time Recording Log Enter the total time spent in each PSP1 phase under Actual on the Project Plan Summary form Exit Criteria A fully tested program that Conforms to the Coding Standard Completed Test Report Template Completed Project Plan Summary form Completed PIP forms describing process problems, improvement suggestions, and lessons learned. Completed Defect and Time Recording Logs PSP1 Postmortem Script 2

132. Size Estimating Template 1

133. Size Estimating Template 2

134. Test Report Template

135. PSP1 Project Plan Summary 1

136. PSP1 Project Plan Summary 2