Product Metrics for Software - PowerPoint PPT Presentation

Loading...

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



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Product Metrics for Software

Description:

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
Category:

less

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

Title: 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 has 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
About PowerShow.com