SOFT ENG FINALS CHAPTER 6

A Comment

McCall’s quality factors were proposed in the early 1970s. They are as valid today as they were in that time. It’s likely that software built to conform to these factors will exhibit high quality well into the 21st century, even if there are dramatic changes in technology.

Measures

provides a quantitative indication of the extent, amount, dimension, capacity, or size of some attribute of a product or process

Metric

IEEE Glossary - “a quantitative measure of the degree to which a system, component, or process possesses a given attribute.”

Indicator

is a metric or combination of metrics that provide insight into the software process, a software project, or the product itself

Measurement Principles

The objectives of measurement should be established before data collection begins;

Each technical metric should be defined in an unambiguous manner;

Metrics should be derived based on a theory that is valid for the domain of application (e.g., metrics for design should draw upon basic design concepts and principles and attempt to provide an indication of the presence of an attribute that is deemed desirable);

Metrics should be tailored to best accommodate specific products and processes [Bas84]

Formulation

The derivation of software measures and metrics appropriate for the representation of the software that is being considered.

Collection

The mechanism used to accumulate data required to derive the formulated metrics.

Analysis

The computation of metrics and the application of mathematical tools.

Interpretation

The evaluation of metrics results in an effort to gain insight into the quality of the representation.

Feedback

Recommendations derived from the interpretation of product metrics transmitted to the software team.

The Goal/Question/Metric Paradigm

(1) establish an explicit measurement goal that is specific to the process activity or product characteristic that is to be assessed

(2) define a set of questions that must be answered in order to achieve the goal, and

(3) identify well-formulatedmetrics that help to answer these questions

Goal definition template

Analyze {the name of activity or attribute to be measured}

for the purpose of {the overall objective of the analysis}

with respect to {the aspect of the activity or attribute that is considered}

from the viewpoint of {the people who have an interest in the measurement}

in the context of {the environment in which the measurement takes place}.

Simple and computable

It should be relatively easy to learn how to derive the metric, and its computation should not demand inordinate effort or time

Empirically and intuitively persuasive

The metric should satisfy the engineer’s intuitive notions about the product attribute under consideration

Consistent and objective

The metric should always yield results that are unambiguous.

Consistent in its use of units and dimensions

The mathematical computation of the metric should use measures that do not lead to bizarre combinations of unit.

Programming language independent

Metrics should be based on the analysis model, the design model, or the structure of the program itself.

Effective mechanism for quality feedback

That is, the metric should provide a software engineer with information that can lead to a higher quality end product

Function-based metrics

use the function point as a normalizing factor or as a measure of the “size” of the specification

Specification metrics

used as an indication of quality by measuring number of requirements by type

function point metric (FP)

first proposed by Albrecht [ALB79], can be used effectively as a means for measuring the functionality delivered by a system.

Function points

are derived using an empirical relationship based on countable (direct) measures of software's information domain and assessments of software complexity

HK metric

architectural complexity as a function of fan-in and fan-out

Morphology metrics

a function of the number of modules and the number of interfaces between modules

Size

defined in terms of four views: population, volume, length, and functionality

Complexity

How classes of an OO design are interrelated to one another

Coupling

The physical connections between elements of the OO design

Sufficiency

“the degree to which an abstraction possesses the features required of it, or the degree to which a design component possesses features in its abstraction, from the point of view of the current application.”

Completeness

An indirect implication about the degree to which the abstraction or design component can be reused

Cohesion

The degree to which all operations working together to achieve a single, well-defined purpose

Primitiveness

Applied to both operations and classes, the degree to which an operation is atomic

Similarity

The degree to which two or more classes are similar in terms of their structure, function, behavior, or purpose

Volatility

Measures the likelihood that a change will occur

Localization

the way in which information is concentrated in a program

Encapsulation

the packaging of data and processing

Information hiding

the way in which information about operational details is hidden by a secure interface

Inheritance

the manner in which the responsibilities of one class are propagated to another

Abstraction

the mechanism that allows a design to focus on essential details

Proposed by Chidamber and Kemerer

weighted methods per class

depth of the inheritance tree

number of children

coupling between object classes

response for a class

lack of cohesion in methods

Proposed by Lorenz and Kidd

class size

number of operations overridden by a subclass

number of operations added by a subclass

specialization index

The MOOD Metrics Suite

Method inheritance factor

Coupling factor

Polymorphism factor

Cohesion metrics

a function of data objects and the focus of their definition

Coupling metrics

a function of input and output parameters, global variables, and modules

Complexity metrics

hundreds have been proposed (e.g., cyclomatic complexity)

Layout appropriateness

a function of layout entities, the geographic position and the “cost” of making transitions among entities

Halstead’s Software Science

a comprehensive collection of metrics all predicated on the number (count and occurrence) of operators and operands within a component or program

Testing effort

can also be estimated using metrics derived from Halstead measures

Binder

suggests a broad array of design metrics that have a direct influence on the “testability” of an OO system.

IEEE Std. 982.1-1988

suggests a software maturity index (SMI) that provides an indication of the stability of a software product (based on changes that occur for each release of the product)