Transcript Software Metrics and Measures

SoftwareMeasures and Metrics
SoftwareMeasurement
Why do we measure?




To characterize
To evaluate
To predict
To improve
Software measurement is concerned with deriving numeric
values for attributes of a software project, product, or process
 Allows for objective comparisons between techniques and processes
 Although some companies have introduced measurement programs,
the systematic use of measurement is still uncommon
 There are few standards in this area
The Measurement Process
 Software measurement process may be part of a quality control process
 Data collected during this process should be maintained as an
organisational resource
 Once a measurement database has been established, comparisons
across projects become possible
Software Measures
process measures
Software
measures
But software is
“
”???
Why do it?
What to measure?
project measures
What does it mean?
product measures How do you usethe results?
What do we use as a basis?
• size?
• function?
Anything that you need to
quantify can be measured
in some way that is superior to
not measuring it at all
-- Tom Gilb
Process vs.Project vs. Product:
 Process measures are organizational / cross-team, and typically what
you want is based on the SDLC model you are using
 Project measures are similar but on a per instance basis and tied to the
milestones and requirements of the customer (including budget!)
 Product measures are attributes of the software itself
Provide a measure of software quality, or quality indicators
 We will spend our time on product measures
Measurement Basics
Measurement Scales
 Nominal - Categorical; either equal or not equal
• Example: Types of programs: “desktop, web, pda”
 Ordinal - Ranking; ordered but not ratio’d; <, >
• Example: Programmer experience: “low, medium, high”
 Interval - Ranked and Additive but not ratio’d; <,>,+,• Example: CC: “CC(X) = 6, CC(Y) = 2, but X is not 3 times as
complex as Y”
 Ratio - Existence of absolute zero ; <,>,+,-,/
• Example: LOC: “X has 3 times as many LOC as Y, therefore X is
three times as large as Y”
Objective vs. Subjective:
 Do calculations require input based on human judgment?
Metrics and Measures
What is a metric?
• A metricis a measure (so why the different term?)
• A software metric is interpreted according to a quality attribute
• Lines of Code, Complexity, Dependency, Cycle Time
• In other words, it has an interpretation based on a target
Metrics assumptions
 A software property can be measured
 A relationship exists between what we can measure and what we
want to know
 This relationship has been formalized and validated
 It may be difficult to relate what can be measured to desirable
quality attributes
Code Size Metrics
Size measures are “controversial”
• Traditionally, lines of code has been used
• But, a lot of issues: Language differences, verbosity, reuse, what to count?
• Is it a proxy for complexity or for LOE?
• Other measures have been proposed
• Function points: measure of complexity
• OO metrics: #classes, methods, etc.
• But these can vary by style of coder.
Why does size matter so much in software?
 Typically the measure against which cost and quality are
normalized against
;
•
•
•
•
defects per KLOC (thousand lines of code)
$ per LOC
page of documentation per KLOC
LOC per person-month
 An indirect measure of effort
Lines of Code (LOC)
LOC is the most popular software product metric
Why?
 It is implied that size  complexity
• is this true?
 It is implied that LOC is the best representation of size
• Is this true?
• How does the language you work in affect this?
 It is implied that more LOC means more work
• Is this true?
Different methods for counting LOC exist
 Examples:
• Method 1: Count each statement (ends with ; or is a
conditional/loop/declaration construct) as 1, everything else 0
• Method 2: Same as 1 except add ½ for each comment line
• Method 3: Same as 2, except add 2 for special constructs
LOC Examples
/* rmitest1Impl.java - Testing Naming.(re)bind on rmiserver */
import java.rmi.*;
import java.rmi.server.*;
Method 1:
Method 2:
Method 3:
public class rmitest1Impl extends java.rmi.server.UnicastRemoteObject
implements rmitest1 {
protected rmitest1Impl() throws java.rmi.RemoteException {
super();
System.out.println("Server object created");
}
public int rmitest(Integer x) throws java.rmi.RemoteException {
System.out.println("In rmitest1Impl::rmitest");
System.out.println("Value of param: " + x);
return 1;
}
public static void main(String[] args)
{
System.setSecurityManager(new RMISecurityManager());
try {
rmitest1Impl rt = new rmitest1Impl();
System.out.println("rmitest attempting to register with rmiregistry");
Naming.bind("rmitest", rt);
System.out.println("rmitest registered with rmiregistry");
} catch (Exception e)
{
e.printStackTrace();
System.exit(0);
} } }
Function Point Analysis
A function point is a unit of measurement to express the amount of
business functionality an information system provides to a user. (Wikipedia)
The function point technique provides an objective, comparative measure that assists
in the evaluation, planning, management and control of software production (IFPUG)
Analyze information
domain of the
application
and develop counts
Establish count for input domain and
system interfaces
Weight each count by
assessing complexity
Assign level of complexity or weight
to each count
Assess influence of
global factors that affect
the application
Grade significance of external factors, F i
such as reuse, concurrency, OS, ...
Compute
function points
function points =
(count x weight) x C
where:
complexity multiplier: C = (0.65 + 0.01 x N)
degree of influence: N = F
i
Measures, Counts, and Weights in FP:
measurement parameter
count
weighting factor
simple avg. complex
number of user inputs
X 3
4
6
=
number of user outputs
X 4
5
7
=
number of user inquiries
X 3
4
6
=
number of files
X 7
10
15
=
number of ext.interfaces
X 5
7
10
=
count-total
complexity multiplier
function points
• In practice the things you measure can get arbitrarily complex and may
need normalization in addition to weighting.
•The point is, it is all subjective
Why Opt for FP Measures?
independent of programming language
uses readily countable characteristics of the
"information domain" of the problem
does not "penalize" inventive implementations that
require fewer LOC than others
makes it easier to accommodate reuse and the
trend toward object-oriented approaches
Code Complexity
Size is important
• Again, typically used as the basis for estimating
developer effort and number of defects
• But does size == complexity?
• Well, generally the bigger it is, the more complex it is
• But not necessarily the case; small amounts of code can be
complex too, just as big sections of code can be trivial (beans)
Complexity measures
• Attempt to capture how “hard” that section of code is
• More complex code generally takes longer to
implement, requires greater or specialized expertise,
and is usually a source of higher defect injection rates
• Are we talking about problem or solution complexity?
• What Brooks called “essential” vs. “accidental” complexity?
Code Complexity Metrics
McCabe’s Cyclomatic Complexity
 Measure Goal: determine the complexity of a code module
independent of its size.
 the number of linear segments of code in a code fragment
• Very useful for constructing unit test cases
 To compute, construct a graph G where:
• Each statement is a node, or vertice in the graph
• Each conditional statement with multiple outcomes has an arc or
edge connecting the statement to the next statement if that
conditional branch is followed.
• After constructing the graph, compute:
CC(G) = E - N + 2
• Where G is the graph, |E| the # edges, |N| the # of nodes
• Note CC(G) of a code segment with no conditionals is 1.
Cyclomatic Complexity - Example
Doesn’t this look familiar???
1
Node getSecondElement() {
2
Node head = getHead();
3
if (head == null)
4
return null;
5
if (head.next == null)
6
return null;
7
8
return head.next.node;
}
1
What is CC(G)?
2
3
4
5
6
7
8
Code Complexity Metrics (cont.)
Cohesion: the extent to which a software module expresses a
singular responsibility
Lack of Cohesion Metrics (LCOM)
 Measure Goal: indicate whether a component represents
one abstraction or multiple abstractions
• Chidamber-Kemerer(LCOM1) - # of pairs of methods using an
attribute (P) minus the # of pairs of methods that do not (Q)
LCOM1 = P - Q if P > Q, 0 otherwise
– 0 is considered good, anything > 0 is bad
• Henderson-Sellers (LCOM2/3) - Ratio of methods that access an
attribute on a class versus those that do not:
LCOM2 = 1 - sum(mA)/(m*a),
–
–
–
–
LCOM3 = (m – sum(mA)/a) / (m-1)
“mA” means the method uses class attribute a in A
“a” is the number of attributes on the class
“m” is the number of methods on the class.
Result of LCOM3 is in the range [0,2], anything > 1 is bad.
Code Complexity Metrics
Lack of Cohesion Methods (cont.)

Hitz&Montazeri (LCOM4) - measure the number of connected
components in a class.
•
For any pair of methods m1 & m2 in M, add 1 if:
1. m1 and m2 do not call each other
--AND-2. m1 and m2 do not reference common class variables --AND-3. Transitivity - any method m1 references and any method m2 references
do not reference each other
•

Any number greater than 0 is bad.
Example:
public void m1(int x)
{
var1 = x*var1;
print(m2(x));
}
public int m2(int y)
{
print(y);
return y*y;
}
var1
public void m3(int z)
{
print(z + var2);
}
var2
Code Complexity Metrics
Coupling is the extent to which the existence and/or operation
of a software module relies on the existence (operation) of
another module
Measure Goal: the number of types the class knows about,
and the nature of dependency between classes
• Coupling is considered poor OO as it inhibits the ability to reuse or delegate.
Measures
 Brito&Abreu (CF): Actual coupling / Max possible
• Take 2 classes C1, C2. C1 is coupled to C2 iff C1 accesses a method or
variable on C2.
n
• Note the relationship is directed, so max = n-2
( )
Several other coupling metrics exist, most all based on counting the
number of times a type appears within another class’ scope
Generally speaking, a desirable quality goal in software design is to have
“high cohesion” but “loose coupling”
• You have modules that work well together w/out depending on each other
Other Metrics
Halstead’s Product Metrics
 Program Vocabulary - the number of unique tokens
 Program Length - size metric based on the number of times the
unique tokens appear in the code
 Program volume - storage required for the program
Other Metrics
 Fan-in / Fan-out – ratio of number of functions that call this function
versus the number of functions this function calls. (coupling)
 Fog index – the average lengths of words and sentences in
documentation. The longer it is the more complex the solution.
 Depth of conditionals – Nesting of if/else or loop constructs even
harder to check than CC measure indicates.
 Length of identifiers – if a developer practices good mnemonic
naming, then presumably s/he writes more understandable code.
 Depth of inheritance / number of overriding methods – a deep and
complex inheritance hierarchy leads to defects and less reuse.
Why are we measuring again?
We are trying to tie it back to quality attributes!
Don’t say it if you can’t back it up with quantifiable data!!!
Number of procedur e
par ameters
Maintainability
Cyclomatic complexity
Reliability
Program size in lines
of code
Portability
Number of error
messages
Usability
Length of user manual
Non-product Metrics
Process Metrics
 majority focus on quality achieved as a consequence of a
repeatable or managed process
 statistical SQA data
• error categorization & analysis
 defect removal efficiency
• propagation from phase to phase
 reuse data
Project Metrics





Effort/time per SE task
Errors uncovered per review hour
Scheduled vs. actual milestone dates
Changes (number) and their characteristics
Distribution of effort on SE tasks
Metrics and Measures Summary
Metrics assumptions
 A software property can be measured
 A relationship exists between what we can measure
and what we want to know
 This relationship has been formalized and validated
 It may be difficult to relate what can be measured to
desirable quality attributes
The Measurement Process
 A software measurement process should be part of a
quality control process
 Data collected during this process should be
maintained as an organisational resource
 Once a measurement database has been established,
comparisons across projects become possible