A Goalbased Framework for
Software Measurement
Lecture # 40B
1
A Goalbased Framework for
Software Measurement
• Today, we’ll talk about a conceptual
framework for the diverse software
measurement activities that contribute to an
organization’s software practices
• These practices may include not only your
usual development and maintenance
activities, but also any experiments and case
studies you may perform as you investigate
new techniques and tools
2
A Goalbased Framework for
Software Measurement
• This framework is based on three
principles:
– Classifying the entities to be examined
– Determining relevant measurement tools
– Identifying the level of maturity that your
organization has reached
3
Classifying Software Measures
4
• The first obligation of any software
measurement activity is identifying the
entities and attributes we wish to measure
• In software, there are three such classes
(discussed next):
5
• Processes
– These are collections of softwarerelated
activities
• Products
– These are any artifacts, deliverables or
documents that result from a process activity
• Resources
– These are entities required by a process activity
6
• A process is usually associated with some
timescale, i.e., the activities in the process are
ordered or related in some way that depends
on time, so that one activity must be
completed before another can begin
• The timing can be explicit, as when design
must be complete by October 31, or implicit,
as when a flow diagram shows that design
must be completed before coding can begin 7
• Resources and products are associated with
the process
• Each process activity has resources and
products that it uses, as well as products
that are produced
• Thus, the product of one activity may feed
another activity, e.g., the design document
8
• Before, we discuss these entities in detail,
let’s distinguish between internal and
external attributes:
– Internal attributes
– External attributes
9
Internal Attributes
• Internal attributes of a product, process or
resource are those that can be measured
purely in terms of the product, process or
resource itself
• In other words, an internal attribute can be
measured by examining the product,
process or resource on its own, separate
from its behavior
10
External Attributes
• External attributes of a product, process or
resource are those that can be measured
only with respect to how the product,
process or resource relates to its
environment
• Here, the behavior of the process, product
or resource is important, rather than the
entity itself
11
Examples of Internal and
External Attributes
• Some attributes of software can be
determined without executing it, like,
software size, its complexity, and the
dependencies among modules
• Some attributes of software can only be
measured when code is executed, like, the
number of failures experienced by a user,
difficulty in navigating screens, database
search time
12
• There is a clear need for internal attribute
measurements to support measurement and
decision making about external attributes
• We need to identify the relationships among
internal and external attributes, as well as to
find new and useful methods for measuring
directly the attributes of interest
13
Processes (3.1.1)
• We often have questions about our software
development activities and processes that
measurement can help us answer
• We want to know how long it takes for a
process to complete, how much it will cost,
whether it is effective or efficient, and how
it compares with other processes that we
could have chosen
14
• However, only a limited number of internal
process attributes can be measured directly
• These measures include:
– The duration of the process or one of its
activities;
– The effort associated with the process or one of
its activities;
– The number of incidents of a specified type
arising during the process or one of its activities
15
• For example, we may be reviewing our
requirements to ensure their quality before
turning them over to the designers
• To measure the effectiveness of the review
process we can measure the number of
requirements errors found during
specification
16
• We can measure the number of
requirements errors found during
integration testing to determine how well
we are doing
• We can get insight into the resources
needed for development process by
measuring the number of personnel working
on the project between May 1 and
September 30
17
Average Cost of each Defect
Detected during the process
18
Average Cost of each Defect
Detection during the Process
Cost
Number of Errors Found
this is an indirect measure
19
Effectiveness of Software Inspections
20
Effectiveness of Software
Inspections
Measure the average amount of effort
expended per thousand lines of code
reviewed
21
Effectiveness of Software Testing
Process
22
Effectiveness of Software
Testing Process
The testing process may be composed of unit testing,
integration testing, system testing, and acceptance
testing
Each component process can be measured to
determine how effectively it contributes to overall
testing effectiveness
We can track the number of errors identified in each
subprocess, along with the duration and cost of
identifying each error, to see if each subprocess is
23
costeffective
• Cost is not the only process measure we can
examine
• Controllability, observability, and stability
are also important in managing large
projects
• These attributes are clearly external
24
• We often use propose objective measures of
external attributes in terms of internal
attributes
• For example, measures of the effectiveness
of code maintenance can be defined in
terms of the number of faults discovered
and the number of faults corrected
25