The function point measure was originally designed to be applied to business information systems applications. To accommodate these applica...
The function point measure was originally designed to be applied to business information systems applications. To accommodate these applications, the data dimension was emphasized to the exclusion of the functional and behavioral (control) dimensions. For this reason, the function point measure was inadequate for many engineering and embedded systems (which emphasize function and control). A number of extensions to the basic function point measure have been proposed to remedy this situation.
A function point extension called feature points, is a superset of the function point measure that can be applied to systems and engineering software applications.The feature point measure accommodates applications in which algorithmic complexity is high. Real-time, process control and embedded software applications tend to have high algorithmic complexity and are therefore amenable to the feature point.
To compute the feature point, information domain values are again counted and weighted. In addition, the feature point metric counts a new software characteristic—algorithms. An algorithm is defined as "a bounded computational problem that is included within a specific computer program” . Inverting a matrix, decoding a bit string, or handling an interrupt are all examples of algorithms.
Another function point extension for real-time systems and engineered products has been developed by Boeing. The Boeing approach integrates the data dimension of software with the functional and control dimensions to provide a function-oriented measure amenable to applications that emphasize function and control capabilities. Called the 3D function point, characteristics of all three software dimensions are “counted, quantified, and transformed” into a measure that provides an indication of the functionality delivered by the software.
The data dimension is evaluated in much the same way as described before. Counts of retained data (the internal program data structure; e.g., files) and external data (inputs, outputs, inquiries, and external references) are used along with measures of complexity to derive a data dimension count. The functional dimension is measured by considering “the number of internal operations required to transform input to output data”. For the purposes of 3D function point computation, a “transformation” is viewed as a series of processing steps that are constrained by a set of semantic statements. The control dimension is measured by counting the number of transitions between states.
A state represents some externally observable mode of behavior, and a transition occurs as a result of some event that causes the software or system to change its mode of behavior (i.e., to change state). For example, a wireless phone contains software that supports auto dial functions. To enter the auto-dial state from a resting state, the user presses an Auto key on the keypad. This event causes an LCD display to prompt for a code that will indicate the party to be called. Upon entry of the code and
hitting the Dial key (another event), the wireless phone software makes a transition to the dialing state. When computing 3D function points, transitions are not assigned a complexity value.
To compute 3D function points, the following relationship is used:
index = I + O + Q + F + E + T + R
where I, O, Q, F, E, T, and R represent complexity weighted values for the elements discussed already: inputs, outputs, inquiries, internal data structures, external files, transformation, and transitions, respectively. Each complexity weighted value is computed using the following relationship:
complexity weighted value = NilWil + NiaWia + NihWih
where Nil, Nia, and Nih represent the number of occurrences of element i for each level of complexity (low, medium, high); and Wil, Wia, and Wih are the corresponding weights.
It should be noted that function points, feature points, and 3D function points represent the same thing—"functionality" or "utility" delivered by software. In fact, each of these measures results in the same value if only the data dimension of an application is considered. For more complex real-time systems, the feature point count is often between 20 and 35 percent higher than the count determined using function points alone.
The function point (and its extensions), like the LOC measure, is controversial. Proponents claim that FP is programming language independent, making it ideal for applications using conventional and nonprocedural languages; that it is based on data that are more likely to be known early in the evolution of a project, making FP more attractive as an estimation approach. Opponents claim that the method requires some "sleight of hand" in that computation is based on subjective rather than objective data; that counts of the information domain (and other dimensions) can be difficult to collect after the fact; and that FP has no direct physical meaning—it's just a number.
