Product Metrics for Software - PowerPoint PPT Presentation


PPT – Product Metrics for Software PowerPoint presentation | free to view - id: 852a3-ZDc1Z


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation

Product Metrics for Software


Process and project metrics apply to the project as a whole ... component, or process possesses a given attribute' -- IEEE Standard Glossary ... – PowerPoint PPT presentation

Number of Views:279
Avg rating:3.0/5.0
Slides: 30
Provided by: AdamM98


Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Product Metrics for Software

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

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

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.

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

McCalls quality factors
  • McCall, Richards, and Walters group these factors
    into three categories, focused on three aspects
    of a software product
  • Its operational characteristics
  • Its ability to undergo change
  • Its adaptability to new environments

McCalls quality factors
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
  • Usability
  • the amount of computing resources and code
    required by the program to perform its function

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

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

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

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
  • The metrics may be in the form of a checklist to
    grade attributes of the software

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

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.

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

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)

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

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

Metrics for Object-Oriented Design
  • Size
  • Complexity
  • Coupling
  • Sufficiency
  • Completeness
  • Cohesion
  • Primitiveness
  • Similarity
  • Volatility

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

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)

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

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)

Metrics for Object-Oriented Design
  • Similarity
  • the degree to which multiple classes are similar
    in terms of structure, function, behavior, or
  • Volatility
  • a measure of the likelihood that a change in
    design will occur

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)

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
  • Positively, large DIT values imply that many
    methods may be reused

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

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

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
  • as RFC increases, testing effort increases
    because the test sequence grows
  • as RFC increases, the overall complexity of the
    class increases

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
  • as LCOM increases, coupling between methods (via
    attributes) increases, and thus class complexity