Cyclomatic complexity and the structural fan-in/fan-out metrics deal with the control flow. However, they don't take data flow into account. Data flow, or information flow, means parameter passing and variable access.

There are several metrics for measuring the information flow: IFIN, IFOUT, IFIO and IC1.

Watching for procedures with high informational complexity can reveal the following issues: procedure has more than one function; procedure is a stress point in the system (with information traffic); procedure has excessive functional complexity. High informational complexity indicates candidate procedures for extensive testing or redesign.

Several metrics have been developed to measure information flow complexity. Generally speaking, two concepts are common to all information flow metrics: fan-in and fan-out. Fan-in is the information that flows into a procedure. Fan-out is what comes out of it. In addition, the concept of procedure length is used. The exact definition of what is in fan-in, fan-out and length may vary.

Project Analyzer traditionally uses the following formulas for calculations of information flow.

Fan-in IFIN = Procedures called + parameters read + global variables read

Informational fan-out (IFOUT) estimates the information a procedure returns.

Fan-out IFOUT = Procedures that call this procedure + ByRef parameters written to + global variables written to

From IFIN and IFOUT, one can calculate a new metric: informational fan-in × fan-out.

IFIO = IFIN * IFOUT

IFIO is reportedly good in predicting the effort needed for implementing a procedure, but not so good at measuring complexity.

Project Analyzer's formula to calculate informational complexity is as follows:

IC1 = LLOC * IFIO

As you can see, for IC1 we use the fan-in and fan-out values and multiply them by procedure length. We have defined length as follows:

length = LLOC = logical lines of code

It is to be noted that IC1 doesn’t conform to the IEEE 982.2 standard method of calculating informational flow complexity. Next we're going into the details of IEEE 982.2 and showing the differences between IC1 and IEEE 982.2. As of now, Project Analyzer doesn't calculate information flow complexity (IFC) according to IEEE 982.2.

The IEEE 982.2 formulas for informational complexity are these:

IFC = (fanin * fanout)^{2}

weighted IFC = length * (fanin * fanout)^{2}

IEEE 982.2 defines fan-in, fan-out and length as follows.

fanin = local flows into a procedure + number of data structures from which the procedure retrieves data

fanout = local flows from a procedure + number of data structures that the procedure updates

length = number of source statements in a procedure (excludes comments in a procedure)

A local flow between procedures A and B exists if:

- A calls B
- B calls A and A returns a value to B that is used by B
- Both A and B are called by another module (procedure) that passes a value from A to B

These formulas differ from the formulas for IC1.

First, the definition of a local flow is different. IC1 takes any call from A to B as a flow into A. On the contrary, IEEE 982.2 sees it as a flow into B. In addition, IEEE 982.2 may take it as a flow into A if B returns a value and A uses it. What is more, there is the case where another procedure passes a value from A to B.

Second, IEEE 982.2 doesn't specify if a parameter counts as a data structure. IC1 counts every parameter read and return values given in parameters.

Third, IEEE 982.2 specifies that length should be calculated from number of statements, not lines. In Visual Basic, LLOC is often reasonably close to the number of statements, so the difference shouldn't be too large.

Readings

- IEEE 982.2 1988. IEEE Guide for the Use of IEEE Standard Dictionary of Measures to Produce Reliable Software. A25. Data of Information Flow Complexity. p. 112.