Scribd
Upload
294 views23 pages

Chapter 23 - Product Metrics

Uploaded by

malik assad
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
294 views23 pages

Chapter 23 - Product Metrics

Uploaded by

malik assad
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 23

Chapter 23

Product Metrics
Slide Set to accompany
Software Engineering: A Practitioner’s Approach, 7/e
by Roger S. Pressman

Slides copyright © 1996, 2001, 2005, 2009 by Roger S. Pressman

For non-profit educational use only


May be reproduced ONLY for student use at the university level when used in conjunction
with Software Engineering: A Practitioner's Approach, 7/e. Any other reproduction or use is
prohibited without the express written permission of the author.

All copyright information MUST appear if these slides are posted on a website for student
use.

1
Why Measure Software?
• Determine quality of the current product or
process
• Predict qualities of a product/process
• Improve quality of a product/process
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
Types of Measures
• Direct Measures (internal attributes)
– Cost, effort, LOC, speed, memory

• Indirect Measures (external attributes)


– Functionality, quality, complexity, efficiency,
reliability, maintainability
Metrics for the Requirements Model

• Function-based metrics: use the function


point as a normalizing factor or as a measure
of the “size” of the specification

5
Function Point metric (FP)
• Function points are derived using an empirical
relationship based on countable (direct) measures of
software's information domain and assessments of
software complexity
• Information domain values are defined in the following
manner:
– number of external inputs (EIs)
– number of external outputs (EOs)
– number of external inquiries (EQs)
– number of internal logical files (ILFs)
– Number of external interface files (EIFs)

6
Function Points
Information Weighting factor
Domain Value Count simple average complex

External Inputs ( EIs) 3 3 4 6 =


External Outputs ( EOs ) 3 4 5 7
=

External Inquiries ( EQs) 3 3 4 6 =

Internal Logical Files ( ILFs) 3 7 10 15 =


3 5 7 10 =
External Interface Files ( EIFs)

Count total

7
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 Metric
• Easy to use
• Easy to compute
• However:
– How to interpret ...
• Empty lines
• Comments
• Several statements on one line
• Language and programmer dependent
• Doesn't respect complexity and content
Halstead’s Complexity Measures
• Calculate:
– n1 - number of distinct operators
– n2 - number of distinct operands
– N1 - total number of operators
– N2 - total number of operands
• Program Length: N = N1 + N2
• Program Vocabulary: n = n1 + n2
• Volume: V = N log n
• Program effort: E=V/L
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
Measures of Software Quality
• Correctness
– Defects/KLOC
– Failures/hours of operation
• Maintainability
– Mean time to change
– Cost to correct
• Usability
– Training time, skill level necessary to use
– Subjective questionnaire or controlled experiment
Metrics for the Object Oriented
• 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
Depth of Inheritance Tree (DIT)
• 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)
• NOC is the number of subclasses immediately
subordinate to a class
• As NOC grows, reuse increases
Coupling between object classes (CBO)

• CBO is the number of collaborations between


two classes
– For a class, C, the CBO metric is the number of
other classes to which the class is coupled
Class Size (CS)
• 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 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
Fan-in and Fan-out
• Fan-in: number of modules calling the module
under consideration
• Fan-out: number of called modules
• High fan-in shows that a module is being used
by other objects (indication of re-use).
• High fan-out indicates high coupling (poor
design)
Fan-in Example
Function A () {
call Function M () ;
}
Function B ( ) {
call Function M ( );
}

• Fan-in for M = 2
Fan-out Example

Function A ( ) {
call function B( ) ;
call function C( ) ;
call function D( );
}
• Fan-out for A = 3
Metrics for Maintenance
• Software Maturity Index (SMI)
– Provides an indication of the stability of a software product based on
changes that occur for each release
• SMI = [MT - (Fa + Fc + Fd)]/MT
where
MT = #modules in the current release
Fa = #modules in the current release that have been added
Fc = #modules in the current release that have been changed
Fd = #modules from the preceding release that were deleted in
the current release
• As the SMI (i.e., the fraction) approaches 1.0, the software
product begins to stabilize

23

You might also like