90 ◾ Simple Statistical Methods for Software Engineering
Code Complexity
Again, function point is a good enough metric of code complexity. If a tool is
available for measuring complexity, we can use the McCabe complexity number.
is cyclomatic complexity measures the amount of decision logic in a single soft-
ware module. Cyclomatic complexity is equal to the number of independent paths
through the standard control flow graph model.
Highly complex modules are more prone to error, harder to understand, harder
to test, and harder to modify. Limiting complexity helps. McCabe proposed 10 as
the limit, but higher levels of complexity are in use.
Defect Density
A common metric to express quality is known as defects per kilo lines of code
(KLOC) or defects per FP. e second formula can be used even in the design
phase.
BOX 6.2 THE FULL FUNCTIONPOINT: A BREAKTHROUGH
e full function point (FFP) revolutionized size measurement. A new
paradigm was invented: data movement is size. Full function points were
proposed in 1997 with the aim of offering a functional size measure spe-
cifically adapted to real-time software. It has been proven that FFP can
also capture the functional size of technical and system software and MIS
software.
FFP distinguishes four types of data movement subprocess: entry, exit,
read, and write, as identified in the context model of software. FFP makes
use of the measurement principle: the functional size of software is directly
proportional to the number of its data movement subprocesses.
Practice tends to show that the FFP approach, while offering results very
similar to those of the IFPUG approach when applied to MIS software, offers
more adequate results when applied to real-time, embedded, or technical soft-
ware by virtue of the fact that (a) its measurement functions are not bounded
by constants and (b) the level of granularity is more relevant to these types
of software. Furthermore, in situations requiring the measurement of smaller
pieces of software, the FFP approach offers a finer degree of granularity than
the one offered by the IFPUG approach by virtue of the identification and
measurement of subprocesses.
Serge Oligny and Alain Abran
Achieving Excellence in Software Development Using Metrics ◾ 91
Defect Classification
Orthogonal defect classification or its variant is considered as a very critical defect
measurement. From the classification, defect profile or defect signature can be
extracted.
Reliability
The price of reliability is the pursuit of the utmost simplicity. It
is a price which the very rich may find hard to pay.
C.A.R. Hoare
It is becoming a growing fashion to estimate reliability before dispatch. A suit-
able reliability model should be adopted for this purpose. A simple metric is failure
intensity, meaning the number of defects uncovered per unit time of testing or
usage.
Examples of Process Metrics
Review Effectiveness
is metric refers to the percentage of defects caught by review. More significantly,
it draws our attention to the review process. It is now a well-established fact that
review effectiveness improves quality and reduces time and cost, and this metric is
worth watching.
Test Effectiveness
is a straightforward calculation of defects found by test cases and is a very good
metric during the testing phase.
Program testing can be used to show the presence of bugs, but
never to show their absence!
Edsger Dijkstra
92 ◾ Simple Statistical Methods for Software Engineering
Test Coverage
ere are two expressions in use for this metric. First, we check how much of the
requirement is covered by test cases (requirements coverage). Second, we track how
much of the code is covered by testing (structural coverage) using a tool.
Subprocess Metrics
As the software development organization climbs the ladder of process maturity,
visibility into what we do increases. One way of achieving this deeper visibility is
to measure subprocesses.
For example, let us consider the case of “review process” and investigate con-
struction of subprocess metrics. e process of review is measured by review effec-
tiveness, the overall performance. To achieve subprocess measurement, review can
be divided into the following subprocesses:
◾ Preparation
◾ Individual review
◾ Group review by meeting
Metrics can be installed to monitor these subprocesses, for instance, as follows:
◾ Preparation effort
◾ Individual review effort
◾ Individual review speed
◾ Group review effort
◾ Group review speed
Subprocess metrics provide the following attractive benefits
◾ We can build process performance models with the data.
◾ We can predict the overall process outcome.
◾ We can establish control at the subprocess level and increase certainty of
achieving goals.
Achieving subprocess measurement is not easy. is requires voluntary effort
from people, very similar to the case of data collection in the personal software
process. We cannot force these metrics into the organization because these metrics
“intrude” into creative efforts. Providing data at the subprocess level require great
maturity and transparency. People resist subprocess data collection because of the
following reasons:
Achieving Excellence in Software Development Using Metrics ◾ 93
◾ e reasons for subprocess data collection are not clearly known.
◾ People hate micromanagement.
◾ People are quick to realize that already collected data have not been used
(a truth).
◾ People do not have time to think of process performance models.
◾ Scientific management is not a popular management style.
◾ People think that statistical process control is not relevant to software
development.
Achieving subprocess metrics therefore requires a cultural transformation.
Converting Metrics into Business Information
Project Dashboard
Project metric data can be transferred to a project dashboard, preferably visual, as
shown in Figure 6.1. e dash board must be updated, as completely as possible,
after every milestone is performed. Some metrics such as customer satisfaction may
be available less frequently, and this does not pose any serious problem. Achieving a
milestone based dashboard to display metric results is the difficult first step.
BOX 6.3 THE RIGHT METRIC FOR PROJECT DELAY
Project delay is often measured using a classic metric “schedule variance.”
is is one of those variance metrics and has enjoyed the favor of many prac-
titioners. e expression defining schedule variance is as follows:
Schedule variance
Actual schedule Estimated sc
=
−(
hhedule
Estimated schedule
)
× 100
If a 6-month project is delayed by 5 days, the schedule variance, according
to the previously mentioned definition, is calculated as follows: (5/180) × 100 =
2.8%. If the process specification limits are ±5%, this schedule performance
is acceptable, or, to a cursory glance, the deviation is not alarming.
Instead of measuring delay as a normalized variance, measure a schedule
slip expressed in actual calendar days by which the project is delayed, and
a new meaning emerges. In projects that deal with the Y2K problem, even
a single minute delay could play havoc. is is an example of the mean-
ing of slippage in real time. In this project, process compliance to preset
94 ◾ Simple Statistical Methods for Software Engineering
Test cases designed
Test cases executed
Test cases succeeded
Cumulative number
of test cases
1 2 3 4 5 6 7 8 9 10 11 12 13 14
Testing time (weeks)
Time to repair (h)
45
40
35
30
25
20
15
10
5
0
1 2 3 4 5 6 7
Planned value
(BCWS)
Earned value
(BCWP)
Budgeted cost
Time
Review date
Review date
RTarget date
Arrival
Closure
Testing time
Cumulative
defects
0.12
0.10
0.08
0.06
0.04
0.02
0
Defect
count
1 2 3 4 5 6 7 8 9 10
Component number
Requirements volatility %
−6
−5.2
−4.4
−3.6
−2.8
−2
−1.2
−0.4
0.4
1.2
2
2.8
3.6
4.4
5.2
6
6.8
7.6
8.4
9.2
10
10.8
11.6
12.4
13.2
14
14.8
15.6
16.4
17.2
18
0 1 2 3 4 5 6 7 8 9 10
Cutomer satisfaction index
Iteration 1
120
100
80
60
40
20
0
≤−100
(−100, −70]
(−70, −40]
(−40, −10]
(−10, 20]
(20, 50]
(50, 80]
(80, 110]
>110
EVA %
0.06
0.05
0.04
0.03
0.02
0.01
0
Milestone delivery bell curves
Delivery date
186
196
206
216
226
236
246
Risk 3%
Project delivery bell curve
Project day
Figure 6.1 Project dashboard.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.