CS615 – Software Engineering I

Lecture 8

Chapter 15: Product Metrics for Software

Overview

Measures, Metrics and Indicators

·     A measure provides a quantitative indication of the extent, amount, dimension, capacity, or size of some attribute of a product or process

·     The IEEE glossary defines a metric as “a quantitative measure of the degree to which a system, component, or process possesses a given attribute.”

·     An indicator is a metric or combination of metrics that provide insight into the software process, a software project, or the product itself

Measurement Principles

·     The objectives of measurement should be established before data collection begins;

·     Each technical metric should be defined in an unambiguous manner;

·     Metrics should be derived based on a theory that is valid for the domain of application (e.g., metrics for design should draw upon basic design concepts and principles and attempt to provide an indication of the presence of an attribute that is deemed desirable);

·     Metrics should be tailored to best accommodate specific products and processes

Measurement Process

·     Formulation. The derivation of software measures and metrics appropriate for the representation of the software that is being considered.

·     Collection. The mechanism used to accumulate data required to derive the formulated metrics.

·     Analysis. The computation of metrics and the application of mathematical tools.

·     Interpretation. The evaluation of metrics results in an effort to gain insight into the quality of the representation.

·     Feedback. Recommendations derived from the interpretation of product metrics transmitted to the software team.

Goal-Oriented Software Measurement

·     The Goal/Question/Metric Paradigm

·    (1) establish an explicit measurement goal that is specific to the process activity or product characteristic that is to be assessed

·    (2) define a set of questions that must be answered in order to achieve the goal, and

·    (3) identify well-formulated metrics that help to answer these questions.

·     Goal definition template

·    Analyze {the name of activity or attribute to be measured}

·    for the purpose of {the overall objective of the analysis}

·    with respect to {the aspect of the activity or attribute that is considered}

·    from the viewpoint of {the people who have an interest in the measurement}

·    in the context of {the environment in which the measurement takes place}.

Metrics Attributes

·     simple and computable. It should be relatively easy to learn how to derive the metric, and its computation should not demand inordinate effort or time

·     empirically and intuitively persuasive. The metric should satisfy the engineer’s intuitive notions about the product attribute under consideration

·     consistent and objective.  The metric should always yield results that are unambiguous.

·     consistent in its use of units and dimensions. The mathematical computation of the metric should use measures that do not lead to bizarre combinations of unit.

·     programming language independent.  Metrics should be based on the analysis model, the design model, or the structure of the program itself.

·     an effective mechanism for quality feedback. That is, the metric should provide a software engineer with information that can lead to a higher quality end product

Collection and Analysis Principles

·     Whenever possible, data collection and analysis should be automated;

·     Valid statistical techniques should be applied to establish relationship between internal product attributes and external quality characteristics

·     Interpretative guidelines and recommendations should be established for each metric

 

Software Quality Principles


McCall's Quality Factors

McCall's Software Metrics - (Subjective)

Relationship between quality factors and metrics

FURPS Quality Factors (Hewlett-Packard)

ISO 9126 Quality Factors

Measurement Process Activities

Formulation Principles for Technical Metrics

Software Metric Attributes

Representative Analysis Metrics

e.g. Part of the analysis model for SafeHome software

 


FP = count total x [0.65 + 0.01 x S (Fi)]

 

where count total is the sum of all FP entries and Fi (i = 1 to 14) are "complexity adjustment values." For the purposes of this example, we assume that S (Fi) is 46 (a moderately complex product).

 

FP = 50 x [0.65 + (0.01 x 46)] = 56

RE/FuP < 0.7 implies a function-strong application

 

0.8 < RE/FuP < 1.4 implies a hybrid application

 

RE/FuP > 1.5 implies a data-strong application

Representative Design Metrics

S(i) = f 2out (i)

D(i) = v(i) / [ fout (i) ]

 

where v(i) is the number of input and output variables that are passed to and from module i

C(i) = S(i) + D(i)

size = n + a

 

where n is the number of nodes and a is the number of arcs

size = 17 + 18 = 35

depth =  the longest path from the root (top) node to a leaf node

For above - depth = 4.

 

width  =  maximum number of nodes at any one level of the architecture

 

For above - width = 6.


arc-to-node ratio, r = a/n, measures connectivity density of the architecture

For above - r = 18/17 = 1.06


s1 =  the total number of modules defined in the program architecture.
s2 =  the number of modules whose correct function depends on the source of data input or that produce data to be used elsewhere (in general, control modules, among others, would not be counted as part of ).
s3 =  the number of modules whose correct function depends on prior processing.
s4 =  the number of database items (includes data objects and all attributes that define objects).
s5 =  the total number of unique database items.
s6 =  the number of database segments (different records or individual objects).
s7 =  the number of modules with a single entry and exit (exception processing is not considered to be a multiple exit).

Program structure: D1, where D1 is defined as follows:


Module independence: D2 = 1 - (s2/s1)
Modules not dependent on prior processing: D3 = 1 - (s3/s1)
Database size: D4 = 1 - (s5/s4)
Database compartmentalization: D5 = 1 - (s6/s4)
Module entrance/exit characteristic: D6 = 1 - (s7/s1)
 

 DSQI = SUM(wiDi)

 

where i = 1 to 6, wi is the relative weighting of the importance of each of the intermediate values,

and S wi = 1 (if all Di are weighted equally, then wi = 0.167).

 

Component-level design metrics

di = number of input data parameters
ci = number of input control parameters
do = number of output data parameters
co = number of output control parameters

gd = number of global variables used as data
gc = number of global variables used as control

w = number of modules called (fan-out)
r = number of modules calling the module under consideration (fan-in)

mc = k/M

 

where k = 1, a proportionality constant and

 

M = di + (a x ci) + do + (b x co) + gd + (c x gc) + w + r

 

where a = b = c = 2

mc = 1/(1 + 0 + 1+ 0 + 0 + + 0 + 1 + 0) = 1/3 = 0.33

mc = 1/[5 + (2 x 5) + 5 + (2 x 5) + 10 + 0 + 3 + 4] = 0.02

C = 1 - mc

 

where the degree of coupling increases nonlinearly between a minimum value in the range 0.66 to a maximum value that approaches 1.0.

cost = Sum[frequency of transition(k) x cost of transition(k)]

LA = 100 x [ (cost of LA - optimal layout)/(cost of proposed layout)]

 

where LA = 100 for an optimal layout.

number of possible layouts = [N!/(K! x (N - K)!] x K!

 

Source Code Metrics - Halstead's Software Science

n1 = the number of distinct operators that appear in a program.

n2 = the number of distinct operands that appear in a program.

N1 = the total number of operator occurrences.

N2 = the total number of operand occurrences

N = n1 log2 n1 + n2 log2 n2

V log2 ( n1 + n2 )

L = 2/n1 * n2 /N2

Testing Metrics

Maintenance Metrics

MT =   the number of modules in the current release
Fc =  the number of modules in the current release that have been changed
Fa =  the number of modules in the current release that have been added
Fd =  the number of modules from the preceding release that were deleted in the current release

SMI = [MT - (Fa + Fc + Fd)] / M