UNIT - 3 - Software Metrics-Rabins at CSJMU - 6 Slides Handouts

Unit III
Software Metrics
Software Metrics: What and Why ?

Unit III 1. How to measure the size of a software?
Software Metrics 2. How much will it cost to develop a software?
3. How many bugs can we expect?
4. When can we stop testing?
5. When can we release the software?
1 Software Engineering UNIT III . 2 Dr. Rabins Porwal
1 2
Software Metrics Software Metrics
 Pressman explained as “A measure provides a quantitative

6. What is the complexity of a module?
indication of the extent, amount, dimension, capacity, or size
7. What is the module strength and coupling? of some attribute of the product or process”.
 Measurement is the act of determine a measure
8. What is the reliability at the time of release?
 The metric is a quantitative measure of the degree to which
9. Which test technique is more effective? a system, component, or process possesses a given
attribute.
10. Are we testing hard or are we testing smart?  Fenton defined measurement as “ it is the process by which
numbers or symbols are assigned to attributes of entities in
11. Do we have a strong program or a weak test suite? the real world in such a way as to describe them according
to clearly defined rules”.
Software Engineering UNIT III . 3 Dr. Rabins Porwal Software Engineering UNIT III . 4 Dr. Rabins Porwal
3 4

 Areas of Applications
 Definition The most established area of software metrics is cost and size
estimation techniques.
Software metrics can be defined as “The continuous application of
measurement based techniques to the software development The prediction of quality levels for software, often in terms of
process and its products to supply meaningful and timely reliability, is another area where software metrics have an important
management information, together with the use of those techniques role to play.
to improve that process and its products”.
The use of software metrics to provide quantitative checks on
software design is also a well established area.
5 6
Compiled by Prof. Rabins Porwal 1

Unit III

 Problems During Implementation  Categories of Metrics
 Statement : Software development is too complex; it i. Product metrics: describe the characteristics of the
cannot be managed like other parts of product such as size, complexity, design features,
the organization.
performance, efficiency, reliability, portability, etc.
Management view : Forget it, we will find developers and
managers who will manage that ii. Process metrics: describe the effectiveness and
development. quality of the processes that produce the software
product. Examples are:
 Statement : I am only six months late with project.
• effort required in the process
Management view : Fine, you are only out of a job.
• time to produce the product
 Statement : But you cannot put reliability constraints • effectiveness of defect removal during development
in the contract.
• number of defects found during testing
Management view : Then we may not get the contract. • maturity of the process
7 8

iii. Project metrics: describe the project characteristics
After the finalization of SRS, we would like to
and execution. Examples are :
estimate size, cost and development time of the
• number of software developers project. Also, in many cases, customer may like to
know the cost and development time even prior to
• staffing pattern over the life cycle of the software
finalization of the SRS.
• cost and schedule
• productivity
9 10

Software planning begins before technical work starts, continues as
In order to conduct a successful software project, we the software evolves from concept to reality, and culminates only
must understand: when the software is retired.
 Scope of work to be done Size estimation
 The risk to be incurred

Cost estimation Development time
 The resources required
 The task to be accomplished Resources
requirements
 The cost to be expended
 The schedule to be followed Fig. 1: Activities during Software
Project
Project Planning scheduling
11 12

Unit III

Size Estimation Fig. 2: Function for sorting an array
1. int sort (int x[ ], int n) Furthermore, if the main interest is the size of the program
Lines of Code (LOC) 2. {
3. int i, j, save, im1;
for specific functionality, it may be reasonable to include
If LOC is simply a count of
4.
5.
/*This function sorts array x in ascending order */
if (n<2) return 1;
executable statements. The only executable statements in
the number of lines then 6. for (i=2; i<=n; i++) figure shown above are in lines 5-17 leading to a count of
7. {
program in figure 2 contains 8. im1=i-1; 13. The differences in the counts are 18 to 17 to 13. One
18 LOC. 9. for (j=1; j<=im1; j++)
can easily see the potential for major discrepancies for
10. if (x[i] < x[j])
11. { large programs with many comments or programs written
When comments and blank 12. save = x[i];
lines are ignored, the 13. x[i] = x[j]; in language that allow a large number of descriptive but
14. x[j] = save;
program in figure 2 contains 15. }
non-executable statement.
17 LOC. 16. }
17. return 0;
18. }
13 14

Conte has defined lines of code as: Function Count
“A line of code is any line of program text that is not a Alan Albrecht while working for IBM, recognized the
comment or blank line, regardless of the number of problem in size measurement in the 1970s, and
statements or fragments of statements on the line. This developed a technique (which he called Function Point
specifically includes all lines containing program header, Analysis), which appeared to be a solution to the size
declaration, and executable and non-executable measurement problem.
statements”.
This is the predominant definition for lines of code used
by researchers. By this definition, figure shown above
has 17 LOC.
15 16

The FPA functional units are shown in figure given below:
The principle of Albrecht’s function point analysis (FPA)
User
is that a system is decomposed into functional units.
 Inputs : information entering the system Inquiries

 Outputs : information leaving the system
 Enquiries : requests for instant access to
information Other
applications
 Internal logical files : information held within the Inputs ILF
EIF
system User
Outputs
 External interface files : information held by other system ILF: Internal logical files
that is used by the system being System
analyzed. EIF: External interface files
Fig. 3: FPAs functional units System

17 18

Unit III

The five functional units are divided in two categories: (ii) Transactional function types
 External Input (EI): An EI processes data or control information
(i) Data function types that comes from outside the system. The EI is an elementary
process, which is the smallest unit of activity that is meaningful
 Internal Logical Files (ILF): A user identifiable group of to the end user in the business.
logicallly related data or control information maintained
within the system.  External Output (EO): An EO is an elementary process that
generate data or control information to be sent outside the
 External Interface files (EIF): A user identifiable group of system.
logically related data or control information referenced by
 External Inquiry (EQ): An EQ is an elementary process that is
the system, but maintained within another system. This
made up to an input-output combination that results in data
means that EIF counted for one system, may be an ILF in
retrieval.
another system.
19 20

Special features
 Function point approach is independent of the language,  Function points are directly linked to the statement of
tools, or methodologies used for implementation; i.e. they requirements; any change of requirements can easily
do not take into consideration programming languages, be followed by a re-estimate.
data base management systems, processing hardware or  Function points are based on the system user’s
any other data base technology.
external view of the system, non-technical users of
 Function points can be estimated from requirement the software system have a better understanding of
specification or design specification, thus making it what function points are measuring.
possible to estimate development efforts in early phases of
development.
21 22

Counting function points Table 2: UFP calculation table
The five functional units are ranked according to their complexity, i.e., Functional Count Complexity Functional
Low, Average, or High, using a set of prescriptive standards. Units Complexity Totals Unit Totals
External Low × 3 =
After classifying each of the five function types, the UFPs are calculated Inputs Average × 4 =
(EIs) High × 6 =
using predefined weights for each function type.
External Low × 4 =
Weighting factors Outputs Average × 5 =
Functional Units (EOs) High × 7 =
Low Average High External =
Low × 3
External Inputs (EI) 3 4 6 Inquiries Average × 4 =
(EQs) High × 6 =
External Output (EO) 4 5 7 External Low × 7 =
logical Average × 10 =
External Inquiries (EQ) 3 4 6 Files (ILFs) High × 15 =
External Low × 5 =
Internal logical files (ILF) 7 10 15 Interface Average × 7 =
External Interface files (EIF) 5 7 10 Files (EIFs) High × 10 =
Total Unadjusted Function Point Count
Table 1 : Functional units with weighting factors
23 24

Unit III

The procedure for the calculation of UFP in mathematical
form is given below:
The weighting factors are identified for all
functional units and multiplied with the functional
units accordingly. The procedure for the
calculation of Unadjusted Function Point (UFP) is
given in table shown above. Where i indicate the row and j indicates the column of Table 1
wij : It is the entry of the ith row and jth column of the table 1
Zij : It is the count of the number of functional units of Type i that
have been classified as having the complexity corresponding to
column j.
25 26
Software Metrics
Software Metrics Table 3 : Computing function points
Rate each factor on a scale of 0 to 5.
0 1 2 3 4 5
No Incidental Moderate Average Significant Essential

Influence
Organizations that use function point methods develop a criterion for Number of factors considered ( Fi )
determining whether a particular entry is Low, Average or High. 1. Does the system require reliable backup and recovery ?
Nonetheless, the determination of complexity is somewhat 2. Is data communication required ?
3. Are there distributed processing functions ?
subjective. 4. Is performance critical ?
5. Will the system run in an existing heavily utilized operational environment ?
FP = UFP × CAF 6. Does the system require on line data entry ?
7. Does the on line data entry require the input transaction to be built over multiple screens or operations ?
8. Are the master files updated on line ?
Where CAF is complexity adjustment factor and is equal to [0.65 + 9. Is the inputs, outputs, files, or inquiries complex ?
0.01 x ΣFi]. The Fi (i=1 to 14) are the degree of influence and are 10. Is the internal processing complex ?
based on responses to questions noted in table 3. 11. Is the code designed to be reusable ?
12. Are conversion and installation included in the design ?
13. Is the system designed for multiple installations in different organizations ?
14. Is the application designed to facilitate change and ease of use by the user ?
27 28

Uses of function points:
Functions points may compute the following important metrics: Example: 4.1
Productivity = FP / persons-months
Quality = Defects / FP Consider a project with the following functional units:
Cost = Rupees / FP Number of user inputs = 50
Documentation = Pages of documentation per FP Number of user outputs = 40
These metrics are controversial and are not universally acceptable. Number of user enquiries = 35
There are standards issued by the International Functions Point User Number of user files = 06
Group (IFPUG, covering the Albrecht method) and the United
Number of external interfaces = 04
Kingdom Function Point User Group (UFPGU, covering the MK11
method). An ISO standard for function point method is also being Assume all complexity adjustment factors and weighting factors are
developed. average. Compute the function points for the project.
29 30

Unit III

Solution
We know Example:4.2
An application has the following:
10 low external inputs, 12 high external outputs, 20 low
internal logical files, 15 high external interface files, 12
UFP = 50 × 4 + 40 × 5 + 35 × 4 + 6 × 10 + 4 × 7
average external inquiries, and a value of complexity
= 200 + 200 + 140 + 60 + 28 = 628 adjustment factor of 1.10.
CAF = (0.65 + 0.01 ΣFi)
What are the unadjusted and adjusted function point counts ?
= (0.65 + 0.01 (14 x 3)) = 0.65 + 0.42 = 1.07
FP = UFP × CAF
= 628 × 1.07 = 672
31 32

Example: 4.3
Solution Consider a project with the following parameters.
Unadjusted function point counts may be calculated using (i) External Inputs:
(a) 10 with low complexity
as:
(b)15 with average complexity
(c) 17 with high complexity
(ii) External Outputs:
(a) 6 with low complexity
= 10 × 3 + 12 × 7 + 20 × 7 + 15 + 10 + 12 × 4 (b)13 with high complexity
= 30 + 84 +140 + 150 + 48 (iii) External Inquiries:
= 452 (a) 3 with low complexity
FP = UFP × CAF (b) 4 with average complexity
= 452 × 1.10 = 497.2. (c) 2 high complexity
33 34

(iv) Internal logical files: Solution: Unadjusted function points may be counted using table 2
(a) 2 with average complexity Functional Count Complexity Complexity Functional
Units Totals Unit Totals
(b)1 with high complexity External 10
Low × 3 = 30
Inputs 15 Average × 4 = 60
(v) External Interface files: (EIs)
192
17 High × 6 = 102
(a) 9 with low complexity External 6
Low × 4 = 24
Outputs 0 0 115
In addition to above, system requires (EOs) 13
Average × 5 =
High × 7 = 91
i. Significant data communication External 3
Low × 3 = 9
Inquiries 4 Average × 4 = 16 37
ii. Performance is very critical (EQs) 2 High × 6 = 12
iii. Designed code may be moderately reusable External 0

Low × 7 = 0
logical 2 Average × 10 = 20 35
iv. System is not designed for multiple installation in different Files (ILFs) 1 High × 15 = 15
organizations. External 9
Low × 5 = 45
Interface 0 Average × 7 = 0 45
Other complexity adjustment factors are treated as average. Compute Files (EIFs) 0 High × 10 = 0
the function points for the project. 424
Total Unadjusted Function Point Count
35 36

Unit III

Token Count
3+4+3+5+3+3+3+3+3+3+2+3+0+3=41 A program is considered to be a series of tokens and if we count the
number of tokens, some interested results may emerge.
CAF = (0.65 + 0.01 × ΣFi) In the early 1970s, Professor Halstead and his co-workers at Purdue
= (0.65 + 0.01 × 41) University developed the software science family of measures.
Tokens are classified as either operators and operands. All software
= 1.06 science measures are functions of the counts of these tokens.
FP = UFP × CAF
Generally, any symbol or keyword in a program that specifies an
= 424 × 1.06 algorithmic action is considered an operator, while a symbol used to
represent data is considered an operand. Most punctuation marks
= 449.44 are also categorized as operators.
Hence FP = 449
37 38

The length of the program in the terms of the total number of tokens
The size of the vocabulary of a program, which consists of the used is
number of unique tokens used to build a program is defined as:
N = N1+N2
N : program length
η = η1+ η2 where
N1 : total occurrences of operators
η : vocabulary of a program
where N2 : total occurrences of operands
η1 : number of unique operators
η2 : number of unique operands Note: N is closely related to the LOC measure of program. For
machine language programs where each line consists of one
operator and one operand, the program length is
N = 2 * LOC
39 40

Volume
V = N * log2 η
Program Difficulty
The unit of measurement of volume is the common unit for
size “bits”. It is the actual size of a program if a uniform D=1/L
binary encoding for the vocabulary is used. Since an As the volume of an implementation of a program increases,
algorithm may be implemented by many different but the program level decreases and the difficulty increases.
equivalent programs, a program that is minimal in size is said Thus, programming practices such as redundant usage of
to have the potential volume V*. Any given program with operands, or the failure to use higher-level control constructs
volume V is considered to implement at the program level L, will tend to increase the volume as well as the difficulty.
as defined below.
Program Level Effort
L = V* / V E=V/L=D*V
The value of L ranges between zero and one, with L=1
representing a program written at the highest possible level The unit of measurement of E is elementary mental
(i.e., with minimum size). discriminations.
41 42

Unit III

 Estimated Program Length
The first hypothesis of software science is that the length of a
well-structured program is a function of the number of unique
operators and operands. This function, called the estimated length
equation, is denoted by and is defined by
The following alternate expressions have been published to

estimate program length. The definitions of unique operators, unique operands, total
operators and total operands are not specifically delineated.
43 44

 Counting rules for C language 5. Local variables with the same name in different functions are
counted as unique operands.
1. Comments are not considered.
6. Functions calls are considered as operators.
2. The identifier and function declarations are not considered.
7. All looping statements e.g., do {…} while ( ), while ( ) {…}, for ( )
3. All the variables and constants are considered operands. {…}, all control statements e.g., if ( ) {…}, if ( ) {…} else {…}, etc.
are considered as operators.
4. Global variables used in different modules of the same
program are counted as multiple occurrences of the same 8. In control construct switch ( ) {case:…}, switch as well as all the
variable. case statements are considered as operators.
45 46
13. In the array variables such as “array-name [index]” “array-

9. The reserve words like return, default, continue, break, sizeof, name” and “index” are considered as operands and [ ] is
etc., are considered as operators. considered as operator.
10. All the brackets, commas, and terminators are considered as
operators. 14. In the structure variables such as “struct-name, member-name”
or “struct-name -> member-name”, struct-name, member-name
11. GOTO is counted as an operator and the label is counted as an are taken as operands and ‘.’, ‘->’ are taken as operators. Some
operand. names of member elements in different structure variables are
counted as unique operands.
12. The unary and binary occurrence of “+” and “-” are dealt
separately. Similarly “*” (multiplication operator) are dealt with 15. All the hash directive are ignored.
separately.
47 48

Unit III

 Potential Volume
Many different but equivalent programs may implement an algorithm.
Amongst all these programs, the one that has minimal size is said to  Estimated Program Level / Difficulty
have the potential volume V*. The implementation of this algorithm would
then require nothing more than invoking the procedure and supplying the
Halstead offered an alternate formula that estimate the program
operands for its input and output parameters. It is shown that the potential level
volume of an algorithm implemented as a procedure call could be
expressed as
and difficulty
The first term in the parentheses, 2, represents the two operators for the
procedure call – the procedure name and a grouping symbol that
separates the procedure name from its parameters. The second term
represents the number of conceptually unique input and output
parameters. It can probably be determined for small appln. programs, it is
much more difficult to compute for large programs, such as compiler or
an operating system.
49 50

 Effort and Time
 Language Level
Using this formula, Halstead and other researchers determined the

language level for various languages as shown in Table 1.
β is normally set to 18 since this seemed to give best results in

Halstead’s earliest experiments, which compared the predicted
times with observed programming times, including the time for
design, coding, and testing.
51 52
Example- 6.I
Consider the sorting program in Fig. 2 shown previously. List out the
operators and operands and also calculate the values of software
science measures like
Table 1: Language levels
53 54

Unit III

Solution
The list of operators and operands is given in table 2.
Table 2: Operators and operands of sorting program of fig. 2
55 56

Here N1=53 and N2=38. The program length N = N1+N2=91 Conceptually unique input and output parameters are
Vocabulary of the program represented by
Volume {x: array holding the integer to be sorted. This is used

both as input and output}.
= 91 x log224 = 417 bits {n: the size of the array to be sorted}.
The estimated program length of the program
The potential volume V* = 5 log25 = 11.6
= 14 log214 + 10 log210
Since L = V* / V
= 14 * 3.81 + 10 * 3.32
= 53.34 + 33.2 = 86.45
57 58

We may use another formula
D=1/L
=417 / 0.038 = 10973.68
Therefore, 10974 elementary mental discrimination are

Estimated program level required to construct the program.
This is probably a reasonable time to produce the program,

which is very simple.
59 60

Unit III
Example- 6.2
Consider the program shown in Table 3. Calculate the various

software science metrics.
Table 3
61 62

Solution
List of operators and operands are given in Table 4.
Table 4
Table 3
63 64

Program vocabulary
Program length N = N1 +N2

= 84 + 55 = 139
Estimated length
% error = 24.91
Program volume V = 749.605 bits
Estimated program level
Table 4
65 66

Unit III
Software Metrics
Minimal volume V* = 20.4417
Effort
= 27488.33 elementary mental discriminations
Time T =
= 1527.1295 seconds
= 25.452 minutes
Software Engineering UNIT III . 67 Dr. Rabins Porwal
67

UNIT - 3 - Software Metrics-Rabins at CSJMU - 6 Slides Handouts

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

UNIT - 3 - Software Metrics-Rabins at CSJMU - 6 Slides Handouts

Uploaded by

Copyright:

Available Formats

Unit III

Software Metrics: What and Why ?

Software Metrics 2. How much will it cost to develop a software?

3. How many bugs can we expect?

4. When can we stop testing?

5. When can we release the software?

1 Software Engineering UNIT III . 2 Dr. Rabins Porwal

Software Metrics Software Metrics

 Pressman explained as “A measure provides a quantitative

Software Metrics Software Metrics

Compiled by Prof. Rabins Porwal 1

Software Metrics Software Metrics

Software Metrics Software Metrics

Software Metrics Software Metrics

 Scope of work to be done Size estimation

 The risk to be incurred

Compiled by Prof. Rabins Porwal 2

Software Metrics Software Metrics

Software Metrics Software Metrics

Software Metrics Software Metrics

 Inputs : information entering the system Inquiries

Fig. 3: FPAs functional units System

Compiled by Prof. Rabins Porwal 3

Software Metrics Software Metrics

Software Metrics Software Metrics

Software Metrics Software Metrics

Compiled by Prof. Rabins Porwal 4

Software Metrics Software Metrics

No Incidental Moderate Average Significant Essential

Software Metrics Software Metrics

Compiled by Prof. Rabins Porwal 5

Software Metrics Software Metrics

Software Metrics Software Metrics

Software Metrics Software Metrics

iii. Designed code may be moderately reusable External 0

Compiled by Prof. Rabins Porwal 6

Software Metrics Software Metrics

Software Metrics Software Metrics

Software Metrics Software Metrics

Compiled by Prof. Rabins Porwal 7

Software Metrics Software Metrics

The following alternate expressions have been published to

Software Metrics Software Metrics

Software Metrics Software Metrics

13. In the array variables such as “array-name [index]” “array-

Compiled by Prof. Rabins Porwal 8

Software Metrics Software Metrics

Software Metrics Software Metrics

Using this formula, Halstead and other researchers determined the

β is normally set to 18 since this seemed to give best results in

Software Metrics Software Metrics

Table 1: Language levels

Compiled by Prof. Rabins Porwal 9

Software Metrics Software Metrics

Table 2: Operators and operands of sorting program of fig. 2

Software Metrics Software Metrics

Volume {x: array holding the integer to be sorted. This is used

Software Metrics Software Metrics

=417 / 0.038 = 10973.68

Therefore, 10974 elementary mental discrimination are

This is probably a reasonable time to produce the program,

Compiled by Prof. Rabins Porwal 10

Software Metrics Software Metrics