Counting and Weighting Algorithms
Since the most visible difference between Function Points and Feature
Points is the new parameter for "algorithms," it is worthwhile
to discuss algorithmic concepts and how algorithms can be counted.
An algorithm is defined in standard software engineering texts
as the set of rules, which must be described and encoded to solve
a computational problem. Some examples of typical algorithms include
calendar date routines, square root extraction routines, and overtime
pay calculation routines.
For Feature Point counting purposes, an algorithm can be defined
in the following terms: "An algorithm is a bounded computational
problem which is included within a specific computer program."
Algorithms vary in difficulty and complexity, and the SPR treatment
of algorithms assumes a range of perhaps 10 to 1 for algorithmic
difficulty. Algorithms requiring only basic arithmetic operations
or a few simple rules are assigned a minimum value of 1. Algorithms
requiring complex equations, matrix operations, and difficult mathematical
and logical processing could be assigned a weight of 10. The default
weight for a normal algorithm using ordinary mathematics would be
3.
Although more than 50 software engineering books are in print that
describe and discuss algorithms, it is interesting there is no available
taxonomy for classifying algorithms other than purely ad hoc methods
based on what the algorithm might be used for. There is a need for
a taxonomy based on complexity, and hopefully the Feature Point
research can move toward that goal. The basis for the provisional
weights for algorithms is twofold:
| • |
The number of calculation
steps or rules required by the algorithm; and |
| • |
The number of factors
or data elements required by the algorithm. |
Since the Feature Point method is still experimental, the approach
to weighting algorithms is still under evolution.
Rules For Counting Algorithms
The following are some supplemental rules for determining what algorithms
are countable and significant.
| • |
The algorithm must
deal with a solvable problem. |
| • |
The algorithm must
deal with a bounded problem. |
| • |
The algorithm must
deal with a definite problem. |
| • |
The algorithm must
be finite and have an end. |
| • |
The algorithm must
be precise and have no ambiguity. |
| • |
The algorithm must
have an input or starting value. |
| • |
The algorithm must
have output or produce a result. |
| • |
The algorithm must
be implementable, in that each step must be capable of execution
on a computer. |
| • |
The algorithm can include
or call upon subordinate algorithms. |
| • |
The algorithm must
be capable of representation via the standard structured programming
concepts of sequence, if-then-else, do-while, CASE, etc. |
These factors are being tuned and evaluated, since Feature Points
are still experimental; however, research is underway to develop
a more rigorous taxonomy and weighting scale for algorithms.
Examples of Typical Algorithms
Although the software engineering literature is plentifully supplied
with illustrations and examples of algorithms, there is currently
no complete catalog of the more common algorithms that occur with
high frequency in software applications. Since it is always more
useful to have tangible examples of concepts, the following are
discussions of some common algorithm types.
Sorting
Sorting is one of the earliest forms of algorithm created during
the computer era. Although physical sorting of records and files
has been carried out for thousands of years, it was not until mechanical
tabulating equipment was developed that sorting became anything
other than a brute force manual task. With the arrival of electronic
computers, the scientific study of sorting began. Sorting itself,
and the development of ever faster sorting algorithms, have been
one of the triumphs of the software engineering community. Prior
to about 1950, sorting methods were primarily simple and ad hoc.
During the 1960's, 70's, and on through today whole new families
of sorting methods and improved algorithms were developed, including
selection sorts, insertion sorts, bubble sorts, quick sort, radix
sorting, and so forth.
Searching
Two of the primary functions of computers in their normal day-to-day
business applications are sorting and searching. Here too, physical
files have been searched for thousands of years, and techniques
for facilitating the storage and retrieval of information long outdate
the computer era. However, it was only after the emergence of electronic
computers that the study of searching algorithms entered a rigorous
and formal phase. This new research into sorting methods led to
the development of binary searches, tree searches, indirect tree
searches, radix searches, and many others.
Step-Rate Calculation Functions
Under the concept of the graduated income tax, a certain level of
taxable income is related to a certain tax rate. Higher incomes
pay higher tax rates, while lower incomes pay lower tax rates. The
same logic of dealing with the dependent relationships of two variables
is perhaps the most common general form of algorithm for business
software. This logic, termed a "step rate calculation function,"
that is used for income tax rates can also apply to the rates for
consuming public utilities such as electricity or water, for salary
and performance calculations, dividends, and many others.
Feedback Loops
Feedback loops of various kinds are common algorithms in process
control applications, hospital patient monitoring applications,
and many forms of embedded software such as fuel injection, radar,
and navigational software. Classic feedback loops are much older
than the computer era, of course, and one of the clearest examples
is provided by the automatic governors on steam engines. Such governors
were normally rotating metal weights whose rotation was driven by
escaping steam. As the velocity of the steam increased when pressures
went higher, the governors opened more widely and allowed excess
steam to escape. This same concept of feedback between two variables
is one of the major classes of algorithms for sensor-based applications.
Function Point Calculations
It is appropriate to conclude the discussion of representative algorithms
with the observation that the calculation sequence for Function
Points is itself an algorithm.
Let us consider two practical examples. Suppose you were writing
a computer program to calculate Function Points using IBM's original
1979 methodology. The calculation sequence would be to multiply
the raw data for inputs, outputs, inquiries, and master files by
the empirical weights Albrecht derived, thus creating a subtotal
of unadjusted Function Points. Then multiply the unadjusted subtotal
by a user-specified complexity factor to create the final adjusted
Function Point total. This entire calculating sequence would comprise
only one algorithm, the "Function Point calculation algorithm."
Since the calculations consisted of only five simple multiplications
and two additions, the weight for this algorithm can be viewed as
minimal and is assigned a weighting value of 1.
Now let us suppose you were writing a computer program to calculate
Function Points using IBM's current methodology, as it was revised
in 1984 and currently exists in 1993.
The calculation sequence today would be to first multiply and sum
the file and data element references to determine high, low, or
medium complexity of the five input parameters. Then multiply the
raw data for inputs, outputs, inquiries, data files, and interfaces
by the separate values for high, low, and medium complexity to quantify
the unadjusted Function Point total.
Then the 14 General System Characteristics must be summed, multiplied
by .01, and the constant of .65 added to create the influence multiplier
weight. Finally, the unadjusted Function Points must be multiplied
by the influence weight to yield the adjusted Function Point total.
Calculating the Function Point total is still of course a single
algorithm, but now the weight would appropriately be set at 3 to
reflect the increased difficulty of the calculation sequence.
Thus the original 1979 version of IBM's Function Points could be
programmed with a single algorithm having a total algorithmic weight
of 1. The 1984 revisions of IBM's Function Point method now require
a more normal weight of 3.
As may be seen from the two examples, as the algorithmic complexity
of an application moves up the difficulty scale, the Feature Point
technique can follow closely.
|
