|
Yesterday we saw that Dynamic Linking and
Embedding (DLE) evolved into Object Linking and
Embedding (OLE) which evolved into ActiveX.
None of this evolution was planned.
Of course most of the problem can be traced
back to creep -- the rate of change in
requirements between the time the coders start
hacking and the time the product is
shrink-wrapped and put on the shelves or given
away over the Internet. Figure 2 relates the
maximum size that can be constructed versus the
creep rate. Any software system larger than the
maximum size (above the line in Figure 2) is
impossible to build. Figure 2 predicts failure
of any software system larger than this maximum
size. As a very rough approximation, each
function point is about 100 C/C++ statements.
Therefore, a 1,000 function point is about
100,000 lines of C/C++.
Capers Jones (COMPUTER, March 1996, p. 117)
says, "creeping user requirements will grow at
an average rate of 1% per month over the entire
development schedule." In the same article, he
says, "raising the number of function points to
the 0.4 power predicts the approximate
development schedule in calendar months." In
mathematical terms this means:
R = FP * (1.01)^(FP^0.4)),
where FP = function points (program size);
R = requirements
The question we pose is, "when does R reach
100% change?" We build the system twice -- once
according to the original requirements, and
then a second time according to the new
requirements. Set R to 2*FP, and solve for FP.
This will tell you when the requirements have
changed 100%, rendering the original
specification completely wrong!
FP = (A/B)^2.5,
where A = log(2), and B = log(1.01)
This yields FP = 40,500 - a pretty large
program!
Suppose we let the 1% creep rate slide? Then,
setting B = log(1+C), where C ranges from 1% to
20%, we get Figure 2. This shows that a small
deviation from 1%, say 5% creep, radically
lowers the size of a "feasible" software
system.
Figure. 2. Maximum program size, measured in function
points, versus the monthly rate of change in requirements.
|