Amity School of Engineering &

Technology

Software Engineering
Module-2
Software Metrics and Project Planning
1
 Software Metrics
 A software metric is a measure of software characteristics
which are measurable or countable. Software metrics are
valuable for many reasons, including measuring software
performance, planning work items, measuring productivity,
and many other uses.
 Characteristics of software Metrics:
1. Quantitative: Metrics must possess quantitative nature. It means metrics can be expressed
in numerical values.
2. Understandable: Metric computation should be easily understood, and
the method of computing metrics should be clearly defined.
3. Applicability: Metrics should be applicable in the initial phases of the
development of the software.
4. Repeatable: When measured repeatedly, the metric values should be the
same and consistent in nature.
5. Economical: The computation of metrics should be economical.
6. Language Independent: Metrics should not depend on any programming
language.
 Classification of software metrics
1.Product Metrics: These are the measures of various characteristics of the
software product. Th e two important software characteristics are:
1. Size and complexity of software.
2. Quality and reliability of software.

2. Process Metrics: These are the measures of various characteristics of the

software development process. For example, the efficiency of fault detection.
They are used to measure the characteristics of methods, techniques, and tools
that are used for developing software.

3. Project metrics are the metrics used by the project manager to check the
project's progress. Data from the past projects are used to collect various
metrics, like time and cost; these estimates are used as a base of new software.
Note that as the project proceeds, the project manager will check its progress
from time-to-time and will compare the effort, cost, and time with the original
effort, cost and time.
 Types of Measurement

Direct Measures:
 Easy to collect
 eg-cost, effort, Lines of Code(LOC),execution speed,
memory size, defects etc

Indirect Measures
 More difficult to access and can be measured indirectly only
 Quality, functionality, complexity, reliability,
efficiency,maintainability etc.
For this we need size and complexity of the projects.
But if we normalize the measures,it is possible to
compare the two
For normalization we have two ways:

 Size oriented metrics

 Function Oriented Metrics
 Size Oriented Metrics

It is one of the earliest and simpler metrics for calculating the size of the computer program. It is
generally used in calculating and comparing the productivity of programmers. These metrics are
derived by normalizing the quality and productivity measures by considering the size of the
product as a metric.
Simple size oriented metrics can be developed for each project
 Function Oriented Metrics

Function-Oriented Metrics are also known

as Function Point Model.

This model generally focuses on the functionality of

the software application being delivered.

These methods are actually independent of the

programming language that is being used in software
applications and based on calculating the Function
Point (FP
Function Oriented metrics
Components in Function Points
All the parameters mentioned above are assigned some weights that have been
experimentally determined and are shown in Table

The functional complexities are multiplied with the corresponding weights against each
function, and the values are added up to determine the UFP (Unadjusted Function Point)
of the subsystem.
Here that weighing factor will be simple, average, or complex for a measurement
parameter type.
The Function Point (FP) is thus calculated with the following formula.

FP = Count-total * [0.65 + 0.01 * ∑(fi)]

= Count-total * CAF

∑(fi) is the sum of all 14 questionnaires and show the complexity adjustment value/ factor-CAF
(where i ranges from 1 to 14). Usually, a student is provided with the value of ∑(f i)

∑(fi) ranges from 0 to 70, i.e.,

and CAF ranges from 0.65 to 1.35 because

1. When ∑(fi) = 0 then CAF = 0.65
2. When ∑(fi) = 70 then CAF = 0.65 + (0.01 * 70) = 0.65 + 0.7 = 1.35
General System Brief Description
Characteristic
1. Data How many communication facilities are
communications there to aid in the transfer or exchange of
information with the application or
system?
2. Distributed data How are distributed data and processing
processing functions handled?
3. Performance Did the user require response time or
throughput?
4. Heavily used How heavily used is the current hardware
configuration platform where the application will be
executed?
5. Transaction rate How frequently are transactions executed
daily, weekly, monthly, etc.?
6. On-Line data entry What percentage of the information is
entered On-Line?
7. End-user efficiency Was the application designed for end-
user efficiency?
8. On-Line update How many ILF’s are updated by On-Line
transaction?
9. Complex processing Does the application have extensive
logical or mathematical processing?
10. Reusability Was the application developed to meet
one or many users needs?
11. Installation ease How difficult is conversion and
installation?
12. Operational ease How effective and/or automated are
start-up, back up, and recovery
procedures?
13. Multiple sites Was the application specifically designed,
developed, and supported to be installed
at multiple sites for multiple
organizations?
14. Facilitate change Was the application specifically designed,
developed, and supported to facilitate
change?
The function points obtained above are unadjusted function points (UFPs). These (UFPs) of a
subsystem are further adjusted by considering some more General System Characteristics (GSCs).
It is a set of 14 GSCs that need to be considered. The procedure for adjusting UFPs is as follows:
1. Degree of Influence (DI) for each of these 14 GSCs is assessed on a scale of 0 to 5. (b) If a
particular GSC has no influence, then its weight is taken as 0 and if it has a strong influence
then its weight is 5.
2. The score of all 14 GSCs is totaled to determine Total Degree of Influence (TDI).
3. Then Value Adjustment Factor (VAF) is computed from TDI by using the formula: VAF =
(TDI * 0.01) + 0.65

value of VAF lies within 0.65 to 1.35 because

4. When TDI = 0, VAF = 0.65
5. When TDI = 70, VAF = 1.35
6. VAF is then multiplied with the UFP to get the final FP count: FP = VAF * UFP
Based on the FP measure of software many other metrics can be computed:
1. Errors/FP
2. $/FP.
3. Defects/FP
4. Pages of documentation/FP
5. Errors/PM.
6. Productivity = FP/PM (effort is measured in person-months).
7. $/Page of Documentation.
 Example
Compute the function point, productivity, documentation, cost per function for the following data:
1. Number of user inputs = 24
2. Number of user outputs = 46
3. Number of inquiries = 8
4. Number of files = 4
5. Number of external interfaces = 2
6. Effort = 36.9 p-m
7. Technical documents = 265 pages
8. User documents = 122 pages
9. Cost = $7744/ month
Various processing complexity factors are: 4, 1, 0, 3, 3, 5, 4, 4, 3, 3, 2, 2, 4, 5.
= 378 * [0.65 + 0.01 * 43]
= 378 * [0.65 + 0.43]
= 378 * 1.08 = 408
 Token Count
In these metrics, a computer program is considered to be a collection of tokens, which may be
classified as either operators or operands. All software science metrics can be defined in terms of
these basic symbols. These symbols are called as a token.
The basic measures are
n1 = count of unique operators.
n2 = count of unique operands.
N1 = count of total occurrences of operators.
N2 = count of total occurrence of operands.
In terms of the total tokens used, the size of the program can be expressed as N = N1 + N2.
 Data Structure Metrics
Essentially the need for software development and other activities are to process data. Some data is
input to a system, program or module; some data may be used internally, and some data is the
output from a system, program, or module.
For Example:
Program Data Input Internal Data Data Output
Payroll Name/Social Withholding rates Gross Pay
Security No./Pay Overtime Factors withholding Net Pay
rate/Number of Insurance Premium Pay Ledgers
hours worked Rates
Spreadsheet Item Names/Item Cell computations Spreadsheet of items
Amounts/Relationsh Subtotal and totals
ips among Items
Software Planner Program Size/No of Model Parameter Est. project effort
Software developer Constants Est. project duration
on team Coefficients
an important set of metrics which capture in the amount of data input, processed in
an output form software. A count of this data structure is called Data Structured
Metrics.
There are some Data Structure metrics to compute the effort and
time required to complete the project. There metrics are:
The Amount of Data.
The Usage of data within a Module.
Program weakness.
The sharing of Data among Modules.
 Information Flow Metrics
information flow metrics is found upon the following concept the simplest system consists of the
component, and it is the work that these components do and how they are fitted together that
identify the complexity of the system. The following are the working definitions that are used in
Information flow:
Component: Any element identified by decomposing a (software) system into it's constituent's
parts.
Cohesion: The degree to which a component performs a single function.
Coupling: The term used to describe the degree of linkage between one component to others in the
same system.
 Cost Estimation
For any new software project, it is necessary to know how much it will cost to develop and how
much development time will it take. These estimates are needed before development is initiated,
but how is this done? Several estimation procedures have been developed and are having the
following attributes in common.
1. Project scope must be established in advanced.
2. Software metrics are used as a support from which evaluation is made.
3. The project is broken into small PCs which are estimated individually.
To achieve true cost & schedule estimate, several option arise.
4. Delay estimation
5. Used symbol decomposition techniques to generate project cost and schedule estimates.
6. Acquire one or more automated estimation tools
 Uses of Cost Estimation

1.During the planning stage, one needs to

choose how many engineers are required for
the project and to develop a schedule.
2.In monitoring the project's progress, one needs
to access whether the project is progressing
according to the procedure and takes
corrective action, if necessary.
Cost Estimation Models
Static, Single Variable Models: When a model makes use of single variables to calculate desired
values such as cost, time, efforts, etc. is said to be a single variable model. The most common
equation is:
C=aLb
Where C = Costs
L= size
a and b are constants

Static Multi-variable model:This model is used to estimate the effort, cost and development time
for a software project with depends on multiple internal or external variables I .e.Effort Adjustment
Factor (cost driver factors). The relationship is given by:
 Amity School of Engineering &
Technology

Thank you

30