1. Estimating Software Size Part I

2. This chapter first discuss the size estimating problem and then describes the PROBE estimating method used in this book. Several other size estimating methods are briefly described along with some of the issues you should consider in using them. You should use the PROBE method for the exercises in the project.

3. Background The principal reason you should estimate the size of a software product is to help you to plan the product’s development. The quality of a software development plan generally depends on the quality of the size estimate. With a good plan, you have the basis for funding and staffing the work. You know what has to be done, when, and by whom. You also know how long it will take and understand the critical dependencies or other constraints. Poor software planning is one of the principal reasons software projects get into trouble. A frequent cause of poor plans is a poor size estimate.

4. Background(cont.) Accepted practice in engineering, manufacturing, and construction is to base development plans on product size estimate. Building construction provides a good example. The degree to which you can accurately and precisely plan a job depends on what you know about it. At the earliest, or preproposal, stage, you have only a general idea of the product requirements. About the only way to make an estimate is by analogy to previous product.

5. Background(cont.) After the proposal phase, you know progressively more about the planned product. You can then make more-refined estimates of jobs size. Estimates for large software jobs can be handled in much the same way. To make an accurate, you must start with a design specification. You then examine and estimate each part of the job. This estimate requires separate estimates for each software component, major document, test cases, installation planning file conversation, and user training. If you want to make accurate estimate, you will have to define all these details and consider each one in the estimate.

6. The size estimating framework The tasks you perform are shown in the rectangles, and the various data, reports, and products are shown in the ovals. In estimating the size you first define the requirements and then produce a conceptual design. You then compare the elements of this conceptual design with the known sizes of program elements you have previously developed. This process helps you to judge the size of the parts of the new product. The tricky part of software size estimating is in characterizing the product elements and relating them to your historical experience.

8. The size Resource Relationship Size is an accurate predictor of the resources required to help a product. The relationship between size and required resources has led to the development of a number of cost models such as COCOMO, PriceS, and SLIM. While these models can be useful, they must be calibrated for each using organization. Each such organization must thus gather its own historical data and use them to set the factors in its cost models. The models also require a size estimate as input. The accuracy of the models is thus limited by the accuracy of the size estimates. So, even you use an estimating model, you need an accurate size estimate.

9. Popular Estimating Methods Size estimating is a skill that must be learned, practiced, and maintained. Because it involves considerable judgment, the selection of an estimating method is also largely a matter of personal taste.

10. Wideband-Delphi Method The Wideband-Delphi estimating method was originated by the Rand Corporation and refined by Boehm. It calls for several engineers to individually produce estimates and it then use a Delphi process to converge on a consensus estimate.

11. The procedure is as follows.

13. For reasonably large programs, the estimators make simultaneous estimate for several product components. At the end of the estimating process, the estimates are combined to produce the total final estimate. The estimating process is run by a moderator. The purpose of the Delphi process is to share those views. By encouraging the participants to discuss the project tasks, a skilled moderator can facilitate very informative discussions. The person who made a particularly high or low estimate is sometimes willing to explain why that value was picked. This method can produce quite accurate estimates.

14. Standard-Component Method The standard – component estimating method is described by Putnam as a way to use an organization’s historical data to make progressively more-refined program size estimates. You start by gathering data on the sizes of the various levels of program abstractions you use, for example, subsystems, modules, and screens. You then judge how many of these components will likely be in your new program. You also judge the largest number you could imagine being in the program as well as the smallest number.

15. Standard-Component Method(cont.) Combine these estimate: Estimate Number= [smallest conceivable number + 4*(likely number) + largest conceivable number] /6 Some of the values Putnam uses for standard- component estimating are shown in an example in the following table

17. Function-Point Method The function-point method is the most popular for estimating the size of commercial software applications. Invented by Albrecht at IBM in 1979. Albrecht identified five basic functions that occur frequently in commercial software development and categorized them according to their relative development complexities. The definitions of these functions are as follows:

18. 1.Input: Inputs are screens or forms through which human users of an application or other programs add new data or update existing data. 2.Output:Outputs are screens or reports that the application produces for human use or for other programs. 3.Inquires:Inquiries are screens that allow users to interrogate an application and ask for assistance or information, such as Help screens. 4.Data files:logical collections of records that the application modifies or updates. 5.Interface: files shared /w other applications and include incoming or outgoing tape files, shared databases, and parameter lists.

19. To make a function-point method estimate, you review the requirements and count the numbers of each type of function the program will need. You then enter these numbers in the blanks in the table and multiply them by the weights to produce the total numbers of function points in each category.

20. John, in his definitive text on this subject, suggests that this function-point total be adjusted by the influence factor shown, with an example, in table 5.5 and 5.6. The influence factor values are selected from 0 to 5, depending on the degree to which you judge that the particular factor falls between very simple to very complex or low to high, and so on.

24. Because there are 14 factors in table 5.5 and their values can each range from 0 to 5, the total of the influence factors then ranges from 0 to 70. From the formula at the bottom of table 5.5, you can see that the total complexity multiplier varies from.65 to 1.35, or from minus to plus 35 percent.

25. As useful as they are, function points are not fully satisfactory for two reasons. First, they cannot be directly measured and second, they are not sensitive to implementation decisions. John address this first problem by producing a number of function-point conversion factors that permit you to count LOC and calculate the program’s likely function point content. If you intend to use it, you should obtain copies of the latest International Function Point Users Group(IFPUG) guidelines and standards.