Daniel Moune Software Measurement and Metrics Full Set of Slides PDF

Outline
Introduction
Basics of Measurements
Goal-based Framework of Measurement
Software Metrics and Measurements
Fundamentals of Software Measurement (Full set of slides)
Daniel Moune
Msc, Software Engineering 2013
Network Engineer CCNA, CCNP, MCITP 2008
ICT Department
ICT University, Yaounde Campus
August 2018
Daniel Moune | moune.Daniel@ictuniversity.org | +237675082872 Software Metrics and Measurements 1

Outline
Introduction
Outline
• Introduction
• What is measurement?
• Measurement purpose
• Software Measurement Challenges
• Basics of Measurements
• Theory of measurement
• Measurement scales and types
• Empiric Investigations
• Products Measurement Models
• LOC Model
• Function-Points Model
• Cost Construction Model
• Process Measurement Models
• attributes classification
• External / internal Metrics
• Goal-based Framework for software measurement
• attributes classification
• External / Internal Metrics

Outline
INTRODUCTION
Introduction
Measurement = Process used to assign values to characteristics or
attributes of a real world entity.
Measure = Quantitative/Qualitative indication of the size of some
product or process attribute.
Metric = Quantitative measure of the degree to which a system
component or process possesses a given attribute .
We use measurement in general
• To describe objects (modeling)
• To assess objects/process/methods (quality assessment)
• To predict trends and tendencies (decision-making)

Outline
INTRODUCTION
Introduction
Problems
• Software is an abstract product, so how do we define
measurable characteristics on something abstract?
• Software quality depends on its development process/methods.
How do we assess processes and methods?
• At the difference of other Engineering domains, Software
Engineering has fuzzy models on how to define project
requirements, costs and risks. So how do we assess these
management parameters?

Outline
INTRODUCTION
Introduction
Problems
• British Computer Society made a survey
• Out of 1027 projects only 130 were successful !!!!
• $81billion has been lost on US Software projects in 1995
• 53% of projects cost almost 200% of original estimate
• Success was defined as
• Delivered with all requirements met
• Within budget
• Within time
• Conformant to quality standards agreed on

Outline
INTRODUCTION
Introduction
• In the software industry, developers will never declare
their products defect free(Why?).
• Software Complexity: Number of possible uses the product permits.
Normally, an industrial product allows only less than a few thousand use
cases and configurations
• Product Visibility: Software products are abstract so software faults
which are stored on diskettes or CDs are invisible.
• Product Development and Production Process: In an industrial product,
defects can be detected during the development and manufacturing.
Unfortunately software defects can be detected only during
development stage

Outline
INTRODUCTION
Introduction
In Software Engineering, we need measurements
in order to achieve almost the same goals
• To describe software components with measurable
characteristics (modeling and design)
• To test and validate software deliverables/methods (quality
assessment)
• To predict project feasibility, risks, costs, maintenance and
delivery schedules (project management)

Outline
INTRODUCTION
Introduction
Questions requiring Measurements for
project management
• What is the cost of each stage of the Software Development process?
• How productive is the staff ?
• How good are the Software deliverables?
• Will the customer be satisfied of the final product?
• When are we going to deliver the early releases, the final releases ?
• What do we need to do in order to mitigate delays and budget overflow?
• How much can we sell the product to a customer?

Outline
INTRODUCTION
Introduction
Questions requiring Measurements for
project design and implementation
• Are the requirements clearly defined and testable?
• What kind of faults are we going to test?
• How are we going to detect these faults ?
• Are the sizes of project modules / units correct?
• How complex is the project design?
• Which framework are we going to use to reduce time for coding / testing /
maintenance?
• When should we stop modifying / working on the project to satisfy the user
requirements?

Outline
Introduction
BASICS OF MEASUREMENTS
Part I: Measurement basics

Outline
Introduction
Measurement (Quantity/Quality assessment)
• Measurement = activity of evaluating an entity’s property by comparison

against a standard entity called “Unit”
• Measure = result of a measure; value (number or symbol) assigned to an

entity’s attribute/property
• Domain = set of possible values of a measure

• Scale = properties of the values that determines which operations can be applied
to them to extract information

Outline
Introduction
Measurement types
Measurements can be classified as
• Direct measurement
• mapping of an attribute to a value from the sole assessment

of that attribute
• Indirect measurement
• Mapping of an attribute to a value from the assessment and
computation of multiple attributes

Outline
Introduction
Measurement and scales

Values from measures have some properties which
allow some categorization
• Quantitative
• Discrete (integer)
• Continuous (floating-decimal, real)
• Interval
• proportional
• Qualitative
• Nominal (unordered)
• Ordinal (ordered using some logic)

Outline
Introduction
Direct Measures Examples

• Length of code (measured by lines of code)
• Duration of testing process (measured by elapsed time in hours)
• Number of defects discovered(measured by the counting of defects)
• Number of pages of per module in SRS documentation
• Number of a system’s functional requirements in the SRS
• Number of revisions or versions produced on each section in the SDS
• Number of diagrams illustration per Section in the SRS
• Number of days spent by the team on each stage of the Software
development process
• Number of tests executed on the code
• Time spent on a programmer on the project(measured by months worked)

Outline
Introduction
Indirect Measures Examples

•

Outline
Introduction
Nominal Scale in Software Measurement

•

Outline
Introduction
Nominal Scale in Software Measurement

Outline
Introduction
Ordinal Scale
• Values of the measure are grouped into classes and these classes can be
compared using a relation of order
• Any mapping to numerical values should preserve the order
Suppose we have to evaluate the conformance on each section of the SRS documentation
according to the description provided in the SRS IEEE 830-1998 template. This can be likely done
with a survey the following scale
Incomprehensible < non conformant < Neutral < moderately Conformant < fully conformant
M(x) 0 1 2 3 4
Conformance incomprehensible Not conformant Neutral Moderately conformant Fully conformant
Then each section score would be obtained by calculating the mode of this variable’s distribution.

Outline
Introduction
Ordinal Scale

Outline
Introduction
Interval Scale
• Values of the measure are grouped into classes and there is classes can be
compared using a relational operator
• Each class has a weight which is provided by the size of its interval. This
weight is going to have an influence on the metrics computation
• Any mapping should preserve ordering and weight
• Adding and subtracting values is possible but not multiplication and division
Suppose we have to evaluate the responsiveness of the web pages of our project’s prototype that has been online since last week.
This can be likely done by asking each participant to specify time taken by they browser to render the gallery page when it is
loading. This can be done using the following
M(x) 0 – 200ms 200 – 500ms 500 – 1000ms 1000 – 5000ms > 5000ms
Meaning Very responsive Responsive Moderately responsive undecidable Not responsive
The responsiveness score would be obtained by calculating the average of this variable’s distribution.

Outline
Introduction
Interval Scale

Outline
Introduction
Proportional/Ratio Scale
• Values of the measure are grouped into classes and there is classes can be
compared using a relational operator
• There is a zero value representing the lack of measurement
• Each class has a weight which is provided by the size of its interval. This
weight is going to have an influence on the metrics computation
• Any mapping should preserve ordering, weight and ratios and start from 0
• Adding and subtracting multiplying and dividing values is allowed
• It is possible to compare several attributes with one single measure
For instance, the number of repeated sections of code per software modules is a clear indicator of the level of
modularity in the project design.
Another example is the algorithmic complexity which represents the number of elementary operations necessary
to successfully execute an algorithm based on the size of inputs is one basic measure of software efficiency.

Outline
Introduction
Proportional/Ratio Scale

Outline
Introduction
Absolute Scale
• Values of the measure are obtained by counting the
number of elements in an entity set
• There is only one possible measurement mapping
namely the actual count
• All arithmetic operations can be performed on the
resulting count
For instance, the length of code measured in KLOC.

Outline
Introduction
Meaningfulness of scales in
measurement
• Analyzing scales help to determine the weight of the measure
in the product assessment
• Scales help to determine the data collection method and the
measurement method
• Scales help to determine which metrics to produce and how to
interpret them
• A statement involving measures or metrics interpretation is
meaningful if its truth value is not modified by any
transformation applied to the allowable scales

Outline
Introduction
Basic Measures (Measures of Location)

Outline
Introduction
Basic Measures (Measures of Spread)

Spread: with measures of spread, researchers can determine how wide data is scattered across
the whole measurement scale.
• Ranges: distribution range is the difference between the largest and smallest values.
Researchers often quote the interquartile range which is the range between the lower quartile
and the upper quartile
• Standard deviation: is the measure of the average spread around the mean.
• Variance : is square of the standard deviation. It gives you an idea of the average
distance of the values to the mean.

Outline
Introduction
Metrics (Quality assessment)

Metric = measure of the degree to which a system, a component or a process
possesses a given attribute. There are 03 kinds of software quality metrics
• Product metrics: describe the characteristics of a software product (e.g. size, cost,
complexity, design features, performance, etc...)
• Process metrics: describe the characteristics of a development/maintenance process
(e.g. efficiency, rate of defect detection, impact of defect removal, response time for fixes and
error recovery, etc...)
• Project metrics : describe the project characteristics and execution (e.g. number of
developers, productivity, success rate, etc...)

Outline
INTRODUCTION
Metrics (Requirements)
Software metrics requirements should satisfy the following
requirements
General requirements
• relevant
• valid
• reliable
• Comprehensive
• Mutually exclusive
Operative requirements
• Easy and simple
• Does not require independent data collection
• Immune to biased interventions

Outline
Introduction
What to measure?
• This is one of the nightmares of QA analysts
• There many approaches and models that have been defined
over the years
• Each of model targets a some dimensions of software quality
assessment domain, so selection of the model should be done
according to the project goals
• A few of these models would be studied in here.

Outline
Introduction
Part II: Product metrics
Product metrics

Outline
INTRODUCTION
Product Metrics(Programmer productivity)

• Rate of software production: measured in terms of
code/documentation produced per time unit (Ex: LOC/day)
• Size related measures:
• Based on the deliverables from current software process
• Amount of delivered source code / documentation
• Function-related measures:
• Function-points
• Object-points
• UCP
• Not quality oriented: Although quality assurance is a factor in
productivity assessment.

Outline
Introduction
Software size metrics
LOC Model

Outline
Introduction
Size metrics (Line of Code)

• Program length: can be used to predict program characteristics e.g.
person-month effort and ease of maintenance
• What’s LOC:
• Measured first proposed when programs were typed on cards with one line per card
• How does this corresponds to statements in Java which can span on several lines?
• What programs should be counted as part of the system?
• Assumes linear relationship between system size and volume of documentation
• Versions of LOC: DSI(Delivered Source Instructions), KLOC
• One instruction is one LOC
• Declarations are counted
• Comments are not

Outline
Introduction
LOC (Advantages and disadvantages)

• Advantage: Simple to measure (Direct measurement)
• Disadvantages:
• Defined on code
• Bad coding practices may introduce more LOC
• Language dependent: actually low level language makes programmers less
productive but introduce more LOC
• Based on a specific view of size (length).
• More LOC does not mean good quality, how about complexity, requirements,
reliability ….????
• Measures of productivity based on LOC suggest that programmers who write verbose
code are more productive than programmers who write compact code !!!!

Outline
Introduction
Software size metrics
Function-Point Model

Outline
Introduction
Function-Point (FP)
A Function Point (FP) is a unit of
measurement to express the amount of
business functionality, an information
system (as a product) provides to a user. It is
used to measure software size.There are
two types of functions
● Data Functions
● Transaction Functions
Data Functions are made up of internal and external
resources that affect the system. Transaction functions are
made up of the processes that are exchanged between the
user, the external applications and the application being
measured

Outline
Introduction
Function-Point (FP)
•

Outline
Introduction
Function-Points (Complexity Adjustment Factor)
M(x) 0 1 2 3 4 5
Weight Not Important Incidental Moderate Average Significant Essential

Outline
Introduction
Complexity Adjustment Factors
Adjustment Factor
1 Backup and recovery
2 Data communication
3 Distributed processing functions
4 Is performance critical
5 Existing Operating Environment
6 On-line data entry
7 Input transaction built over multiple screens

Outline
Introduction
Complexity Adjustment Factors
Adjustment Factor
8 Master files updated on-line
9 Complexity of inputs, outputs, files, inquiries
10 Complexity of processing
11 Code design for re-use
12 Are conversion/installation included in design?
13 Multiple installations
14 Application designed to facilitate change by the user

Outline
Introduction
Function-Points (Advantages and disadvantages)

Outline
Introduction
Average LOC per FP (sample list)
Avg LOC Language

320 Assembly language
128 C
105 Cobol / Fortran
90 Pascal / Ada
70 Ada
64 C++
31 Java /Python/ Object Oriented Languages
20 4th generation languages (4GLs)

Outline
Introduction
Average LOC per FP (sample list)

Avg LOC Language
•
16 Code generators
15 HTML
12 SQL
6 Spreadsheets (VBA)

Outline
Introduction
Function-Points and Normalization

• Advantages:
• Function points are used to normalize measures
– Errors (bugs) per FP (discovered at programming)
– Defects per FP (discovered at programming)
– More accurate than LOC
– $ Cost per FP
– Pages of documentation per FP
– FP per person-month
• The average number of LOC per FP is a language-dependent factor varying from
approximately 300 for assembly language to 12 for 4th generation languages

Outline
Introduction
Software Cost metrics
Constructive Cost Model

Outline
INTRODUCTION
Software Cost (Components)

• Effort Cost: dominant cost in almost all projects
• Staff salaries
• Social/insurance costs and benefits
• Tools Cost: Hardware and software used for development.
• Overheads: Ignored by most debutants.
• Cost for air-conditioning, heating, lighting, renting
• Cost of networking and telecommunications (telephone, fax, internet….)
• Cost of shared facilities (library, restaurant, etc…)
• Cost of documentation/archiving (printing, DVD burning, etc…)
• Depreciation cost of assets
• Activity based costing
• Meetings / interviews costs
• Travels and training costs

Outline
INTRODUCTION
Software Cost (Factors)

• Market opportunity: Objective is to move into a new segment of the
software market. Accepting low profit on a project may give
opportunity of more profit later
• Cost estimation uncertainty: objective is to increase the software price
by some contingency above the normal profit in order to cover possible
loss.
• Contractual terms: objective is to lower software price by allowing
developers to retain ownership of source code.
• Requirements volatility: objective is to lower software price to win a
contract. After the contract is awarded, high prices may be charged for
changes in requirements.
• Financial health: objective is to lower software price to win a contract.
It is better to make small profit than declare bankruptcy

Outline
Introduction
COCOMO Basics
• COCOMO Barry W. Boehm,1981 (Constructive Cost Model) for Cost and effort estimation.
• Empirical model based on projects’ experience derived from the analysis of 63
software projects in 1981.
• Computes software development effort as a function of program size (SLOC, KLOC)
• Procedural cost estimation model based on 02 parameters:
• Effort: Amount of labor required to complete a task. It is measured in person-days/
person-weeks/person-months
• Schedule: Amount of calendar time required to complete an activity. Unit here is hour/day/month/year
• Differentiates 03 types of software projects
Software Project
Organic Small teams with good experience working with less rigid requirements
Medium teams with mixed experience working with a mix of rigid and less
Semi-detached
requirements
Embedded Project with tight constraints (combination of organic and semi-detached)

Outline
Introduction
COCOMO Basics
•
Software Project a b c d
Organic 2.4 1.05 2.5 0.38
Semi-detached 3.0 1.12 2.5 0.35
Embedded 3.6 1.20 2.5 0.32

Outline
Introduction
COCOMO Intermediate
•
Software Project a b c d
Organic 3.2 1.05 2.5 0.38
Semi-detached 3.0 1.12 2.5 0.35
Embedded 2.8 1.20 2.5 0.32

Outline
Introduction
COCOMO Intermediate (Product attributes)

Outline
Introduction
COCOMO Intermediate (Hardware attributes)

Outline
Introduction
COCOMO Intermediate (Project attributes)

Outline
Introduction
COCOMO Intermediate (Personnel attributes)

Outline
Introduction
Source Code metrics
Source Code Quality Metrics

Outline
Introduction
GOAL-BASED FRAMEWORK OF MEASUREMENT
Source Code Metrics (What?)

Source Code Metrics: can be classified in 03 groups
• Structural metrics
• Number of methods / fields
• Afferent / Efferent coupling
• Relational cohesion
• Type / Method rank
• Number of parameters / variables
• Complexity metrics
• McCabe complexity metrics
• Halstead Complexity metrics
• Object Oriented metrics
• Weighted methods per Class
• Number of children
• Depth of inheritance Tree

Outline
Introduction
Source Code metrics (Structural)

Structural metrics define how code is organized
• Number of functions/ methods / parameters/variables
• measure the number of functions/methods/fields per module. Classes/functions with too many methods may be
trying to do too much, or in any case may be more difficult to maintain.
• Afferent / Efferent coupling
• measure the number of inbound use of types / modules in the current module (Afferent) or the number of
outbound use of types / modules of the current module (Efferent)
• Abstractness/Instability
• degree of abstraction of a module/package. Relative susceptibility of class to change
• Type / Method rank
• Similar to Google Page Rank, this metric allow to determine which types/classes are most critical to an application
by accounting based on their efferent coupling . High TypeRank types should generally be the most well-tested
and best designed, since bugs in these types will tend to have higher impact on the application.

Outline
Introduction
Source Code metrics (Coupling)

Outline
Introduction
Source Code metrics (Coupling)

Outline
Introduction
Source Code metrics (Instability)

Outline
Introduction
Source Code metrics (Abstractness)

Outline
Introduction
Source Code metrics (Halstead Complexity)

Code Name Formula
PVocabulary Program Vocabulary
PLength Program length or
PVolume Program Volume
PDifficulty Program Difficulty
PEffort Program Effort
Time Required to
TrProg
program
Number of Delivered
NDelBug
Bugs

Outline
Introduction
Source Code metrics (Halstead Complexity)

Outline
Introduction
Source Code metrics (MacCabe’s Complexity)

Complexity metrics define how complex is the code logic
● MacCabe’s Cyclomatic Complexity (v(G))
● Measures - The complexity of a module's decision structure.
● Calculation - Count of linearly independent paths through a function or set of functions.
● Higher cyclomatic complexities correlate with greater testing and maintenance requirements. Complexities
above 20 also correspond to higher error rates.
● MacCabe’s Essential Complexity (ev(G))
● Measures - The degree to which a module contains unstructured constructs.
● Calculation - Cyclomatic complexity of a module's remaining decision structure, once it has been reduced by
fusing primitive, well-structured regions.

Outline
Introduction

Outline
Introduction

Outline
Introduction

Outline
Introduction

Outline
Introduction

Outline
Introduction
Helpdesk Quality
Helpdesk Quality Metrics

Outline
Introduction
HD Metrics(What?)
HD quality metrics : involves 03 groups of measures
• Calls metrics
• Calls density metrics = rate of customer requests for HD services as measured by the number of
calls
• Calls severity metrics = categorization of customer requests based on a weighted scale applied
on the accounting of the customer request over a period of time
• HD success metrics = rate of success in response to customer request. A success is achieved by
completing the required service within the time determined in the service contract
• Productivity and effectiveness metrics

Outline
Introduction
HD Metrics(Calls Density Metrics)

Code Name Formula
HDD HD calls density
WHDD Development Error Density
WHDF Weighted HD calls per function points
NHYC = the number of HD calls during a year of service.

KLMC = Thousands of lines of maintained software code.
WHYC = weighted HD calls received during one year of service.
NMFP = number of function points to be maintained.

Outline
Introduction
HD Metrics(Calls Severity Metrics)

Code Name Formula
ASHC Average Severity of HD calls
Calls severity metrics aim at detecting one type of adverse situation: increasingly
severe HD calls.
The computed results may contribute to improvements in all or parts of the user
interface (its “user friendliness”) as well as the user manual and integrated help
menus.
The Average Severity of HD Calls (ASHC): refers to failures detected during a period of
one year

Outline
Introduction
HD Metrics(HD Success Metrics)

Code Name Formula
ASHC HD Success metrics
NHYNOT = Number of yearly HD calls completed on time during one year of

service.

Outline
Introduction
HD Metrics(Productivity and Effectiveness metrics)

Code Name Formula
HDP HD Productivity
FHDP Function Point HD Productivity
HDE HD effectiveness
HDYH = Total yearly working hours invested in HD servicing of the

software system.
NMFP = number of function points to be maintained.

Outline
Introduction
Corrective Maintenance Quality
Corrective Maintenance Quality

Metrics

Outline
Introduction
Corrective Maintenance Quality Metrics(What?)
CM quality metrics : deal with several aspects of the quality of maintenance services. A
distinction is needed between software system failures treated by the maintenance teams and failures of
the maintenance service that refer to cases where the maintenance failed to provide a repair that meets
the designated standards or contract requirements. software maintenance metrics are classified as
follows
• Software System failures density metrics = rate of demand for corrective
maintenance, based on the records of failures identified during regular operation of the
software system
• Software System failures severity metrics = rate of severe software system failures
encountered to by the corrective maintenance team based on a weighted scale.
• Software System failures of maintenance services metrics = rate of
maintenance services incapacity to complete the failure correction on time or rate of failed
corrections.
• Software System availibility metrics = rate of disturbances caused to the customer by
periods of time where the services of the software system are unavailable or only partly
available

Outline
Introduction
CM Metrics(failure density metrics)

Code Name Formula
SSFD Software Systems Failure Density
Weighted Software Systems Failure

WSSFD
Density
Weighted Software Systems Failure

WSSFF
per Function Point
NYF = number of software failures detected during a year of maintenance service.

WYF = weighted number of yearly software failures detected during one year of
maintenance service.
NMFP = number of function points designated for the maintained software.

Outline
Introduction
CM Metrics(System failure Severity Metrics)

Code Name Formula
Average Severity of Software

ASSSF
System Failures
The Average Severity of Software System Failures(ASSSF):

refers to failures detected during a period of one year of
maintenance service

Outline
Introduction
CM Metrics(Failure of maintenance Metrics)

Code Name Formula
Maintenance Repeated repair

MRepF
Failure metric
NYF = number of software failures detected during a year of

maintenance service.
RepYF = Number of repeated software failure calls (service
failures).

Outline
Introduction
CM Metrics(System Availability metrics)

Code Name Formula
FA Full Availability metric
VitA Vital Availability metric
TuA Total Unavailability metric
NYSerH = Number of hours software system is in service during one year.

NYFH = Number of hours where at least one function is unavailable (failed) during one year,
including total failure of the software system.
NYVitFH = Number of hours when at least one vital function is unavailable (failed) during
one year, including total failure of the software system.
NYTFH = Number of hours of total failure (all system functions failed) during one year.
NYFH ≥ NYVitFH ≥ NYTFH.
1 – TUA ≥ VitA ≥FA
Outline
Introduction
Part III: Process Metrics
Process Metrics

Outline
Introduction
Process Metrics
Software process metrics fall into one of the following categories:
• Quality metrics: describe the spread of defects/errors in the final product (e.g. error
density, error severity, error removal efficiency, etc...)
• Timetable metrics: describe the rate of activities/tasks completion along with the
milestones achievements (e.g. timetable observance, average delay of milestone completion,
etc...)
• Productivity metrics : describe the rate of code and documentation release over
the time (e.g. development productivity, code reuse, documentation reuse, etc...)

Outline
Introduction
Quality Metrics(Error Density)

Error Density : involves 02 measures
• Software size: measured in KLOC, DSI or NFP
• Errors accounting : obtained by counting errors discovered during each stage of the
software development process
• NCE = Number of Code Errors detected in the source code through code inspections and
testing
• NDE = Number of Design Errors detected in the product documentation through
validation and verification
• WCE = Weighted total Code Errors detected in the source code through code inspections
and testing
• WDE = Weighted total Design Errors detected in the product documentation through
validation and verification

Outline
Introduction
Quality Metrics(Error Density Metrics)

Code Name Formula
CDE Code Error Density
DED Development Error Density
WCED Weighted Code Error Density
WDED Weighted Development Error Density
Weighted Code Errors per Function

WCEF
Point
Weighted Development Errors per

WDEF
Function Point

Outline
Introduction
Quality Metrics(Error Severity Metrics)

Code Name Formula
ASCE Code Error Density
ASDE Development Error Density
The metrics ASCE and ASDE are used to detect adverse

situations of increasing numbers of severe errors in situations
where errors and weighted errors, as measured by error density
metrics, are generally decreasing

Outline
Introduction
Quality Metrics(Error Removal Effectiveness Metrics)
Code Name Formula

Development Errors Removal
DERE
Effectiveness
Development Weighted Errors

DWERE
Removal Effectiveness
Software developers can measure the effectiveness of error removal by the software
quality assurance system after a period of regular operation (usually 6 or 12 months) of
the system. The metrics combine the error records of the development stage with the
failures records compiled during the first year (or any defined period) of regular
operation.
NYF = Number of Software failures detected during a year of maintenance service
WYF = Weighted number of Software failures detected during a year of maintenance
service
Outline
Introduction
Quality Metrics(Timetable Metrics)
Code Name Formula
TTO Time Table Observance
Average Delay of Milestone

ADMC
Completion
Software process timetable metrics may be based on accounts of success (completion of milestones
per schedule) in addition to failure events (non-completion per schedule). An alternative approach
calculates the average delay of milestones. TTO and ADMC metrics are based on data for all
relevant milestones scheduled in the project plan. In other words, only milestones that were
designated for completion in the project plan stage are considered in the metrics’ computation.
Therefore, these metrics can be applied throughout development and need not wait for the
project’s completion.
MSOT = Milestone completed on time
TCDAM = Total Completion Delays(days, weeks, etc...) for all milestones.
MS = Total number of milestones

Outline
Introduction
Quality Metrics(Productivity Metrics)

Code Name Formula
DevP Document Productivity
FDevP Function Point Productivity
CRe Code Reuse
DocRe Documentation Reuse
DevH = Total working hours invested in the development of the software system.
ReKLOC = Number of thousands of reused lines of code.
ReDoc = Number of reused pages of documentation.
NDoc = Number of pages of documentation.

Outline
Introduction
Tools
Here is a non-exhaustive list of tools for Source
code metrics visualization
• NDepend
• Sextant

Outline
Introduction
Empirical investigations
Conclusion
Thank you guys for making silence during my presentation!

And,
Thank you HKS sir for providing me this wonderful topic!

Daniel Moune Software Measurement and Metrics Full Set of Slides PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Daniel Moune Software Measurement and Metrics Full Set of Slides PDF

Uploaded by

Copyright:

Available Formats

Outline

Software Metrics and Measurements

Fundamentals of Software Measurement (Full set of slides)

Daniel Moune | moune.Daniel@ictuniversity.org | +237675082872 Software Metrics and Measurements 1

Daniel Moune | moune.Daniel@ictuniversity.org | +237675082872 Software Metrics and Measurements 2

Daniel Moune | moune.Daniel@ictuniversity.org | +237675082872 Software Metrics and Measurements 3

Daniel Moune | moune.Daniel@ictuniversity.org | +237675082872 Software Metrics and Measurements 4

Daniel Moune | moune.Daniel@ictuniversity.org | +237675082872 Software Metrics and Measurements 5

Daniel Moune | moune.Daniel@ictuniversity.org | +237675082872 Software Metrics and Measurements 6

Daniel Moune | moune.Daniel@ictuniversity.org | +237675082872 Software Metrics and Measurements 7

Daniel Moune | moune.Daniel@ictuniversity.org | +237675082872 Software Metrics and Measurements 8

Daniel Moune | moune.Daniel@ictuniversity.org | +237675082872 Software Metrics and Measurements 9

Part I: Measurement basics

Daniel Moune | moune.Daniel@ictuniversity.org | +237675082872 Software Metrics and Measurements 10

Measurement (Quantity/Quality assessment)

• Measurement = activity of evaluating an entity’s property by comparison

• Measure = result of a measure; value (number or symbol) assigned to an

• Domain = set of possible values of a measure

Daniel Moune | moune.Daniel@ictuniversity.org | +237675082872 Software Metrics and Measurements 11

• mapping of an attribute to a value from the sole assessment

Daniel Moune | moune.Daniel@ictuniversity.org | +237675082872 Software Metrics and Measurements 12

Measurement and scales

Daniel Moune | moune.Daniel@ictuniversity.org | +237675082872 Software Metrics and Measurements 13

Direct Measures Examples

Daniel Moune | moune.Daniel@ictuniversity.org | +237675082872 Software Metrics and Measurements 14

Indirect Measures Examples

Daniel Moune | moune.Daniel@ictuniversity.org | +237675082872 Software Metrics and Measurements 15

Nominal Scale in Software Measurement

Daniel Moune | moune.Daniel@ictuniversity.org | +237675082872 Software Metrics and Measurements 16

Nominal Scale in Software Measurement

Daniel Moune | moune.Daniel@ictuniversity.org | +237675082872 Software Metrics and Measurements 17

Daniel Moune | moune.Daniel@ictuniversity.org | +237675082872 Software Metrics and Measurements 18

Daniel Moune | moune.Daniel@ictuniversity.org | +237675082872 Software Metrics and Measurements 19

Meaning Very responsive Responsive Moderately responsive undecidable Not responsive

Daniel Moune | moune.Daniel@ictuniversity.org | +237675082872 Software Metrics and Measurements 20

Daniel Moune | moune.Daniel@ictuniversity.org | +237675082872 Software Metrics and Measurements 21

Daniel Moune | moune.Daniel@ictuniversity.org | +237675082872 Software Metrics and Measurements 22

Daniel Moune | moune.Daniel@ictuniversity.org | +237675082872 Software Metrics and Measurements 23

Daniel Moune | moune.Daniel@ictuniversity.org | +237675082872 Software Metrics and Measurements 24

Daniel Moune | moune.Daniel@ictuniversity.org | +237675082872 Software Metrics and Measurements 25

Basic Measures (Measures of Location)

Daniel Moune | moune.Daniel@ictuniversity.org | +237675082872 Software Metrics and Measurements 26

Basic Measures (Measures of Spread)

Daniel Moune | moune.Daniel@ictuniversity.org | +237675082872 Software Metrics and Measurements 27

Metrics (Quality assessment)

Daniel Moune | moune.Daniel@ictuniversity.org | +237675082872 Software Metrics and Measurements 28

Daniel Moune | moune.Daniel@ictuniversity.org | +237675082872 Software Metrics and Measurements 29

Daniel Moune | moune.Daniel@ictuniversity.org | +237675082872 Software Metrics and Measurements 30

Part II: Product metrics

Daniel Moune | moune.Daniel@ictuniversity.org | +237675082872 Software Metrics and Measurements 31

Product Metrics(Programmer productivity)

Daniel Moune | moune.Daniel@ictuniversity.org | +237675082872 Software Metrics and Measurements 32

Software size metrics

Daniel Moune | moune.Daniel@ictuniversity.org | +237675082872 Software Metrics and Measurements 33

Size metrics (Line of Code)

Daniel Moune | moune.Daniel@ictuniversity.org | +237675082872 Software Metrics and Measurements 34

LOC (Advantages and disadvantages)

Daniel Moune | moune.Daniel@ictuniversity.org | +237675082872 Software Metrics and Measurements 35

Software size metrics

Daniel Moune | moune.Daniel@ictuniversity.org | +237675082872 Software Metrics and Measurements 36

Data Functions are made up of internal and external

resources that affect the system. Transaction functions are

made up of the processes that are exchanged between the