This chapter describes the use of product metrics in the software quality assurance process. The use of metrics for project management is discussed later in the text. Software engineers use product metrics to help them assess the quality of the design and construction of the software product being built. Product metrics provide software engineers with a basis to conduct analysis, design, coding, and testing more objectively. Qualitative criteria for assessing software quality are not always sufficient by themselves. The process of using product metrics begins by deriving the software measures and metrics that are appropriate for the software representation under consideration. Then data are collected and metrics are computed. The metrics are computed and compared to pre-established guidelines and historical data. The results of these 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).
McCall's Quality Factors
Product Operation
Correctness
Efficiency
Integrity
Reliability
Usability
Product Revision
Flexibility
Maintainability
Testability
Product Transition
Interoperability
Portability
Reusability
McCall's Software Metrics
Auditability
Accuracy
Communication commonality
Completeness
Consistency
Data commonality
Error tolerance
Execution efficiency
Expandability
Generality
Hardware independence
Instrumentation
Modularity
Operability
Security
Self-documentation
Simplicity
Software system independence
Traceability
Training
ISO 9126 Quality Factors
Functionality
Reliability
Usability
Efficiency
Maintainability
Portability
Benefits of Product Metrics
Assist in the evaluation of the analysis and evaluation model
Provide indication of procedural design complexity and source code complexity
Facilitate design of more effective testing
Measurement Process Activities
Formulation - derivation of software measures and metrics appropriate for software representation being considered
Collection - mechanism used to accumulate the date used to derive the software metrics
Analysis - computation of metrics
Interpretation - evaluation of metrics that results in gaining insight into quality of the work product
Feedback - recommendations derived from interpretation of the metrics is transmitted to the software development team
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)
GQM emphasizes the need
establish explicit measurement goal specific to the process activity or product characteristic being assessed
define a set of questions that must be answered in order to achieve the goal
identify well-formulated metrics that help to answer these questions
A goal definition template can be used to define each measurement goal
Attributes of Effective Software Metrics
Simple and computable
Empirically and intuitively persuasive
Consistent and objective
Consistent in use of units and measures
Programming language independent
Provides an effective mechanism for quality feedback
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
Specification quality metrics (Davis)
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)
OO design metrics
Size (population, volume, length, functionality)
Complexity (how classes interrelate to one another)
Coupling (physical connections between design elements)
Sufficiency (how well design components reflect all properties of the problem domain)
Completeness (coverage of all parts of problem domain)
Cohesion (manner in which all operations work together)
Primitiveness (degree to which attributes and operations are atomic)
Similarity (degree to which two or more classes are alike)
Volatility (likelihood a design component will change)
Class-Oriented Metrics
Chidamber and Kemerer (CK) Metrics Suite
weighted metrics per class (WMC)
depth of inheritance tree (DIT)
number of children (NOC)
coupling between object classes (CBO)
response for a class (RFC)
lack of cohesion in methods (LCOM)
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)
