What do design-level metrics such as Fan-in and Fan-out primarily measure?

Concept: Fan-in and Fan-out are design-level software metrics (the Henry-Kafura information-flow metrics) that count how modules in a design communicate with each other: the Fan-in of a module M is the number of other modules that call M (plus the data structures M reads), and the Fan-out of M is the number of other modules M calls (plus the data structures M updates).

Application: Applied here, both quantities are computed purely from the module call/data-flow graph of the design - they tally inter-module calls and data references, so they capture the complexity of interaction (coupling) between modules, not any property of a single module's internal code.

Cross-check: Contrasting with the other options confirms this reading:

• Code readability is assessed with style/documentation metrics (naming, comments, formatting) that Fan-in/Fan-out never touch.

• System reliability is assessed with operational metrics such as failure rate and mean time between failures (MTBF), not a static call graph.

• Testing effort is estimated from measures such as cyclomatic complexity or test-case counts; a high fan-in/fan-out module often needs more testing, but that is a downstream consequence, not what the metric itself measures.

Result: Since Fan-in and Fan-out are computed strictly from how many other modules call into / are called by a module, they primarily measure module interaction complexity.