85
Chapter 6
Achieving Excellence in
Software Development
Using Metrics
We have seen metric development to suit the context, address needs and fulfill per-
formance goals in Chapter 5. Now we shall discuss how to apply metrics to manage
the software development cycle and achieve excellent results.
Let us look at a few representative metrics shown in the following paragraphs
for developing the approach. For a comprehensive study of metrics, see Fenton [1],
Grady [2], Stephan Kan [3], Pandian [4], and Putnam [5].
Examples of Project Metrics
Time to Deliver
The first 90 percent of the code accounts for the first 90 percent
of the development time … The remaining 10 percent of the
code accounts for the other 90 percent of the development time.
Tom Cargill
86 ◾ Simple Statistical Methods for Software Engineering
is is the most serious concern of any project manager, time being a scarce
resource that cannot be bought out but can only be saved. e trick is to track time
performance using any convenient metric every milestone. e metric could be
schedule variance or schedule slippage or earned value metrics (EVM).
Cost
is metric is tracked often as man days; the overhead can be added by a finance
expert.
Quality
Every work product quality should be tracked by counting defects and normalizing
the defect count by an appropriate expression of size.
Productivity
Size developed per man day is a common expression of this metric. ere are several
other definitions to choose from depending upon the purpose of measurement.
Time to Repair
e time taken to fix bugs is an important metric and is tracked automatically
through the bug tracking tool.
Customer Satisfaction
is metric is obtained using quarterly surveys or annual surveys.
Requirement Volatility
Score creep or requirement volatility is a crucial metric and is to be closely tracked
by the project team.
Examples of Product Metrics
Requirement Size
Requirement management suggests we measure the size in terms of number of
features or number of pages or simply the number of requirements. Some use “use
case points” or another specially designed metric.
Achieving Excellence in Software Development Using Metrics ◾ 87
Design Complexity
With proper design, the features come cheaply. This approach
is arduous, but continues to succeed.
Dennis Ritchie
Function point (FP) and its variants can be used to judge design complexity; we
need to measure the flow of information from and into every module. A summary
of function point metrics is presented by Caper Jones [6].
A simple design metric has been proposed by Ball State University [7]:
e external design metric De is defined as
De = e1 (inflows * outflows) + e2 (fan-in * fan-out)
where inflows is the number of data entities passed to the module from
superordinate or subordinate modules plus external entities, outflows is
the number of data entities passed from the module to superordinate
or subordinate modules plus external entities, fan-in and fan-out are
the number of superordinate and subordinate modules, respectively,
directly connected to the given module, and e1 and e2 are weighting
factors.
e internal design metric Di is defined as
Di = i1 (CC) + i2 (DSM) + i3 (I/O)
where CC, the Central Calls, is the number of procedure or function
invocations, DSM, the Data Structure Manipulations, is the number of
references to complex data types, which are data types that use indirect
addressing, I/O, the Input/Output, is the number of external device
accesses, and i1, i2, and i3 are weighting factors.
D(G) is a linear combination of the external design metric De and
the internal design metric Di and has the form
D(G) = De + Di
88 ◾ Simple Statistical Methods for Software Engineering
e calculation of De is based on information available during
architectural design, whereas Di is calculated when detailed design is
completed.
e need for a Design Metric cannot be overemphasized. Good design makes
the remaining phases of software development a smooth journey.
BOX 6.1 MEET THE EXPERTALLAN J. ALBRECHT:
THE FATHER OF FUNCTION POINT
Allan J. Albrecht (1927–2010), the father of function points, never imag-
ined that function points would be used by a large user community spread
around several countries. Allan clearly outlined productivity as work prod-
uct output divided by work effort. However, it was the development of the
function point analysis concept as a means of identifying work product
that has been his greatest contribution. Allan Albrecht’s ideas shaped many
careers.
Function point metrics were invented at IBM’s White Plains development
center in 1975. Function point metrics were placed in the public domain by
IBM in 1978. Responsibility for function point counting rules soon trans-
ferred to the IFPUG.
e original formula was simple and can be used quickly without any
hassle. e weights he used in the formula proved to be right and remained
valid long after his invention. IBM advertised FP as a key to success and
grabbed huge software development orders.
He developed the function point metric in response to a
business need, to enable IBM customers for application
software to state their requirements in a way that reflected
the function of a proposed software system in terms that
Achieving Excellence in Software Development Using Metrics ◾ 89
Code Size
A good way to stay flexible is to write less code.
Pragmatic Programmer
e size of developed, deleted, modified, or reused code must be tracked as lines
of code. Distinction can be made between executable and comment lines.
If function point metric is selected (in all phases), we can first calculate func-
tional size using the original formula invented by Allan J. Albrecht:
EI × 4 = _____
EO × 5 = _____
EQ × 4 = _____
ILF × 10 = _____
EIF × 7 = _____
Total FP = _____
where EI is the external input, EO is the external output, EI is the external inquiry,
ILF is the internal logical file, and EIF is the external interface file.
e International Function Point User’s Group (IFPUG) has introduced a
detailed FP counting method in 1986 [8]. e results still agree with Albrecht’s
formula, but counting has become more precise. e IFPUG rules are time con-
suming to apply.
they could readily deal with, not the more technical lan-
guage, e.g., SLOC counts, of the software developers.
This was truly a major step forward in the state of the art,
and in the state of practice of our profession.
John Gaffney
FP could be applied to all programming languages and across all develop-
ment phases; this helps development management and simplifies benchmark-
ing. FP is a better predictor of defects than lines of code. FP is also a more
effective estimator of cost and time.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.