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) image from book

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.




Software Estimation. Demystifying the Black Art
Software Estimation: Demystifying the Black Art (Best Practices (Microsoft))
ISBN: 0735605351
EAN: 2147483647
Year: 2004
Pages: 212

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net