Page 160 - DCAP305_PRINCIPLES_OF_SOFTWARE_ENGINEERING

Principles of Software Engineering

Notes for all times at a specific location in the computational domain, or more complex, such as the
complete response history at a specific location, modal frequencies, mode shapes, load-deflection
curve slopes and inflection points, peak amplitudes, signal decay rates, temporal moments,
shock response spectra, etc. In some cases, a feature can be used directly as a validation metric;
in other cases, the feature must be processed further into a form more suitable for comparison
with experimental data.
Now we discuss some of the metrics that can be extracted from a design and that could be
useful for evaluating the design. We do not discuss the standard metrics of effort or defect that
are collected (as per the project plan) for project monitoring. Size is always a product metric
of interest, as size is the single most influential factor deciding the cost of the project. As the
actual size of the project is known only when the project ends, at early stages the project sizes
only an estimate. Our ability to estimate size becomes more accurate as development proceeds.
Hence, after design, size (and cost) re-estimation are typically done by project management.
After design, as all the modules in the system and major data structures are known, the size of
the final system can be estimated quite accurately.
For estimating the size, the total number of modules is an important metric. This can be easily
obtained from the design. By using an average size of a module, from this metric the final size
in LOG can be estimated. Alternatively, the size of each module can be estimated, and then the
total size of the system will be estimated as the sum of all the estimates.
7.2.1 Network Metrics
Network metrics for design focus on the structure chart (mostly the call graph component of the
structure chart) and define some metrics of how “good” the structure or network is in an effort
to quantify the complexity of the call graph. As coupling of a module increases if it is called by
more modules, a good structure is considered one that has exactly one caller. That is, the call
graph structure is simplest if it is a pure tree. The more the structure chart deviates from a tree,
the more complex the system. Deviation of the tree is then defined as the graph impurity of the
design. Graph impurity can be defined as:
Graph impurity = n – e – 1
Where n is the number of nodes in the structure chart and e is the number of edges. As in a
pure tree the total number of nodes is one more than the number of edges, the graph impurity
for a tree is O. Each time a module has a fan-in of more than one, the graph impurity increases.
The major drawback of this approach is that it ignores the common use of some routines like
library or support routines. An approach to handle this is not to consider the lowest-level nodes
for graph impurity because most often the lowest-level modules are the ones that are used by
many different modules, particularly if the structure chart was factored. Library routines are
also at the lowest level of the structure chart (even if they have a structure of their own, it does
not show in the structure chart of the application using the routine). Other network metrics
have also been defined. For most of these metrics, significant correlations with properties of
interest have not been established. Hence, their use is limited to getting some idea about the
structure of the design.
7.2.2 Stability Metrics

We know that maintainability of software is a highly preferred quality. Maintenance activity is
hard and error-prone as changes in one module require changes in other modules to maintain
consistency, which require further changes, and so on. It is clearly desirable to minimize this
ripple effect of performing a change, which is largely determined by the structure of the software.
Stability of a design is a metric that tries to quantify the resistance of a design to the potential
ripple effects that are caused by changes in modules. The higher the stability of a program
design, the improved the maintainability of the program. Here we define the stability metric.
At the lowest level, stability is defined for a module. From this, the stability of the whole system
design can be obtained. The aim is to define a measure so that the higher the measure the less
the ripple effect on other modules that in some way are related to this module. The modules

154 LOVELY PROFESSIONAL UNIVERSITY