CSCI 630 - Software Engineering
Product Metrics for Software
- Software engineers use product metrics to help them assess the quality of
the design and construction of the software product being built.
- first, derive software measures and metrics that are appropriate for
the software representation under consideration
- data are collected
- metrics are computed
- metrics are compared to pre-established guidelines and historical data
- results of comparisons are used to guide modifications made to work
products arising from analysis, design, coding, or testing
- Software Quality Principles - a Qualitative View
- Conformance to software requirements is the foundation from which quality
is measured.
- Specified standards define a set of development criteria that guide
the manner in which software is engineered.
- Software quality is suspect when a software product conforms to its
explicitly stated requirements and fails to conform to the customer's
implicit requirements (e.g., ease of use).
- ISO 9126 Quality Factors
- Functionality
- Reliability
- Usability
- Efficiency
- Maintainability
- Portability
- Product Metrics
- Benefits of Product Metrics
- Assist in the evaluation of the analysis and design models
- Provide indication of procedural design complexity and source code
complexity
- Facilitate design of more effective testing
- Measurement Process Activities

- Measurement Principles
- The objectives of measurement should be established before collecting
any data.
- Each product metric should be defined in an unambiguous manner.
- Metrics should be derived based on a theory that is valid for the
application domain.
- Metrics should be tailored to accommodate specific products and
processes.

- Metrics Characterization and Validation Principles
- A metric should have desirable mathematical properties
- The value of a metric should increase when positive software traits
occur or decrease when undesirable software traits are encountered
- Each metric should be validated empirically in several contexts
before it is used to make decisions
- Measurement Collection and Analysis Principles
- Automate data collection and analysis whenever possible
- Use valid statistical techniques to establish relationships between
internal product attributes and external quality characteristics
- Establish interpretive guidelines and recommendations for each metric
- Goal-Oriented Software Measurement (GQM)
- Attributes of Effective Software Metrics
- Important Metrics Areas
- Analysis Model Aspects
- Functionality delivered
- System size
- Specification quality
- Design Model Attributes
- Architecture metrics
- Component-level metrics
- Specialized OO Design Metrics
- Source Code Characteristics
- Halstead metrics
- Complexity metrics
- Length metrics
- Testing
- Statement and branch coverage metrics
- Defect-related metrics
- Testing effectiveness
- In-process metrics
- Representative Analysis Metrics

|
- Function-based metrics
- Representative Design Metrics
- Architectural design metrics
- Structural complexity (based on module fanout)
- Data complexity (based on module interface inputs and outputs)
- System complexity (sum of structural and data complexity)
- Morphology (number of nodes and arcs in program graph)
- Design structure quality index (DSQI)
- a formula involving derived measures based on:
- Object-Oriented design metrics
- characteristics of object-oriented designs that lead to specialized
design metrics
- categories of object-oriented design metrics
- Class-Oriented Metrics
- Chidamber and Kemerer - CK Metrics Suite
- Harrison, Counsel, and Nithi (MOOD) Metrics Suite
- method inheritance factor (MIF)
- coupling factor (CF)
- polymorphism factor (PF)
- Lorenz and Kidd
- class size (CS)
- number of operations overridden by a subclass (NOO)
- number of operations added by a subclass (NOA)
- specialization index (SI)
- Component-level design metrics
- Operation-Oriented Metrics
- Interface design metrics
- a function of layout entities
- the geographic position
- the cost of making transitions among entities
- Source Code Metrics
- Halstead's Metrics (lots of controversy here)
- Overall program length
- Potential minimum algorithm volume
- Actual algorithm volume (number of bits used to specify program)
- Program level (software complexity)
- Language level (constant for given language)
- Testing Metrics
- Metrics that predict the likely number of tests required during
various testing phases
- Function-based metrics (e.g., function points)
- Architectural design metrics
- Cyclomatic complexity can target modules that are candidates
for extensive unit testing
- Halstead effort
- Metrics that focus on test coverage for a given component
- Cyclomatic complexity lies at the core of basis path testing
- Object-Oriented Testing Metrics
- provide indication of the testability of an OO system
- Encapsulation
- Lack of cohesion in methods (LCOM)
- Percent public and protected (PAP)
- Public access to data members (PAD)
- Inheritance
- Number of root classes (NOR)
- Fan in (FIN)
- Number of children (NOC)
- Depth of inheritance tree (DIT)
- Class complexity
- Weighted metrics per class (WMC)
- Coupling between object classes (CBO)
- Response for a class (RFC)
- Maintenance Metrics
- Software Maturity Index (IEEE Standard 982.1-1988)
- SMI approaches 1.0 as product begins to stabilize
Notes and figures from:
- Software Engineering: A Practitioner's Approach, 6th Edition, by Roger S
Pressman, R.S. Pressman & Associates, McGraw-Hill, 2005