Software design involves making choices: developing alternatives, comparing them, and

choosing one that seems better than the others. Making such choices is easier if there are
objective measures that can say: this choice is better than that choice. Software design metrics
are measures that assign numbers to designs or parts of designs, attempting to characterize
product attributes (such as maintainability, defect rate, or development time) at an early stage of
the life cycle. Applying metrics to software is a way to measure and improve software quality.
Many metrics apply to software implementations (code), so they cannot be used early in the life
cycle.

A metric that measures the quality of software design should measure the relative
independence of each module. Computer scientists have agreed for some time that
a good system design should consist of modules which:
• can be developed independently with minimal in- teraction between modules
• can be understood with very little knowledge of other modules
• can be modified without knowing very much about other modules
• can have errors localized to one module

Thus, interconnectivity metrics would seem to be a good starting point for evaluating
system design. During detailed design the major consideration of the designer is the
flow of control through a module, ie the order in which paths of the module are
executed and the complexity of the decisions to be made before traversing those
paths. Thus, graph theoretic metrics would seem to be a candidate for detailed
design complexity metrics.
A major question to be asked about design metrics is why they have not been
adopted in the past. There is a good case for using connectivity and graph theoretic
measures for software design quality. Certainly, we are now fairly confident of their
worth at the coding stage. There are two possible conjectures for this lack of use.
The notations used by software engineers to express the two sub-phases of design
are inadequate to hold information needed for design metric calculation. Somehow
what is being measured in the coding phase is unavailable during the design phase.
The other is that the lack of work in the evaluation of design metrics is more an
indication of a lack of work in the general area of software tools for the software
developer. In order to refute the first conjecture this paper will concentrate on
examining interconnectivity metrics for system design and graph theoretic metrics
for detailed design. Interconnectivity metrics measure the use which modules make
of other modules, the flow of data to and from modules and the amount of shared
data that each module uses.