12.2 Standard Components

12.2 Standard Components

If you develop many programs that are architecturally similar to each other, you can use the standard components approach to estimate size. You first need to find relevant elements to count in your previous systems. The specifics will vary depending on the kind of work you do. Typical systems might include dynamic Web pages, static Web pages, files, database tables, business rules, graphics, screens, dialogs, reports, and so on. After you've identified what the standard components are, you compute the average lines of code per component for your past systems. Table 12-4 shows an example of historical data for standard components.

Table 12-4: Example of Historical Data on Lines of Code per Standard Component

Standard Component	LOC per Component
Dynamic Web pages	487
Static Web pages	58
Database tables	2,437
Reports	288
Business rules	8,327

Once you have your historical data, you estimate the number of standard components you'll have in the new program, and you compute the size of the new program based on past sizes. Table 12-5 shows one example.

Table 12-5: Example of Using Standard Components to Create a Size Estimate

Standard Component	LOC per Component	Minimum Possible Number	Most Likely Number	Maximum Possible Number	EstimatedNumber	Estimated LOC
Dynamic Web pages	487	11	25	50	26.8	13,052
Static Web pages	58	20	35	40	33.3	1,931
Database tables	2,437	12	15	20	15.3	37,286
Reports	288	8	12	20	12.7	3,658
Business rules	8,327	-	1	-	1	8,327
TOTAL	-	-	-	-	-	64,254

In this table, you enter your estimated counts in columns 3 through 5. In column 3, you enter the minimum number of components you can possibly imagine the project having. For the dynamic Web pages component in this example, that number is 11. In the next column, you enter the number you think is the most likely—25 for dynamic Web pages. Then, in the fifth column, you enter the maximum number of components you can imagine—in this case, 50. The estimated number in column 6 is then computed using the Program Evaluation and Review Technique (PERT) formula that was discussed in Chapter 9, "Individual Expert Judgment." Here's that formula adapted to estimate number of components:

(#7)

In this example, the estimated number of dynamic Web pages works out to [11 + (4 x 25) + 50] / 6 = 26.8. ^[1]

Once again, the numbers in this table are for purposes of illustration only, and you should derive your own numbers from your own historical data.

Using Standard Components with Percentiles

A variation on this approach is based on the use of percentiles rather than estimated number of components. In this approach, you again need to have enough historical projects to compute meaningful percentiles (in other words, at least 10 historical projects, and, ideally, closer to 20). But if you have that much historical data, rather than estimating a number, you can estimate how much different from average you believe each component will be. Table 12-6 provides an example of a reference table you could construct.

Table 12-6: Example of Reference Table for Standard Components

LOC per Component (Percentile)
Standard Components	Very Small (10th)	Small (25th)	Average (50th)	Large (75th)	Very Large (90th)
Dynamic Web pages	5,105	6,037	12,123	24,030	35,702
Static Web pages	1,511	1,751	2,111	2,723	3,487
Database tables	22,498	30,020	40,027	45,776	47,002
Reports	1,518	2,518	3,530	5,833	5,533
Business rules	7,007	7,534	8,509	10,663	12,111

The entries in this table give the size of the standard components relative to other projects your organization has done. According to this table, 10% of the organization's projects had 5,105 lines of code or fewer for their dynamic Web pages, 50% of projects had 2,111 lines of code or fewer for their static Web pages, 75% of projects had 10,663 lines of code or fewer for their business rules, and so on.

Once you have a reference table, you can classify the size you expect in each standard component area and look up the lines of code estimated for each component in Table 12-6. Table 12-7 shows an example.

Table 12-7: Example of Using Standard Components to Create a Size Estimate

Standard Component	Size Classification	Estimated LOC (from Table 12-6)
Dynamic Web pages	Average	12,123
Static Web pages	Large	2,723
Database tables	Small	30,020
Reports	Very Small	1,518
Business rules	Average	8,509
TOTAL	-	54,893

The entries in this table imply that you expect the project you're estimating to have an average number of dynamic Web pages compared to other projects your organization has done, a larger than average number of static Web pages, a smaller than average number of database tables, and so on.

This approach yields a size estimate of 54,893 lines of code. When presenting that number, it would once again be accurate to simplify it to 55,000 or 60,000 LOC (that is, 1 or 2 significant digits).

Limitations of Standard Components

The standard components approach has the advantage of requiring very little effort other than using your instincts to assess the sizes that the standard components will be in the new system and looking up the corresponding entries in the reference table. It will take some effort to construct and maintain a reference table similar to Table 12-4 or Table 12-6.

The practice of standard components is not based on counting, and so it violates the general principle of count, compute, judge. It does, however, tie estimates back to something familiar, and so it can be useful at times.

Overall, while the use of standard components is probably not the best technique to use later in a project, it can support the goal of minimizing the effort to create an early-in-the-project estimate that is subject to a high degree of inaccuracy anyway because of the Cone of Uncertainty.

Tip #56

Consider using standard components as a low-effort technique to estimate size in a project's early stages.

^[1]Sometimes people are confused by whether they should be dividing by 6 or some other number. The discussion in Chapter 10 about not dividing by 6 applied to computation of standard deviations. This formula computes the expected value, not the standard deviation, so the caution about not dividing by 6 doesn't apply here.