Product Metrics for Software

1
Product Metrics for Software

• Chapter 15
• Software Engineering A Practitioners Approach
• Roger S. Pressman

2
What are product metrics?

• Metrics measurable ways to design and assess the
  software product
• Process and project metrics apply to the project
  as a whole
• Project metrics focus on specific attributes of
  the project
• Collected as technical tasks are being conducted

3
Software quality

• Conformance to explicitly stated functional and
  performance requirements, explicitly documented
  development standards, and implicit
  characteristics that are expected of all
  professionally developed software.

4
McCalls quality factors

• Two categories of software quality factors
• Factors that can be directly measured (bugs or
  defects)
• Factors that can be measured only indirectly
  (usability or maintainability)
• Both sets can (and should) be measured

5
McCalls quality factors

• McCall, Richards, and Walters group these factors
  into three categories, focused on three aspects
  of a software product
• Its operational characteristics
• (PRODUCT OPERATION)
• Its ability to undergo change
• (PRODUCT REVISION)
• Its adaptability to new environments
• (PRODUCT TRANSITION)

6
McCalls quality factors
7
Product Operation

• Correctness
• the extent to which a program satisfies its
  specifications and fulfills the customers
  mission objectives
• Reliability
• the extent to which a program can be expected to
  perform its intended function with required
  precision
• Usability
• the amount of computing resources and code
  required by the program to perform its function

8
Product Operation (cont.)

• Integrity
• the extent to which access to software or data by
  unauthorized persons can be controlled
• Efficiency
• the effort required to learn, operate, prepare
  input for, and interpret output of a program

9
Product Revision

• Maintainability
• the effort required to locate and fix an error in
  a program
• Flexibility
• the effort required to modify an operational
  program
• Testability
• the effort required to test a program to ensure
  that it performs its intended function

10
Product Transition

• Portability
• the effort required to transfer the program from
  one hardware and/or software system to another
• Reusability
• the extent to which a program (or parts or a
  program) can be reused in other applications
• Interoperability
• the effort required to couple one system to
  another

11
McCalls quality factors

• It is difficult (and sometimes impossible) to
  directly measure all of these quality factors
• Many of McCalls metrics can only be measured
  subjectively
• The metrics may be in the form of a checklist to
  grade attributes of the software

12
Clarifying definitions

• Measure within the software engineering context,
  measure is a noun
• A measure provides a quantitative of the extent,
  amount, dimension, capacity, or size of some
  attribute of a product or process.
• Measurement is the act of determining a measure

13
Clarifying definitions

• Metric
• a quantitative measure of the degree to which a
  system, component, or process possesses a given
  attribute -- IEEE Standard Glossary
• Indicator
• a metric or combination of metrics that provides
  insight into the software process, project, or
  product itself.

14
Challenges of product metrics

• Attempts to develop a single, all-encompassing
  metric for software complexity have been called a
  search for the impossible holy grail
• Of the dozens proposed, each takes a slightly
  different (but valid) perspective

15
Challenges of product metrics

• Valid metrics for evaluation of a new car
• Body design
• Mechanical characteristics
• Cost
• Fuel economy
• Performance
• All valid metrics, but some may be at odds with
  one another
• Some metrics are subjective (attractiveness)

16
Challenges of product metrics

• Challenges are cause for caution
• However, these challenges are not cause to
  dismiss product metrics entirely
• Measurement is essential if quality is to be
  achieved

17
Metrics for Object-Oriented Design

• Much about OO design is subjective - a good
  programmer knows what makes good code
• To scale in size and complexity, a more objective
  view can benefit both expert and novice

18
Metrics for Object-Oriented Design

• Size
• Complexity
• Coupling
• Sufficiency
• Completeness

• Cohesion
• Primitiveness
• Similarity
• Volatility

19
Metrics for Object-Oriented Design

• Size defined in terms of four views
• Population static count of OO entities such as
  classes or operations
• Volume identical to population measure but taken
  dynamically at a given instant in time
• Length measure of a chain of interconnected
  design elements
• Functionality indirect indication of the value
  delivered to the customer

20
Metrics for Object-Oriented Design

• Complexity
• viewed in terms of structural characteristics by
  examining how classes are related to one another
• Coupling
• the physical connections between elements (e.g.
  the number of messages passed between objects)

21
Metrics for Object-Oriented Design

• Sufficiency
• the degree to which a design component fully
  reflects all properties of the application object
  it is modeling
• Completeness
• like sufficiency, but the abstraction is
  considered from multiple points of view, rather
  than simply the current application

22
Metrics for Object-Oriented Design

• Cohesion
• the degree to which the OO properties are part of
  the problem or design domain
• Primitiveness
• applied to both operations and classes, the
  degree to which an operation is atomic (similar
  to simplicity)

23
Metrics for Object-Oriented Design

• Similarity
• the degree to which multiple classes are similar
  in terms of structure, function, behavior, or
  purpose
• Volatility
• a measure of the likelihood that a change in
  design will occur

24
The CK Metrics Suite

• Chidamber and Kemerer have proposed six
  class-based design metrics for OO systems

• Weighted methods per class (WMC)
• Depth of the inheritance tree (DIT)
• Number of children (NOC)

• Coupling between object classes (CBO)
• Response for a class (RFC)
• Lack of cohesion in methods (LCOM)

25
The CK Metrics Suite

• Depth of the Inheritance tree (DIT)
• the maximum length from the node to the root of
  the tree
• as DIT grows, it becomes difficult to predict
  behavior of a class because of the high degree of
  inheritance
• Positively, large DIT values imply that many
  methods may be reused

26
The CK Metrics Suite

• Number of children (NOC)
• count of the subclasses immediately subordinate
  to a class
• as NOC grows, reuse increases
• as NOC grows, abstraction can become diluted
• increase in NOC means the amount of testing will
  increase

27
The CK Metrics Suite

• Coupling between object classes (CBO)
• the number of collaborations listed for a class
• as CBO increases, reusability of the class
  decreases
• high CBO values complicate modifications
• in general, CBO values for each class should be
  kept as low as possible

28
The CK Metrics Suite

• Response for a class (RFC)
• the number of methods that can potentially be
  executed in response to a message received by an
  object
• as RFC increases, testing effort increases
  because the test sequence grows
• as RFC increases, the overall complexity of the
  class increases

29
The CK Metrics Suite

• Lack of cohesion in methods (LCOM)
• measure of the number of methods within a class
  that access the same instance variables
• if no methods access the same attributes, LCOM
  0
• as LCOM increases, coupling between methods (via
  attributes) increases, and thus class complexity
  increases