This document discusses various ways to measure internal attributes of software such as size, functionality, complexity, structure, and modularity. It describes commonly used measures like lines of code, function points, object points, and complexity metrics. It also covers control flow graphs, module coupling, cohesion, and information flow metrics. Finally, it briefly mentions data structures and difficulties measuring overall complexity before concluding with external measures.

1. CHAPTER 2
MEASURING INTERNAL
PRODUCT ATTRIBUTES

2. 2.1 Aspects of Software Size
 Effort
 Productivity
 Cost
Software size can be outlined using three attributes:
 Length
 Functionality
 Complexity
Mr. M. E. Patil
S.S.B.T COET, Bambhori

3. 2.2 Length
 Code
 Traditional code measures
 Dealing with non-textual or external code
 Specification and designs
2.3 Functionality
 Function Points
Total
Measurement Parameters Count Weight Factor
Simple Ave Complex
Number of Inputs * 3 4 6
Number of User Outputs * 4 5 7
Number of User Inquiries * 3 4 6
Number of Files * 7 10 15
Number of External Interfaces * 5 7 10
Count-Total
Mr. M. E. Patil
S.S.B.T COET, Bambhori

4. FP = count-total * [ 0 . 65  0 . 01 * SUM ( Fi )]
Fi are complexity adjustment values founded on the
answers to the questions in the table below.
Fi
1 Does the system require reliable back up and recovery?
2 Are data communication required
3 Are there distributed processing functions?
4 Is performance critical
5 Will the system run in an existing, heavily utilized operating system
6 Does the system require on-line entry?
7 Does the on-line data entry require the input transaction to be built over multiple screen or
operations?
8 Are the master files updated on-line?
9 Are the inputs, outputs, files, or inquiries complex?
10 Is the internal processing complex?
11 Is the code designed to be reusable
12 Are the 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 by the user?
Mr. M. E. Patil
Total
S.S.B.T COET, Bambhori

5. FP
Productivi ty 
person - months
quality
Quality 
FP
£
Cost 
FP
pages of documentation
Documentation 
FP
Mr. M. E. Patil
S.S.B.T COET, Bambhori

6. COCOMO 2.0
• Alternatives to lines of code as a size input for
a revised COCOMO, Boehm chose function
points for use when the system is totally
specified.
• They required a size measure for earlier in the
development stage, when feasibility is being
considered and prototypes produced.
• They choose object points for this early size
measure in COCOMO 2.0.
Mr. M. E. Patil
S.S.B.T COET, Bambhori

7. • To calculate object points, an initial size
measure is produced by counting the number
of screens, reports and third-generation
language elements that are to be included in
the application.
• Each object is classified as simple, medium or
difficult in a manner close to function points
(See table below).
Mr. M. E. Patil
S.S.B.T COET, Bambhori

8.  COCOMO 2.0
Table Object point complexity levels.
For Screens
Number and source of data tables
Number of views Total < 4 Total <8 Total 8+
contained (<2 server, (2-3 servers, (>3 server,
< 2 clients) 3-5 client) >5 client)
<3 Simple Simple Medium
3-7 Simple Medium Difficult
8+ Medium Difficult Difficult
For Reports
Number and source of data tables
Number of Total < 4 Total <8 Total 8+
sections contained (<2 server, (2-3 servers, (>3 server,
< 2 clients) 3-5 client) >5 client)
<3 Simple Simple Medium
3-7 Simple Medium Difficult
8+ Medium Difficult Difficult
Mr. M. E. Patil
S.S.B.T COET, Bambhori

9. Table Complexity weights for object points.
Object type Simple Medium Difficult
Screen 1 2 3
Report 2 5 8
3GL component - - 10
The reuse is taken in account.
New object points = (object points) x (100 – r)/100
Where r is the % of reused components
Mr. M. E. Patil
S.S.B.T COET, Bambhori

10. DeMarco’s Approach
• DeMarco produced a functionality measure
founded on his structured analysis and design
notation.
• These bang metrics included two measures:
– one for “function strong” systems, and
– another for “data strong” systems.
Bang may be defined formally and its computation
can be automated within CASE tools that support
the mehtodology
Mr. M. E. Patil
S.S.B.T COET, Bambhori

11. Function Strong
• The function bang measure is founded on the
number of functional primitives (the number
of lowest level bubbles) in a data-flow
diagram.
• The basic function-primitive count is weighted
based on the kind of functional primitive and
the number of data tokens used in the
primitive.
Mr. M. E. Patil
S.S.B.T COET, Bambhori

12. Data Strong
• The data bang measure is founded on the
number of entities in the entity-relationship
model.
• The basic entity count is weighted according
to the number of associations involving each
entity.
• These can be easily adapted for structured
analysis technique.
Mr. M. E. Patil
S.S.B.T COET, Bambhori

13. Complexity
• Complexity of problem:- Amount of resources
required for an optimal solution.
• Complexity of solution:- Resources needed for
implementation of a particular solution.
– Time complexity :- resource is computer time
– Space complexity:- resource is computer memory
Mr. M. E. Patil
S.S.B.T COET, Bambhori

14. • Measuring algorithmic efficiency:-
– Efficiency of a searching or sorting algorithm can
be measured as the function f(n) representing the
number of primitive operations required for an
input list of size n.
Mr. M. E. Patil
S.S.B.T COET, Bambhori

15. Big-O notations
• A precise mathematical formalism is called as
Big-O notation.
• It allows us to define an order relation on
functions.
• This permits us to define relation to
characterize efficiency.
• We derive it of a function f(n) by finding the
dominating term of f(n) an then ignoring
constant multiples.
Mr. M. E. Patil
S.S.B.T COET, Bambhori

16. • F(n) = 3 n2 + 2n +26
• The dominating term of f(n) is 3n2
• Ignore the constant 3 it will become n2
• Thus we can say that big-o n2 can be written
as @(n2)
Mr. M. E. Patil
S.S.B.T COET, Bambhori

17. Structure
• Types of structural measures
– Control flow structure
– Data-flow structure
– Data structure
Mr. M. E. Patil
S.S.B.T COET, Bambhori

18. Control flow
• It address the sequence in which instructions
are executed in a program.
• This aspect of structure reflects the iterative
and looping nature of program
• Simple size counts an instruction just once,
control flow makes more visible the fact that
an instruction maybe executed many times as
the program is actually rns.
Mr. M. E. Patil
S.S.B.T COET, Bambhori

19. Data flow
• It follows the trail of data item as it is created
or handled by the program.
• It trace the behavior of the data as it interacts
with the program.
Mr. M. E. Patil
S.S.B.T COET, Bambhori

20. Data Structure
• It is the organization of the data itself,
independent of program.
• The structure of data tells us about the
difficulty involved in writing programs to
handle the data.
Mr. M. E. Patil
S.S.B.T COET, Bambhori

21. Control-Flow Structure
• The control flow measures are usually
modeled with directed graph.
• Each node (or point) corresponds to a
program statement
• Each arc (or directed edge) indicates the flow
of control from one statement to another.
• We call these directed graphs control flow
graphs or flow graphs.
Mr. M. E. Patil
S.S.B.T COET, Bambhori

22. 2.7 Control-Flow Structure
 Flow graphs-
10 INPUT P 10
20 Div = 2 20
30 Lim=INT(SQR(P)) 30
40 Flag = P/Div- INT(P/Div)
40
50 If Flag = 0 OR Div = Lim
THEN 80 50
60 Div = Div +1 80 60
70 GO TO 40
80 IF Flag <> 0 OR P>4 THEN
110 90
110
90 Print Div
100 GO TO 120
110 Print P 120
120 End
Mr. M. E. Patil
S.S.B.T COET, Bambhori

23. Flow graph model of structure
• Graph consists of set of points (or nodes) and
line segments (or edges).
• In a directed graph , each edge is assigned a
direction , indicated by a arrowhead on the
edge . This directed edge is called an arc.
• Arc is an ordered pair , <x , y> where x and y
(nodes) are the starting and ending point of
the arc.
Mr. M. E. Patil
S.S.B.T COET, Bambhori

24. • In-degree:- of the node is the number of arcs
arriving at the node
• Out-degree:- of the node is the number of
arcs that leave the node.
• A path is the sequence of consecutive
(directed ) edges, some of which may be
traversed more than once during sequence.
• Simple path is the one in which there are no
repeated edges.
Mr. M. E. Patil
S.S.B.T COET, Bambhori

25. • A Flowgraph is a directed graph in which two
nodes, the start node and the stop nodes,
obeys the properties:-
– Stop node has out degree zero
– And every node lies on the some path from the
start node to the stop node
Mr. M. E. Patil
S.S.B.T COET, Bambhori

26. Mr. M. E. Patil
S.S.B.T COET, Bambhori

27. Sequencing and Nesting
• There are only two operation available with
which we can build a new flow graph form the
old.
Mr. M. E. Patil
S.S.B.T COET, Bambhori

28. Mr. M. E. Patil
S.S.B.T COET, Bambhori

29. Mr. M. E. Patil
S.S.B.T COET, Bambhori

30. Mr. M. E. Patil
S.S.B.T COET, Bambhori

31. 2.8 Modularity and Information Flow
Attributes
 Models of modularity and information flow
Main
Scores
Scores
eof
Read_Scores
Average
Scores
Average
Average
Calc_Av Print_Av
Mr. M. E. Patil
S.S.B.T COET, Bambhori

32. Module call-graph
A Module A calls B, C
C Module B calls D
B
Module C calls D, E
D E
 Global Modularity
M 1 = modules/procedures
M 2 = modules/variable
Mr. M. E. Patil
S.S.B.T COET, Bambhori

33.  Morphology
Size 12 nodes, 15 edges
Depth 3
Width 6
Edge-to-node ratio 1.25
Mr. M. E. Patil
S.S.B.T COET, Bambhori

34.  Coupling
 No coupling relation
 Data coupling relation
 Stamp coupling relation
 Control coupling relation
Common coupling relation
 Content coupling relation
 Cohesion
 Functional
 Sequential
 Communicational
 Procedural
number of modules having functional cohesion
 Temporal Cohesion ratio =
total number of modules
 Logical
 Coincidental
Mr. M. E. Patil
S.S.B.T COET, Bambhori

35.  Information Flow
a
Fan-out for the figure is 4.
b c d e
w x y
Fan-in is 3 for z.
z
Mr. M. E. Patil
S.S.B.T COET, Bambhori

36.  Henry and Kafura’s Metrics
length × (fan _ in × fan _ out )2
WC
FD CW DR
GDR RD FWS PW
DOC
Mr. M. E. Patil
S.S.B.T COET, Bambhori

37. Module Fan-in Fan-out [(fan-in)(fan- Length Complexity
out)]
WC 2 2 16 30 480
FD 2 2 16 11 176
CW 3 3 81 40 1080
DR 1 0 0 23 0
GDN 0 1 0 14 0
RD 2 1 4 28 112
FWS 1 1 1 46 46
PW 1 1 1 29 29
 Shepperd’s Metric
IF4 m = ( fan _ inm × fan _ out m ) 2
IF4=Sum( IF4 m )
Mr. M. E. Patil
S.S.B.T COET, Bambhori

38.  Moses, Farrow and Smith Metric
Information flow Advantages
• Measures total level of information flow between the modules of a system.
• Evaluates potential design changes.
• Allows the identification of design problems such as modules with a large amount of
fan-in and fan-out.
• Can be produced in the design stage
• Takes into account data-driven programs.
• Address issues such as complexity and cohesion.
• Suitable for identifying software that exhibits maintenance problems and may be
error prone and unreliable.
• Appropriate for identifying lack of cohesion, stress points and missing levels of
design abstraction.
• Provides motivation for their use in the prediction of cohesion.
Information flow disadvantages
• All the flows have equal weighting.
• If there is no external interactions can give misleading values.
• Underestimates local and global information flows
Mr. M. E. Patil
S.S.B.T COET, Bambhori

39.  Object-Oriented Metrics
Metric 1: weighted methods per class (WMC)
Metric 2: depth of inheritance tree (DIT)
Metric 3: number of children (NOC)
Metric 4: coupling between object classes (CBO)
Metric 5: response of the class (RFC)
Metric 6: lack of cohesion metric (LCOM)
2.9 Data Structures
2.10 Difficulties with General “Complexity”
Measures
2.11 Measuring External Product Attribute
Mr. M. E. Patil
S.S.B.T COET, Bambhori

40.  Modeling Software Quality
Device Independence
Portability
Completeness
Reliability Accuracy
Consistency
As is utility Efficiency
Device efficiency
Human Engineering
Accessibility
General
Communicativeness
Utility
Testability
Metrics
Structuredness
Understandability Self descriptiveness
Maintainability
Conciseness
Modifiability
Legibility
Augmentability
Primary uses Intermediate
Primitive Constructs
Construction
Mr. M. E. Patil
S.S.B.T COET, Bambhori

41.  Early model
 The ISO 9126 standard quality model
Functionality
Reliability
Efficiency
Usability
Maintainability
Portability
Mr. M. E. Patil
S.S.B.T COET, Bambhori

42. Managerial Requirement definition
Stated or implied needs requirements
ISO 9126 & other technical info
Quality
Requirement
definition Metric Rating level Assessment
selection definition criteria Preparation
definition
Software
development Products
Measured
Measurement
value
Rating
Related
value
Result
Assessment (accepted or
unaccepted)
Mr. M. E. Patil
S.S.B.T COET, Bambhori

43.  Measuring Aspects of Quality
ET
Portabilit y = 1 -
ER
ET – resources needed to move the system to the
target environment
ER – measure of the resources needed to produce the
system for the resident environment.
 Defects-based quality measures
number of known defects
defect density =
product size
 Usability
Usability of a software product is the extent to which the product is convenient and
practical to use.
 Entry level
 Learnability
 Handling ability
Mr. M. E. Patil
S.S.B.T COET, Bambhori

44. quantity * quality
task effectiveness = %
100
effectiven ess
temporal effectiven ess =
task time
task time - unproductive time
productive period = 100%
task time
 Reusability
 Reliability
Probability of failure on demand
Rate of Fault Occurrence
Mean time to failure
Availability
Mr. M. E. Patil
S.S.B.T COET, Bambhori

45.  Maintainability
 Understandability
Mr. M. E. Patil
S.S.B.T COET, Bambhori