0% found this document useful (0 votes)
1 views

Functional Point and Cyclometric complexity

Functional Point Analysis (FPA) is a method developed by Allan J. Albrecht for estimating software project size and functionality, measured in function points (FP). It involves categorizing functions into types such as external inputs, outputs, inquiries, internal files, and external interfaces, and calculating the Unadjusted Function Point (UFP) using a specific formula. Additionally, cyclomatic complexity is introduced as a metric for assessing code complexity through control flow graphs, with various formulas to calculate it, highlighting its importance in code maintainability and testing.

Uploaded by

prespotgaming
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
1 views

Functional Point and Cyclometric complexity

Functional Point Analysis (FPA) is a method developed by Allan J. Albrecht for estimating software project size and functionality, measured in function points (FP). It involves categorizing functions into types such as external inputs, outputs, inquiries, internal files, and external interfaces, and calculating the Unadjusted Function Point (UFP) using a specific formula. Additionally, cyclomatic complexity is introduced as a metric for assessing code complexity through control flow graphs, with various formulas to calculate it, highlighting its importance in code maintainability and testing.

Uploaded by

prespotgaming
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 15

Functional Point (FP) Analysis

Allan J. Albrecht initially developed function Point Analysis in 1979 at IBM and it has been
further modified by the International Function Point Users Group (IFPUG). FPA is used to
make estimate of the software project, including its testing in terms of functionality or
function size of the software product. However, functional point analysis may be used for the
test estimation of the product. The functional size of the product is measured in terms of the
function point, which is a standard of measurement to measure the software application.
Objectives of FPA
The basic and primary purpose of the functional point analysis is to measure and provide the
software application functional size to the client, customer, and the stakeholder on their
request. Further, it is used to measure the software project development along with its
maintenance, consistently throughout the project irrespective of the tools and the
technologies.
Following are the points regarding FPs
1. FPs of an application is found out by counting the number and types of functions used in
the applications. Various functions used in an application can be put under five types, as
shown in Table:
Types of FP Attributes

Measurements Parameters Examples

1.Number of External Inputs(EI) Input screen and tables

2. Number of External Output (EO) Output screens and reports

3. Number of external inquiries (EQ) Prompts and interrupts.

4. Number of internal files (ILF) Databases and directories

5. Number of external interfaces (EIF) Shared databases and shared routines.

The functional complexities are multiplied with the corresponding weights against each
function, and the values are added up to determine the UFP (Unadjusted Function Point) of
the subsystem.
Here that weighing factor will be simple, average, or complex for a measurement parameter
type.
The Function Point (FP) is thus calculated with the following formula.
FP = Count-total * [0.65 + 0.01 * ∑(fi)]
= Count-total * CAF
where Count-total is obtained from the above Table.
CAF = [0.65 + 0.01 *∑(fi)]
and ∑(fi) is the sum of all 14 questionnaires and show the complexity adjustment value/
factor-CAF (where i ranges from 1 to 14). Usually, a student is provided with the value of
∑(fi)
Also note that ∑(fi) ranges from 0 to 70, i.e.,

0 <= ∑(fi) <=70

and CAF ranges from 0.65 to 1.35 because

 When ∑(fi) = 0 then CAF = 0.65


 When ∑(fi) = 70 then CAF = 0.65 + (0.01 * 70) = 0.65 + 0.7 = 1.35
a. Degree of Influence (DI) for each of these 14 GSCs is assessed on a scale of 0 to 5.
(b) If a particular GSC has no influence, then its weight is taken as 0 and if it has a
strong influence then its weight is 5.
b. The score of all 14 GSCs is totaled to determine Total Degree of Influence (TDI).
c. Then Value Adjustment Factor (VAF) is computed from TDI by using the formula:
VAF = (TDI * 0.01) + 0.65
Documentation = Pages of documentation/FP
Cyclomatic Complexity
The cyclomatic complexity is obtained by drawing a control flow graph of the code, and it
calculates the total number of linearly independent paths running through the complete
program. Higher the cyclomatic complexity number, higher is the risk to update and
maintain code, higher is the probability of finding issues, and more difficult it is to
understand the code. The cyclomatic complexity measures the readability of the code, and
total count of distinct, linearly-independent paths in the program which gives an idea of how
complicated the implementation logic is.
Formula to Calculate the Cyclomatic Complexity
There are three formulae to calculate the cyclomatic complexity as listed below −
Formula 1
For a program code control graph(G), the cyclomatic complexity denoted by V(G) is equal
to E - N + 2 * P, where E is equal to the total number of edges, N is equal to the number of
nodes, and P is equal to the total number of connected components in the graph.
Formula 2
For a program code control graph(G), the cyclomatic complexity denoted by V(G) is equal
to P + 1, where P is equal to the total number of decision or conditional nodes. The decision
or conditional nodes result in bringing out two branches in a control flow graph.
Formula 3
For a program code control graph(G), the cyclomatic complexity denoted by V(G) is equal
to the R + 1, where R is the total count of the closed regions within the control flow graph.
Example
Let us take an example of the below block of code from where we will calculate the
cyclomatic complexity using the formulae discussed above.
The control flow graph of the above lines of code is shown below −

In the above control flow graph, there are seven nodes(N) denoted by blue circles. Please
note, the total number of lines in the code is equal to the total number of nodes. There are
eight edges(E) in the control flow graph denoted in red, and since there is only one method,
the total number of connected components(P) in the graph is 1. So as per the formula,
V(G) = E - N + 2 * P
=8-7+2*1=3
In the above code and its control flow graph, there are two conditional statements, IF X =
300, and THEN IF Y > Z, hence there are two conditional nodes(P) namely, 1, and 2,
denoted in green in the control flow graph. So as per the formula,
V(G) = P + 1
=2+1=3
In the above control flow graph, there are two closed regions(R), denoted by two transparent
circles namely 1, and 2 denoted in orange in the control flow graph. So as per the formula,
V(G) = R + 1
=2+1=3
So using the three formulae, we have obtained the same value of cyclomatic complexity as
3.
Uses of Cyclomatic Complexity
The uses of the cyclomatic complexity are listed below −
 Detecting all the independent paths prove to be very helpful for both the developers
and testers.
 It confirms that every path in the code is verified at least once.
 It helps to detect the uncovered paths in the program code.
 It assists in improving the code coverage.
 It aids in identifying the potential risks and to mitigate them.
Advantages of Cyclomatic Complexity
The advantages of the cyclomatic complexity are listed below −
 It is used as a quality metric for the code developed for the software.
 It is faster than the Halstead metric.
 It helps to determine the effort and critical areas for testing.
 It steers the testing process.
 It can be applied easily.
Disadvantages of Cyclomatic Complexity
The disadvantages of the cyclomatic complexity are listed below −
 It is only concerned with complexity of the software code and not the data it handles.
 The cyclomatic complexity value for nested program code is not easily determined.
 The cyclomatic complexity may bear false value for simple comparisons and decision
structures.
Example 1
For simple code statements, we can merge them into a single node.
int main() {
int x = 5, y = 10;
x = y + 2;
cout << x << endl;
return 0;
}
Here is the control flow graph and the cyclomatic complexity for the code above.

Figure 1: Control Flow Graph and Cyclomatic Complexity for Example 1


Example 2
For a code with if and else blocks, we tend to make decision branches as shown in Figure 2.
int main() {
int x = 5, y = 10;
if(x > y) {
cout << "x is greater.";
}
else {
cout << "y is greater."
}
return 0;
}
Here is the control flow graph and the cyclomatic complexity for the code above.

Figure 2: Control Flow Graph and Cyclomatic Complexity for Example 2


Example 3
For loops, we need to show a loop in the control flow graph as well.
int main() {
int a, b;
cin >> a;
cin >> b;
for(int i = 0; i < b; i++) {
a = a + i;
}
cout << a << endl;
return 0;
}
Here is the control flow graph and the cyclomatic complexity for the code above.

Figure 3: Control Flow Graph and Cyclomatic Complexity for Example 3


Example 4
The switch statements are represented as follows:
int main() {
int day;
cin >> day;
switch(day) {
case "1":
cout << "Monday";
break;

case "2":
cout << "Tuesday";

case "3":
cout << "Wednesday";
break;

case "4":
cout << "Thursday";

case "5":
cout << "Friday";
break;

default:
cout << "Weekend";
break;
}
return 0;
}
Here is the control flow graph and the cyclomatic complexity for the code above.
Figure 4: Control Flow Graph and Cyclomatic Complexity for Example 4

You might also like