Cyclomatic complexity is a software metric used to measure the complexity of a program. Thomas J. McCabe developed this metric in 1976.McCabe interprets a computer program as a set of a strongly connected directed graph. Nodes represent parts of the source code having no branches and arcs represent possible control flow transfers during program execution. The notion of program graph has been used for this measure, and it is used to measure and control the number of paths through a program. The complexity of a computer program can be correlated with the topological complexity of a graph.
How to Calculate Cyclomatic Complexity?
McCabe proposed the cyclomatic number, V (G) of graph theory as an indicator of software complexity. The cyclomatic number is equal to the number of linearly independent paths through a program in its graphs representation. For a program control graph G, cyclomatic number, V (G), is given as:
V (G) = E – N + 2 * P
E = The number of edges in graphs G
N = The number of nodes in graphs G
P = The number of connected components in graph G.
Example:
Properties of Cyclomatic complexity:
Following are the properties of Cyclomatic complexity:
V (G) is the maximum number of independent paths in the graph
The other set of metrics we would live to consider are known as Information Flow Metrics. The basis of information flow metrics is found upon the following concept the simplest system consists of the component, and it is the work that these components do and how they are fitted together that identify the complexity of the system. The following are the working definitions that are used in Information flow:
Component: Any element identified by decomposing a (software) system into it’s constituent’s parts.
Cohesion: The degree to which a component performs a single function.
Coupling: The term used to describe the degree of linkage between one component to others in the same system.
Information Flow metrics deal with this type of complexity by observing the flow of information among system components or modules. This metrics is given by Henry and Kafura. So it is also known as Henry and Kafura’s Metric.
This metrics is based on the measurement of the information flow among system modules. It is sensitive to the complexity due to interconnection among system component. This measure includes the complexity of a software module is defined to be the sum of complexities of the procedures included in the module. A process contributes complexity due to the following two factors.
The complexity of the procedure code itself.
The complexity due to the procedure’s connections to its environment. The effect of the first factor has been included through LOC (Line Of Code) measure. For the quantification of the second factor, Henry and Kafura have defined two terms, namely FAN-IN and FAN-OUT.
FAN-IN: FAN-IN of a procedure is the number of local flows into that procedure plus the number of data structures from which this procedure retrieve information.
FAN -OUT: FAN-OUT is the number of local flows from that procedure plus the number of data structures which that procedure updates.
Essentially the need for software development and other activities are to process data. Some data is input to a system, program or module; some data may be used internally, and some data is the output from a system, program, or module.
Example:
Program
Data Input
Internal Data
Data Output
Payroll
Name/Social Security No./Pay rate/Number of hours worked
That’s why an important set of metrics which capture in the amount of data input, processed in an output form software. A count of this data structure is called Data Structured Metrics. In these concentrations is on variables (and given constant) within each module & ignores the input-output dependencies.
There are some Data Structure metrics to compute the effort and time required to complete the project. There metrics are:
The Amount of Data.
The Usage of data within a Module.
Program weakness.
The sharing of Data among Modules.
1. The Amount of Data: To measure the amount of Data, there are further many different metrics, and these are:
Number of variable (VARS): In this metric, the Number of variables used in the program is counted.
Number of Operands (η2): In this metric, the Number of operands used in the program is counted. η2 = VARS + Constants + Labels
Total number of occurrence of the variable (N2): In this metric, the total number of occurrence of the variables are computed
2. The Usage of data within a Module: The measure this metric, the average numbers of live variables are computed. A variable is live from its first to its last references within the procedure.
For Example: If we want to characterize the average number of live variables for a program having modules, we can use this equation.
Where (LV) is the average live variable metric computed from the ith module. This equation could compute the average span size (SP) for a program of n spans.
3. Program weakness: Program weakness depends on its Modules weakness. If Modules are weak(less Cohesive), then it increases the effort and time metrics required to complete the project.
Module Weakness (WM) = LV* γ
A program is normally a combination of various modules; hence, program weakness can be a useful measure and is defined as:
Where
WMi: Weakness of the ith module
WP: Weakness of the program
m: No of modules in the program
4.There Sharing of Data among Module: As the data sharing between the Modules increases (higher Coupling), no parameter passing between Modules also increased, As a result, more effort and time are required to complete the project. So Sharing Data among Module is an important metrics to calculate effort and time.
Feature point is the superset of function point measure that can be applied to systems and engineering software applications.
The feature points are used in those applications in which the algorithmic complexity is high like real-time systems where time constraints are there, embedded systems, etc.
Feature points are computed by counting the information domain values and are weighed by only single weight.
Feature point includes another measurement parameter-ALGORITHM.
The table for the computation of feature point is as follows:
Feature Point Calculations
Measurement Parameter
Count
Weighing factor
1. Number of external inputs (EI)
–
*
4
–
2. Number of external outputs (EO)
–
*
5
–
3. Number of external inquiries (EQ)
–
*
4
–
4. Number of internal files (ILF)
–
*
7
–
5. Number of external interfaces (EIF)
–
*
7
–
6.Algorithms used Count total →
–
*
3
–
The feature point is thus calculated with the following formula:
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) .
6. Function point and feature point both represent systems functionality only.
7. For real-time applications that are very complex, the feature point is between 20 and 35% higher than the count determined using function point above.
3D function points
Three dimensions may be used to represent 3D function points?data dimension, functional dimension, and control dimension.
2. The data dimension is evaluated as FPs are calculated. Herein, counts are made for inputs, outputs, inquiries, external interfaces, and files.
3. The functional dimension adds another feature-Transformation, that is, the sequence of steps which transforms input to output.
4. The control dimension that adds another feature-Transition that is defined as the total number of transitions between states. A state represents some externally observable mode
Now fi for average case = 3. So sum of all fi (i ←1 to 14) = 14 * 3 = 42 FP = Count-total * [0.65 + 0.01 *∑(fi ) ] = 618 * [0.65 + 0.01 * 42] = 618 * [0.65 + 0.42] = 618 * 1.07 = 661.26
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.
All these parameters are then individually assessed for complexity.
The FPA functional units are shown in Fig:
2. FP characterizes the complexity of the software system and hence can be used to depict the project time and the manpower requirement.
3. The effort required to develop the project depends on what the software does.
4. FP is programming language independent.
5. FP method is used for data processing systems, business systems like information systems.
6. The five parameters mentioned above are also known as information domain characteristics.
7. All the parameters mentioned above are assigned some weights that have been experimentally determined and are shown in Table
Weights of 5-FP Attributes
Measurement Parameter
Low
Average
High
1. Number of external inputs (EI)
7
10
15
2. Number of external outputs (EO)
5
7
10
3. Number of external inquiries (EQ)
3
4
6
4. Number of internal files (ILF)
4
5
7
5. Number of external interfaces (EIF)
3
4
6
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.
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
Based on the FP measure of software many other metrics can be computed:
Errors/FP
$/FP.
Defects/FP
Pages of documentation/FP
Errors/PM.
Productivity = FP/PM (effort is measured in person-months).
$/Page of Documentation.
8. LOCs of an application can be estimated from FPs. That is, they are interconvertible. This process is known as backfiring. For example, 1 FP is equal to about 100 lines of COBOL code.
9. FP metrics is used mostly for measuring the size of Management Information System (MIS) software.
10. But the function points obtained above are unadjusted function points (UFPs). These (UFPs) of a subsystem are further adjusted by considering some more General System Characteristics (GSCs). It is a set of 14 GSCs that need to be considered. The procedure for adjusting UFPs is as follows:
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.
The score of all 14 GSCs is totaled to determine Total Degree of Influence (TDI).
Then Value Adjustment Factor (VAF) is computed from TDI by using the formula: VAF = (TDI * 0.01) + 0.65
Remember that the value of VAF lies within 0.65 to 1.35 because
When TDI = 0, VAF = 0.65
When TDI = 70, VAF = 1.35
VAF is then multiplied with the UFP to get the final FP count: FP = VAF * UFP
Example: Compute the function point, productivity, documentation, cost per function for the following data:
According to Halstead’s “A computer program is an implementation of an algorithm considered to be a collection of tokens which can be classified as either operators or operand.”
Token Count
In these metrics, a computer program is considered to be a collection of tokens, which may be classified as either operators or operands. All software science metrics can be defined in terms of these basic symbols. These symbols are called as a token.
The basic measures are
n1 = count of unique operators. n2 = count of unique operands. N1 = count of total occurrences of operators. N2 = count of total occurrence of operands.
In terms of the total tokens used, the size of the program can be expressed as N = N1 + N2.
Halstead metrics are:
Program Volume (V)
The unit of measurement of volume is the standard unit for size “bits.” It is the actual size of a program if a uniform binary encoding for the vocabulary is used.
V=N*log2n
Program Level (L)
The value of L ranges between zero and one, with L=1 representing a program written at the highest possible level (i.e., with minimum size).
L=V*/V
Program Difficulty
The difficulty level or error-proneness (D) of the program is proportional to the number of the unique operator in the program.
D= (n1/2) * (N2/n2)
Programming Effort (E)
The unit of measurement of E is elementary mental discriminations.
E=V/L=D*V
Estimated Program Length
According to Halstead, The first Hypothesis of software science is that the length of a well-structured program is a function only of the number of unique operators and operands.
N=N1+N2
And estimated program length is denoted by N^
N^ = n1log2n1 + n2log2n2
The following alternate expressions have been published to estimate program length:
NJ = log2 (n1!) + log2 (n2!)
NB = n1 * log2n2 + n2 * log2n1
NC = n1 * sqrt(n1) + n2 * sqrt(n2)
NS = (n * log2n) / 2
Potential Minimum Volume
The potential minimum volume V* is defined as the volume of the most short program in which a problem can be coded.
V* = (2 + n2*) * log2 (2 + n2*)
Here, n2* is the count of unique input and output parameters
Size of Vocabulary (n)
The size of the vocabulary of a program, which consists of the number of unique tokens used to build a program, is defined as:
n=n1+n2
where
n=vocabulary of a program n1=number of unique operators n2=number of unique operands
Language Level – Shows the algorithm implementation program language level. The same algorithm demands additional effort if it is written in a low-level program language. For example, it is easier to program in Pascal than in Assembler. L’ = V / D / D lambda = L * V* = L2 * V
Language levels
Language
Language level λ
Variance σ
PL/1
1.53
0.92
ALGOL
1.21
0.74
FORTRAN
1.14
0.81
CDC Assembly
0.88
0.42
PASCAL
2.54
–
APL
2.42
–
C
0.857
0.445
Counting rules for C language
Comments are not considered.
The identifier and function declarations are not considered
All the variables and constants are considered operands.
Global variables used in different modules of the same program are counted as multiple occurrences of the same variable.
Local variables with the same name in different functions are counted as unique operands.
Functions calls are considered as operators.
All looping statements e.g., do {…} while ( ), while ( ) {…}, for ( ) {…}, all control statements e.g., if ( ) {…}, if ( ) {…} else {…}, etc. are considered as operators.
In control construct switch ( ) {case:…}, switch as well as all the case statements are considered as operators.
The reserve words like return, default, continue, break, sizeof, etc., are considered as operators.
All the brackets, commas, and terminators are considered as operators.
GOTO is counted as an operator, and the label is counted as an operand.
The unary and binary occurrence of “+” and “-” are dealt with separately. Similarly “*” (multiplication operator) are dealt separately.
In the array variables such as “array-name [index]” “array-name” and “index” are considered as operands and [ ] is considered an operator.
In the structure variables such as “struct-name, member-name” or “struct-name -> member-name,” struct-name, member-name are considered as operands and ‘.’, ‘->’ are taken as operators. Some names of member elements in different structure variables are counted as unique operands.
All the hash directive is ignored.
Example: Consider the sorting program as shown in fig: List out the operators and operands and also calculate the value of software science measure like n, N, V, E, λ ,etc.
Solution: The list of operators and operands is given in the table
Operators
Occurrences
Operands
Occurrences
int
4
SORT
1
()
5
x
7
,
4
n
3
[]
7
i
8
if
2
j
7
<
2
save
3
;
11
im1
3
for
2
2
2
=
6
1
3
–
1
0
1
<=
2
–
–
++
2
–
–
return
2
–
–
{}
3
–
–
n1=14
N1=53
n2=10
N2=38
Here N1=53 and N2=38. The program length N=N1+N2=53+38=91
It is one of the earliest and simpler metrics for calculating the size of the computer program. It is generally used in calculating and comparing the productivity of programmers. These metrics are derived by normalizing the quality and productivity measures by considering the size of the product as a metric.
Following are the points regarding LOC measures:
In size-oriented metrics, LOC is considered to be the normalization value.
It is an older method that was developed when FORTRAN and COBOL programming were very popular.
Productivity is defined as KLOC / EFFORT, where effort is measured in person-months.
Size-oriented metrics depend on the programming language used.
As productivity depends on KLOC, so assembly language code will have more productivity.
LOC measure requires a level of detail which may not be practically achievable.
The more expressive is the programming language, the lower is the productivity.
LOC method of measurement does not apply to projects that deal with visual (GUI-based) programming. As already explained, Graphical User Interfaces (GUIs) use forms basically. LOC metric is not applicable here.
It requires that all organizations must use the same method for counting LOC. This is so because some organizations use only executable statements, some useful comments, and some do not. Thus, the standard needs to be established.
These metrics are not universally accepted.
Based on the LOC/KLOC count of software, many other metrics can be computed:
Errors/KLOC.
$/ KLOC.
Defects/KLOC.
Pages of documentation/KLOC.
Errors/PM.
Productivity = KLOC/PM (effort is measured in person-months).
$/ Page of documentation.
Advantages of LOC
Simple to measure
Disadvantage of LOC
It is defined on the code. For example, it cannot measure the size of the specification.
It characterizes only one specific view of size, namely length, it takes no account of functionality or complexity
Bad software design may cause an excessive line of code
A software metric is a measure of software characteristics which are measurable or countable. Software metrics are valuable for many reasons, including measuring software performance, planning work items, measuring productivity, and many other uses.
Within the software development process, many metrics are that are all connected. Software metrics are similar to the four functions of management: Planning, Organization, Control, or Improvement.
Classification of Software Metrics
Software metrics can be classified into two types as follows:
1. Product Metrics: These are the measures of various characteristics of the software product. The two important software characteristics are:
Size and complexity of software.
Quality and reliability of software.
These metrics can be computed for different stages of SDLC.
2. Process Metrics: These are the measures of various characteristics of the software development process. For example, the efficiency of fault detection. They are used to measure the characteristics of methods, techniques, and tools that are used for developing software.
Types of Metrics
Internal metrics: Internal metrics are the metrics used for measuring properties that are viewed to be of greater importance to a software developer. For example, Lines of Code (LOC) measure.
External metrics: External metrics are the metrics used for measuring properties that are viewed to be of greater importance to the user, e.g., portability, reliability, functionality, usability, etc.
Hybrid metrics: Hybrid metrics are the metrics that combine product, process, and resource metrics. For example, cost per FP where FP stands for Function Point Metric.
Project metrics: Project metrics are the metrics used by the project manager to check the project’s progress. Data from the past projects are used to collect various metrics, like time and cost; these estimates are used as a base of new software. Note that as the project proceeds, the project manager will check its progress from time-to-time and will compare the effort, cost, and time with the original effort, cost and time. Also understand that these metrics are used to decrease the development costs, time efforts and risks. The project quality can also be improved. As quality improves, the number of errors and time, as well as cost required, is also reduced.
Advantage of Software Metrics
The advantages of software metrics are as follows:
Comparative study of various design methodology of software systems.
For analysis, comparison, and critical study of different programming language concerning their characteristics.
In comparing and evaluating the capabilities and productivity of people involved in software development.
In the preparation of software quality specifications.
In the verification of compliance of software systems requirements and specifications.
In making inference about the effort to be put in the design and development of the software systems.
In getting an idea about the complexity of the code.
In taking decisions regarding further division of a complex module is to be done or not.
In guiding resource manager for their proper utilization.
In comparison and making design tradeoffs between software development and maintenance cost.
In providing feedback to software managers about the progress and quality during various phases of the software development life cycle.
In the allocation of testing resources for testing the code.
Disadvantage of Software Metrics
The disadvantages of Software Metrics are as follows:
The application of software metrics is not always easy, and in some cases, it is difficult and costly.
The verification and justification of software metrics are based on historical/empirical data whose validity is difficult to verify.
These are useful for managing software products but not for evaluating the performance of the technical staff.
The definition and derivation of Software metrics are usually based on assuming which are not standardized and may depend upon tools available and working environment.
Most of the predictive models rely on estimates of certain variables which are often not known precisely.
Characteristics of Software Metrics:
In software engineering, software metrics ought to have the following qualities.
Quantitative: In order to be useful metrics, need to be quantitative. It implies that measurements are able to be expressed numerically.
Intelligible: Metric computation should be easy to understand and the process should be clearly described.
Applicability: Early in the software development process metrics should be used.
Repeatable: Metric values ought to be the same when taken consistently, on a regular basis.
Economic: It should be economical to compute metrics.
Language agnostic: Metrics should not rely on any programming language for computation. they should be language-independent.
Requirements of Software metrics:
Among the many uses for software metrics in software engineering are productivity, estimation work item, planning software performance analysis and more. Software metrics can be used to track productivity plan, future tasks, monitor performance, and better control the production process during project management. Together with management functions software metrics can also help you streamline your projects by establishing more effective processes, planning software maintenance, and informing production teams of problems that need to be fixed. Among the many reasons why software metrics are necessary are the following:
It is possible to save money by avoiding errors.
Contributes to better project planning overall.
Contributes to the development of project planning in general.
This stimulates a desire to enhance procedures.
Facilitates a more in-depth examination of the risks.
Contributes to the analysis of indicators at every testing phase to improve the effectiveness of problem eradication.
Over time test automations return on investment rises.
Strengthens the link between system complexity risks and testing coverage.
