Why Pi Measure? All of the existing complexity measures give a potential or a hypothetical complexity. That is because they measure the program at rest due to their static nature. The Pi Measure measures the actual dynamic complexity of a program in execution. The Pi Measure shows the degree to which the potential, static complexity is realized in execution.

The Pi Measure Measure Execution Complexity Purely Dynamic Measure Improve Testing Find More Defects Prioritize and Evaluate Testing

What the is Pi Measure? The Pi Measure is a unique software-complexity measure. It is a purely dynamic complexity measure that does not rely on static code properties. It is based on the degree of control and data surprise the software under measure shows in execution. Highly complex code changes internal control and data in unpredictable and diverse ways.

Pi Measure

Software complexity measures are divided into static and dynamic measures. The static measures are concerned with measuring program attributes such as program size and the complexity of its structure. The dynamic measures are a product of static complexity and an operational profile. Unlike existing complexity measures, the Pi measure is based only on run-time code properties. According to this complexity metric a software is more complex if it is executed in more diverse ways.

More complex code, based on a measure of diversity, contains higher degree of control and data surprise than less complex code. That is, code with low complexity tends to group same or similar executions, whereas highly complex code could change control flows and data flows in highly unpredictable and diversified ways. Test cases that cause same or similar control flows and data flows through the program tend to be dependent, since they all tend to be grouped around either correct or faulty control flows and data flows. We observe that good test case design and highly complex software intersect at test case independence. That is, test cases designed with higher degree of independence use the software in more complex ways and consequently detect more faults.

More control and data variation in the code indicates more complex code, since such code carries more control and data surprise in execution. Code with no control and data variation always performs an identical computation, and as such is of trivial complexity regardless of other known measures, such as, for example, software science metrics, cyclometic complexity, or a combination of the two. On the other side of the spectrum, code with infinite control and data diversity always performs different computation, and as such is of highest complexity regardless of other known measures such as, for example, lines of code, relative program complexity, or bandwidth metric.

The Pi complexity of a program depends on the actual execution of the program, that is, complexity is defined in terms of the actual diversity a set of test cases carries for a particular program. For instance, a program with 10 lines of code is of higher complexity if the test set exercises it in independent, highly diverse ways, than a program with 1000 lines of code whose test set contains only one identical test case repeated many times. As this example hints, the Pi Measure is used to measure the strength of the correlation between existing complexity metrics and software faults. In particular, higher value of the Pi Measure gives stronger correlation between existing complexity measures and software faults.

For more information on the Pi Measure, including a concrete example, go to complexity.