Answer:
Measurement
is fundamental to any engineering
discipline, and software engineering
is no exception. Measurement
enables us to gain insight by
providing a mechanism for objective
evaluation.
There are four reasons for measuring
software processes, products
and resources:
1. To characterize
2. To evaluate
3. To predict
4. To improve
We characterize to gain understanding of processes,
products, resources and environments,
and to establish baselines for
comparisons with future assessments.
We evaluate to determine status
with respect to plans. Measures
are the sensors that let us
know when our projects and processes
are drifting off track, so that
we can bring them back under
control.
We predict so that we can plan.
Measuring for prediction involves
gaining understandings of relationships
among processes and products
and building models of these
relationships, so that the values
we observe for some attributes
can be used to predict others.
We measure to improve when we
gather quantitative information
to help us identify roadblocks,
root causes, inefficiencies
and other opportunities for
improving product quality and
process performance.
Measures,
Measurement, Metrics, Threshold
and Indicators
Measure - A qualitative or quantitative
attribute used to ascertain
or appraise by comparing to
a standard.
Measurement - A figure, datum point, extent, or amount
obtained by measuring.
An extent or value obtained
by measuring.
Example: A systems's operating temperature is 97 degrees
centigrade. Degrees centigrade
is the standard measure.
Ninety-seven is the number of
multiples or fractions of the
standard, i.e., measurement,
being appraised.
Metric - The extent or degree to which a product possesses
and exhibits a quality, a property,
or an attribute.
Example: system's operating temperature is within the
acceptable range of 90-100 degrees
centigrade. The temperature
metric, with its associated
temperature range, provides
more information than if it
stated only that the system
is operating satisfactorily.
Threshold - A performance value or parameter necessary
to provide a capability.
Example: Safety requires a system operate between the
temperatures of 90 and 100 degrees
centigrade. The thresholds
of 90 degrees centigrade and
100 degrees centigrade provide
information on the acceptable
values of temperature.
Indicator - One or more measurements, which provide
insight when compared with the
established thresholds.
Example: During a system test, the system temperature
measurements slowly increased
from 97 degrees centigrade to
the maximum threshold
of 100 degrees centigrade at
test end. Although the system's
operating temperature was within
the established threshold
at the end of the test, the
slope or trend (indicator)
of the measurement data
indicates the system
probably would have exceeded
the maximum temperature threshold
had the test continued. Exceeding
temperature threshold
would cause the system to fail
its performance parameters.
In the context of Software we consider the following
examples:
For Measure the Number of errors
uncovered in the review
For Measurement the collection of
Number of errors in different
reviews.
For Metric the Average number of
errors found per review.
Process Indicators enable a
software engineering organization
to gain insight into the efficiency
of an existing process.
Project indicators enable a
software project manager to
1. Assess the status of an ongoing
project
2. Track potential risks
3. Uncover problem areas before they
go critical
4. Adjust workflows
5. Evaluate the project team's ability
to control quality of software
work
products.
Process sits at the center of
a triangle connecting three
factors that have a profound
influence on software quality
and organizational performance.
This triangle exists within
a circle of environmental conditions
that include the developmental
environment such as CASE tools,
business conditions such as
deadlines, business rules and
customer characteristics such
as communication.
According to Grady there are private
and public metrics. Because
it is natural that
individual software engineers
might be sensitive to the use
of metrics collected on an individual
and serve as an indicator for
the individual only. Hence
Private metrics are used to
measure the efficiency of an
individual.
Examples of Private Metrics: -
1)
Defect rates by Individual
2)
Defect rates by Module
3)
Errors found during development
The personal software process is
a structured set of process
descriptions, measurements and
methods that can help engineers
to improve their personal performance.
It provides the forms, scripts
and standards that help them
estimate and plan their work.
It shows them how to define
processes and how to measure
their quality and productivity.
A fundamental Personal Software
Process principle is that everyone
is different and that a method
that is effective for one engineer
may not be suitable for another.
The PSP thus
helps engineers to measure and
track their own work so they
can find the methods that are
best for them.
Private Process data can serve
as an important driver as the
individual software engineer
works to improve.
Some process metrics are private
to the software project team
but public to all team members.
Examples include defects reported
for major software functions
(that have been developed by
a number of practitioners),
error found during formal technical
reviews, and lines of code or
function points per module and
function. These dates are reviewed
by the team to uncover indicators
that can improve team performance.
Public metrics generally
assimilate information that
originally was private to individuals
and teams. Project level defect
rates (absolutely not attributed
to an individual), effort, calendar
times, and related data are
collected and evaluated in an
attempt to uncover indicators
that can improve organizational
process performance.
Project Metrics are used to
minimize the development schedule
by making the adjustments necessary
to avoid delays and mitigate
(lessens) potential problems
and risks. Second use of project
metrics is to assess product
quality on an ongoing basis
and, when necessary, modify
the technical approach to improve
quality.
Software Measurement:
There are two types: Direct
Measures and Indirect Measures.
Direct Measures of the software engineering
process include cost and effort
applied. Direct measures of
the product include lines of
code (LOC) produced, execution
speed, memory size, and defects
reported over some set period
of time.
Indirect measures of
the product include functionality,
quality, complexity, efficiency,
reliability, maintainability,
and many other "-abilities".
The cost and effort required
to build software, the number
of lines of code produced, and
other direct measures are relatively
easy to collect, as long as
specific conventions for measurement
are established in advance.
However, the quality and functionality
of software or its efficiency
or maintainability are more
difficult to assess and can
be measured only indirectly.
Product metrics that are private
to an individual are often combined
to develop project metrics that
are public to a software team.
Project metrics are then consolidated
to create process metrics that
are public to the software organization
as a whole.
Example: Individuals on two
different project teams A and
B record and categorize all
errors that they find during
the software process.
Individual measures are then
combined to develop team measures.
Team A found 342 errors during
the software process prior to
release. Team B found 184 errors.
These need to be normalized
in order to know the more effective
team in uncovering errors.
In size-oriented metrics the
Lines of code may be chosen
as normalization value. Size-oriented
metrics are:
Errors
Per KLOC
Defects
per KLOC
$
per LOC
Page of documentation per KLOC.
Size
oriented metrics are not universally
accepted as the best way to
measure the process of software
development. Function oriented
software metrics use a measure
of the functionality delivered
by the application as a normalization
value. These are:
Errors per Function Point
Defects per FP
$ per FP
Pages of documentation per FP
FP
per person-month
Cont...
