The document outlines the importance of software metrics in evaluating software quality, productivity, and the effectiveness of engineering methods. It details the measurement process, including the formulation, collection, analysis, and interpretation of metrics, while categorizing metrics into process, product, and project metrics. Additionally, it discusses normalization methods, direct and indirect measures, and introduces the function point metric as a means to assess software functionality.

1. -By: Aadarsh Sharma
-152409
-ME CSE (Regular)

2.  Introduction
 Attributes of Software Metrics
 Activities of a Measurement Process
 Types
 Normalization of Metrics
 References
2

3.  Help software engineers to better understand the attributes of models
and assess the quality of the software
 Help software engineers to gain insight into the design and
construction of the software
 Focus on specific attributes of software engineering work products
resulting from analysis, design, coding, and testing
 Provide a systematic way to assess quality based on a set of clearly
defined rules
 Provide an “on-the-spot” rather than “after-the-fact” insight into the
software development
3

4.  Measure
 Provides a quantitative indication of the extent, amount, dimension,
capacity, or size of some attribute of a product or process
 Metric
 (IEEE) A quantitative measure of the degree to which a system, component,
or process possesses a given attribute
 Indicator
 A metric or combination of metrics that provides insight into the software
process, a software project, or the product itself
4

5.  To indicate the quality of the product.
 To assess the productivity of the people who
produce the product
 To assess the benefits derived from new
software engineering methods and tools
 To form a baseline for estimation
 To help justify requests for new tools or
additional training

6.  Formulation
 The derivation (i.e., identification) 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 in an effort to gain insight into the quality of
the representation
 Feedback
 Recommendations derived from the interpretation of product metrics
and passed on to the software development team
6

7.  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
7
(More on next slide)

8.  Consistent in the use of units and dimensions
 The mathematical computation of the metric should use measures that
do not lead to bizarre combinations of units
 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 high-quality feedback
 The metric should lead to a higher-quality end product
8

9. 1. Process Metrics
2. Product Metrics
3. Project Metrics

10.  Process metrics are measures of the software
development process, such as
 Overall development time
 Type of methodology used
 Process metrics are collected across all
projects and over long periods of time.
 Their intent is to provide indicators that lead
to long-term software process improvement.

11.  Project Metrics are the measures of Software
Project and are used to monitor and control
the project. They enable a software project
manager to:
 Minimize the development time by making the adjustments
necessary to avoid delays and potential problems and risks.
 Assess product quality on an ongoing basis & modify the
technical approach to improve quality.

12.  Product metrics are measures of the software
product at any stage of its development,
from requirements to installed system.
Product metrics may measure:
 the complexity of the software design
 the size of the final program
 the number of pages of documentation produced

13.  Direct measures
 Easy to collect
 E.g. Cost, Effort, Lines of codes (LOC), Execution Speed,
Memory size, Defects etc.
 Indirect measures
 More difficult to assess & can be measured indirectly only.
 Quality, Functionality, Complexity, Reliability, Efficiency,
Maintainability etc.

14.  2 different project
teams are working to
record errors in a
software process
 Team A – Finds 342
errors during software
process before release
 Team B- Finds 184
errors
Which team is
more effective
in finding
errors?

15.  To answer this we need to know the size &
complexity of the projects.
 But if we normalize the measures, it is
possible to compare the two
 For normalization we have 2 ways-
 Size-Oriented Metrics
 Function Oriented Metrics

16. • Based on the “size” of the software produced
Project Effort
(person-
month)
Cost
($)
LOC kLOC Doc.
(pgs)
Error
s
People
A 24 168,000 12100 12.1 365 29 3
B 62 440,000 27200 27.2 1224 86 5

17.  Errors per KLOC
 $ per KLOC
 Pages of documentation per KLOC
 Errors per person-month
 LOC per person-month
 Advantages of Size Oriented Metrics
 LOC can be easily counted
 Many software estimation models use LOC or KLOC as input.
 Disadvantages of Size Oriented Metrics
 LOC measures are language dependent, programmer dependent
 Their use in estimation requires a lot of detail which can be difficult to achieve.

18.  The function point metric (FP), first proposed
by Albrecht, can be used effectively as a
means for measuring the functionality
delivered by a system.
 Functionality is measured indirectly using a
measure called function point.
 Function points (FP) - derived using an
empirical relationship based on countable
measures of software & assessments of
software complexity

19. 19
Information
Domain Value Count simple average complex
Weighting factor
External Inputs ( EIs)
External Outputs ( EOs)
External Inquiries ( EQs)
Internal Logical Files ( ILFs)
External Interface Files ( EIFs)
3 4 6
4 5 7
3 4 6
7 10 15
5 7 10
=
=
=
=
=
Count total
3
3
3
3
3
• Errorsper FP
• Defectsper FP
• $ per FP
• Pagesof documentation per FP

20. 1. Count the measurement parameters.
2. Assess the complexity of the values.
3. Calculate the raw FP (see next table).
4. Rate the complexity factors to produce the
complexity adjustment value (CAV)
5. Calculate the adjusted FP as follows:
FP = raw FP x [0.65 + 0.01 x CAV]

21. • Advantages: language independent, based on data known
early in project, good for estimation
• Disadvantages: calculation complexity, subjective
assessments, FP has no physical meaning (just a number)

22.  http://www.slideshare.net/13-software-
metrics
 Software Engineering: A Practitioner’s
Approach, 6th edition by Roger S. Pressman
 https://en.wikipedia.org/wiki/Software_metri
c
 http://www.cs.kent.edu/~jmaletic/cs63901/le
ctures/SoftwareMetrics.pdf
22

23. Any Queries ?
23