Chapter 23 - Product Metrics for Software

Overview

This chapter describes the use of product metrics in the software quality assurance process. Software engineers use product metrics to help them assess the quality of the design and construction 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.

 

Definitions

• Measure – provides a quantitative indication of the extent, amount, capacity, or size of some attribute of a product or process
• Measurement – act of determining a measure
• Metric – statistic that relates individual measures to one another
• Indicator – metric or combination of metrics that provide insight into the software process, software project, or the product itself to make things better

 

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

 

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)

• A goal definition template can be used to define each measurement goal
• GQM emphasizes the need

1. establish explicit measurement goal specific to the process activity or product characteristic being assessed
2. define a set of questions that must be answered in order to achieve the goal
3. identify well-formulated metrics that help to answer these questions

 

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
• Provide an effective mechanism for quality feedback

 

Requirements Model Metrics

• Function-based metrics

• Function points

• Specification quality metrics (Davis)\

• Specificity
• Completeness

 

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)
• number of operations added by a subclass (NOA)
• specialization index (SI)

 

Component-Level Design Metrics

• Cohesion metrics (data slice, data tokens, glue tokens, superglue tokens, stickiness)
• Coupling metrics (data and control flow, global, environmental)
• Complexity metrics (e.g. cyclomatic complexity)

 

Operation-Oriented Metrics

• Average operation size (OSavg)
• Operation complexity (OC)
• Average number of parameters per operation (NPavg)

 

Using WebApp Design Metrics

• Is the WebApp interface usable?
• Are the aesthetics of the WebApp pleasing to the user and appropriate for the information domain?
• Is the content designed to impart the most information for the least amount of effort?
• Is navigation efficient and straightforward?
• Has the WebApp architecture been designed to accommodate special goals and objectives of users, content structure, functionality, and effective navigation flow?
• Are the WebApp components designed to reduce procedural complexity and enhance correctness, reliability, and performance?

 

WebApp Interface Metrics

• Layout appropriateness
• Layout complexity
• Layout region complexity
• Recognition complexity
• Recognition time
• Typing effort
• Mouse pick effort
• Selection complexity
• Content acquisition time

 

Aesthetic (graphic layout) metrics

• Word count
• Body text percentage
• Emphasized body text %
• Text positioning count
• Text cluster count
• Link count
• Page size
• Graphic percentage
• Graphics count
• Color count
• Font count

 

Content Metrics

• Page wait
• Page complexity
• Graphic complexity
• Audio complexity
• Video complexity
• Animation complexity
• Scanned image complexity

 

Navigation Metrics

• Page link complexity
• Connectivity
• Connectivity density

 

Halstead’s Software Science (Source Code Metrics)

• 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

• 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

• 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)

 

Maintenance Metrics

• Software Maturity Index (IEEE Standard 982.1-1988)
• SMI approaches 1.0 as product begins to stabilize