UNIVERSITATEA “POLITEHNICA” TIMISOARA

Facultatea de Automatica si Calculatoare

FUNCTION-ORIENTED METRICS

Student: Vasile CHINDRIS, Indrumator: As. Ing. Carmen HOLOTESCU

An IV – CTI
CUPRINS

1. What are Software metrics?

2. Function Oriented Metrics.
1. Function-point method.
2. Conversion of Function-point to SLOC
3. Characteristic-point method
4. Cyclomatic Complexity
3. Trends in Software Metrics
 1. What are Software metrics?

Effective management of any process requires quantification, measurement, and

modeling. Software metrics provide a quantitative basis for the development and
validation of models of the software development process. Metrics can be used to
improve software productivity and quality.
Unfortunately, the current state of software metrics is confused. Many metrics
have been invented. Most of these have been defined and then tested only in a limited
environment, if at all. In some cases, remarkable successes have been reported in the
initial application or validation of these metrics. However, subsequent attempts to test or
use the metrics in other situations have yielded very different results. One part of the
problem is that we have failed to identify a commonly accepted set of software
properties to be measured. As a result, the same metric has been used to measure very
different software properties. Moreover, we have virtually no theoretical models and a
multitude of metrics, only a few of which have enjoyed any widespread use or
acceptance.
Basically, software metrics are no more than some numbers that you get from
your project when you consider it from a certain perspective. The hard part is to interpret
these numbers and to decide what is good, what is wrong and what is acceptable.
Ordinarily, these measurements of the software process and product are studied
and developed for use in modeling the software development process. These metrics and
models are then used to estimate/predict product costs and schedules and to measure
productivity and product quality. Information gained from the metrics and the model can
then be used in the management and control of the development process, leading, one
hopes, to improve results.
Good metrics should facilitate the development of models that are capable of
predicting process or product parameters, not just describing them. Thus, ideal metrics
should be :
– simple, precisely definable—so that it is clear how the metric can be evaluated;
– objective, to the greatest extent possible;
– easily obtainable (i.e., at reasonable cost);
– valid—the metric should measure what it is intended to measure; and
– robust—relatively insensitive to (intuitively) insignificant changes in the process
or product.
 2) Function Oriented Metrics.

Function Oriented Metrics consists in estimating of the complexity of the

functions implemented by the SW product to be developed. There are 2 categories of
metrics:
– Functional points oriented metrics
– Feature points oriented metrics
There are some specific estimation methods based on these metrics:
– Function-Point Method
– Conversion of Function Points in SLOC
– Characteristic-Point Method
– Proxy-Based Method

2.1) Function Point Method

The function-point method, invented by Albrecht at IBM in 1979, is probably the

most popular method for estimating the size of commercial software applications.
Albrecht identified five basic functions that occur frequently in commercial
software development and categorized them according to their relative development
complexities. [Albrecht]
The definitions of these five basic functions are as follows: [Jones]
1) Inputs:
– Inputs are screens or forms through which human users of an application or
other programs add new data or update existing data.
– If an input screen is too large for a single normal display (usually 80
columns by 25 lines) and flows over onto a second screen, the set counts as
one input.
– Inputs that require unique processing are what should be considered.

2) Outputs:
– Outputs are screens or reports that the application produces for human use
or for other programs.
– Note that outputs requiring separate processing are the units to count;
– For example, in a payroll application, an output function that created, say,
100 checks would still count as one output.
 3) Inquiries:
– Inquiries are screens that allow users to interrogate an application and ask
for assistance or information, such as Help screens.

4) Data files:
– Data files are logical collections of records that the application modifies or
updates. A file can be, for example:
– A flat file such as a tape file,
– One leg of a hierarchical database such as IMS,
– One table within a relational database,
– One path through a CODASYL network database.

5) Interfaces:
– Interfaces are files shared with other applications and include:
– Incoming or outgoing tape files,
– Shared databases,
– Parameter lists.

To make a function-point estimate:

– Review the requirements and count the numbers of each type of function
the program will likely need.
– Enter these numbers in the Basic Counts area in Table 1 and multiply them
by the Weights area to produce the total numbers of function points in each
category.
– Add the obtained values.
– The obtained number is “Unadjusted Total” of functional points of the SW
you have estimated.

Basic Counts Function Type Weights Total

Inputs x4
Outputs x5
Inquiries x4
Logical Files x 10
Interfaces x7
Unadjusted total
Table 1
 Jones, in his definitive text on this subject, suggests that this unadjusted function-
point total be adjusted by the influence factors shown, (with an example), in Table 2.
The influence factors values are selected from 0 to 5, depending on the degree to
which you judge that the particular factor falls between very simple to very complex or
very low to very high, and so on.
Because there are 14 factors in Table 2 and their values can each range from 0 to
5, the total Sum of the influence factors then ranges from 0 to 70. The formula to
calculate the Complexity multiplier is:

Complexity multiplier=0.65+0.01*(Sum_of_the_influence_factors)

From the above formula, it can be seen that the total Complexity multiplier varies
from 0.65 (when Sum=0) to 1.35 (when Sum=70), or from minus to plus 35 percent.
To finalize the size estimation in this new conditions:
– Estimate the impact of each influence factor by values from 0 to 5.
– Add the assigned values for this factors and obtain the
Sum_of_influence_factors.
– Calculate the Complexity Multiplier based on the formula:
Complexity Multiplier=0.65+0.01*(Sum_of_influence_factors)
– Multiply the Unadjusted Total of functional points with the Complexity
Multiplier in order to obtain the Function points number for the estimated
SW.

Nr. crt Factor Influence

0 = non influence
1 = little influence
2 = moderate influence
3 = average influence
4 = significant influence
5 = strong influence
1. Data communications 2
2. Distributed functions 0
3. Performance objectives 3
4. Heavily used configuration 3
5. Transaction rate 4
6. On line data entry 4
7. End-user efficiency 3
8. On line update 2
 9. Complex processing 3
10. Reusability 2
11. Installation ease 3
12. Operational ease 4
13. Multiple sites 5
14. Facilitate change 3
Sum of influence factors 41
Complexity Multiplier = 1.06
0.65+0.01*(Sum_of_influence_factors)
Function Points = Complexity Multiplier * 135*1.06 = 143
Unadjusted Function Points

Table 2

An Example [Hu95] (Table 3):

A count of an applications requirement statement might yield a total of:
– 8 inputs,
– 12 outputs,
– 4 inquiries,
– 2 logical files,
– 1 interface.

Based on proposed estimation algorithm, multiply these numbers by the weights

to give the values in the total column. The 8 inputs, for example, are multiplied by a
weight of 4, giving a total of 32 (Table 3). The Unadjusted total of function-point would
then be 135. The influence factors you selected from Table 2 are used to calculate the
function point adjustment (Complexity Multiplier) of 1.06. When you multiply the
unadjusted function-point total of 135 by this factor, you get a total of 143 function
points.
 Basic Counts Function Type Weights Total
8 Inputs 8x4 32
12 Outputs 12 x 5 60
4 Inquiries 4x4 16
2 Logical Files 2 x 10 20
1 Interfaces 1x7 7
Unadjusted total 135
Table 3

2.2) Conversion of Function Points to SLOC

It is sometimes necessary to convert from SLOC to function points, or vice-versa.

Several software cost models, such as Stage 2 of COCOMO II, allow the user to input
function points (or a variant of a function point), though they must convert function
points to SLOC because the model’s algorithms are based on SLOC.
The opposite situation occurs in the CHECKPOINT® model where SLOC inputs
must be converted to function points. This conversion process is sometimes called
“backfiring.” To help in this conversion process, sets of SLOC to function point ratios
have been developed. Table 4 shows ratios for various languages based on research by
Jones and Reifer.
Jones specifies language levels that show the number of equivalent assembly
language SLOC generated by one SLOC of the specified language. Jones further states
that language levels are useful for converting size from one language to another, and for
assessing relative language productivity Although the relationship between language
level and productivity is not linear.

Language Jones Jones Reifer

Language Level SLOC/FP SLOC/FP
Assembler 1 320 400
COBOL 3 107 100
Fortran 3 107 105
Ada (1983) 4.5 71 72
PROLOG 5 64 64
Pascal 3.5 91 70
 PL/1 4 80 65

Table 4

While function point to SLOC conversion ratios are useful, and often sometimes
necessary, they should be used with caution. Table 4 illustrates that:
– While the two researchers agree on the ratios for some languages such as Ada,
they differ on the ratios for other programming languages such as Pascal and
PL/1.
– For the COBOL language, research by Henderson showed that the conversion
ratios are inconsistent both within and between databases. For example:
– For two databases maintained at the Air Force Standard Systems Center,
Henderson found that for a military data base of 26 COBOL programs,
the average SLOC to function point ratio was 14:1,
– While for a database of 31 commercial COBOL programs, the average
SLOC to function point ratio was 165:1.
– Furthermore, there was considerable variance for these ratios within the
databases.
Therefore, for some languages it appears that backfiring should not be used, and
for cost estimation, it is probably best to use a model for which the algorithms are based
on the user’s size measure (i.e., calibrated parametric sizing models).

2.3) Characteristic-point Method

The metrics based on characteristic points was proposed by C.A. Jones [C.A.
Jones, “A short History of Function Point Method and Feature Points Software
Productivity” Research, Inc., Burlington, MA, June, 1986].
The method is not very much different from function-point method. In fact there
are three differences:
– Function-points are substituted with characteristic points
– The associated weights has different values
– A new parameter is added: algorithms with weight 3

The method’s steps:

– Estimate the counter associated to the characteristic point and calculate the
Total (Table 5.). There are versions of method in which weights differs
function of program complexity (simple, average, complex). The determined
Total can be adjusted in a similar manner as in functional point method:
Establish the weights of the 14 influence factors;
– Calculate the value of the complexity adjustment factor (SIF) as sum of the 14
influence factors
 – Calculate the value of the AdjustedTotal :
AdjustedTotal =Total*(0.65 + 0.01*SIF)

Characteristic Type Basic Counts Weights Total

External Inputs 4
External Outputs 5
External Inquiries 4
Internal Files 7
External Interfaces 7
Algorithms 3
Total

Table 5

2.4) Cyclomatic Complexity

Given any computer program, we can draw its control flow graph, G, wherein
each node corresponds to a block of sequential code and each arc corresponds to a
branch or decision point in the program. The cyclomatic complexity of such a graph can
be computed by a simple formula from graph theory, as v(G) = e − n + 2, where e is the
number of edges, and n is the number of nodes in the graph. McCabe proposed that v(G)
can be used as a measure of program complexity and, hence, as a guide to program
development and testing. For structured programs, v(G) can be computed without
reference to the program flow graph by using only the number of decision points
in the program text [McCabe76]. McCabe’s cyclomatic complexity metric has been
related to programming effort, debugging performance, and maintenance effort. The
studies by Curtis and Woodfield referenced earlier also report results for this metric
[Curtis79b, Woodfield81, Harrison-82].

Myers noted that McCabe’s cyclomatic complexity measure, v(G), provides a

measure of program complexity but fails to differentiate the complexity of some rather
simple cases involving single conditions (as opposed to multiple conditions) in
conditional statements. As an improvement to the original formula, Myers suggests
extending v(G) to v ′(G) = [l:u], where l and u are lower and upper bounds, respectively,
for the complexity. This formula gives more satisfactory results for the cases noted by
Myers [Myers77]. Stetter proposed that the program flow graph be expanded to include
data declarations and data references, thus allowing the graph to depict the program
complexity more completely. If H is the new program flow graph, it will generally
contain multiple entry and exit nodes. A function f (H) can be computed as a measure of
the flow complexity of program H. The deficiencies noted by Myers are also eliminated
by f (H) [Stetter84].

3. Trends in Software Metrics

Current trends in the software metrics area are encouraging. Metrics are being
applied more widely, with good results in many cases. The limitations of existing models
have been recognized, and people are becoming more realistic in their expectations of
what these models can provide. There is a growing awareness that metrics programs pay
off, but not without some investment of both time and resources. As the benefits of
software metrics programs become more evident, the establishment of such a program
will become essential for software development organizations to remain competitive in
this area.
Finally, although there are still a large number of metrics in use or under active
investigation, a smaller set of metrics is emerging as having more practical utility in the
measurement of the software development process. An economical set of metrics
capturing the essential characteristics of software may yet emerge from this smaller,
more useful set. Software engineering is still a very young discipline. There are
encouraging signs that we are beginning to understand some of the basic parameters that
are most influential in the processes of software production.
 Bibliography:

1. http://www.sei.cmu.edu/publications/documents/cms/cm.012.ht
ml
2. http://www.google.ro/url?sa=t&source=web&ct=res&cd=1&url=http%3A%2F%2
Fwww.csie.mcu.edu.tw%2F~hsong%2Fse%2Fse_04metrics.ppt&ei=bIn9Sc6FG4
OS_Qa3n5yiBA&usg=AFQjCNHGGZAMn_0DMkBqhdFz391AbKARnw&sig2
=qGmpLYW1J8vbqTbyUM_9_w
3. http://www.google.com/url?sa=t&source=web&ct=res&cd=1&url=http%3A%2F
%2Fwww.engineerszone.org%2Fstdymat%2Fcs%2F5%2520sem%2520cs%2520s
e%2Funit-
2_b.pdf&ei=BYr9SZrsDdqOsAbKifG4BA&usg=AFQjCNFB04GjtEI8nASeTXK
pg0vbDwTydg&sig2=YuK-klAEJx5mgDrVGuqoKg (www.engineerszone.org)
4. Vladimir Cretu, curs MPS pentru anul IV Calculatoare, capitolul 4, “Function
oriented metrics”.