copyright@nit.sainipoonam@gmail.com

Software Metrics

1. Software Metric- A definition

2. Types of Software metrics

3. Frame work of product metrics

4. Product metrics for SDLC

a. Metrics: Requirements phase

b. Metric for analysis model

c. Metric for design model

d. Metric for source code

e. Metric for Testing

f. Metric for Maintenance

5. Types of Software Measurement

6. Software Quality metric

7. Software Metrics cost

Contents

• A quantitative measure of the degree to which a system, component, or process possesses a given attribute.

Measured by: individual module during development

Errors should be categorized by origin, type, cost

Software Metric- A definition

Measure - quantitative indication of extent, amount, dimension, capacity, or size of some attribute of a product or process.E.g. Number of errors uncovered

Measurement- is the act of obtaining a measure

E.g. Reviews or unit tests etc. Metric – relates the individual measures in some way

E.g. Average number of errors found per review or per unit test

Indicator - a metric or combination of metrics that provide insight into the software process, a software project, or the product itself

Software Metric- A definition contd….

Role of Measurement

Processes,Products &

Services

Understand

Predict

Control

Evaluate

Example - Metric: % defects corrected

Metrics Objective Statement Template

To

understandevaluatecontrolpredict

theattributeof theentity

in order to

goal(s)

evaluate

% defectsfound &

corrected during testing

To thein order to

ensure all known defectsare corrected

before shipment

1.Product metricsquantify characteristics of the product being developed

size, reliability

2.Process metricsquantify characteristics of the process being used to develop the software

• efficiency of fault detection

3.Project metricsEnable a software project manager to assess the status of an ongoing project, track potential risks, uncover problem areas before they go “critical” & evaluate the project team’s ability to control quality of software work products.

Kinds of software metrics

Insights of process paradigm, software engineering tasks, work product, or milestones

Lead to long term process improvementPrivate process metrics

(e.g. defect rates by individual or module) are known only to the individual or team concerned

Public process metrics enable organizations to make strategic changes to

improve the software processStatistical software process improvement helps

an organization to discover its strengths and weaknesses

Process metrics

Explicit results of software development activities e.g., Deliverables, documentation, by products

Assesses the state of the project Track potential risks Uncover problem areas Adjust workflow or tasks Evaluate teams ability to control quality

Product Metrics

Software project metrics are used by the software team to adapt project workflow and technical activities.

Project metrics are used to avoid development schedule delays, to mitigate potential risks, and to assess product quality on an on-going basis.

Every project should measure its inputs (resources), outputs (deliverables), and results (effectiveness of deliverables).

Application of project metrics on most software projects occurs during estimation.

Project Metrics

According to Roche, a measurement process can be characterized by five activities.

1. Formulation- derivation of s/w measures and metrics

2. Collection- to accumulate data required to derive formulated metrics.

3. Analysis- computation of metrics & application of mathematical tools.

4. Interpretation- evaluation of metrics to gain insight into the quality of the representation.

5. Feedback- Recommendations derived from interpretation transmitted to the s/w team.

Principles of measurement

A set of attributes that should be encompassed by effective software metrics are as follows

1. Simple and Computable

2. Consistent and objective

3. Consistent in the use of units and dimensions

4. Programming language independent

5. An effective mechanism for high quality feedback

Attributes of Metrics

Function-Based MetricsMetrics for specification quality

Metrics: Requirements phase

Function points are computed from direct measures of the information domain of a business software application and assessment of its complexity.

Once computed function points are used like LOC to normalize measures for software productivity, quality, and other attributes

Use a measure of the functionality delivered by the application as a normalization value.

The relationship of LOC and function points depends on the language used to implement the software.

Function-Based Metrics

• Information domain values are defined as follow:

1. No. of external inputs(EIs)

2. No. of external output(EOs)

3. No. of external inquiries(EQs)

4. No. of internal logical files(ILFs)

5. No. of external interface files(EIFs)

• Compute function point as follows:

FP = count-total * [0.65 + 0.01 * Σ(Fi)]

The Fi ( i = 1 to 14) are "complexity adjustment values“.

Function-Based Metrics contd..

Davis suggested that the qualitative characteristics of s/w quality can be can be represented using one or more metrics.

e.g., say there are nr number of requirements in a specification, such that nr = nf + nnf

Specificity(lack of ambiguity): Q1 = nui /nr

Completeness: Q2 = nu /ni ns

Overall Completeness: Q3 = nc /nc + nnv

Metrics for Specification Quality

There are five design model for software metrics.

1. Architectural design2. Object oriented design3. Class oriented Metrics4. Component level design5. Operations oriented design

Metrics: Design Phase

• It focus on characteristic of the program architecture.• These metrics are “black box” in the sense that they do not

require any knowledge of the inner workings of a particular software component.

• According to Card & Glass three s/w design complexity measure

1.Structural Complexity

2.Data Complexity

3.System Complexity

Architectural design

1. Structural Complexity S(i) of a module i. S(i) = fout

2(i) Fan out is the number of modules immediately

subordinate (directly invoked).2. Data Complexity D(i)

D(i) = v(i)/[fout(i)+1] v(i) is the number of inputs and outputs passed to and

from i3. System Complexity C(i)

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

As each of these complexity values increases the overall complexity of the system also increases

Proposed by Card and Glass, 90

Architectural design contd..

Size = n + a n number of nodes

a= number of arcs

Depth Width Arc-to-Node ratio , r = a/n (indicator of

coupling)

Proposed by Fenton, 91

Architectural design contd..

• Much about OO design is subjective - a good programmer “knows” what makes good code

• There are 9 characteristic of an OO design

Object oriented design

1.Size2.Complexity3.Coupling4.Sufficiency5.Completeness

6.Cohesion7.Primitiveness8.Similarity9.Volatility

Chidamber and Kemerer have proposed six class-based design metrics for OO systems.

Class oriented Metrics

1. Weighted methods per class (WMC)

2. Depth of the inheritance tree (DIT)

3. Number of children (NOC)

1. Weighted methods per class (WMC)

2. Depth of the inheritance tree (DIT)

3. Number of children (NOC)

4. Coupling between object classes (CBO)

5. Response for a class (RFC)6. Lack of cohesion in methods

(LCOM)

4. Coupling between object classes (CBO)

5. Response for a class (RFC)6. Lack of cohesion in methods

(LCOM)

• Component- level design metrics focus on internal characteristics of a software component .

• It include measures of the “three Cs”-

(a.)cohesion metrics

(b.)coupling metrics

(c.)complexity metrics• It is “glass box” in the sense that they require knowledge of

inner working of the module under consideration.

Component level design

Three simple metric, proposed by Lorenz and Kidd

1. Average operation size (LOC, volume)

2. Operation complexity (cyclomatic)

3. Average number of parameters per operation

Operations oriented design

Halstead assigned quantitative laws to the development of computer s/w, using a set of primitive measures

They may be derived after code is generated or estimated once design is complete

The measures are :

n1 : no. of distinct operators that appear in a program

n2 : no. of distinct operands that appear in a program

N1 : total no. of operator occurrences

N2 : total no. of operand occurrencesHalstead uses primitive measures to develop

expression for

Metrics: Source code

• Program length, potential min. vol. For an algo. , actual vol., program level, language level.

• Halstead shows that length N can be estimated

N= n1 log2n1 +n2 log2n2

And program volume

V= N log2 (n1+n2)

• Halstead defines a volume ratio L as the ratio of volume of most compact form of a program to the volume of the actual program

Volume ratio

L= 2/n1 *n2/N2 ,

where L must always be less than 1.

• This metrics focus on the process of testing, not the technical characteristic of the tests themselves

• Function-based metrics can be used as a predictor for overall testing effort

• Architectural design metrics provide information on the ease or difficulty associated with integration testing

• Cyclomatic complexity lies at the core of basis path testing

Testing metrics fall into two broad categories

1. Metrics that attempt to predict the likely number of tests required at various testing levels

2. Metrics that focus on test coverage for a given component

Metrics: Testing

• Testing effort can also be estimated using metrics derived from Halstead measures

Program Level(PL) =1/[(n1/2)*(N2/n2)]

Halstead effort(e)= Program vol.(V)/PL

% of testing effort(k)=e(k)/Σe(i)

where e(k) is computed for module k

Halstead metrics testing

The OO design metrics provide an indication of design quality.

The metrics consider aspects of encapsulation and inheritance.

A sampling follows:

1. Lack of cohesion in methods(LCOM)

2. Percent public and protected(PAP)

3. Public access to data members(PAD)

4. Numbers of root classes (NOR)

5. Fan- in(FIN)

6. Number of children(NOC) and depth of the inheritance tree(DIT)

Metrics for OO Testing

Software maturity index(SMI) that provides an indication of the stability of a software product

Software maturity index is computed as

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

where Mt= no. of modules in the current release

Fc= no. of modules in the current release that have been change .

Fa= no. of modules in the current release that have been added.

Fd= no. of modules from the preceding release that were deleted in the current release.

Metrics: Maintenance

The overriding goal of software engineering is to produce a high-quality system, application, or product.

The quality of a system, application, or product is only as good as

• The requirements that describe the problem

• The design that models the solution

• The code that leads to an executable program

• The tests that exercise the software to uncover errors. To accomplish this real-time quality assessment, the

engineer must use technical measures to evaluate quality in objective, rather than subjective, ways.

Software Quality Metrics

1. Correctness : The degree to which the software performs its required function. Common measure:

• Defects per KLOC, where a defect is defined as a verified lack of conformance to requirements.

2. Maintainability: The ease with which a program can be corrected if an error is encountered, adapted if its environment changes, or enhanced if the customer desires a change in requirements.

A simple time -oriented metric Mean-time -to-change (MTTC), the time it takes to analyze the change request, design an appropriate modification, implement the change, test it, and distribute the change to all users

Measuring Quality

3. Integrity: Measures a system's ability to withstand attacks (both accidental and intentional) on its security.

• Attacks programs, data, and documents.

• To measure integrity, two additional attributes must be defined

– Threat

– Security Threat: The probability that an attack of a specific type

will occur within a given time. Security: The probability that the attack of a specific type

will be repelled.

integrity = Σ [1 - threat x (1 - security)]

where threat and security are summed over each type of attack.

4. Usability: User friendliness.

• If a program is not "user friendly," it is often doomed to failure, even if the functions that it performs are valuable

• User friendliness can be measured in terms of four characteristics

(i) the physical and/or intellectual skill required to learn the system

(ii) the time required to become moderately efficient in the use of the system

(iii) the net increase in productivity measured when the system is used by someone who is moderately efficient

(iv) a subjective assessment of users attitudes toward the system

A quality metric that provides benefits at both project and process level is defect removal efficiency.

DRE is a measure of the filtering ability of quality assurance and control activities as they are applied throughout all process frame work activates.

DRE = E / (E + D)where

E = number of errors found before delivery of the software to the end user

D = number of defects found after delivery• The ideal value for DRE is 1. No defects are found in the software• Realistically, D will be greater than zero, but the value of DRE can still

approach 1 as E increases• As E increases it is likely that the final value of D will decrease

Defect Removal Efficiency

DRE can also be used within the project to assess a team's ability to find errors before they are passed to the next framework activity

DREi = Ei / (Ei + Ei + 1)

where

• Ei = number of errors found during software engineering activity i.

• Ei + 1 = number of errors found during software engineering activity i +1 that are traceable to errors that were not discovered in software engineering activity i.

Defect Removal Efficiency

Don’t

Measure individuals

Use metrics as a “stick”

Ignore the data

Use only one metric Cost

Quality

Schedule

DoSelect metrics based on goals

Goal 1 Goal 2

Question 1 Question 2 Question 3 Question 4

Metrics 1 Metric 2 Metric 3 Metric 4 Metric 5

[Basili-88]

Focus on processes, products & services

Processes,Products &

Services

Provide feedback

Feedback

Data

Data Providers Metrics

Obtain “buy-in”