Software Metrics

Engineering

• Engineering is a discipline based on quantitative approaches– All branches of engineering rely upon the use

measurements• Software Engineering is not an exception– SE uses measurements to evaluate the quality of

software products

Software Metrics

• Software metrics are an attempt to quantify the quality of the software

• Measures are expressed in terms of computable formulas or expressions

• Elements of these expressions are derived from source code, design and other artifacts used in software development

Quality Measurement

• Direct measurement– Are values calculated directly from known sources

(source code, design diagram etc.)– E.g. number of software failures over some time

period• Indirect measurement– Cannot be so accurately defined nor directly

realized– E.g. reliability, maintainability, usability

Advantages of Metrics

• Metrics are a tool for comparing certain aspects of software

• Sometimes metrics provide guidance for evaluating complexity, time and cost of a future product

• Metrics can be used to evaluate software engineers

• Metrics can even be applied to the creation of development teams

Example

A general rule in allocating project time:• 25%: Analysis & Design• 50%: Coding & Unit Test• 25%: Integration/System/Acceptance Test

Weyuker’s Properties of Metrics

• Two programs for the same application need not have the same metrics values

• If a program P consists of modules Q and R, the complexity of P is generally not the sum of the complexities of Q and R

GOM (Goal Oriented Metrics)

• General metrics equation– F = c1× m1+c2× m2+…+cn× mn

– Cj is a regression coefficient and mk is a primitive metric (those that are directly observable from software artifacts)

• Metric F is found by computing all mk and then evaluating the expression for predefined cj

Some Quality Factors• Accuracy

– Accuracy refers to the precision of computations and control• Completeness

– Completeness is the degree to which full implementation of required functionality has been achieved

• Consistency– Consistency refers to the degree to which requirements are continued (i.e.,

not changed) throughout the development process• Expandability

– Expandability is the degree to which a product can be extended to include additional features

• Hardware Independence– Hardware independence is the degree to which a product depends on the

underlying hardware

ISO 9126 Quality Factors

• Reliability– Reliability refers to the amount of time software is available

for use– Reliability can be measured by the frequency of failure, the

severity of failure, the accuracy of output results, the ability to recover from failure and mean-time –to-failure

• Portability– Portability is the degree to which software can be ported to

another platform or environment– Portability is measured by adaptability, installability,

conformance, hardware and software dependences

What makes a software metric effective?

• It must be easy to derive, calculate and understand

• It must be useful for improving some aspect of software engineering

• It should be independent of any programming language

• It should be platform and environment independent

Function-point Metrics

• Function-point metrics are intended to measure the size complexity of a software system

• They can be evaluating using a data flow diagram, and counting any of the following:– The number of user inputs– The number of outputs to user– The number of user inquiries– The number of files or data stores– The number of external interfaces

Sample formula for function-point metrics

• Fp = total of primitive metrics × (0.65 + 0.01 × )Where Fj is a value to be chosen by the

developer to indicate the complexity of this product with regard to other competitive products. Typical values for Fj range from 1 to 50

€

F j∑

Function-point Example

Function Points: Application requirements are examined to determine project/code size:

• Count number of inputs, outputs, inquiries, master files, interfaces the program will require.

• Measures product size for the user's point of view

• Feature Points: Includes # of complex algorithms

Example Continued

Step 1: To estimate Function Points count the number of:

Example Continued

Step 2: Multiply each category count by its’ weight:________________

UnadjustedFunctionPoints (UFP) = SUM(I=0..6) [#AttributeTypeI ComplexityFactor]

Example ContinuedStep 3: Calculate the Degree of Influence:DegreeOfInfluence (DI): Determine complexity of 14

factors:Each factor is rated on a scale from 0 (no influence) to 5

(high influence)

Example Continued

Sum the Degree of Influence factors and solve the below equation.

Function Points = UFP * (0.65 + 0.01 * DegreeOfInfluence) _____________

A metric for specification quality

• Specificity is the opposite of ambiguitySpecificity = Where nui refers to the number of functional requirements that are

interpreted identically by all reviewers and nr refers to the total number of requirements (both functional and non-functional) in the requirements document

• Completeness can be measured as follows:Completeness = Where nu refers to the number of unique functional requirements

that do not depend on any other requirement, n j refers to the number of external inputs and ns number of states of the system

€

nui /nr

€

nu /(n j × ns)

A metric for measuring coupling between two modules in imperative paradigm

• Coupling = k / MWhereM = di + (a×ci)+do+(b×co)+gd+(c×gc)+w+rdi the number of input data parametersci number of input control parametersdo number of output data parametersco number of output control parametergd number of global data varialsgc number of global control variablesw number of modules calledr number of modules calling this modulek =1, a =b= c=2(all these can be adjusted)

Metrics for O-O Systems

• Like testing, metric equation for procedural paradigm have been found to be inadequate for O-O paradigm

• Several OO metrics have been published in the literature:

C&K metrics(1994), Kim’s metrics(1994,1996), MOOD’s metrics(1995), Liu’s metrics(1999)

Metrics for O-O Systems

• DOR(C )=

Where r( C ) denotes the number of subclasses of C

t denotes the total number of classes in the program

tr denotes the sum of all subclasses in the program

€

k

t + trk=1

r(C )

∑

Object Oriented Class EstimationObject Oriented Class Estimation A. Estimate the number of classes in code to be developed/modified: ________ B. Categorize the type of user interface and assign weight:

No UI: 2.0Simple text-based UI: 2.25Simple GUI 2.5Complex GUI 3.0

C. Multiply # Classes by UI Weight: ________ D. Add A + C to get estimate of total number of classes: ________ E. Multiply D (total # classes) by # person days/class (15-20) ________

24

Calculation of ‘Lack of Cohesion’ metrics

Lack of Cohesion (LCOM) for a class is defined as follows:• Let ‘C’ denote the class for which LCOM is computed.• Let ‘m’ denote the number of methods in C.• Let ‘a’ denote the attributes of C.• Let ‘m(a)’ denote the methods of C that access the

attribute ‘a’ in C.• Let ‘Sum(m(a))’ denote the sum of all ‘m(a)’ over all the

attributes in C.• Now, LCOM( C ) is defined as ( m – Sum (m(a)) / a) /

(m – 1)

25

Cohesion Metrics

• If class C has only one method or no method, LCOM is undefined. If there are no attributes in C, then also LCOM is undefined. In both situations, for computational purposes, LCOM is set to zero.

• Normally, LCOM value is expected to be between 0 and 2. A value greater than 1 is an indication that the class must be redesigned. The higher is the value of LCOM, the lower is the cohesion and hence the need for redesign.

26

Example

27

Calculation

The class ‘Account’ (without constructor) ‘Account’ (with constructor)m = 4, a = 3 m = 5, a = 3m(Account#) = 1 m(Account#) = 2m(UserID) = 1 m(UserID) = 2m(Balance) = 3 m(Balance) = 3sum(m(a)) = 5 sum(m(a)) = 7LCOM (Account) = (4 – 5 / 3) / (3 – 1) = 1.667 LCOM(Account) = (5 – 7 / 3) (5

– 1) = 0.667

28

CalculationThe class ‘LoginAccount’ (without constructor) ‘LoginAccount’ (with

constructor)

m = 1, a = 2 m = 2, a = 2m(UserID) = 0 m(UserID) = 1m(Password) = 1 m(Password) = 2sum(m(a)) = 1 sum(m(a)) = 3LCOM (LoginAccount) = (1 – 1 / 2) / (1- 1) LCOM(LoginAccount) = (2

= 0 (set to zero because m = 1) – 3 / 2) (2 – 1) = 0.5

29

CalculationThe class ‘AccountsDatabase’ (without constructor) ‘AccountsDatabase’ (with

constructor)

m = 4, a = 1m = 5, a = 1

m(Accounts) = 4m(Accounts) = 5

sum(m(a)) = 4sum(m(a)) = 5

LCOM (AccountsDatabase) = (4 – 4 / 1) / (4 – 1) LCOM(AccountsDatabase) = (5 – 5/1)(5-1) = 0

= 0 / 3 = 0

30

Calculation

The class ‘Login Accounts Database’Exactly similar to ‘Accounts Database’ and hence

LCOM (Login Accounts Database) = 0, both for with constructor and without constructor.

MOOD’s Metric for Measure of Polymorphism

• Polymorphism factor =

Where TC denotes the number of classes in the system

DC(Ci ) denotes the number of subclasses of Ci

Mo(Ci ) denotes the number of overriding methods in Ci

Mn(Ci ) denotes the number of new methods in Ci

€

Mo(Ci)i=1

TC

∑Mn (Ci) ×DC(Ci)i=1

TC

∑

MOOD’s Metric on Degree of Coupling between Classes

• Coupling factor = WhereIs_client(Ci, Cj) = 1 if client Ci has at least one

non-inheritance reference to supplier classes Cj; otherwise, it is 0

denotes the maximum number of coupling due to inheritance

€

( Is_client(Ci,C j ))j=1

TC

∑i=1

TC

∑

TC2 −TC −2 × (Ci)i=1

TC

∑

€

2 × (Ci)i=1

TC

∑

Problem with metrics

• Defining metrics formulas is difficult– No standards and no guidelines: each equation

defines a metric for a particular application• Correctness of the metrics formulas must be

established before using them• Metrics measure a product, too late to predict

the complexity of the product