SOFTWARE PROJECT METRICS

Sunday, August 22, 2010 1

 THE METRICS
The IEEE Standard Glossary of Software Engineering
Terms [IEE93] defines metric as -
“a quantitative measure of the degree to which a system,
component, or process possesses a given attribute.”

Measurement
Based
Techniques
Appli
ed
To
To
Software Supp
ly Engineering &
Processes,
To Management
Products & Impro Information
Services ve
Sunday, August 22, 2010 2
The Need for Software Metrics
The software crisis must be addressed and, to the
extent possible, resolved. To do so requires more
accurate schedule and cost estimates, better quality
products, and higher productivity. All these can be
achieved through more effective software
management, which, in turn, can be facilitated by the
improved use of software metrics. Improvement of the
management process depends upon improved ability
to identify, measure, and control essential parameters
of the development process. This is the goal of
software metrics—the identification and measurement
of the essential parameters that affect software
development.

Sunday, August 22, 2010 3

IDEAL SOFTWARE METRICS
1. Simple, precisely definable—so that it is
clear how the metric can be evaluated.
2. Objective, to the greatest extent possible.
3. Easily obtainable (i.e., at reasonable cost).
4. Valid—the metric should measure what it is
intended to measure.
5. Robust—relatively insensitive to
(intuitively) insignificant changes in the
process or product.

Sunday, August 22, 2010 4

 Types of Software Metrics

1. LOC (Line of Code)

2. FP (Function Point)
3. Halstead's Software Science
4. McCabes's cyclomatic complexity
5. Quality Metrics
6. COCOMO Model

Sunday, August 22, 2010 5

 LOC
LOC is one of the earliest and simplest metric for estimating
the effort and size for estimating the effort and size of a
computer program. However, there is no standard definition
of what makes a line of code. Due to this, different workers
for the same program may obtain different counts.
LOC Metrics counts total lines of code (LOC), blank lines of
code (BLOC), comment lines of code (CLOC), lines with
both code and comments (C&SLOC), logical source lines of
code (SLOC-L), and number of comment words (CWORDS).
Physical executable source lines of code (SLOC-P) is
calculated as
the total lines of source code - blank lines and comment lines.
Counts are calculated on a per file basis and accumulated for
the entire project. Loc Metrics also generates a comment word
histogram.
http://www.locmetrics.com/
Sunday, August 22, 2010 6
 LOC
Advantages:
1. Simple to measure.

Disadvantages:
1. It is programming language dependent.
2. Problem size varies with individual coding style.
3. Poor software design may lead to excessive and
unnecessary line of code.
4. LOC focuses only on coding.
5. LOC can be measured accurately by only after
coding is completed.
6. It cant calculate the effort properly.
7. LOC discourages code reuse!

Sunday, August 22, 2010 7

 FP
Function Point (FP) was developed by Allan J. Albrecht
in mid 1970’s. It was an attempt to overcome difficulties
associated with LOC as a measure of software size, and to
assist in developing a mechanism to predict effort
associated with software development.
FP basically, is an objective and structured technique to
measure software size by quantifying its functionality
provided to the user based on the requirements and logical
design.
This technique breaks the system into smaller components
so that they can be better understood and analyzed.
FP analysis, thus divides the system into five basic
components namely external inputs, external outputs,
queries, logical master files and interface files.

Sunday, August 22, 2010 8

 FP
FP data is used in two ways:
1. As an estimation variable that is used to "size" each
element of the software
2. As baseline metrics collected from past projects and
used in conjunction with estimation variables to develop
cost and effort projections.
The approach is to identify and count a number of unique
function types called the “information domains”:
1. external inputs (e.g. file names)
2. external outputs (e.g. reports, messages)
3. queries (interactive inputs needing a response)
4.external files or interfaces (files shared with other
software systems)
5. internal files (invisible outside the system)

Sunday, August 22, 2010 9

 FP
Each of these is then individually assessed for complexity
and given a weighting value which varies from 3 (for
simple external inputs) to 15 (for complex internal files).
Unadjusted function points ( UFP ) is calculated as follows :

The sum of all the occurrences is computed by multiplying

each function count with a weighting and then adding up all
the values. The weights are based on the complexity of the
feature being counted. Albrecht’s original method classified
the weightings as:

Sunday, August 22, 2010 10

 UFP
Function
Low Average High Count
Type
External
x3 x4 x6
Input
External
x4 x5 x7
Output

Logical
x7 x10 x15
Internal File

External
x5 x7 x10
Interface File

External
x3 x4 x6
Inquiry

Total UFP

Sunday, August 22, 2010 11

 FP
Low, average and high decision can be determined with this table :

1-5 Data element 6-19 Data 20+ Data

types element types element types

0-1 File types

Low Low Average
referenced

2-3 File types

Low Average High
referenced

4+ File types
Average High High
referenced

Sunday, August 22, 2010 12

 TCF
There are 14 technical complexity factor. Each complexity factor is
rated on the basis of its degree of influence, from no influence to very
influential :
1. Data communications
2. Performance
3. Heavily used configuration
4. Transaction rate
5. Online data entry
6. End user efficiency
7. Online update
8. Complex processing
9. Reusability
10. Installation ease
11. Operations ease
12. Multiple sites
13. Facilitate change
14. Distributed functions

Sunday, August 22, 2010 13

 FP
In order to find adjusted FP, UFP is multiplied by technical complexity
factor ( TCF ) which can be calculated by the formula :

TCF = 0.65 + ( sum of factors ) / 100

Then FP = UFP x TCF

Sunday, August 22, 2010 14

 FP
Advantages of FP :
1. It is not restricted to code
2. Language independent
3. The necessary data is available early in a project. We
need only a detailed specification.
4. More accurate than estimated LOC
Drawbacks of FP :
1. Subjective counting
2. Hard to automate and difficult to compute
3. Ignores quality of output
4. Oriented to traditional data processing applications
5. Effort prediction using the unadjusted function count is
often no worse than when the TCF is added

Sunday, August 22, 2010 15

 FP – WEB REFERENCES
INTERNATIONAL FUNCTION POINT USER GROUP
http://www.ifpug.org/

http://www.devdaily.com/FunctionPoints/

http://www.softwaremetrics.com/Function%20Point%20Training%20
Booklet%20New.pdf

FP CALCULATOR
http://groups.engin.umd.umich.edu/CIS/course.des/cis525/js/f00/h
arvey/FP_Calc.html

Sunday, August 22, 2010 16

 FP – Problem
1. Data communications 3
Calculate the FP for a
2. Performance 2 given medium scale
3. Heavily used configuration 0
software project with the
given set of data:
4. Transaction rate 3
5. Online data entry 4
6. End user efficiency 4
7. Online update 3
8. Complex processing 3
9. Reusability 5
10. Installation ease 4
11. Operations ease 4
12. Multiple sites 4
13. Facilitate change 5
Technical Complexity
14. Distributed functions 2 Factor Table
Sunday, August 22, 2010 17
 FP – Problem
Information Domain
External External Logical External User
Input Output Internal File Interface File Inquiry
3 Files 2 Files 4 Files having 1 File having 5 Files
having 11 having 3 5 Data 11 Data having 15
Data Data Elements Elements Data
Elements Elements. Elements

2 Files 6 Files 3 Files having 8 No.s of 2 Files

having 23 having 23 13 Data Complex files having 14
Data Data Elements Data
Elements Elements Elements

5 Files having
10 Data
Elements

Sunday, August 22, 2010 18