SE UNIT-3.pdf

Software Engineering (KCS-601)
Unit-3: Software Design
Dr. Radhey Shyam
Professor
Department of Computer Science and Engineering
SRMCEM Lucknow
(Affiliated to Dr. A.P.J. Abdul Kalam Technical University, Lucknow)
Unit-3 have been compiled/prepared by Dr. Radhey Shyam, with grateful acknowledgment who made their
course contents freely available or (Contributed directly or indirectly). Feel free to use this study material
for your own academic purposes. For any query, the communication can be made through this mail
shyam0058@gmail.com.
April 7, 2022

SoftwareDesign
2
More creative than analysis
Problem solving activity
‘HOW’
Software design document (SDD)
The goal of the design process is to product a model or
representation of a system, which can be used later to build that
system.
Whydesignisimportant?
3
A good design is the key to successful product. Few desirable
characteristics that every good software design must possess
are:
1. Correctness
2. Understandability
3. Efficiency
4. Maintainability
Without well-design system, we risk building an unstable
system.
• One that will fail when small changes are made.
• One that will be difficult to maintain.

GooddesignvsBadDesign
4
Characteristics Good design Bad design
Change Change in one part of
the system does not
always require a
change in another part
of the system.
One change
requires changes to
many parts of the
system.
Cost Small High
Nature Simple Complex
Extension System can be
extended with changes
in only one place
System cannot be
extended easily.
Objectivesof Design
5
It deals with transforming the customer requirements as
described in the SRS document into a form that is
implementable using a programming language. The
design needs to be :
 CorrectandComplete
 Understandable
Attherightlevel
 Maintainable

Software Design
6
DesignFramework
7

SoftwareDesign
8
SoftwareDesign
9
Conceptual Design and Technical Design

SoftwareDesign
1
0
Conceptual design answers :
 Wherewillthedatacomefrom?
 Whatwillhappentothedatainthesystem?
 Howwillthesystemlooktousers?
 Whatchoiceswillbeofferedtousers?
 Whatisthetimingofevents?
 Howwillthereportsandscreenslooklike?
SoftwareDesign
1
1
Technical design describes :-
 Hardwareconfiguration
Softwareneeds
CommunicationInterfaces
 I/Oofthesystem
 SoftwareArchitecture
 NetworkArchitecture
Any other thing that translates the requirements into a solution to the
customer’s problem.

HLDandLLD
1
2
High Level Design Low Level Design
Also known as macro level/
system design
Also known as micro level/
detailed design
Overall architecture of the
application
Detailed description of the each
and every module
participants are design team,
review team and client
participants are only design team
input criteria is Software
Requirement Specification(SRS)
input criteria is HLD, which are
reviewed and authorized
Output criteria is database design,
functional design and review
record
Output criteria is Program
specification and unit test plan
LOWLEVELDESIGN
1
3
MODULARIZATION
A system is considered modular, if it consists of discrete components
so that each component can be implemented separately and a
change to one component has minimal impact on other components.

AdvantagesofModularSystems
1
4
• Modular systems are easier to understand and explain because their
parts are functionally independent.
• Modular systems are easier to document because each part can be
documented as an independent unit.
• Programming individual modules is easier because the programmer
can focus on just one small, simple problem rather than a large complex
problem.
• Testing and debugging individual modules is easier because they
can be dealt with in isolation from the rest of the program.
• Bugs are easier to isolate and understand and they can be fixed
without fear of introducing problems outside the module.
DESIGNMODEL
1
5
After analyzing and specifying all the requirements, the process of
software design begins. Each of the elements of analysis model is
used to create the design model. The elements of design model are:-
1. Data Design (ER Diagram + Data Dictionary)
2. Architectural Design (DFD)
3. Interface Design (DFD + Control flow diagrams)
4. Component-level Design (Process + Control specification)

SOFTWARE DESIGN
16
Software design is a creative process, just like designing anything else
To see a wrong design, we can check with the requirements in the
analysis model
To see a bad design, we need to assess the design model and analyze the
components, whether the performance can be improved by changing the
modules or the interfaces
In analyzing the software Design, many factors are used, out of which
two important factors are –
Coupling
Cohesion
COUPLING
17
Coupling is the measure of “the degree of
interdependence between modules".
We aim to minimize coupling – to make modules as
independent as possible.
Low coupling can be achieve by:
eliminating unnecessary relationships
reducing the number of necessary relationships

COUPLING
(Uncoupled : no dependencies)
(a)
18
Uncoupled modules have no interconnections at all,
they are completely independent.
Loosely coupled:
some dependencies
(B)
Highly coupled:
many dependencies
(C)
Fig. : Module coupling
19

Consider the example of editing a student record in a
‘student information system’.
Edit student
record
Retrieve
student record
Student name,
student ID,
address,
course
Student
record
Edit student
record
Retrieve
student record
Student
record
20
Student
ID
Poor design: Tight Coupling Good design: Loose Coupling
Fig. : Example of coupling
Given two procedures A & B, we can identify number of
ways in which they can be coupled.
Fig : The types of module coupling
21
Data coupling Best (Most required)
Stamp coupling
Control coupling
External coupling
Common coupling
Content coupling Worst (Least required)

Data coupling
22
Stamp coupling
Stamp coupling occurs between module A and B when
complete data structure is passed from one module to another.
The dependency between module A and B is said to be data
coupled if their dependency is based on the fact they
than
are
communicate
communicating
independent.
by only
through
passing
data,
of data.
the two
Other
modules
Control coupling
23
Module A and B are said to be control coupled if they
communicate by passing of control information. This is usually
accomplished by means of flags that are set by one module and
reacted upon by the dependent module.
External coupling
A form of a coupling in which a module has a dependency to other
module, external to the software being developed or to a particular
type of hardware. This is basically related to the communication to
external tools and devices such as the operating system, shared
libraries or the hardware .
Common coupling
With common coupling, module A and module B have shared data.
Global data areas are commonly found in programming languages.
Making a change to the common data means tracing back to all the
modules which access that data to evaluate the effect of changes.

Fig : Example of common coupling
24
Content coupling
25
Content coupling occurs when module A changes data of
module B or when control is passed from one module to the
middle of another.

Impact of Coupling on Design
26
A good design process should aim at reducing coupling.
Reduction of coupling -> reduction of dependence of one
module on another -> increase the independence of module ->
increase the ability to change or maintain the modules.
COHESION
27
Cohesion measures how a single module is related to a particular
functionality in the system.
– only one module is involved
– ideally, a highly cohesive module should do only one task/
activity/function
– example:
• a sorting module that contains only one sorting function and this
function sorts integers only.
• a sorting module that contains several sorting functions that implement
various sorting techniques but all sort integers only.
• a sorting module that contains several sorting functions that implement
various sorting techniques but sort integers and floats.

Cohesion is a measure of the degree to
elements of a module are functionally related.
which the
COHESION
Fig : Cohesion=Strength of relations within modules
28
Module
strength
Types of cohesion
29
➢ Functional cohesion
➢ Sequential cohesion
➢ Procedural cohesion
➢ Temporal cohesion
➢ Logical cohesion
➢ Coincident cohesion

Fig : Types of module cohesion
30
Functional Cohesion Best (high)
Sequential Cohesion
Communicational Cohesion
Procedural Cohesion
Temporal Cohesion
Logical Cohesion
Coincidental Cohesion Worst (low)
Given a procedure that carries out operations A & B, we can
describe various forms of cohesion between A & B.
Functional Cohesion
31
➢. This is very good reason for them to be contained in the same
procedure.
➢ All elements contribute to the execution of one and only one
problem-related task
➢ Examples of functional cohesive modules:
• Compute cosine of angle
• Read transaction record
• Assign seat to airline passenger
➢A and B are part of a single functional task

Sequential Cohesion
32
➢Module A outputs some data which forms the input to B. This
is the reason for them to be contained in the same procedure.
➢ Elements are involved in activities such that output data from one
activity becomes input data to the next
➢Usually has good coupling and is easily maintained
Communicational Cohesion
33
➢ A and B both operate on the same input data or contribute
toward the same output data .
 Not flexible, for example, if we need to focus on some activities
and not the others
Example of Communicational Cohesion
- module determine customer details
use customer account no
find customer name
find customer loan balance
return customer name, loan balance
end module

34
Procedural Cohesion
 Procedural cohesion occurs in modules whose instructions
accomplish different tasks yet have been combined
because there is a specific order in which the tasks are to be
completed.
 Example: an input function receiving a data, a function that
processes the data, and a function that outputs the result of that
computation, all placed in the same module
 Example: report module of an examination system includes
the following –
 calculate student GPA
 print student record
 calculate cumulative GPA
 print cumulative GPA
35
 Module exhibits temporal cohesion when it contains tasks that
are related by the fact that all tasks must be executed in the
same time-span.
 functions that are related by time, all placed in the same
module
 example: the alarm system, automatic telephone dialing unit of a
security system both placed in the same module; these two must
be activated at the same time
 moderate level of cohesion
Temporal Cohesion

36
Logical Cohesion
➢ Logical cohesion occurs in modules that contain
instructions that appear to be related because they fall into
the same category.
- module display record
if record-type is student then
display student record
else if record-type is staff then
display staff record
end module
➢ functions that are logically related to each other, all placed
in the same module
- example: a set of functions that output a given data in various
formats (bar chart, graph, pie-chart, …)
➢ moderate level of cohesion
37
➢Coincidental cohesion exists in modules that
contain instructions that have little or no relationship to one
another.
➢ functions that are not at all related to each other but are placed
in a single module (happen to be a coincidence)
- example: a function that performs sorting and a printer driver,
both in the same module
➢ functions that are somewhat related but do not have much in
common also fall in this category.
- example: a function that computes an average of a sequence
and a function that sorts a sequence, both being placed in the
same module
 low-level cohesion
Coincidental Cohesion

Examples of Cohesion
Function A
Function
B
Function
D
Function
C
Function
E
Coincidental
Parts unrelated
Function A
Function A’
Function A’’
logic
Logical
Similar functions
Time t0
Time t0 + X
Time t0 + 2X
Temporal
Related by time
Function A
Function B
Function C
Procedural
Related by order of functions
Examples of Cohesion
Function A part 1
Function A part 2
Function A part 3
Functional
Sequential with complete, related functions
Function A
Function B
Function C
Communicational
Access same data
Function A
Function B
Function C
Sequential
Output of one is input to another

Impact of Cohesion on Design
40
A good design process should try to maximize cohesion
of each module
maximizing cohesion -> maximizing the use of the module
towards particular functionality -> appropriate modularization of
the design
Relationship between Cohesion & Coupling
Fig : View of cohesion and coupling
If the software is not properly modularized, a host of
seemingly trivial enhancement or changes will result into death of
the project. Therefore, a software engineer must design the modules
with goal of high cohesion and low coupling.
41

Evaluating Coupling and Cohesion
42
• Coupling can be evaluated using metrics tools.
- metrics will be discussed later.
• Cohesion is generally evaluated manually by experts /
software engineers.
– walk through the design documents and iterate the design
until cohesion is improved to a satisfactory level .
HIGHLEVELDESIGN
4
3
ARCHITECTURAL DESIGN
The HLD, also called architectural design.
Large systems are always decomposed into subsystems that provide some
related set of services. The initial design process of identifying these sub-
systems and establishing a framework for sub-system control and
communication is called architectural design.
Architectural design methods look into various alternate architectural style
of designing a system. These are:
• Data centric architecture
• Data flow architecture
• Object oriented architecture
• Layered architecture

ARCHITECTURALDESIGN
4
4
Data centric architecture approach involves the use of a central
database operations of inserting, updating it in the form of a table.
Data flow architecture is applied when input data takes the form of
output after passing through various phases of transformations.
These transformations can be through various computations done on
data.
In Object oriented architecture, the software design moves around
the classes and objects of the system. The class encapsulates the
data and methods.
Layered approach defines the number of layers and each layer
performs tasks. The outermost layer handles the functionality of user
interface and the innermost layer handles interaction with the
hardware.
ObjectiveofArchitecturalDesign
4
5
• To develop a model of software architecture, this gives overall
organization of program module in the software product.
• To control relationship between modules. One module may
control another module or may be controlled by another
module.
• The organization of module can be represented through a
tree like structure.
•In addition, HLD possess some attributes such as height,
depth, width and module fan-in, fan-out.

Attributes
4
6
The height or depth of the design hierarchy is the number of
modules along the longest path from the top-level module
down to the lowest module in the hierarchy.
The width of the design hierarchy is the largest number of
modules existing at a given level of the hierarchy.
The no. of components which controls a said component is
called fan-in i.e, the no of incoming edges to a component.
The no. of components that are controlled by a module is
called fan-out i.e, the no of outgoing edges.
STRATEGY OF DESIGN
47
A good system design strategy is to organize the program modules in
such a way that are easy to develop and latter to, change.
Structured design techniques help developers to deal with the size
and complexity of programs. Analysts create instructions for the
developers about how code should be written and how pieces of
code should fit together to form a program. It is important for two
reasons:
➢ First, even pre-existing code, if any, needs to be understood,
organized and pieced together.
➢ Second, it is still common for the project team to have to write
some code and produce original programs that support the
application logic of the system.

Bottom-Up Design
Fig : Bottom-up tree structure
These modules are collected together in the form of a
“library”.
48
Top-Down Design
• A top down design approach starts by
identifying the major modules of the system,
decomposing them into their lower level
modules and iterating until the desired level of
detail is achieved. This is stepwise refinement;
starting from an abstract design, in each step
the design is refined to a more concrete level,
until we reach a level where no more
refinement is needed and the design can be
implemented directly. 49

Hybrid Design
For top-down approach to be effective, some bottom-up approach
is essential for the following reasons:
➢ To permit common sub modules.
➢ Near the bottom of the hierarchy, where the intuition is simpler,
and the need for bottom-up testing is greater, because there are
more number of modules at low levels than high levels.
➢ In the use of pre-written library modules, in particular, reuse of
modules.
50
Structure Chart
It partition a system into block boxes. A black box means
that functionality is known to the user without the knowledge of
internal design.
Fig : Hierarchical format of a structure chart 51

Fig. 17 : Structure chart notations
52
Fig : Update file
A structure chart for “update file” is given in fig.
53

Fig: Transaction-centered structure
A transaction centered structure describes a system that processes a
number of different types of transactions. It is illustrated in Fig.
54
In the above figure the MAIN module controls the system operation its
functions is to:
55
➢ invoke the INPUT module to read a transaction;
➢ determine the kind of transaction and select one of a number
of transaction modules to process that transaction, and
➢ output the results of the processing by calling OUTPUT
module.

Pseudocode
• Pseudocode notation can be used in both the
preliminary and detailed design phases.
• Using pseudocode, the designer describes
system characteristics using short, concise,
English language phrases that are structured by
key words such as If-Then-Else, While-Do, and
End.
56

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.
Halstead metrics are:
Program Volume (V)
The unit of measurement of volume is the standard unit for size "bits." It is the actual size of
a program if a uniform binary encoding for the vocabulary is used.
V=N*log2n
Program Level (L)
The value of L ranges between zero and one, with L=1 representing a program written at the
highest possible level (i.e., with minimum size).
L=V*/V
Program Difficulty
The difficulty level or error-proneness (D) of the program is proportional to the number of
the unique operator in the program.
D= (n1/2) * (N2/n2)
Programming Effort (E)
The unit of measurement of E is elementary mental discriminations.
E=V/L=D*V
Estimated Program Length
According to Halstead, The first Hypothesis of software science is that the length of a well-
structured program is a function only of the number of unique operators and operands.
N=N1+N2
And estimated program length is denoted by N^
N^ = n1log2n1 + n2log2n2
The following alternate expressions have been published to estimate program length:
NJ = log2 (n1!) + log2 (n2!)
NB = n1 * log2n2 + n2 * log2n1

NC = n1 * sqrt(n1) + n2 * sqrt(n2)
NS = (n * log2n) / 2
Potential Minimum Volume
The potential minimum volume V* is defined as the volume of the most short program in
which a problem can be coded.
V* = (2 + n2*) * log2 (2 + n2*)
Here, n2* is the count of unique input and output parameters
Size of Vocabulary (n)
The size of the vocabulary of a program, which consists of the number of unique tokens used
to build a program, is defined as:
n=n1+n2
Where
n=vocabulary of a program
n1=number of unique operators
n2=number of unique operands
Halstead's Complexity Measures
Howard Halstead introduced metrics to measure software complexity. Halstead’s metrics
depends upon the actual implementation of program and its measures, which are computed
directly from the operators and operands from source code, in static manner. It allows to
evaluate testing time, vocabulary, size, difficulty, errors, and efforts for C/C++/Java source
code.
According to Halstead, “A computer program is an implementation of an algorithm
considered to be a collection of tokens which can be classified as either operators or
operands”. Halstead metrics think a program as sequence of operators and their associated
operands.
He defines various indicators to check complexity of module.
Parameter Meaning
n1 Number of unique operators
n2 Number of unique operands
N1 Number of total occurrence of operators

N2 Number of total occurrence of operands
When we select source file to view its complexity details in Metric Viewer, the following
result is seen in Metric Report:
Metric Meaning Mathematical Representation
n Vocabulary n1 + n2
N Size N1 + N2
V Volume Length * Log2 Vocabulary
D Difficulty (n1/2) * (N1/n2)
E Efforts Difficulty * Volume
B Errors Volume / 3000
T Testing time Time = Efforts / S, where S=18 seconds.
Cyclomatic Complexity Measures
Every program encompasses statements to execute in order to perform some task and other
decision-making statements that decide, what statements need to be executed. These
decision-making constructs change the flow of the program.
If we compare two programs of same size, the one with more decision-making statements
will be more complex as the control of program jumps frequently.
McCabe, in 1976, proposed Cyclomatic Complexity Measure to quantify complexity of given
software. It is graph driven model that is based on decision-making constructs of program
such as if-else, do-while, repeat-until, switch-case and go to statements.
Process to make flow control graph:
 Break program in smaller blocks, delimited by decision-making constructs.
 Create nodes representing each of these nodes.
 Connect nodes as follows:
 If control can branch from block i to block j
 Draw an arc
 From exit node to entry node
 Draw an arc.
To calculate Cyclomatic complexity of a program module, we use the formula -
V (G) = e – n + 2

Where
e is total number of edges
n is total number of nodes
The Cyclomatic complexity of the above module is
e = 10
n = 8
Cyclomatic Complexity = 10 - 8 + 2
= 4
According to P. Jorgensen, Cyclomatic Complexity of a module should not exceed 10.

Halstead’s uses certain measures such as program length, program vocabulary, volume,
difficulty, and effort for the given algorithm. By this Halstead’s is trying to show that the
program length can be calculated, volume of algorithm can be estimated. The above given table
shows how actually these measure can be obtained.
The Halstead’s measures are applicable to operational system and to development efforts once
the code has been written. Thus using Halstead’s measurement experimental verification can be
performed in software science.
Program length:
The length of a program is total usage of operators and operands in the program.
Length (N) = N1 + N2
Program vocabulary:
The Program vocabulary is the number of unique operators and operands used in the program.
Vocabulary (n) = n1 + n2
Program Volume:
The Program Volume can be defined as minimum number of bits needed to encode the program.
Volume (V) = N log2 n
Length estimation:
N = n1 log2 n1 + n2 log2 n2
Guideline for calculating operands and operators:
1. All the variables and constants are considered as operands.
2. Local variables with same name, if occurring in different functions are counted as unique
operand.
3. Function calls are considered as operators.

4. The looping statements, do … while, while, for, are operators. The statements if, if …
else, are operators. The switch … case statements are considered as operators.
5. The reserve worlds, returns, default, continue, break, sizeof are all operators.
6. The brackets, commas, semicolons, are operators.
7. The unary and binary operators are considered as operators. The & is considered as
operator.
8. In arrays, array name and index are considered as operands and [ ] is considered as
operator.
9. All hash directives can be ignored.
10. Comments are not considered.
11. In Goto statement, goto is considered as operator and label as operand.
Example: Obtain Halstead’s length and volume measure for following C function.
Void swap (int a[ ], int i)
{
int temp;
Temp = a[i];
a[i] = a[i+1];
a[i+1] = temp;
}
We first find out the operands and operators from above function along with their occurrences.
Operands Occurrences Operators Occurrences
swap 1 ( ) 1
a 5 { } 1
i 5 void 1
temp 3 int 3
1 2 [ ] 5

, 1
; 4
= 3
+ 2
n1 = 5 N1 = 16 n2 = 9 N2 = 21
N = N1 + N2
= 16 +21 = 37
N = 37
n = n1 + n2
= 5 + 9 = 14
n = 14
Estimated length = n1 log n1 + n2 log n2
= 5 log 5 + 9 log 9
= 5 * 2.32 + 9 * 2.19 = 31.37
Estimated length = 31.37
Volume = N * log n
= 37 * log (14)
37 * 2.63 = 97.64
Volume (V) = 97.64

Software Metrics
Software Engineering
Definitions
• Measure - quantitative indication of extent,
amount, dimension, capacity, or size of some
attribute of a product or process.
– Number of errors
• Metric - quantitative measure of degree to which
a system, component or process possesses a
given attribute. “A handle or guess about a
given attribute.”
– Number of errors found per person hours expended
Why Measure Software?
• Determine quality of the current product or
process
• Predict qualities of a product/process
• Improve quality of a product/process
Example Metrics
• Defects rates
• Errors rates
• Measured by:
– individual
– module
– during development
• Errors should be categorized by origin,
type, cost

Metric Classification
• Products
– Explicit results of software development
activities.
– Deliverables, documentation, by products
• Processes
– Activities related to production of software
• Resources
– Inputs into the software development activities
– hardware, knowledge, people
Product vs. Process
• Process Metrics-
– Insights of process paradigm, software engineering
tasks, work product, or milestones.
– Lead to long term process improvement.
• Product Metrics-
– Assesses the state of the project
– Track potential risks
– Uncover problem areas
– Adjust workflow or tasks
– Evaluate teams ability to control quality
Types of Measures
• Direct Measures (internal attributes)
– Cost, effort, LOC, speed, memory
• Indirect Measures (external attributes)
– Functionality, quality, complexity, efficiency,
reliability, maintainability
Size Oriented Metrics
• Size of the software produced
• Lines Of Code (LOC)
• 1000 Lines Of Code KLOC
• Effort measured in person months
• Errors/KLOC
• Defects/KLOC
• Cost/LOC
• Documentation Pages/KLOC
• LOC is programmer & language dependent

LOC Metrics
• Easy to use
• Easy to compute
• Can compute LOC of existing systems but
cost and requirements traceability may be
lost
• Language & programmer dependent
Function Oriented Metrics
• Function Point Analysis [Albrecht ’79, ’83]
• International Function Point Users Group
(IFPUG)
• Indirect measure
• Derived using empirical relationships
based on countable (direct) measures of
the software system (domain and
requirements)
Computing Functions Points
• Number of user inputs
– Distinct input from user
• Number of user outputs
– Reports, screens, error messages, etc
• Number of user inquiries
– On line input that generates some result
• Number of files
– Logical file (database)
• Number of external interfaces
– Data files/connections as interface to other systems
Compute Function Points
• FP = Total Count * [0.65 + .01*Sum(Fi)]
• Total count is all the counts times a
weighting factor that is determined for
each organization via empirical data
• Fi (i=1 to 14) are complexity adjustment
values

Complexity Adjustment
• Does the system require reliable backup and
recovery?
• Are data communications required?
• Are there distributed processing functions?
• Is performance critical?
• Will the system run in an existing heavily utilized
operational environment?
• Does the system require on-line data entry?
• Does the online data entry require the input
transaction to be built over multiple screens or
operations?
Complexity Adjustment (cont)
• Are the master files updated on line?
• Are the inputs, outputs, files, or inquiries
complex?
• Is the internal processing complex?
• Is the code designed to be reusable?
• Are conversions and installations included in the
design?
• Is the system designed for multiple installations
in different organizations?
• Is the application designed to facilitate change
and ease of use by the user?
Using FP
• Errors per FP
• Defects per FP
• Cost per FP
• Pages of documentation per FP
• FP per person month
FP and Languages
Language
Assembly
C
COBOL
FORTRAN
Pascal
C++
Ada
VB
SQL
LOC/FP
320
128
106
106
90
64
53
32
12

Using FP
• FP and LOC based metrics have been found to
be relatively accurate predictors of effort and
cost
• Need a baseline of historical information to use
them properly
• Language dependent
• Productivity factors: People, problem, process,
product, and resources
• FP can not be reverse engineered from existing
systems easily
Complexity Metrics
• LOC - a function of complexity
• Language and programmer dependent
• Halstead’s Software Science (entropy
measures)
– n1 - number of distinct operators
– n2 - number of distinct operands
– N1 - total number of operators
– N2 - total number of operands
Example
if (k < 2)
{
if (k > 3)
x = x*k;
}
• Distinct operators: if ( ) { } > < = * ;
• Distinct operands: k 2 3 x
• n1 = 10
• n2 = 4
• N1 = 13
• N2 = 7
Halstead’s Metrics
• Amenable to experimental verification [1970s]
• Length: N = N1 + N2
• Vocabulary: n = n1 + n2
• Estimated length: = n1 log2 n1 + n2 log2 n2
– Close estimate of length for well structured programs
• Purity ratio: PR = /N
N̂
N̂

Program Complexity
• Volume: V = N log2 n
– Number of bits to provide a unique designator for each of the n
items in the program vocabulary.
• Program effort: E=V/L
– L = V*/V
– V* is the volume of most compact design implementation
– This is a good measure of program understandability
McCabe’s Complexity Measures
• McCabe’s metrics are based on a control
flow representation of the program.
• A program graph is used to depict control
flow.
• Nodes represent processing tasks (one or
more code statements)
• Edges represent control flow between
nodes
Flow Graph Notation
Sequence
If-then-else
While
Until
Cyclomatic Complexity
• Set of independent paths through the
graph (basis set)
• V(G) = E – N + 2
– E is the number of flow graph edges
– N is the number of nodes
• V(G) = P + 1
– P is the number of predicate nodes

Example
i = 0;
while (i<n-1) do
j = i + 1;
while (j<n) do
if A[i]<A[j] then
swap(A[i], A[j]);
end do;
i=i+1;
end do;
Flow Graph
1
3
5
4
6
7
2
Computing V(G)
• V(G) = 9 – 7 + 2 = 4
• V(G) = 3 + 1 = 4
• Basis Set
– 1, 7
– 1, 2, 6, 1, 7
– 1, 2, 3, 4, 5, 2, 6, 1, 7
– 1, 2, 3, 5, 2, 6, 1, 7
Another Example
1
6
7
4
5
8
3
9
2
What is V(G)?

Meaning
• V(G) is the number of (enclosed)
regions/areas of the planar graph
• Number of regions increases with the
number of decision paths and loops.
• A quantitative measure of testing difficulty
and an indication of ultimate reliability
• Experimental data shows value of V(G)
should be no more then 10. Testing is
very difficulty above this value.
McClure’s Complexity Metric
• Complexity = C + V
– C is the number of comparisons in a module
– V is the number of control variables
referenced in the module
• Similar to McCabe’s but with regard to
control variables.
Metrics and Software Quality
FURPS
• Functionality - features of system
• Usability – aesthesis, documentation
• Reliability – frequency of failure, security
• Performance – speed, throughput
• Supportability – maintainability
Measures of Software Quality
• Correctness
– Defects/KLOC
– Defect is a verified lack of conformance to requirements
– Failures/hours of operation
• Maintainability
– Mean time to change
– Change request to new version (Analyze, design etc)
– Cost to correct
• Integrity
– Fault tolerance, security & threats
• Usability
– Training time, skill level necessary to use, Increase in
productivity, subjective questionnaire or controlled experiment

Quality Model
product
operation revision transition
reliability efficiency usability maintainability testability portability reusability
Metrics
High level Design Metrics
• Structural Complexity
• Data Complexity
• System Complexity
• Card & Glass ’80
• Structural Complexity S(i) of a module i.
– S(i) = fout
2(i)
– Fan out is the number of modules immediately
subordinate (directly invoked).
Design Metrics
• Data Complexity D(i)
– D(i) = v(i)/[fout(i)+1]
– v(i) is the number of inputs and outputs
passed to and from i.
• System Complexity C(i)
– C(i) = S(i) + D(i)
– As each increases the overall complexity of
the architecture increases.
System Complexity Metric
• Another metric:
– length(i) * [fin(i) + fout(i)]2
– Length is LOC
– Fan in is the number of modules that invoke i.
• Graph based:
– Nodes + edges
– Modules + lines of control
– Depth of tree, arc to node ratio

1
Coupling
• Data and control flow
– di – input data parameters
– ci input control parameters
– do output data parameters
– co output control parameters
• Global
– gd global variables for data
– gc global variables for control
• Environmental
– w fan in number of modules called
– r fan out number modules that call module
Metrics for Coupling
• Mc = k/m, k=1
– m = di + aci + do + bco + gd + cgc + w + r
– a, b, c, k can be adjusted based on actual
data
Component Level Metrics
• Cohesion (internal interaction)
• Coupling (external interaction)
• Complexity of program flow
• Cohesion – difficult to measure
– Bieman ’94, TSE 20(8)
– Data slice – from a program slice
Using Metrics
• The Process
– Select appropriate metrics for problem
– Utilized metrics on problem
– Assessment and feedback
• Formulate
• Collect
• Analysis
• Interpretation
• Feedback

1
Metrics for the Object Oriented
• Chidamber & Kemerer ’94 TSE 20(6)
• Metrics specifically designed to address
object oriented software
• Class oriented metrics
• Direct measures
Weighted Methods per Class
WMC =
• ci is the complexity (e.g., volume,
cyclomatic complexity, etc.) of each
method
• Must normalize
• What about inherited methods?
– Be consistent
∑
=
n
i
i
c
1
Depth of Inheritance Tree
• DIT is the maximum length from a node to
the root (base class)
• Lower level subclasses inherit a number of
methods making behavior harder to
predict
• However, more methods are reused in
higher DIT trees.
Number of Children
• NOC is the number of subclasses
immediately subordinate to a class
• As NOC grows, reuse increases
• But the abstraction may be diluted

1
Coupling between Classes
• CBO is the number of collaborations
between two classes
• As collaboration increases reuse
decreases
• CRC – lists the number of collaborations
– Classes, Responsibilities, and Collaborations
Response for a Class
• RFC is the number of methods that could
be called in response to a message to a
class
• Testing effort increases as RFC increases
Lack of Cohesion in Methods
• LCOM – poorly described in Pressman
• Class Ck with n methods M1,…Mn
• Ij is the set of instance variables used by
Mj
LCOM
• There are n such sets I1 ,…, In
– P = {(Ii, Ij) | (Ii ∩ Ij ) = ∅}
– Q = {(Ii, Ij) | (Ii ∩ Ij ) ≠ ∅}
• If all n sets Ii are ∅ then P = ∅
• LCOM = |P| - |Q|, if |P| > |Q|
• LCOM = 0 otherwise

1
Example LCOM
• Take class C with M1, M2, M3
• I1 = {a, b, c, d, e}
• I2 = {a, b, e}
• I3 = {x, y, z}
• P = {(I1, I3), (I2, I3)}
• Q = {(I1, I2)}
• Thus LCOM = 1
Explanation
• LCOM is the number of empty
intersections minus the number of non-
empty intersections
• This is a notion of degree of similarity of
methods.
• If two methods use common instance
variables then they are similar
• LCOM of zero is not maximally cohesive
• |P| = |Q| or |P| < |Q|
Class Size
• CS
– Total number of operations (inherited, private,
public)
– Number of attributes (inherited, private,
public)
• May be an indication of too much
responsibility for a class
Number of Operations Overridden
• NOO
• A large number for NOO indicates
possible problems with the design
• Poor abstraction in inheritance hierarchy

1
Number of Operations Added
• NOA
• The number of operations added by a
subclass
• As operations are added it is farther away
from super class
• As depth increases NOA should decrease
Specialization Index
SI = [NOO * L] / Mtotal
• L is the level in class hierarchy
• Mtotal is the total number of methods
• Higher values indicate class in hierarchy
that does not conform to the abstraction
Method Inheritance Factor
MIF = .
• Mi(Ci) is the number of methods inherited
and not overridden in Ci
• Ma(Ci) is the number of methods that can
be invoked with Ci
• Md(Ci) is the number of methods declared
in Ci
∑
∑
=
=
n
i
i
a
n
i
i
i
C
M
C
M
1
1
)
(
)
(
MIF
• Ma(Ci) = Md(Ci) + Mi(Ci)
• All that can be invoked = new or
overloaded + things inherited
• MIF is [0,1]
• MIF near 1 means little specialization
• MIF near 0 means large change

1
Coupling Factor
CF= .
• is_client(x,y) = 1 iff a relationship exists between
the client class and the server class. 0
otherwise.
• (TC2-TC) is the total number of relationships
possible (Total Classes2 – diagonal)
• CF is [0,1] with 1 meaning high coupling
)
(
)
,
(
_
2
TC
TC
C
C
client
is
i j j
i
−
∑∑
Polymorphism Factor
PF = .
• Mn() is the number of new methods
• Mo() is the number of overriding methods
• DC() number of descendent classes of a base
class
• The number of methods that redefines inherited
methods, divided by maximum number of
possible distinct polymorphic situations
[ ]
∑
∑
∗
i i
i
n
i i
o
C
DC
C
M
C
M
)
(
)
(
)
(
Operational Oriented Metrics
• Average operation size (LOC, volume)
• Number of messages sent by an operator
• Operation complexity – cyclomatic
• Average number of parameters/operation
– Larger the number the more complex the
collaboration
Encapsulation
• Lack of cohesion
• Percent public and protected
• Public access to data members

1
Inheritance
• Number of root classes
• Fan in – multiple inheritance
• NOC, DIT, etc.

Software Metrics
2
C h a p t e r
2.1 INTRODUCTION
I am reminded of a very interesting story when we talk of software metrics. Once there was a
meeting going on in USA. In that meeting, one of the ladies was asked to tell the length of the
software that her team members had developed. She took out a 30 cm scale from her bag and
started measuring the length of her program. All those who were present in the meeting started
laughing. The point is: do we measure our software like this? Is it possible to find the length and
the volume of our software? Was this lady right in her measurement procedure? No, certainly
not, she is incorrect. It is possible to measure the length and the volume of the software. But
certainly, not with a scale. This chapter focuses on the issues related to software measurement
and the techniques used for software measurement.
2.2 PROJECT MANAGEMENT PROCESS ACTIVITIES
Software Project Management (SPM) is the means by which an orderly control process can be
imposed on the software development process in order to ensure software quality. To meet the
cost, quality and schedules objectives, resources have to be properly allocated to each activity.
SPM is the way of achieving all these objectives. Note that SPM focuses on the issues
like planning a project, estimating resources, scheduling, monitoring and controlling the
project. During SPM, the project manager breaks down the development process into a number
of smaller, manageable tasks that are called phases. Also note that all such tasks have a single
objective and will produce a well-defined deliverable. Each task has a clear beginning and an
end. The following activities occur during SPM:
1. Proposal writing.
2. Project planning and scheduling.
3. Project cost estimation.
4. Project monitoring and reviews.
5. Personnel selection and evaluation.

Software Metrics 31
4. Project Monitoring and Reviews
The project manager must check the progress of the project from time to time and compare
the actual and planned progress and costs. Here, either formal or informal methods may
be used.
5. Personnel Selection and Evaluation
It is difficult to get skilled, experienced and trained engineers. The project manager must
appoint them.
6. Report Writing
The project manager is responsible for reporting of the project to both client and contractor
organizations. A brief document may be prepared.
7. Quality Management
It includes activities like quality assurance, quality planning and quality control during
SDLC.
8. Configuration Management (CM)
CM is a set of activities designed to control change by identifying the work products
that are likely to change, establishing relationships among them, defining mechanisms
for managing different versions of these products, controlling the changes imposed and
auditing and reporting on the changes made.
We usually talk of 4 Ps that are very important from SPM point of view. These 4 Ps form the
management’s spectrum and are shown in Figure 2.2.
The
People
The
Project
The
Process
The
Product
Figure 2.2 The 4 Ps of Management

Software Metrics 33
(a) Measure: It provides a quantitative indication of the extent, dimension, size and the
capacity of a product.
(b) Measurement: It is defined as the act of evaluating a measure. Actual measurements
must be performed on a given software system in order to use metrics for quantifying
characteristics of a given software. In software projects, if we want to calculate the length,
in terms of size metric of software then we use Lines of Code (LOC) measure.
(c) Metric: It is a quantitative measure of the degree to which a system or its component
possesses a given attribute. A number of metrics have been proposed to quantify the
software like the size, complexity and reliability of the software.
For example, say, we have collected 10 errors in some program, then it is a measure. On the
other hand, if we have collected the error data of say, 8 programs instead of one program, i.e.,
say 2, 6, 4, 9, 1, 3, 8, 2 errors, then it becomes its measurement. On the other hand, the relation
between these measures is a metric. This relation might be the average number of errors found
per review.
But note that for estimation, models are needed. These models are built to estimate the metric
value based on the value of some other metrics that we can measure. A model is a relationship
of the predicted variable and the other variables that can be measured. The models may be
based on empirical data or it may be analytic. It should be clear that measures, measurement,
metrics and models go together. Also note that metrics provide a quantification of some property,
measurements provide the actual value for the metrics and models are needed to get the value
for the metric that can’t be measured directly.
NOTE: All metrics must have a purpose.
Software metrics should be collected to ensure about the process and project indicators. Process
indicators enable a software engineering organization to gain insight into the efficiency of an
existing process. So, by using it the management will be able to know the existing processes.
This is the reason as why process metrics are collected across all the projects and over long
periods of time. Such metrics will provide process indicators which will lead to the software
process improvements.
Project indicators are used to check the progress of software development. So, a project
manager will be able to estimate the total work done on the project, mitigate the risk, and
minimize errors and to do quality control.
Note that in some cases, same software metrics may be used for both project and process
metrics. Also understand that software process and product metrics are quantitative measures.
Initially, basic quality and productivity data are collected. Then these data are analyzed, compared
against past averages and now estimate whether quality and productivity improvements have
occurred.
NOTE: Measures obtained by a project team will be converted into metrics for use during
the project. These metrics will be evaluated to provide the indicators.
Software metrics can be classified into three types as follows:
(a) Product Metrics: These are the measures of different characteristics of the software
product. The two important software characteristics are:

34 Modern Software Engineering
1. Size and complexity of software.
2. Quality and reliability of software.
These metrics can be computed for different stages of SDLC.
(b) Process Metrics: These are the measures of different characteristics of software
development process. For example, efficiency of fault detection. They are used to measure
the characteristics of methods, techniques and tools that are used for developing software.
(c) Resource Metrics: These are the quantitative measures of various resources used
in the software project. Resources may be hardware resources or software resources or
human resources. This metric denotes how efficiently these resources are being used.
Other types of metrics:
(a) Internal metrics.
(b) External metrics.
(c) Hybrid metrics.
(d) Project metrics.
Internal metrics are the metrics used for measuring properties that are viewed to be of
greater importance to a software developer. For example, Lines of Code (LOC) measure.
External metrics are the metrics used for measuring properties that are viewed to be of
greater importance to the user, For e.g., portability, reliability, functionality, usability, etc.
Hybrid metrics are the metrics that combine product, process and resource metrics. For
example, cost per FP where FP stands for function point metric and will be discussed in the next
section of this chapter.
Project metrics are the metrics used by the project manager to check the project’s progress.
Data from the past projects is 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. Also understand that these metrics are used to decrease the development
costs, time efforts and risks. The project quality can also be improved. As quality improves, the
number of errors and time as well as cost required is also reduced.
2.4 MEASURING SOFTWARE
The most important product metric is its size. Size may be expressed in terms of the LOC, number
of classes or number of bytes of source code. But LOC is the most popular metric. Software is
measured for the following reasons:
(a) To indicate the quality of the product.
(b) To assess the productivity of the people.
(c) To form a baseline for estimation.
(d) To justify the needs of new tools and staff training.
(e) To access advantages for new tools and methods.

Software Metrics 35
2.4.1 Size-Oriented Metrics/LOC Metrics/Direct Measures
LOC or thousands of LOC (KLOC) has been a very traditional and direct method of metrics of
software. These metrics are derived by normalizing the quality and productivity measures by
considering the size of the product as a metric. Please remember the following points regarding
LOC measures:
1. In size-oriented metrics, LOC is considered to be the normalization value.
2. It is an older method that was developed when FORTRAN and COBOL programming
were very popular.
3. Productivity is defined as KLOC / EFFORT where effort is measured in person-months.
4. Size-oriented metrics depend on the programming language used.
5. As productivity depends on KLOC, so assembly language code will have more
productivity.
6. LOC measure requires a level of detail which may not be practically achievable.
7. The more expressive is the programming language, the lower is the productivity.
8. LOC method of measurement is not applicable to projects that deal with visual (GUI-
based) programming. As already explained, Graphical User Interfaces (GUIs) use forms
basically. LOC metric is not applicable there.
9. It requires that all organizations must use the same method for counting LOC. This is so
because some organizations use only executable statements, some use comments and some
do not. So, a standard needs to be established.
10. These metrics are not universally accepted.
Based on the LOC/KLOC count of software, many other metrics can be computed:
(a) Errors/KLOC.
(b) $/ KLOC.
(c) Defects/KLOC.
(d) Pages of documentation/KLOC.
(e) Errors/PM.
(f) Productivity = KLOC/PM (effort is measured in person-months).
(g) $/ Page of documentation.
Advantages and disadvantages of LOC measure:
Proponents (in favor) of LOC measure claim that LOC is an artifact of all software
development projects that can be easily counted.
Opponents (against), however, argue that LOC measures are programming language
dependent. That is, a C program will take lesser LOC as compared to a COBOL/assembly
language program for a given task. For example, a bubble sort program in C will take lesser
number of LOC as compared to a COBOL program of bubble sort.
2.4.2 Text-Based Metrics
Another metrics that may be used is the size of the text of SRS. The size could be the number
of pages, number of paragraphs, number of functional requirements, etc.

Advantages and disadvantages of text-based measure:
Proponents (in favor) of text-based metric say that it is used mostly to convey a general
sense about the size of the product or project.
Opponents (against) say that such metrics are dependent on the authors of the document
and are not the accurate indicators of the size of the project.
2.4.3 Function Oriented Metrics
In 1977, A. J. Albrecht of IBM developed a method of software metrics based on the functionality
of the software delivered by an application as a normalization value. He called it the Function
Points (FPs). They are derived using an empirical relationship based on direct measures of
software’s information domain and assessments of software complexity. Note that FPs try to
quantify the functionality of the system, i.e., what the system performs. This is taken as
the method of measurement as FPs cannot be measured directly. Also note that FP is not a
single characteristic but is a combination of several software features/characteristics. A
non-profit organization called International Function Point User Group (IFPUG) was formed
in 1986 that took the responsibility of developing the counting rules and FP definitions. Today,
IFPUG has more than 3000 members and has affiliates in 24 countries. FP also has many variants
like backfired FPs, COSMIC FPs, Feature Points, The Netherlands FPs, etc. Remember the
following points regarding FPs:
1. FPs of an application is found out by counting the number and types of functions used in
the applications. Various functions used in an application can be put under five types as
shown in Table 2.1:
Table 2.1 Types of FP Attributes
Measurement Parameter Examples
1. Number of external inputs (EI) Input screen and tables.
2. Number of external outputs (EO) Output screens and reports.
3. Number of external inquiries (EQ) Prompts and interrupts.
4. Number of internal files (ILF) Databases and directories.
5. Number of external interfaces (EIF) Shared databases and shared routines.
All these parameters are then individually assessed for complexity.
2. FP characterizes the complexity of the software system and hence can be used to depict
the project time and the manpower requirement.
3. The effort required to develop the project depends on what the software does.
4. FP is programming language independent.
5. FP method is used for data processing systems, business systems like information systems.
6. The 5 parameters mentioned above are also known as information domain characteristics.
7. All the above-mentioned parameters are assigned some weights that have been
experimentally determined and are shown in Table 2.2.

Software Metrics 37
Table 2.2 Weights of 5-FP Attributes
Measurement Parameter Low Average High
1. Number of external inputs (EI) 7 10 15
2. Number of external outputs (EO) 5 7 10
3. Number of external inquiries (EQ) 3 4 6
4. Number of internal files (ILF) 4 5 7
5. Number of external interfaces (EIF) 3 4 6
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. So we draw another Table 2.3 now.
Table 2.3 Computing FPs
Measurement Parameter Count
Weighing factor
Simple Average Complex
1. Number of external inputs (EI) — * 3 4 6 = —
2. Number of external outputs (EO) — * 4 5 7 = —
3. Number of external inquiries (EQ) — * 3 4 6 = —
4. Number of internal files (ILF) — * 7 10 15 = —
5. Number of external interfaces (EIF) — * 5 7 10 = —
Count-total Æ —
Note 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 * S(Fi ) ]
= Count-total * CAF
where Count-total is obtained from the above Table.
CAF = [0.65 + 0.01 * S(Fi )]
and S(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 S (Fi). Also note that S (Fi) ranges from 0 to 70, i.e.,
0 <= S (Fi ) <=70
and CAF ranges from 0.65 to 1.35 because
(a) When S (Fi) = 0 then CAF = 0.65
(b) When S (Fi) = 70 then CAF = 0.65 + (0.01 * 70) = 0.65 + 0.7 = 1.35

Based on the FP measure of software many other metrics can be computed:
(a) Errors/FP
(b) $/FP.
(c) Defects/FP
(d) Pages of documentation/FP
(e) Errors/PM.
(f) Productivity = FP/PM (effort is measured in person-months).
(g) $/Page of Documentation.
8. LOCs of an application can be estimated from FPs. That is, they are interconvertible. This
process is known as backfiring. For example, 1 FP is equal to about 100 lines of COBOL
code.
9. FP metrics is used mostly for measuring the size of Management Information System
(MIS) software.
10. But 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:
(a) 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.
(c) The score of all 14 GSCs is totaled to determine Total Degree of Influence (TDI).
(d) Then Value Adjustment Factor (VAF) is computed from TDI by using the formula:
VAF = (TDI * 0.01) + 0.65
Remember that the value of VAF lies within 0.65 to 1.35 because
(a) When TDI = 0, VAF = 0.65
(b) When TDI = 70, VAF = 1.35
(e) VAF is then multiplied with the UFP to get the final FP count:
FP = VAF * UFP
Before we discuss the extended-FP metrics further, we solve some problems now.
Example 1 Compute the function point value for a project with the following information
domain characteristics:
(1) No. of user inputs = 32
(2) No. of user outputs = 60
(3) No. of user inquiries = 24
(4) No. of files = 8
(5) No. of external interfaces = 2
Assume all complexity adjustment values are average. Assume that 14 algorithms have
been counted. [RGTU June 2003, 2005, Dec. 2006, June 2008]

4. Number of internal files (ILF) 4 * 7 10 15 = 40
5. Number of external interfaces (EIF) 2 * 5 7 10 = 14
Count-total Æ 578
Now Fi for average case = 3.
So sum of all Fi (i ¨ 1 to 14) = 14 * 3 = 42
FP = Count-total * [0.65 + 0.01 * S (Fi ) ]
= 578 * [0.65 + 0.01 * 42]
= 578 * [0.65 + 0.42]
= 578 * 1.07
= 618.46
Example 3 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.
Solution: We draw the Table 3 firstly, using Table 2.3:
Measurement Parameter Count Weighing factor
1. Number of external inputs (EI) 24 * 4 = 96
2. Number of external outputs (EO) 46 * 4 = 184
3. Number of external inquiries (EQ) 8 * 6 = 48
4. Number of internal files (ILF) 4 * 10 = 40
5. Number of external interfaces (EIF) 2 * 5 = 10
Count-total Æ 378
So sum of all Fi (i ¨ 1 to 14) = 4 + 1 + 0 + 3 + 5 + 4 + 4 + 3 + 3 + 2 + 2 + 4 + 5 = 43
FP = Count-total * [0.65 + 0.01 * S (Fi )]
= 378 * [0.65 + 0.01 * 43]

Software Metrics 41
= 378 * [0.65 + 0.43]
= 378 * 1.08
= 408
Productivity = FP/ Effort = 408 / 36.9 = 11.1
Total pages of documentation = technical document + user document
= 265 + 122 = 387 pages
Documentation = Pages of documentation/FP
= 387/408 = 0.94
Cost per function = cost/ productivity = 7744/ 11.1 = $700
Assume all complexity adjustment values are moderate and 14 algorithms have been
counted. (GGSIPU, B.Tech (CSE/IT)-4th
Sem. May 2010)
Table 3 Computing FPs
Count-total Æ 617
Now Fi for moderate case = 2.
FP = Count-total * [0.65 + 0.01 * S (Fi )]
= 617 * [0.65 + 0.01 * 28]
= 617 * [0.65 + 0.28]
= 617 * 1.23
= 758.91 = 759

Assume all complexity adjustment values are moderate and 14 algorithms have been
counted.
Count-total Æ 364
Now Fi for moderate case = 2.
= 364 * [0.65 + 0.01 * 28]
= 364 * [0.65 + 0.28]
= 364 * 1.23
= 447.72 = 448
2.4.4 Extended Function Point (EFP) Metrics
FP metric has been further extended to compute:
(a) Feature points.
(b) 3D function points.
Feature Points:
According to Jones,
1. Feature point is the superset of function point measure that can be applied to systems and
engineering software applications.

Software Metrics 43
2. The feature points are used in those applications in which the algorithmic complexity is
high like real-time systems where time constraints are there, embedded systems, etc.
3. Feature points are computed by counting the information domain values and are weighed
by only single weight.
4. Feature point includes another measurement parameter—ALGORITHM.
5. The table for the computation of feature point is as follows:
Table 2.4 Feature Point Calculations
1. Number of external inputs (EI) – * 4 —
2. Number of external outputs (EO) – * 5 —
3. Number of external inquiries (EQ) – * 4 —
4. Number of internal files (ILF) – * 7 —
5. Number of external interfaces (EIF) – * 7 —
6. Algorithms used – * 3 —
Count-total Æ —
The feature point is thus calculated with the following formula:
= Count-total * CAF
where count-total is obtained from the above table.
CAF = [0.65 + 0.01 * S (Fi ) ]
and S (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 S (Fi).
6. Function point and feature point both represent systems functionality only.
7. For real-time applications that are very complex, the feature point is between 20 and 35%
higher than the count determined using function point above.
3D-Function Points
According to Boeing,
1. Three dimensions may be used to represent 3D function points–data dimension, functional
dimension and control dimension.
2. The data dimension is evaluated as FPs are calculated. Herein, counts are made for inputs,
outputs, inquiries, external interfaces and files.
3. The functional dimension adds another feature—Transformation, that is, the sequence
of steps which transforms input to output.
4. The control dimension that adds another feature—Transition that is defined as the total
number of transitions between states. A state represents some externally observable mode

Software Metrics 45
1. Number of external inputs (EI) 32 * 3 4 6 = 128
2. Number of external outputs (EO) 60 * 4 5 7 = 300
3. Number of external inquiries (EQ) 24 * 3 4 6 = 96
4. Number of internal files (ILF) 8 * 7 10 15 = 80
5. Number of external interfaces (EIF) 2 * 5 7 10 = 14
Count-total Æ 618
Now Fi for average case = 3.
FP = Count-total * [0.65 + 0.01 * ∑ (Fi ) ]
= 618 * [0.65 + 0.01 * 42]
= 618 * [0.65 + 0.42]
= 618 * 1.07
= 661.26
and feature point = (32 *4 + 60 * 5 + 24 * 4 + 80 +14) * 1.07 + {12 * 15 *1.07}
= 853.86
Example 2 Compute the 3D-function point value for an embedded system with the
following characteristics:
(1) Internal data structures = 6
(2) External data structures = 3
(7) Transformations = 36
(8) Transitions = 24
Assume complexity of the above counts is high. [RGTU June 2004]
Solution: We draw the Table 6 first. For embedded systems, the weighting factor is complex
and complexity is high. So,

Measurement Parameter Count
Weighing factor
1. Number of external inputs (EI) 12 * 3 4 6 = 72
2. Number of external outputs (EO) 60 * 4 5 7 = 420
3. Number of external inquiries (EQ) 9 * 3 4 6 = 54
4. Number of internal data structure 6 * 7 10 15 = 90
5. Number of external data structure 3 * 5 7 10 = 30
6. Number of external interfaces 3 * 5 7 10 = 30
7. Number of transformations 36 * —— 36
8. Number of transitions 24 * —— 24
Count-total Æ 756
So, for 3D function points, the required index is 756.
2.5 CASE TOOLS FOR SOFTWARE METRICS
Many CASE tools (Computer Aided Software Engineering tools) exist for measuring software.
They are either open source or are paid tools. Some of them are listed below:
1. Analyst4j tool is based on the Eclipse platform and available as a stand-alone Rich Client
Application or as an Eclipse IDE plug-in. It features search, metrics, analyzing quality,
and report generation for Java programs.
2. CCCC is an open source command-line tool. It analyzes C++ and Java lines and
generates reports on various metrics, including Lines of Code and metrics proposed by
Chidamber & Kemerer and Henry & Kafura.
3. Chidamber & Kemerer Java Metrics is an open source command-line tool. It calculates
the C&K object-oriented metrics by processing the byte-code of compiled Java.
4. Dependency Finder is an open source. It is a suite of tools for analyzing compiled Java
code. Its core is a dependency analysis application that extracts dependency graphs and
mines them for useful information. This application comes as a command-line tool, a
Swing-based application and a web application.
5. Eclipse Metrics Plug-in 1.3.6 by Frank Sauer is an open source metrics calculation and
dependency analyzer plugin for the Eclipse IDE. It measures various metrics and detects
cycles in package and type dependencies.
6. Eclipse Metrics Plug-in 3.4 by Lance Walton is open source. It calculates various metrics
during build cycles and warns, via the problems view, of metrics ‘range violations’.
7. OOMeter is an experimental software metrics tool developed by Alghamdi. It accepts
Java/C# source code and UML models in XMI and calculates various metrics.
8. Semmle is an Eclipse plug-in. It provides an SQL like querying language for object-
oriented code, which allows searching for bugs, measure code metrics, etc.

9. 3D Function Point method was proposed by:
(a) Boeing (b) Jacobson
(c) Albrecht (d) None of the above
10. Total number of General System Characteristics (GSCs) are:
(a) 12 (b) 13
(c) 14 (d) 15
Answers
1. (b) 2. (a) 3. (c) 4. (b) 5. (a) 6. (b)
7. (c) 8. (a) 9. (a) 10. (c)
SHORT QUESTIONS WITH ANSWERS
1. Distinguish between FP and LOC measures.
Ans. 1: Let us tabulate the differences between the two:
FP LOC
1. FP is specification based. 1. LOC is analogy based.
2. FP is language independent. 2. LOC is language dependent.
3. FP is user-oriented. 3. LOC is design-oriented.
4. It is extendible to LOC. 4. It is convertible to FP (backfiring).
2. What is Bang Metrics?
Ans. 2: Bang metrics is a function metric indicating the size of the system. It measures the
total functionality of the software system delivered to the user. It was defined by DeMarco.
He suggests that the goal of a good project is to maximize ‘BANG PER BUCK’ that is,
bang divided by the total project cost.
3. How can we compute the estimated value of the software size?
Ans. 3: The expected value for the estimation variable (size, S) can be calculated as the
weighted average of Optimistic value-good over bad (a), most likely (m) and pessimistic
value-not sure value (b) estimates as follows:
S = (a + 4m + b)/6
where S is the FP estimate and the condition a < m < b also holds.
4. Say, for a language, Size = 100FP and LOC/FP is 128. Compute corresponding
LOC? [GGSIPU, B. Tech (CSE)-7TH
sem., 2009]
Ans. 4: LOC = (100) * (128) = 12,800 = 12.8KLOC.
5. Is it possible for different engineers to arrive at different FP measures for the same
problem?
Ans. 5: Yes, it is possible. Let us take an example of this. Say, if a data employee details
consists of the employees name, his address, then one person may consider it to be a single

References
1. Roger S. Pressman, Software Engineering a Practitioner Approach, 3rd
Edition, TMH, 2005.
2. Rajib Mall, Fundamantal of Software Engineering, 3rd
Edition,PHI Publication, 2007.
3. Deepak Jain, Software Engineering for Practitioners, Ist
Edition, Oxford, 2012.
4. K K Agarwal and Yogesh Singh, Software Engineering, 3rd
Edition,Oxford, 2012.
73

SE UNIT-3.pdf

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à SE UNIT-3.pdf

Similaire à SE UNIT-3.pdf (20)

Plus de Dr. Radhey Shyam

Plus de Dr. Radhey Shyam (20)

Dernier

Dernier (20)

SE UNIT-3.pdf