## Box The Norden Rayleigh Function

where m(t) = staffing requirement (number of persons) at any time "t" (in years) during the life of the project K = total project effort in staff-years (SY) a = acceleration factor

The acceleration factor is given by: ^

This document was created by an unregistered ChmMagic, please go to http://www.bisenter.com to register it. Thanks Where td = time of delivery = development time

Later, in the 1970s, Lawrence H. Putnam (Quality Software Management, QSM) applied Norden's observations to the software life cycle, validating the existence of an optimum staffing shape for a given project. He began with 50 U.S. Army projects and now has empirical evidence for several thousand. Based on statistical analysis of these projects (QSM has been collecting data on completed projects since 1975), Putnam found that the relationship among the three principal elements of software estimating—size, schedule, and effort—matched the Norden/Rayleigh function. As size goes up, so do effort, time, and defects, but in different types of relationships (exponential, logarithmic). He concluded that reducing size is one way to reduce schedule, effort, and number of defects. Size can be reduced a number of ways, including "requirements scrubbing" (eliminating "gold plating" or nonessential features), phased or incremental delivery, reuse, and commercial-off-the-shelf products.

Like Boehm, Putnam used scatter diagrams and curve-fitting techniques to find relationships in his observed data. After plotting the major trend line that represents all observed data points (size versus months), the mean was calculated (50% of the projects fell above the line and 50% of the projects fell below the line), along with values for +1s (only 16% of the data points fell above this line; 84% of the data points fell below this line) and for-1s (only 16% of the data points fell below this line; 84% of the data points fell above this line), as shown [figure 11-14. If a project is estimated to fall above the line, the indication is that it is not practical to build the product now—this has become known as the Impractical Zone. If a project is estimated to fall below -1 s, the indication is that it is not possible to build the product this fast (this has become known as the Impossible Zone, although many project managers have been known to forge ahead anyway).

Figure 11-14. Impractical/Impossible Zones

Figure 11-14. Impractical/Impossible Zones

QSM's Software Lifecycle Management (SLIM) process consists of methodologies tied together with the decision-support tools, SLIM-Estimate©, SLIM-Control©, and S LI M-Metrics©. SLIM-Estimate© supports estimating and planning, SLIM-Control© supports tracking and forecasting, and SLIM-Metrics© supports data capture and analysis.

The software production relationship is described in Box 11711.