Software Module 4

108 Software Engineering
Unit 6: Software Metrics

Notes
Structure
6.1 Introduction
6.2 Software Metrics
6.3 Size Metrics
6.4 Classification of Metrics
6.4.1 Size-oriented Metrics
6.4.2 Function-oriented Metrics
6.4.3 Extended Function Point Metrics
6.4.4 Cyclomatic Complexity
6.4.5 Metrics for Software Quality
6.4.6 Design Metrics
6.4.7 Object Oriented Software Metrics
6.5 Metric Analysis
6.5.1 Function-based Metrics
6.6 Summary
6.7 Check Your Progress
6.8 Questions and Exercises
6.9 Key Terms
6.10 Further Readings
Objectives
After studying this unit, you should be able to:
z Understand the concept of Software metrics
z Learn about the Classification of metrics
z Understand the Metric Analysis Process
6.1 Introduction
Software metrics deal with the measurement of the software product and process by
which it is developed. Several objectives of software metrics are discussed. Different
types of metrics such as size metrics, object oriented metrics, communication metrics
and requirements metrics are discussed in detail.
6.2 Software Metrics

Poor size estimation is one of the main reasons major software-intensive acquisition
programs ultimately fail. Size is the critical factor in determining cost, schedule, and
effort. The failure to accurately predict (usually too small) results in budget overruns and
late deliveries which undermine confidence and erode support for your program. Size
estimation is a complicated activity, the results of which must be constantly updated
with actual counts throughout the life cycle. Size measures include source lines-of-
code, function points, and feature points. Complexity is a function of size, which greatly
impacts design errors and latent defects, ultimately resulting in quality problems, cost
overruns, and schedule slips. Complexity must be continuously measured, tracked, and
Amity Directorate of Distance and Online Education

Software Metrics 109
controlled. Another factor leading to size estimate inaccuracies is requirements creep
which also must be baseline and diligently controlled. Software metrics measure
different aspects of software complexity and therefore play an important role in Notes
analyzing and improving software quality. Pervious research has indicated that they
provide useful information on external quality aspects of software such as its
maintainability, reusability and reliability. Software metrics provide a mean of estimating
the efforts needed for testing. Software metrics are often categorized into products and
process metrics.
Advantage of Software Metrics

z In Comparative study of various design methodology of software systems.
z For analysis, comparison and critical study of various programming language with
respect to their characteristics.
z In comparing and evaluating capabilities and productivity of people involved in
software development.
z In the preparation of software quality specifications.
z In the verification of compliance of software systems requirements and
specifications.
z In making inference about the effort to be put in the design and development of the
software systems.
z In getting an idea about the complexity of the code.
z In taking decisions regarding further division of complex module is to be done or
not.
z In providing guidance to resource manager for their proper utilization.
z In comparison and making design tradeoffs between software development and
maintenance cost.
z In providing feedback to software managers about the progress and quality during
various phases of software development life cycle.
z In allocation of testing resources for testing the code.
Limitation of Software Metrics

z The application of software metrics is not always easy and in some cases it is
difficult and costly.
z The verification and justification of software metrics is based on historical/empirical
data whose validity is difficult to verify.
z These are useful for managing the software products but not for evaluating
performance of the technical staff.
z The definition and derivation of Software metrics is generally based on assuming
which are not standardized and may depend upon tools available and working
environment.
z Most of the predictive models rely on estimates of certain variables which are often
not known exactly.
z Most of the software development models are probabilistic and empirical.
6.3 Size Metrics

Line of Code
z It is one of the earliest and simpler metrics for calculating the size of computer
program.
z It is generally used in calculating and comparing the productivity of programmers.
z Productivity is measured as LOC/man-month.

z Any line of program text excluding comment or blank line, regardless of the number
of statements or parts of statements on the line, is considered a Line of Code.
Notes
Token Count
In this metrics, a computer program is considered to be a collection of tokens, which
may be classified as either operators or operands. All software science metrics can be
defined in terms of these basic symbols. These symbols are called as token. The basic
measures are n1 = count of unique operators.
n2 = count of unique operands.
N1 = count of total occurrences of operators.
N2 = count of total occurrence of operands. In terms of the total tokens used, the
size of the program can be expressed as N = N1 + N2
Function Count
z The size of a large software product can be estimated in better way through a larger
unit called module. A module can be defined as segment of code which may be
compiled independently.
z For example, let a software product require n modules. It is generally agreed that
the size of module should be about 50-60 line of code. Therefore size estimate of
this Software product is about n x 60 line of code.
6.4 Classification of Metrics

Measurements in the physical world can be categorized in two ways: direct measures
(e.g., the length of a bolt) and indirect measures (e.g., the "quality" of bolts produced,
measured by counting rejects). Software metrics can be categorized similarly.
A direct metric is "a metric that does not depend upon a measure of any other
attribute." Direct metrics are important under Standard 1061, because a direct metric is
presumed valid and other metrics are validated in terms of it ("Use only validated
metrics (i.e. either direct metrics or metrics validated with respect to direct metrics)").
"Direct" measurement is often used synonymously with "fundamental" measurement
and contrasted with indirect or derived measurement.
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.
The contrast between direct measurement and indirect, or derived measurement, is
between a (direct) metric function whose domain is only one variable and a (derived)
function whose domain is an n-tuple. For example, density is a function of mass and
volume. Some common derived metrics in software engineering are:
z Programmer productivity (code size/ programming time)
z Module defect density (bugs / module size)
z Requirements stability (number of initial requirements / total number of
requirements)
z System spoilage (effort spent fixing faults / total project effort)

In this section, we will discuss the different types of metrics.
6.4.1 Size-oriented Metrics Notes

Size-oriented software metrics are derived by normalizing quality and/or productivity
measures by considering the size of the software that has been produced. If a software
organization maintains simple records, a table of size-oriented measures, such as the
one shown in Figure 6.1, can be created. The table lists each software development
project that has been completed over the past few years and corresponding measures
for that project. Referring to the table entry (Figure 6.1) for project alpha: 12,100 lines of
code were developed with 24 person-months of effort at a cost of $168,000. It should be
noted that the effort and cost recorded in the table represent all software engineering
activities (analysis, design, code, and test), not just coding. Further information for
project alpha indicates that 365 pages of documentation were developed, 134 errors
were recorded before the software was released, and 29 defects were encountered
after release to the customer within the first year of operation.
Figure 6.1: Size-oriented Metrics
Three people worked on the development of software for project alpha.

In order to develop metrics that can be assimilated with similar metrics from other
projects, we choose lines of code as our normalization value. From the rudimentary
data contained in the table, a set of simple size-oriented metrics can be developed for
each project:
z Errors per KLOC (thousand lines of code).
z Defects per KLOC.
z $ per LOC.
z Page of documentation per KLOC.
In addition, other interesting metrics can be computed:
z Errors per person-month.
z LOC per person-month.
z $ per page of documentation.
Size-oriented metrics are not universally accepted as the best way to measure the
process of software development. Most of the controversy swirls around the use of lines
of code as a key measure. Proponents of the LOC measure claim that LOC is an
"artifact" of all software development projects that can be easily counted, that many

existing software estimation models use LOC or KLOC as a key input, and that a large
body of literature and data predicated on LOC already exists. On the other hand,
Notes opponents argue that LOC measures are programming language dependent, that they
penalize well-designed but shorter programs, that they cannot easily accommodate
nonprocedural languages, and that their use in estimation requires a level of detail that
may be difficult to achieve (i.e., the planner must estimate the LOC to be produced long
before analysis and design have been completed).
6.4.2 Function-oriented Metrics

Function-oriented software metrics use a measure of the functionality delivered by the
application as a normalization value. Since ‘functionality’ cannot be measured directly, it
must be derived indirectly using other direct measures. Function-oriented metrics were
first proposed by Albrecht, who suggested a measure called the function point. Function
points are derived using an empirical relationship based on countable (direct) measures
of software's information domain and assessments of software complexity.
Figure 6.2: Computing Function Point
Function points are computed by completing the table shown in Figure 6.2. Five
information domain characteristics are determined and counts are provided in the
appropriate table location. Information domain values are defined in the following
manner:
z Number of user inputs: Each user input that provides distinct application-oriented
data to the software is counted. Inputs should be distinguished from inquiries, which
are counted separately.
z Number of user outputs: Each user output that provides application-oriented
information to the user is counted. In this context output refers to reports, screens,
error messages, etc. Individual data items within a report are not counted
separately.
z Number of user inquiries: An inquiry is defined as an on-line input that results in
the generation of some immediate software response in the form of an on-line
output. Each distinct inquiry is counted.
z Number of files: Each logical master file (i.e., a logical grouping of data that may
be one part of a large database or a separate file) is counted.
z Number of external interfaces: All machine readable interfaces (e.g., data files on
storage media) that are used to transmit information to another system are counted.
Once these data have been collected, a complexity value is associated with each
count. Organizations that use function point methods develop criteria for determining
whether a particular entry is simple, average, or complex. Nonetheless, the
determination of complexity is somewhat subjective.

To compute function points (FP), the following relationship is used:
FP = Count total × [0.65 + 0.01 × Σ (Fi)] Notes

where count total is the sum of all FP entries obtained from Figure 6.2.
The Fi (i = 1 to 14) are "complexity adjustment values" based on responses to the
following questions:
1. Does the system require reliable backup and recovery?
2. Are data communications required?
3. Are there distributed processing functions?
4. Is performance critical?
5. Will the system run in an existing, heavily utilized operational environment?
6. Does the system require on-line data entry?
7. Does the on-line data entry require the input transaction to be built over multiple
screens or operations?
8. Are the master files updated on-line?
9. Are the inputs, outputs, files, or inquiries complex?
10. Is the internal processing complex?
11. Is the code designed to be reusable?
12. Are conversion and installation included in the design?
13. Is the system designed for multiple installations in different organizations?
14. Is the application designed to facilitate change and ease of use by the user?
Each of these questions is answered using a scale that ranges from 0 (not
important or applicable) to 5 (absolutely essential). The constant values in Equation and
the weighting factors that are applied to information domain counts are determined
empirically.
Once function points have been calculated, they are used in a manner analogous to
LOC as a way to normalize measures for software productivity, quality, and other
attributes:
1. Errors per FP.
2. Defects per FP.
3. $ per FP.
4. Pages of documentation per FP.
5. FP per person-month.
6.4.3 Extended Function Point Metrics

The function point measure was originally designed to be applied to business
information systems applications. To accommodate these applications, the data
dimension (the information domain values discussed previously) was emphasized to the
exclusion of the functional and behavioral (control) dimensions. For this reason, the
function point measure was inadequate for many engineering and embedded systems
(which emphasize function and control). A number of extensions to the basic function
point measure have been proposed to remedy this situation.
A function point extension called feature points is a superset of the function point
measure that can be applied to systems and engineering software applications.
The feature point measure accommodates applications in which algorithmic
complexity is high. Real-time, process control and embedded software applications tend
to have high algorithmic complexity and are therefore amenable to the feature point.

To compute the feature point, information domain values are again counted and
weighted. In addition, the feature point metric counts new software characteristic
Notes algorithms. An algorithm is defined as “a bounded computational problem that is
included within a specific computer program”. Inverting a matrix, decoding a bit string,
or handling an interrupt are all examples of algorithms.
Another function point extension for real-time systems and engineered products has
been developed by Boeing. The Boeing approach integrates the data dimension of
software with the functional and control dimensions to provide a function-oriented
measure amenable to applications that emphasize function and control capabilities.
Called the 3D function point, characteristics of all three software dimensions are
“counted, quantified, and transformed” into a measure that provides an indication of the
functionality delivered by the software.
Counts of retained data (the internal program data structure; e.g., files) and external
data (inputs, outputs, inquiries, and external references) are used along with measures
of complexity to derive a data dimension count. The functional dimension is measured
by considering “the number of internal operations required to transform input to output
data”. For the purposes of 3D function point computation, a “transformation” is viewed
as a series of processing steps that are constrained by a set of semantic statements.
The control dimension is measured by counting the number of transitions between
states.
A state represents some externally observable mode of behavior, and a transition
occurs as a result of some event that causes the software or system to change its mode
of behavior (i.e., to change state). For example, a wireless phone contains software that
supports auto dial functions. To enter the auto-dial state from a resting state, the user
presses an Auto key on the keypad. This event causes an LCD display to prompt for a
code that will indicate the party to be called. Upon entry of the code and hitting the Dial
key (another event), the wireless phone software makes a transition to the dialing state.
When computing 3D function points, transitions are not assigned a complexity value.
To compute 3D function points, the following relationship is used:
Index = I + O + Q + F + E + T + R
Figure 6.2: Determining the Complexity of a Transformation for 3D Function Point
where I, O, Q, F, E, T, and R represent complexity weighted values for the elements

discussed already: inputs, outputs, inquiries, internal data structures, external files,
transformation, and transitions, respectively. Each complexity weighted value is
computed using the following relationship:
Complexity weighted value = NilWil + NiaWia + NihWih

where Nil, Nia, and Nih represent the number of occurrences of element i (e.g., out-
puts) for each level of complexity (low, medium, high); and Wil, Wia, and Wih are the
corresponding weights. The overall complexity of a transformation for 3D function points is Notes
shown in Figure 6.2.
It should be noted that function points, feature points, and 3D function points
represent the same thing—"functionality" or "utility" delivered by software. In fact, each
of these measures results in the same value if only the data dimension of an application
is considered. For more complex real-time systems, the feature point count is often
between 20 and 35 percent higher than the count determined using function points
alone.
The function point (and its extensions), like the LOC measure, is controversial.
Proponents claim that FP is programming language independent, making it ideal for
applications using conventional and nonprocedural languages; that it is based on data
that are more likely to be known early in the evolution of a project, making FP more
attractive as an estimation approach. Opponents claim that the method requires some
"sleight of hand" in that computation is based on subjective rather than objective data;
that counts of the information domain (and other dimensions) can be difficult to collect
after the fact; and that FP has no direct physical meaning—it's just a number.
6.4.4 Cyclomatic Complexity

It is invented by Thomas McCabe (1974) to measure the complexity of a program’s
conditional logic. It counts the number of decisions in the program, under the
assumption that decisions are difficult for people. It makes assumptions about decision-
counting rules and linear dependence of the total count to complexity.
Cyclomatic complexity, also known as V(G) or the graph theoretic number, is
probably the most widely used complexity metric in software engineering. Defined by
Thomas McCabe, it's easy to understand and calculate, and it gives useful results. This
metric considers the control logic in a procedure. It's a measure of structural complexity.
Low complexity is desirable.
How to calculate cyclomatic complexity?
CC = Number of decisions + 1
The cyclomatic complexity of a procedure equals the number of decisions plus one.
What are decisions? Decisions are caused by conditional statements. In Visual Basic
they are If..ElseIf..Else, Case, For..Next, Until, While, Catch and When. In order to get
CC, one simply counts the conditional statements. A multiway decision, the Select Case
block, typical counts as several conditional statements. The decisions counted for each
statement or construct are listed below.
Table 13.1: decisions Counted for Each Statement
Construct Decisions Reasoning

If..Then +1 An If statement is a single decision.
ElseIf..Then +1 ElseIf adds a new decision.
Else 0 Else does not cause a new decision. The decision is
at the If.
#If..#ElseIf..#Else 0 Conditional compilation adds no run-time decisions.
Select Case 0 Select Case initiates the following Case branches,
but does not add a decision alone.
Case +1 Each Case branch adds a new decision.
Case Else 0 Case Else does not cause a new decision. The
decisions were made at the other Cases.
For [Each] .. Next +1 There is a decision at the For statement.
Do While|Until +1 There is a decision at the start of the Do..Loop.

Loop While|Until +1 There is a decision at the end of the Do..Loop.

Do..Loop alone 0 There is no decision in an unconditional Do..Loop
Notes without While or Until. *
While +1 There is a decision at the start of the While..Wend or
While..End While loop.
Catch +1 Each Catch branch adds a new conditional path of
execution. Even though a Catch can be either
conditional (catches specific exceptions) or
unconditional (catches all exceptions), we treat all of
them the same way. *
Catch..When +2 The When condition adds a second decision. *
* Rules marked with an asterisk were added into Project Analyzer v8.0. Previous versions did not take these
rules into account.
The minimum limit for cyclomatic complexity is 1. This happens with a procedure
having no decisions at all. There is no maximum value since a procedure can have any
number of decisions.
Notes:
z A Case branch can cover several alternative values or ranges, such as Case 1, 2, 5
To 10. As they introduce no additional branches to decide on, they do not increase
cyclomatic complexity either.
z Cyclomatic complexity does not consider if any decisions actually happen at run-
time. A conditional statement can be unconditional in reality. This happens with
constant decisions such as If True Then. This kind of an "unconditional condition"
counts as a regular decision in cyclomatic complexity, even when there is only one
path to take, really.
z Multiple exits do not increase complexity. A procedure with a single exit is as
complex as one with multiple exits.
z Exit statements (Exit Do, Exit Sub, Return, End, and similar) do not increase
cyclomatic complexity. They are not decisions, but jumps. Complexity-wise, exit
statements are similar to GoTo statements, with the target being either end-of-
structure or end-of-procedure.
z Yield statements do not increase cyclomatic complexity. Yield, new in VB2012, is
like a procedure call, but backwards, back to the caller procedure. Execution
potentially continues with the statement following Yield. If it doesn't, Yield is just a
special exit, which doesn't increase cyclomatic complexity either.
Variations: CC, CC2 and CC3

Cyclomatic complexity comes in a couple of variations as to what exactly counts as a
decision. Project Analyzer supports three alternative cyclomatic complexity metrics. CC
is the basic version. CC2 and CC3 use slightly different rules.
CC does not count Boolean operators such as And and Or. Boolean operators add
internal complexity to the decisions, but they are not counted in CC. CC and CC3 are
similar what comes to Booleans, but CC2 is different.
CC2 Cyclomatic complexity with Booleans ("extended cyclomatic complexity")

CC2 = CC + Boolean operators
CC2 extends cyclomatic complexity by including Boolean operators in the decision
count. Whenever a Boolean operator (And, Or, Xor, Eqv, AndAlso, OrElse) is found
within a conditional statement, CC2 increases by one. The statements considered are:
If, ElseIf, Select, Case, Until, While, When.

The reasoning behind CC2 is that a Boolean operator increases the internal
complexity of a decision. CC2 counts the "real" number of decisions, regardless of
whether they appear as a single conditional statement or split into several statements. Notes
Instead of using Boolean operators to combine decisions into one (x=1 And y=2), you
could as well split the decisions into several sub-conditions (If x=1 Then If y=2 Then).
CC2 is immune to this kind of restructuring, which might be well justified to make the
code more readable. On the other hand, one can decrease CC simply by combining
decisions with Boolean operators, which may not make sense.
Including Boolean operators in cyclomatic complexity was originally suggested by
Thomas McCabe. In this sense, both CC and CC2 are "original" cyclomatic complexity
measures.
Alternative names: CC2 is also known as ECC extended cyclomatic complexity or
strict cyclomatic complexity.
A Case branch can cover several alternative values or ranges, such as Case 1, 2, 5
To 10. These are not counted in CC2, even if they add internal complexity to the
decision, quite the same way as the Or operator does in an If statement. A Case with
several alternatives (Case 1, 2, 3) is usually simpler than the same decision as an If
statement (If x=1 Or x=2 Or x=3 Then). A Case like this will also yield a lower CC2 than
the respective If. Splitting the If statement into successive If..ElseIf branches will keep
CC2 unmodified, but rewriting it as a single Case will decrease CC2.
CC3 Cyclomatic complexity without Cases ("modified cyclomatic complexity")

CC3 = CC where each Select block counts as one
CC3 equals the regular CC metric, but each Select Case block is counted as one
branch, not as multiple branches. In this variation, a Select Case is treated as if it were
a single big decision. This leads to considerably lower complexity values for procedures
with large Select Case statements. In many cases, Select Case blocks are simple
enough to consider as one decision, which justifies the use of CC3.
Alternative name: CC3 is sometimes called modified cyclomatic complexity.
Summary of cyclomatic complexity metrics is shown in the table 13.2.
Table 13.2: Summary of Cyclomatic Complexity Metrics
Metric Name Boolean Select Case Alternative name

operators
CC Cyclomatic complexity Not counted +1 for each Case Regular cyclomatic
branch complexity
CC2 Cyclomatic complexity +1 for each +1 for each Case Extended or strict
with Booleans Boolean branch cyclomatic complexity
CC3 Cyclomatic complexity Not counted +1 for an entire Modified cyclomatic
without Cases Select Case complexity
CC, CC2 or CC3 — which one to use? This is your decision. Pick up the one that
suits your use best. CC and CC2 are "original" metrics and probably more widely used
than CC3. The numeric values are, in increasing order: CC3 (lowest), CC (middle) and
CC2 (highest). In a sense, CC2 is the most pessimistic metric. All of them are heavily
correlated, so you can achieve good results with any of them.
Values of Cyclomatic Complexity

A high cyclomatic complexity denotes a complex procedure that's hard to understand,
test and maintain. There's a relationship between cyclomatic complexity and the "risk" in
a procedure.

CC Type of procedure Risk

1-4 A simple procedure Low
Notes
5-10 A well structured and stable procedure Low
11-20 A more complex procedure Moderate
21-50 A complex procedure, alarming High
>50 An error-prone, extremely troublesome, untestable procedure Very high
The original, usual limit for a maximum acceptable value for cyclomatic complexity
is 10. Other values, such as 15 or 20, have also been suggested. Regardless of the
exact limit, if cyclomatic complexity exceeds 20, you should consider it alarming.
Procedures with a high cyclomatic complexity should be simplified or split into several
smaller procedures.
Cyclomatic complexity equals the minimum number of test cases you must execute
to cover every possible execution path through your procedure. This is important
information for testing. Carefully test procedures with the highest cyclomatic complexity
values.
Bad Fix Probability

There is a frequently quoted table of "bad fix probability" values by cyclomatic
complexity. This is the probability of an error accidentally inserted into a program while
trying to fix a previous error.
CC Bad fix probability
1-10 5%
20-30 20%
>50 40%
approaching 100 60%
As the complexity reaches high values, changes in the program are likely to
produce new errors.
Cyclomatic Complexity and Select Case

The use of multi-branch statements (Select Case) often leads to high cyclomatic
complexity values. This is a potential source of confusion. Should a long multiway
selection be split into several procedures?
McCabe originally recommended exempting modules consisting of single multiway
decision statements from the complexity limit.
Although a procedure consisting of a single multiway decision may require many
tests, each test should be easy to construct and execute. Each decision branch can be
understood and maintained in isolation, so the procedure is likely to be reliable and
maintainable. Therefore, it is reasonable to exempt procedures consisting of a single
multiway decision statement from a complexity limit.
If the branches of the decision statement contain complexity themselves, the
rationale and thus the exemption does not automatically apply. However, if all the
branches have very low complexity code in them, it may well apply.
Resolution: For each procedure, either limit cyclomatic complexity to 10 (or another
sensible limit) or provide a written explanation of why the limit was exceeded.
TCC Total Cyclomatic Complexity

The total cyclomatic complexity for a project or a class is calculated as follows.
TCC = Sum(CC) - Count(CC) + 1

TCC equals the number of decisions + 1 in a project or a class. It's similar to CC but
for several procedures.
Notes
Sum(CC) is simply the total sum of CC of all procedures. Count(CC) equals the
number of procedures. It's deducted because we already added +1 in the formula of CC
for each procedure.
TCC is immune to modularization, or the lack of modularization. TCC always equals
the number of decisions + 1. It is not affected by how many procedures the decisions
are distributed in.
TCC can be decreased by reducing the complexity of individual procedures. An
alternative is to eliminate duplicated or unused procedures.
DECDENS Decision Density

Cyclomatic complexity is usually higher in longer procedures. How much decision is
there actually, compared to lines of code? This is where you need decision density,
which also known as cyclomatic density.
DECDENS = Sum(CC) / LLOC
This metric shows the average cyclomatic density in your project. The numerator is
sum of CC over all your procedures. The denominator is the logical lines of code metric.
DECDENS ignores single-line procedure declarations since cyclomatic complexity isn't
defined for them. DECDENS is relatively constant across projects.
A high or low DECDENS does not necessarily means anything is wrong. A low
DECDENS might indicate lack of logic, such as in generated code, or code that
primarily loads some data instead of performing actions.
6.4.5 Metrics for Software Quality

Software metrics are numerical data related to software development. Metrics strongly
support software project management activities. They relate to the four functions of
management as follows:
1. Planning: Metrics serve as a basis of cost estimating, training planning, resource
planning, scheduling, and budgeting.
2. Organizing: Size and schedule metrics influence a project's organization.
3. Controlling: Metrics are used to status and track software development activities
for compliance to plans.
4. Improving: Metrics are used as a tool for process improvement and to identify
where improvement efforts should be concentrated and measure the effects of
process improvement efforts.
A metric quantifies a characteristic of a process or product. Metrics can be directly
observable quantities or can be derived from one or more directly observable quantities.
Examples of raw metrics include the number of source lines of code, number of
documentation pages, number of staff-hours, number of tests, number of requirements,
etc. Examples of derived metrics include source lines of code per staff-hour, defects per
thousand lines of code, or a cost performance index.
The term indicator is used to denote a representation of metric data that provides
insight into an ongoing software development project or process improvement activity.
Indicators are metrics in a form suitable for assessing project behavior or process
improvement.
For example, an indicator may be the behavior of a metric over time or the ratio of
two metrics. Indicators may include the comparison of actual values versus the plan,
project stability metrics, or quality metrics. Examples of indicators used on a project
include actual versus planned task completions, actual versus planned staffing, number

of trouble reports written and resolved over time, and number of requirements changes
over time.
Notes
Indicators are used in conjunction with one another to provide a more complete
picture of project or organization behavior. For example, a progress indicator is related
to requirements and size indicators. All three indicators should be used and interpreted
together.
An Overview of Factors that Affect Quality

McCall and Cavano define a set of quality factors that were a first step toward the
development of metrics for software quality. These factors assess software from three
distinct points of view: (1) product operation (using it), (2) product revision (changing it),
and (3) product transition (modifying it to work in a different environment; i.e., "porting"
it). In their work, the authors describe the relationship between these quality factors
(what they call a framework) and other aspects of the software engineering process:
z First, the framework provides a mechanism for the project manager to identify what
qualities are important. These qualities are attributes of the software in addition to
its functional correctness and performance which have life cycle implications. Such
factors as maintainability and portability have been shown in recent years to have
significant life cycle cost impact.
z Secondly, the framework provides a means for quantitatively assessing how well
the development is progressing relative to the quality goals established.
z Thirdly, the framework provides for more interaction of QA personnel throughout the
development effort.
z Lastly, quality assurance personal can use indications of poor quality to help identify
[better] standards to be enforced in the future.
Measuring Quality
Although there are many measures of software quality, correctness, maintainability,
integrity, and usability provide useful indicators for the project team. Gilb suggests
definitions and measures for each.
z Correctness: A program must operate correctly or it provides little value to its
users. Correctness is the degree to which the software performs its required
function. The most common measure for correctness is defects per KLOC, where a
defect is defined as a verified lack of conformance to requirements. When
considering the overall quality of a software product, defects are those problems
reported by a user of the program after the program has been released for general
use. For quality assessment purposes, defects are counted over a standard period
of time, typically one year.
z Maintainability: Software maintenance accounts for more effort than any other
software engineering activity. Maintainability is the ease with which a program can
be corrected if an error is encountered, adapted if its environment changes, or
enhanced if the customer desires a change in requirements. There is no way to
measure maintainability directly; therefore, we must use indirect measures. A
simple time-oriented metric is mean-time-to change (MTTC), the time it takes to
analyze the change request, design an appropriate modification, implement the
change, test it, and distribute the change to all users. On average, programs that
are maintainable will have a lower MTTC (for equivalent types of changes) than
programs that are not maintainable.
z Integrity: Software integrity has become increasingly important in the age of
hackers and firewalls. This attribute measures a system's ability to withstand
attacks (both accidental and intentional) to its security. Attacks can be made on all
three components of software: programs, data, and documents.
To measure integrity, two additional attributes must be defined: threat and security.
Threat is the probability (which can be estimated or derived from empirical

evidence) that an attack of a specific type will occur within a given time. Security is
the probability (which can be estimated or derived from empirical evidence) that the
attack of a specific type will be repelled. The integrity of a system can then be Notes
defined as:
Integrity = Summation [(1 – Threat) × (1 – Security)]
where threat and security are summed over each type of attack.
z Usability: The catch phrase "user-friendliness" has become ubiquitous in
discussions of software products. If a program is not user-friendly, it is often
doomed to failure, even if the functions that it performs are valuable. Usability is an
attempt to quantify user-friendliness and can be measured in terms of four
characteristics:
the physical and or intellectual skill required to learn the system,
the time required to become moderately efficient in the use of the system,
the net increase in productivity (over the approach that the system replaces)
measured when the system is used by someone who is moderately efficient,
and
a subjective assessment (sometimes obtained through a questionnaire) of
users attitudes toward the system. aintainability directly; therefore, we must use
indirect measures. A simple time-oriented metric is mean-time-to change
(MTTC), the time it takes to analyze the change request, design an appropriate
modification, implement the change, test it, and distribute the change to all
users. On average, programs that are maintainable will have a lower MTTC (for
equivalent types of changes) than programs that are not maintainable.
z Integrity: Software integrity has become increasingly important in the age of
hackers and firewalls. This attribute measures a system's ability to withstand
attacks (both accidental and intentional) to its security. Attacks can be made on all
three components of software: programs, data, and documents.
To measure integrity, two additional attributes must be defined: threat and security.
Threat is the probability (which can be estimated or derived from empirical
evidence) that an attack of a specific type will occur within a given time. Security is
the probability (which can be estimated or derived from empirical evidence) that the
attack of a specific type will be repelled. The integrity of a system can then be
defined as:
Integrity = Summation [(1 – Threat) × (1 – Security)]
where threat and security are summed over each type of attack.
z Usability: The catch phrase "user-friendliness" has become ubiquitous in
discussions of software products. If a program is not user-friendly, it is often
doomed to failure, even if the functions that it performs are valuable. Usability is an
attempt to quantify user-friendliness and can be measured in terms of four
characteristics:
the physical and or intellectual skill required to learn the system,
the time required to become moderately efficient in the use of the system,
the net increase in productivity (over the approach that the system replaces)
measured when the system is used by someone who is moderately efficient,
and
a subjective assessment (sometimes obtained through a questionnaire) of
users attitudes toward the system.
Defect Removal Efficiency

A quality metric that provides benefit at both the project and process level is Defect
Removal Efficiency (DRE). In essence, DRE is a measure of the filtering ability of

quality assurance and control activities as they are applied throughout all process
framework activities.
Notes
When considered for a project as a whole, DRE is defined in the following manner:
DRE = E/(E + D)
where E is the number of errors found before delivery of the software to the end-
user and D is the number of defects found after delivery.
The ideal value for DRE is 1. That is, no defects are found in the software.
Realistically, D will be greater than 0, but the value of DRE can still approach 1. As E
increases (for a given value of D), the overall value of DRE begins to approach 1. In
fact, as E increases, it is likely that the final value of D will decrease (errors are filtered
out before they become defects). If used as a metric that provides an indicator of the
filtering ability of quality control and assurance activities, DRE encourages a software
project team to institute techniques for finding as many errors as possible before
delivery.
DRE can also be used within the project to assess a team’s ability to find errors
before they are passed to the next framework activity or software engineering task. For
example, the requirements analysis task produces an analysis model that can be
reviewed to find and correct errors. Those errors that are not found during the review of
the analysis model are passed on to the design task (where they may or may not be
found). When used in this context, we redefine DRE as
DREi = Ei/ (Ei + Ei+1)
where Ei is the number of errors found during software engineering activity i and
Ei+1 is the number of errors found during software engineering activity i+1 that are
traceable to errors that were not discovered in software engineering activity i.
A quality objective for a software team (or an individual software engineer) is to
achieve DREi that approaches 1. That is, errors should be filtered out before they are
passed on to the next activity.
6.4.6 Design Metrics

It is inconceivable that the design of a new aircraft, a new computer chip, or a new
office building would be conducted without defining design measures, determining
metrics for various aspects of design quality, and using them to guide the manner in
which the design evolves. And yet, the design of complex software-based systems often
proceeds with virtually no measurement. The irony of this is that design metrics for
software are available, but the vast majority of software engineers continue to be
unaware of their existence.
Design metrics for computer software, like all other software metrics, are not
perfect. Debate continues over their efficacy and the manner in which they should be
applied. Many experts argue that further experimentation is required before design
measures can be used. And yet, design without measurement is an unacceptable
alternative.
In the sections that follow, we examine some of the more common design metrics
for computer software. Each can provide the designer with improved insight and all can
help the design to evolve to a higher level of quality.
Data Structure Metrics

A set of metries that capture the amount of data input to, processed in, and output from
software are called the data structure metrics. The importance of such metries can be
seen intuitively in the following example: assuming that a problem can be solved in two
ways, resulting in two programs A and B. A has 25 input parameters, 35 internal data
items, and 10 output parameters. B has 5 input parameters, 12 internal data items, and

4 output parameters. We can surmise that A is probably more complicated, took more
time to program, and has a greater probability of errors than B.
Notes
This section presents several data structure metrics. Some concentrate on
variables (and even constants) within each module and ignore the input/output
dependencies. Othern concern themselves primarily with the input/output situation.
Since there is no general agreement on how the lines of code measure is to be
counted, one should not be surprised that there are various methods for measuring data
structures as well.
Information Flow Metrics

z Information Flow metrics deal with this type of complexity by observing the flow of
information among system components or modules.This metrics is given by Henry
and Kafura. So it is also known as Henry and Kafura’s Metric.
z This metrics is based on the measurement of the information flow among system
modules. It is sensitive to the complexity due to interconnection among system
component. This measure includes complexity of a software module is defined to be
the sum of complexities of the procedures included in the module.
A procedure contributes complexity due to the following two factors.
1. The complexity of the procedure code itself.
2. The complexity due to procedure’s connections to its environment.
The effect of the first factor has been included through LOC (Lin Of Code) measure.
For the quantification of second factor, Henry and Kafura have defined wo terms,
namely FAN-IN and FAN-OUT.
FAN-IN of a procedure is the number of local flows into that procedure plus the
number of data structures from which this procedure retrieve information.
FAN –OUT is the number of local flows from that procedure plus the number of data
structures which that procedure updates.
Procedure Complexity = Length * (FAN-IN * FANOUT)**2

Where the length is taken as LOC and the term FAN-IN *FAN-OUT represent the
total number of input –output combinations for the procedure.
Architectural Design Metrics

Architectural design metrics focus on characteristics of the program architecture with an
emphasis on the architectural structure and the effectiveness of modules. These
metrics are black box in the sense that they do not require any knowledge of the inner
workings of a particular software component.
Card and Glass define three software design complexity measures: structural
complexity, data complexity, and system complexity.
Structural complexity of a module i is defined in the following manner:
S(i) = f2out(i)
where fout(i) is the fan-out of module i.
Data complexity provides an indication of the complexity in the internal interface for
a module i and is defined as
D(i) = v(i)/[fout(i) +1]
where v(i) is the number of input and output variables that are passed to and from
module i.

Finally, system complexity is defined as the sum of structural and data complexity,
specified as
Notes
C(i) = S(i) + D(i)
As each of these complexity values increases, the overall architectural complexity
of the system also increases. This leads to a greater likelihood that integration and test-
ing effort will also increase.
An earlier high-level architectural design metric proposed by Henry and Kafura also
makes use the fan-in and fan-out. The authors define a complexity metric (applicable to
call and return architectures) of the form
HKM = length(i) x [fin(i) + fout(i)]2

where length(i) is the number of programming language statements in a module i
and fin(i) is the fan-in of a module i. Henry and Kafura extend the definitions of fan-in
and fan-out presented in this book to include not only the number of module control
connections (module calls) but also the number of data structures from which a module i
retrieves (fan-in) or updates (fan-out) data. To compute HKM during design, the procedural
design may be used to estimate the number of programming language statements for
module i. Like the Card and Glass metrics noted previously, an increase in the Henry-
Kafura metric leads to a greater likelihood that integration and testing effort will also
increase for a module.
Fenton suggests a number of simple morphology (i.e., shape) metrics that enable
different program architectures to be compared using a set of straightforward
dimensions. Referring to Figure 6.3, the following metrics can be defined:
size = n + a
Figure 6.3: Morphology Metrics
where n is the number of nodes and a is the number of arcs. For the architecture
shown in Figure 6.3,
size = 17 + 18 = 35
depth = the longest path from the root (top) node to a leaf node. For the architecture
shown in Figure 6.3, depth = 4.
width = maximum number of nodes at any one level of the architecture. For the
architecture shown in Figure 6.3, width = 6.
arc-to-node ratio, r = a/n,

which measures the connectivity density of the architecture and may provide a sim-
ple indication of the coupling of the architecture. For the architecture shown in Figure 6.3,
r = 18/ 17 = 1.06. Notes
The U.S. Air Force Systems Command has developed a number of software quality
indicators that are based on measurable design characteristics of a computer program.
Using concepts similar to those proposed in IEEE Std. 982.1-1988, the Air Force uses
information obtained from data and architectural design to derive a design structure quality
index (DSQI) that ranges from 0 to 1. The following values must be ascertained to compute
the DSQI:
S1 = the total number of modules defined in the program architecture.
S2 = the number of modules whose correct function depends on the source of data
input or that produce data to be used elsewhere (in general, control modules, among
others, would not be counted as part of S2).
S3 = the number of modules whose correct function depends on prior processing.
S4 = the number of database items (includes data objects and all attributes that
define objects).
S5 = the total number of unique database items.
S6 = the number of database segments (different records or individual objects).
S7 = the number of modules with a single entry and exit (exception processing is
not considered to be a multiple exit).
Once values S1 through S7 are determined for a computer program, the following
intermediate values can be computed:
Program structure: D1, where D1 is defined as follows:
If the architectural design was developed using a distinct method (e.g., data flow-
oriented design or object-oriented design), then D1 = 1, otherwise D1 = 0.
Module independence: D2 = 1 – (S2/S1)
Modules not dependent on prior processing: D3 = 1 – (S3/S1)
Database size: D4 = 1 — (S5/S4)
Database compartmentalization: D5 = 1 – (S6/S4)
Module entrance/exit characteristic: D6 = 1 – (S7/S1)
With these intermediate values determined, the DSQI is computed in the following
manner:
DSQI = X wiDi (19-5)
Where, i = 1 to 6, wi is the relative weighing of the importance of each of the inter-
mediate values, and X wi = 1 (if all Di are weighed equally, then wi = 0.167).
The value of DSQI for past designs can be determined and compared to a design
that is currently under development. If the DSQI is significantly lower than average,
further design work and review are indicated. Similarly, if major changes are to be
made to an existing design, the effect of those changes on DSQI can be calculated.
6.4.7 Object Oriented Software Metrics

Many different metrics have been proposed for object-oriented systems. The object-
oriented metrics measure principle structures that, if improperly designed, negatively
affect the design and code quality attributes. The selected object-oriented metrics are
primarily applied to the concepts of classes, coupling, and inheritance. For some of the
object-oriented metrics discussed here, multiple definitions are given, since researchers

and practitioners have not reached a common definition or counting methodology. In

some cases, the counting method for a metric is determined by the software analysis
Notes package being used to collect the metrics.
Class
A class is a template from which objects can be created. This set of objects share a
common structure and a common behavior manifested by the set of methods. Three
class metrics described here measure the complexity of a class using the class’s
methods, messages and cohesion.
Method
A method is an operation upon an object and is defined in the class declaration.
METRIC: Weighted Methods per Class (WMC)

The WMC is a count of the methods implemented within a class or the sum of the
complexities of the methods (method complexity is measured by cyclomatic
complexity). The second measurement is difficult to implement since not all methods
are accessible within the class hierarchy due to inheritance. The number of methods
and the complexity of the methods involved is a predictor of how much time and effort is
required to develop and maintain the class. The larger the number of methods in a
class, the greater the potential impact on children since children inherit all of the
methods defined in a class. Classes with large numbers of methods are likely to be
more application specific, limiting the possibility of reuse. This metric measures
Understandability, Maintainability, and Reusability.
Message
A message is a request that an object makes of another object to perform an operation.
The operation executed as a result of receiving a message is called a method. The next
metric looks at methods and messages within a class.
METRIC: Response for a Class (RFC)

The RFC is the carnality of the set of all methods that can be invoked in response to a
message to an object of the class or by some method in the class. This includes all
methods accessible within the class hierarchy. This metric looks at the combination of
the complexity of a class through the number of methods and the amount of
communication with other classes. The larger the number of methods that can be
invoked from a class through messages, the greater the complexity of the class. If a
large number of methods can be invoked in response to a message, the testing and
debugging of the class becomes complicated since it requires a greater level of
understanding on the part of the tester. A worst case value for possible responses will
assist in the appropriate allocation of testing time. This metric evaluates
Understandability, Maintainability, and Testability.
Cohesion
Cohesion is the degree to which methods within a class are related to one another and
work together to provide well-bounded behavior. Effective object-oriented designs
maximize cohesion since it promotes encapsulation. The third class metrics investigates
cohesion.
METRIC: Lack of Cohesion of Methods (LCOM)

LCOM measures the degree of similarity of methods by data input variables or
attributes (structural properties of classes. Any measure of separateness of methods
helps identify flaws in the design of classes. There are at least two different ways of
measuring cohesion:

Calculate for each data field in a class what percentage of the methods use that
data field. Average the percentages then subtract from 100%. Lower percentages mean
greater cohesion of data and methods in the class. Notes
Methods are more similar if they operate on the same attributes. Count the number
of disjoint sets produced from the intersection of the sets of attributes used by the
methods. High cohesion indicates good class subdivision. Lack of cohesion or low
cohesion increases complexity, thereby increasing the likelihood of errors during the
development process.
Classes with low cohesion could probably be subdivided into two or more
subclasses with increased cohesion. This metric evaluates Efficiency and Reusability.
Coupling
Coupling is a measure of the strength of association established by a connection
from one entity to another. Classes (objects) are coupled three ways:
When a message is passed between objects, the objects are said to be coupled.
Classes are coupled when methods declared in one class use methods or attributes
of the other classes.
Inheritance introduces significant tight coupling between superclasses and their
subclasses.
Since good object-oriented design requires a balance between coupling and
inheritance, coupling measures focus on non-inheritance coupling. The next object-
oriented metric measures coupling strength.
METRIC: Coupling Between Object Classes (CBO)

CBO is a count of the number of other classes to which a class is coupled. It is
measured by counting the number of distinct non-inheritance related class hierarchies
on which a class depends. Excessive coupling is detrimental to modular design and
prevents reuse. The more independent a class is, the easier it is reuse in another
application. The larger the number of couples, the higher the sensitivity to changes in
other parts of the design and therefore maintenance is more difficult. Strong coupling
complicates a system since a module is harder to understand, change or correct by
itself if it is interrelated with other modules. Complexity can be reduced by designing
systems with the weakest possible coupling between modules. This improves
modularity and promotes encapsulation. CBO evaluates Efficiency and Reusability.
Inheritance
Another design abstraction in object-oriented systems is the use of inheritance.
Inheritance is a type of relationship among classes that enables programmers to reuse
previously defined objects including variables and operators. Inheritance decreases
complexity by reducing the number of operations and operators, but this abstraction of
objects can make maintenance and design difficult. The two metrics used to measure
the amount of inheritance are the depth and breadth of the inheritance hierarchy.
METRIC: Depth of Inheritance Tree (DIT)

The depth of a class within the inheritance hierarchy is the maximum length from the
class node to the root of the tree and is measured by the number of ancestor classes.
The deeper a class is within the hierarchy, the greater the number methods it is likely to
inherit making it more complex to predict its behavior. Deeper trees constitute greater
design complexity, since more methods and classes are involved, but the greater the
potential for reuse of inherited methods. A support metric for DIT is the number of
methods inherited (NMI). This metric primarily evaluates Efficiency and Reuse but also
relates to Understandability and Testability.

METRIC: Number of Children (NOC)
Notes The number of children is the number of immediate subclasses subordinate to a class in
the hierarchy. It is an indicator of the potential influence a class can have on the design
and on the system. The greater the number of children, the greater the likelihood of
improper abstraction of the parent and may be a case of misuse of subclassing. But the
greater the number of children, the greater the reusability since inheritance is a form of
reuse. If a class has a large number of children, it may require more testing of the
methods of that class, thus increase the testing time. NOC, therefore, primarily
evaluates Efficiency, Reusability, and Testability.
6.5 Metric Analysis

Technical work in software engineering begins with the creation of the analysis model. It
is at this stage that requirements are derived and that a foundation for design is
established. Therefore, technical metrics that provide insight into the quality of the
analysis model are desirable.
Although relatively few analysis and specification metrics have appeared in the
literature, it is possible to adapt metrics derived for project application for use in this
context. These metrics examine the analysis model with the intent of predicting the
“size” of the resultant system. It is likely that size and design complexity will be directly
correlated.
Figure 6.4: Part of the analysis model of SafeHome software
6.5.1 Function-based Metrics

The function point metric can be used effectively as a means for predicting the size of a
system that will be derived from the analysis model. To illustrate the use of the FP
metric in this context, we consider a simple analysis model representation, illustrated in
Figure 6.4. Referring to the figure, a data flow diagram for a function within the
SafeHome software is represented. The function manages user interaction, accepting a
user password to activate or deactivate the system, and allows inquiries on the status of
security zones and various security sensors. The function displays a series of prompting
messages and sends appropriate control signals to various components of the security
system.
The data flow diagram is evaluated to determine the key measures required for
computation of the function point metric:
z Number of user inputs
z Number of user outputs

z Number of user inquiries
z Number of files
Notes
z Number of external interfaces
Figure 6.5: Computing function points for a SafeHome function
Three user inputs—password, panic button, and activate/deactivate—are shown in

the figure along with two inquires—zone inquiry and sensor inquiry. One file (system
configuration file) is shown. Two user outputs (messages and sensor status) and four
external interfaces (test sensor, zone setting, activate/deactivate, and alarm alert) are
also present. These data, along with the appropriate complexity, are shown in Figure
6.5.
6.6 Summary
Size-oriented software metrics are derived by normalizing quality and/or productivity
measures by considering the size of the software that has been produced. Function-
oriented software metrics use a measure of the functionality delivered by the application
as a normalization value. A function point extension called feature points is a superset
of the function point measure that can be applied to systems and engineering software
applications. Cyclomatic complexity, also known as V(G) or the graph theoretic number,
is probably the most widely used complexity metric in software engineering. Cyclomatic
complexity comes in a couple of variations as to what exactly counts as a decision.
Software metrics are numerical data related to software development. Metrics strongly
support software project management activities. The object-oriented metrics measure
principle structures that, if improperly designed, negatively affect the design and code
quality attributes. Product and process entities have specific attributes. Attributes are
usually divided into internal and external attributes. The contrast between direct
measurement and indirect, or derived measurement, is between a (direct) metric
function whose domain is only one variable and a (derived) function whose domain is
an n-tuple

Multiple Choice Questions
1. The intent of project metrics is:
(a) minimization of development schedule
(b) for strategic purposes
(c) assessing project quality on ongoing basis
(d) both a and c

2. Which of the following is not a direct measure of SE process?

(a) Efficiency
Notes
(b) Cost
(c) Effort Applied
(d) All of the mentioned
3. Which of the following is an indirect measure of product?
(a) Quality
(b) Complexity
(c) Reliability
(d) All of the Mentioned
4. In size oriented metrics, metrics are developed based on the __________________.
(a) number of Functions
(b) number of user inputs
(c) number of lines of code
(d) amount of memory usage
5. Which of the following is not an information domain required for determining unction
point in FPA?
(a) Number of user Input
(b) Number of user Inquiries
(c) Number of external Interfaces
(d) Number of errors
6. How many Information Domain Values are used for Function Point Computation?
(a) three
(b) four
(c) five
(d) six
7. Function Point Computation is given by the formula
(a) FP = [count total * 0.65] + 0.01 * sum(Fi)
(b) FP = count total * [0.65 + 0.01 * sum(Fi)]
(c) FP = count total * [0.65 + 0.01] * sum(Fi)
(d) FP = [count total * 0.65 + 0.01] * sum(Fi)
8. Architectural Design Metrics are ___________ in nature.
(a) Black Box
(b) White Box
(c) Gray Box
(d) Green Box
9. Structural complexity of a module i is given as S(i) = f*f (i). What does f symbolizes
here?
(a) “fan check-out” of module i
(b) “fan check-in” of module i
(c) “fan in” of module i
(d) “fan out” of module i

10. SMI = [Mt - (Fa + Fc + Fd)]/Mt. Here Mt is the number of modules
(a) in the current release
Notes
(b) in the current release that have been changed
(c) from the preceding release that were deleted in the current release

1. Compute the nominal effort and development time for m organic type software
product with an estimated size of 50,00 line of code.
2. If a software product for busines aplication costs Rs. 1, 0,00 to buy and that its size
is 60 KLOC asuming that in house developers cost Rs, 10,00 per month.
3. Compare the relative advantages and disadvantages of function-oriented design
and object- oriented design.
4. Briefly explain the difference between the two software productivity metrics: Lines of
Code (KLOC) and Function Points (FP). Explain how do we use these two metrics
for project estimation.
5. Explain the concept of size-oriented and function-oriented metrics.
6. Describe Architectural Design Metrics with example.
7. Describe the relationship that is used to compute function points (FP).
8. Write short note on following:
(a) Function-Based Metrics
(b) Architectural Design Metrics
6.9 Key Terms

z Software Metrics: A quantitative measure of the degree to which a system,
component, or process possesses a given attribute.
z Size-oriented Software Metrics: Size-oriented software metrics are derived by
normalizing quality and/or productivity measures by considering the size of the
software that has been produced.
z Function-oriented Software Metrics: Function-oriented software metrics use a
measure of the functionality delivered by the application as a normalization value.
z Cyclomatic Complexity: Cyclomatic Complexity counts the number of decisions in
the program, under the assumption that decisions are difficult for people.
z Cohesion: Cohesion is the degree to which methods within a class are related to
one another and work together to provide well-bounded behavior.
z Coupling: Coupling is a measure of the strength of association established by a
connection from one entity to another.
z Attribute: An attribute is a characteristic or property of an entity.
z Direct metric: A direct metric is "a metric that does not depend upon a measure of
any other attribute."
Check Your Progress: Answers

1. (d) both a and c
2. (a) Efficiency
3. (d) All of the Mentioned
4. (c) number of lines of code
5. (d) Number of errors
6. (c) five
7. (b) FP = count total * [0.65 + 0.01 * sum(Fi)]

8. (a) Black Box

9. (d) “fan out” of module i
Notes
10. (a) in the current release

z Rajib Mall, Fundamentals Of Software Engineering, PHI Learning Pvt. , 2009
z Vasudeva Varma, Varma Vasudeva, Software Architecture: A Case Based
Approach, Pearson Education India, 2009
z K. K. Aggarwal, Yogesh Singh, Software Engineering, New Age International, 2006
z Ajeet Pandey, Neeraj Kumar Goyal, Early Software Reliability Prediction: A Fuzzy
Logic Approach, Springer Science & Business Media, 2013

Software Reliability 133
Unit 7: Software Reliability

Notes
Structure
7.1 Introduction
7.2 Basic Concepts
7.3 Software Quality
7.4 Software Reliability Models
7.4.1 Software Reliability
7.4.2 Error Rates
7.4.3 Rayleigh Model
7.4.4 Weibull Model
7.5 Defect Removal Effectiveness
7.5.1 Applicable Product Categories
7.5.2 Detailed Description
7.5.3 Sample Charts
7.6 Capability Maturity Model
7.7 ISO 9000
7.8 Summary
7.11 Key Terms
Objectives
After studying this unit, you should be able to:
z Define software reliability, software reliability models and error rates
z Explain the Rayleigh model
z Describe the Weibull model
7.1 Introduction
The concept of software quality is more complex than what common people tend to
believe. However, it is very popular both for common people and IT professionals. If we
look at the definition of quality in a dictionary, it is usual to find something like the
following: set of characteristics that allows us to rank things as better or worse than
other similar ones.
Different philosophers attempts to define software quality as a complex concept that
can be decomposed in more detailed characteristics to enable evaluation of quality
through the evaluation of more detailed characteristics that are supposed to be easy to
measure or assess.
Software Quality Engineering is a process that evaluates, assesses, and improves
the quality of software.
Software quality is often defined as "the degree to which software meets
requirements for reliability, maintainability, transportability, etc., as contrasted with
functional, performance, and interface requirements that are satisfied as a result of

software engineering."
Notes
Quality must be built into a software product during its development to satisfy
quality requirements established for it.
Quality assurance consists of the auditing and reporting functions of management.
The goal of quality assurance is to provide management with the data necessary to be
informed about product quality.
7.2 Basic Concepts

There is no doubt that the reliability of a computer program is an important element of
its overall quality. If a program repeatedly and frequently fails to perform, it matters little
whether other software quality factors are acceptable.
Software reliability, unlike many other quality factors, can be measured, directed,
and estimated using historical and developmental data. Software reliability is defined in
statistical terms as "the probability of failure free operation of a computer program in a
specified environment for a specified time".
Measures of Reliability and Availability

Early work in software reliability attempted to extrapolate the mathematics of hardware
reliability theory. Most hardware related reliability models are predicated on failure due
to wear rather than failure due to design defects. In hardware, failures due to physical
wear are more likely than a design related failure. Unfortunately, the opposite is true for
software. In fact, all software failures can be traced to design or implementation
problems. There is still debate over the relationship between key concepts in hardware
reliability and their applicability to software , although certain link has yet to be
established, it is worthwhile to consider a few simple concepts that apply to both system
elements.
If we consider a computer-based system, a simple measure of reliability is mean
time between failure (MTBF), where
MTBF = MTTF + MTTR
(The acronyms MTTF and MTTR are mean time to failure and mean time to repair,
respectively)
Many researchers argue that MTBF is a far more useful measure them
defects/KLOC. Stated simply an end user is concerned with failures, not with the total
defect count. Because each defect contained within a program does not have the same
failure rate, the total defect count provides little indication of the reliability of a system.
For example, consider a program that has been in operation for 14 months. Many
defects in this program may remain undetected for decades before they are discovered.
The MTBF of such obscure defect might be 50 or even 100 years. Other defects in as
yet undiscovered, might have a failure rate if 18 or 24 months. Even if every one of the
first category of defects (those with long MTBF) is removed, the impact on software
reliability is negligible.
In addition to a reliability measure, we must develop a measure of availability.
Software availability is the probability that a program is operating according to
requirements at a given point in time and is defined as:
Availability = MTTF/ (MTTF + MTTR) ? 100%

The MTBF reliability measure is equally sensitive to MTTF and MTTR The
availability measure is somewhat more sensitive to MTTR an indirect measure of the
maintainability of software.

Software Safety
When software is used as part of the control system, complexity can increase by an Notes
order of magnitude or more. Design faults induced by human error-something that can
be uncovered and eliminated in hardware-based conventional control become much
more difficult to uncover when software is used.
Software safety is a software quality assurance activity that focuses on the
identification and assessment of potential risk that may affect software negatively and
cause an entire system to fail.
If risk can be identified early in the software engineering process, software design
features can be specified that will either eliminate or control potential risk.
A modeling and analysis process is conducted as part of software safety. Initially,
risks are identified and categorized by criticality and risk intensity. For example, some of
the risk associated with a computer-based cruise control for an automobile might be:
z Causes uncontrolled acceleration that cannot be stopped
z Does not respond to depression of brake pedal (by turning off) does not engage
when switch is activated
z Slowly loses or gains speed
Once these system-level risks are identified, analysis techniques are used to assign
severity and probability of occurrence. To be effective, software must be analyzed in the
context of the entire system. For example, a subtle user input error may be magnified
by a software fault to produce control data that improperly positions a mechanical
device. If a set of external environmental conditions are met, the improper position of
the mechanical device will cause an unfortunate failure.
Analysis techniques such as fault tree analysis , real-time logic, can be used to
predict the chain of events that can cause risk and the probability that each of the
events will occur to create the chain.
Once risk are identified and analyzed, safety-related requirements can be specified
for the software.
That is, the specification can contain a list of undesirable events and the desired
system responses to these events. The role of software in managing undesirable events
is then indicated.
Although software reliability and software safety are closely related to one another,
it is important to understand the subtle difference between them. Software reliability
uses statistical analysis to determine the likelihood that a software failure will occur.
However, the occurrence of a failure does not necessarily result in a hazard or mishap.
Software safety examines the ways in which failures result in conditions that can lead to
a mishap. That is, failures are not considered in a vacuum, but are evaluated in the
context of an entire computer-based system.
7.3 Software Quality

Quality can be defined as as "a characteristic or attribute of something". As an attribute
of an item, quality refers to measurable characteristics-thing we are able to compare to
known standards such 100 as length, color, electrical properties, malleability, and so on.
However, software, largely an intellectual entity, is more challenging to characterize
than physical objects.
When we examine an item based on its measurable characteristics, two kinds of
quality may be encountered; quality of design and quality of conformance.
Quality of design refers to the characteristics that designers specify for an item. The
grade of materials, tolerances, and performance specifications all contribute to the
quality of design. As higher-graded materials are used and tighter tolerances and

greater levels of performance are specified, the design quality of a product increases, if
the product is manufactured according to specifications.
Notes
Quality of conformance is the degree to which the design specifications are followed
during manufacturing. Again the greater the degree of conformance, the higher the level
of quality of conformance.
In software development quality of design encompasses requirements,
specifications, and the design of the system. Quality of conformance is an issue
focused primarily on implementation. If the implementation follows the design and the
resulting system meets its requirements and performance goals, conformance quality is
high Quality.
Quality Control
Variation control may be equated to quality control. But how do we achieve quality
control? Quality control is the series of inspections reviews, and tests used throughout
the development cycle to ensure that each work product meets the requirements placed
upon it, Quality control includes a feedback loop to the process that created the work
product. The combination of measurement and feedback allows us to tune the process
when the work products created fail to meet their specifications. This approach views
quality control as part of the manufacturing process.
Quality control activities may be fully automated, entirely manual or a combination
of automated tools and human interaction. A key concept of quality control is that all
work products have clearly defined and measurable specifications. To which we may
compare the outputs of each process. The feedback loop is essential to minimize the
defects produced.
Quality Assurance
Quality assurance consists of the auditing and reporting functions of management. The
goal of quality assurance is to provide management with the data necessary to be
informed about product quality, thereby gaining insight and confidence that product
quality is meeting its goals.
Of course, if the data provided through quality assurance identify problems, it is
management's responsibility to address the problems and apply the necessary
resources to resolve quality issues.
Cost of Quality
Cost of quality includes all costs incurred in the pursuit of quality or in performing quality
related activities. Cost of quality, to identify opportunities for reducing the cost of quality
and to provide a normalized basis of comparison.
Quality costs may be divided into costs associated with prevention, appraisal, and
failure. Prevention costs include:
z Quality planning
z Formal technical reviews
z Test equipment
z Training
Appraisal costs include activities to gain insight into product condition "first time
through" each process. Appraisal costs include:
z In-process and inter process inspection
z Equipment calibration and maintenance
z Testing

Failure costs are costs that would disappear if no defects appeared before shipping
a product to customers. Failure costs may be subdivided into internal failure costs and
external failure costs. Internal failure costs are the costs incurred when we detect an Notes
error in our product prior to shipment. Internal failure costs include:
z Rework
z Repair
z Failure mode analysis
External failure costs are the costs associated with defects found after the product
has been shipped to the customer. External failure costs include:
z Complaint resolution
z Product return and replacement
z Help line support
z Warranty work
7.4 Software Reliability Models

Reliability is the probability of not failing in a specified length of time. This is usually
denoted by R(n), where n is the number of time units. If the time unit is days, then R(1)
is the probability of not failing in 1 day. The probability of failing in a specified length of
time is 1 minus the reliability for that length of time (F(n) = 1 - R(1)).
7.4.1 Software Reliability

Software reliability is a measure of how often the software encounters a data input or
other condition that it does not process correctly to produce the right answer. Software
reliability is not concerned with software wearing out. A better analogy for software
failures is picking marbles out of a bag or throwing darts blindfolded at balloons on a
wall.
Over 225 models have been developed since early 1970s, but how to quantify
software reliability still remains unsolved. There is no single model which can be used in
every situation. There is no model which is either complete or fully developed.
7.4.2 Error Rates

If an error happens every 2 days, then the instantaneous error rate would be 0.5 errors
per day. The error rate is the inverse of the time between errors (inter-error time). The
error rate can be used as an estimate of the probability of failure, F(1).
Unless we know some trend, the best estimate of the short-term future behavior is
the current behavior. So if we find 20 errors on one day, our best estimate for the next
day is 20 errors.
Example: If an error happens after 2 days, what is the probability that the system will
not fail in 1, 2, 3, and 4 days?
If an error happens every 2 days, we can use 0.5 as the instantaneous error rate. It
can also be used to estimate the failure probability for 1 day. Thus,
F(1) = 0.5. Then, R(1) = 1 – F(1) = 0:5: R(2) = 0:25: R(3) = 0:125: R(4) = 0:0625.
If we can see a trend in the error rates, then we can estimate the error rate better.
Instead of using equations to fit the data, plots of the failure rate can be used to
visualize the behavior.
If x is the inter-failure time, 1 = x is the instantaneous failure rate. Plot the
instantaneous failure rate versus either failure number or the elapsed time of the failure.
Try to fit a straight line to the points. The value of the line at the current time can be
used for the error rate.

The intersection of this line with the horizontal axis indicates either the fault number
where the failure rate goes to zero, or the amount of time necessary to remove all the
Notes faults. When the x-axis is the elapsed time, then the area under the straight line (units
are time failure/time) represents the number of faults.
Thus, empirical data about how often the software fails during testing or observation
is used to estimate the current rate. Theoretical ideas will be used to refine the
predictions for longer periods of time.
7.4.3 Rayleigh Model

In spite of diligent planning, documentation, and proper process adherence in software
development, occurrences of defects are inevitable. In today’s cutting edge competition,
it is important to make conscious efforts to control and minimize these defects by using
techniques to allow in-process quality monitoring and control. Defect Prediction using
Rayleigh’s distribution curve is one such method that helps us to understand the density
of the defects and their distribution across project phases as a project progresses.
Rayleigh’s defect prediction model is useful in determining the number of defects
that are likely to occur during execution of a project in the early stages. This model can
evolve and improve over time by considering data from previous phases of the project
cycle. Predicting the total number of defects before testing begins improves the quality
of the product being delivered and helps in planning and decision making for future
project releases.
Deriving Rayleigh’s Defect Prediction Curve

Rayleigh prediction requires two inputs: the number of phases planned and the total
end-to-end defects. The model then predicts the number of defects in each phase. The
Rayleigh function is given by the following formula:
( 2
Estimated Defect Density in Phase = E ⋅ e −B(P −1) − e −BP
2
)
Where E = Total no. of Defects
P = Phase Number
B = Defect Detection Efficiency
Defect Detection Efficiency can be calculated by using the following method:
No. of Defects Found in a Phase
Defect Detection Efficiency = × 100
Total Number of Defects in the Phase
Using the above formula the Rayleigh’s Curve can be plotted as given below:
Figure 7.1: Rayleigh’s Curve
Case 1: If the actual defects are less than the predicted defects, the quality of
reviews need to be examined.

Notes
Figure 7.2: Actual defects are less than the predicted defects
Case 2: If the actual defects are more than the predicted, the model and total
defects expected are to be readjusted dynamically.
Figure 7.3: Actual defects are more than the predicted
Advantages of Rayleigh’s Defect Prediction Model

It is one of the dynamic methods to predict the reliability of the software.
Only a few input parameters are required for the prediction process.
These models are based on statistical distribution of defects found, which is proven
to be better than the static models.
Rayleigh’s Model is better than other dynamic models such as Exponential and S-
Curve Models since it models the entire software development lifecycle.
Since the models and approaches vary depending on many factors, none of them
will predict exact defect numbers. Rayleigh’s Model is the most commonly used and
useful defect prediction model as it can be used to predict the additional test effort
required to achieve desired quality level during the testing phase. At the end of the
testing phase, the model can be used to predict the number of remaining defects in the
system and helping to predict reliability of the software.
7.4.4 Weibull Model
Formulas and Plots

The Weibull is a very flexible life distribution model with two parameters. It has CDF and
PDF and other key formulas given by:
PDF:CDF:Reliability:Failure
Rate:Mean:Median:Variance:f(t,γ,α)=γt(tα)γe−(tα)γF(t)=1−e−(tα)γR(t)=e−(tα)γh(t)=γα(tα)
γ−1αΓ(1+1γ)α(ln2)1γα2Γ(1+2γ)−[αΓ(1+1γ)]2
with α the scale parameter (the Characteristic Life), γ (gamma) the Shape
Parameter, and Γ is the Gamma function with Γ(N)=(N−1)! for integer N.

The cumulative hazard function for the Weibull is the integral of the failure rate or
H(t)=(tα)γ.
Notes
In probability theory and statistics, the Weibull distribution / ve b l/ is a
continuous probability distribution. It is named after Waloddi Weibull, who described it in
detail in 1951, although it was first identified by Fréchet (1927) and first applied by
Rosin & Rammler (1933) to describe a particle size distribution.
A more general three-parameter form of the Weibull includes an additional waiting
timeparameter μ (sometimes called a shift or location parameter). The formulas for
the 3-parameter Weibull are easily obtained from the above formulas by replacing t by
(t−μ)wherever t appears. No failure can occur before μ hours, so the time scale starts
at μ, and not 0. If a shift parameter μ is known (based, perhaps, on the physics of the
failure mode), then all you have to do is subtract μ from all the observed failure times
and/or readout times and analyze the resulting shifted data with a two-parameter
Weibull.
Various texts and articles in the literature use a variety of different symbols for the
same Weibull parameters.
Example: The characteristic life is sometimes called c (ν = nu or η = eta) and the
shape parameter is also called m (or β = beta). To add to the confusion, some software
uses β as the characteristic life parameter and α as the shape parameter. Some authors
even parameterize the density function differently, using a scale parameter θ=αγ.
Special Case: When γ = 1, the Weibull reduces to the Exponential Model, with
α = 1/λ = themean time to fail (MTTF).
Depending on the value of the shape parameter γ, the Weibull model can
empirically fit a wide range of data histogram shapes. This is shown by the PDF
example curves below.
Weibull data "shapes"
Figure 7.4: Example of Weibull Distribution shapes

From a failure rate model viewpoint, the Weibull is a natural extension of the
constant failure rate exponential model since the Weibull has a polynomial failure rate
with exponent {γ−1}. This makes all the failure rate curves shown in the following plot Notes
possible.
Weibull failure rate "shapes"
Figure 7.5: Example of Weibull failure rate functions
The Weibull is very flexible and also has theoretical justification in many
applications
Uses of the Weibull Distribution Model

Because of its flexible shape and ability to model a wide range of failure rates, the
Weibull has been used successfully in many applications as a purely empirical model.
The Weibull model can be derived theoretically as a form of Extreme Value
Distribution, governing the time to occurrence of the "weakest link" of many competing
failure processes. This may explain why it has been so successful in applications such
as capacitor, ball bearing, relay and material strength failures.
Another special case of the Weibull occurs when the shape parameter is 2. The
distribution is called the Rayleigh Distribution and it turns out to be the theoretical
probability model for the magnitude of radial error when the x and y coordinate errors
are independent normals with 0 mean and the same standard deviation.
Weibull probability plot
We generated 100 Weibull random variables using T = 1000, γ = 1.5 and α =
5000. To see how well these random Weibull data points are actually fit by a Weibull
distribution, we generated the probability plot shown below.
The log scale used is base 10.

Notes
Figure 7.6: Weibull Q-Q Plot
If the data follow a Weibull distribution, the points should follow a straight line.
We can comput the PDF and CDF values for failure time T = 1000, using the
example Weibull distribution with γ = 1.5 and α = 5000. The PDF value is 0.000123 and
the CDF value is 0.08556.
Functions for computing Weibull PDF values, CDF values, and for producing
probability plots, are found in both Dataplot code and R code.
7.5 Defect Removal Effectiveness

Defect removal effectiveness is a very important aspect of product quality. A good
defect removal process promotes the release of products with lower latent defects,
generating high customer confidence.
The scope of the defect removal efficiency measurement is by project and
verification/validation life-cycle phase.
Defect tracking measurements are intended to ensure monitoring of product defects
and their resolution processes so those defects do not escape into the field and impact
the customer.
The information obtained from this measurement should be used for in-process
tracking to determine the need for corrective action during a project’s appropriate test
life cycle phases.
7.5.1 Applicable Product Categories

This measurement applies to all categories listed in the Product Category Definitions
table.
7.5.2 Detailed Description
Terminology
z Measured Test Cycle: A project test activity or test life-cycle phase deemed
appropriate by the organization to measure.
z Found Defect: These defects are found during a measured test cycle. Found
defects are categorized by severity.
z Removed Defect: These defects are those removed during a measured test cycle.
Notes
Removed defects are categorized by severity..
Defect Classifications
Defects severity shall be established and defined such as the following:
z Severity 1 Defects: This represents a major, functional impacting defect, which
MUST BE resolved prior to approval of product.
z Severity 2 Defects: This represents a moderately impacting defect, which
SHOULD BE resolved prior to approval of product.
z Severity 3 Defects: This represents a minimal impacting defect, whose resolution
needs to be negotiated with impacted personnel.
Counting Rules
z Each found defect should be counted in the measured test cycle where it was
found.
z Each removed defect should be counted in the measured test cycle where it was
removed.
Counting Rule Exclusions

None
Calculations and Formulas

Defects Found and Removed. Defects categorized by severity. Measurements
maintained and tracked for Integration Test, System Test, and overall should be
calculated as follows:
z F1 = Number of severity 1 defects found during a measured test cycle.
z R1 = Number of severity 1 defects removed during a measured test cycle.
Defect Removal Efficiency, by severity, for a measured test cycle should be
calculated as follows:
z DRE1 = (R1 / F1 ) x 100%.
z DRE2 = (R2 / F2 ) x 100%.
z DRE3 = (R3 / F3 ) x 100%.
Reporting and Data Format

z Data should be collected and reported periodically during the measured test cycle
and used for continual improvement.
z Project team determines the objectives for the Defect Removal Efficiency
measurements.
z The organization should establish thresholds to indicate the need for corrective
action.

7.5.3 Sample Charts
Notes Defect Rem oval Effectiveness
10 0%
90%
80%
70%
60%
DRE 1
50% DRE 2
DRE 3
40%
30%
20%
10%
0%
1 2 3 4 5 6 7 8 9 10
Measurement Period
Figure 7.7 Sample charts
Measurement Period
1 2 3 4 5 6 7 8 9 10
DRE1 5% 20% 25% 35% 50% 70% 84% 90% 95% 98%
DRE2 3% 10% 20% 25% 40% 65% 70% 80% 90% 95%
DRE3 19% 50% 80% 71% 80% 95% 83% 85% 90% 90%
7.6 Capability Maturity Model

Developing good software is difficult. Much time and effort has been spent searching for
ways to improve software development. Many solutions have been proposed to help
development projects deliver a quality product on time and on budget. One of the most
sophisticated of these approaches is the Capability Maturity Model, or CMM. The CMM
is a process improvement approach to software engineering, originally developed by the
Software Engineering Institute (SEI) at Carnegie-Mellon University. The term CMM is
occasionally used to describe any process improvement approach to software
development. In this discussion, it refers strictly to the SEI model. A process
improvement model defines a set of steps intended to define, evaluate, and optimize
the business processes within an organization. The CMM outlines a series of steps
software development organizations can take to improve results. Organizations are
evaluated against a scale of five maturity levels, and the steps needed to achieve the
next level are identified. The CMM is an attempt to formalize what is often a chaotic and
disorganized process. It emphasizes well-defined processes, goals, and practices as a
way to turn software production into a successful, repeatable endeavor. In 2002, CMM
was replaced by the more comprehensive Capability Maturity Model Integration (CMMI).
In the following section, the history of CMM and CMMI and the maturity levels of the two
models are explained. The discussion concludes with an overview of how CMM and
CMMI can be applied in an organization.
The CMM is used to evaluate the maturity level of an organization. Five levels (1
through 5) are defined. The maturity levels effectively classify development
organizations by their capability to control critical processes. The SEI maintains that
predictability, effectiveness, and control of the development process improve as an
organization moves up through the levels.
The goal is to achieve a level of discipline that provides for continuous improvement
in the overall development process. Key process areas are sets of related activities that
are used as a group to achieve a goal or set of goals. Defining goals is critical. The

extent to which goals are met determines the capability of the organization at a given
level. Goals define the scope, intent, and boundaries of each key process area.
Notes
The two different implementations of CMMI are staged and continuous. The staged
model is descended from the software development CMM. The latest version of CMMI,
version 1.2, contains 22 process areas, divided into four categories, with maturity levels
for each (the previous version, 1.1, contains 25 process areas). The four categories are
process management, project management, engineering, and support. Each of the 22
process areas contains 1 to 4 goals, with each goal consisting of different practices. An
additional set of goals and practices (the generic goals and practices) apply across all
process areas.
The staged model uses appraisals to produce a CMMI level rating. CMMI
appraisals use the Standard CMMI Appraisal Method for Process Improvement
(SCAMPI) to provide benchmarks in the different process areas. The focus of the
remainder of this article is the use of the CMM and CMMI for software development.
The Levels
The adoption of CMMI includes more definition of process areas. Rather than a single
grade, an appraisal in CMMI evaluates performance in all the process areas. This
finergrained approach allows for more detailed assessment of the areas an organization
needs to improve. The levels in CMMI and CMM are approximately the same, although
some have been renamed. Meeting the goals at one level explicitly requires meeting all
goals at lower levels. In both models, maturity levels provide a way to predict the future
performance of organizations based on process discipline. Recent versions of CMMI
include a level 0, which is defined as Incomplete. Some authors have posited that
negative levels should be provided, to account for environments that are actively
counterproductive.
The key features of the maturity levels are briefly discussed next.
Maturity Level 1:
Initial In the beginning, everything is chaotic. SEI frequently uses the phrase “ad hoc” to
describe processes at this maturity level. The organization does not provide stability in
its processes. Success depends upon individual competence, motivation, and effort.
Level 1 organizations can produce good results, but they are frequently late and over
budget.
Maturity Level 2: Repeatable (in CMMI, Managed)

At level 2, success in development projects is repeatable. Requirements are managed,
and processes are planned, performed, measured, and controlled. Project management
is used to track costs and schedules. The discipline is present to ensure that practices
endure in times of stress. Project status and delivery is visible to management at
agreed-upon points, for example, major milestones.
Maturity Level 3: Defined

Level 3 organizations have standardized their development processes so that they are
well-documented and understood. These standard processes are used to provide
consistency across the organization. Management sets project objectives based on
standard processes, and ensures that these goals are addressed. At maturity level 3,
the standards and procedures for an individual project are derived from organizational
standards to suit that particular project. This is a key distinction between levels 2 and 3.
Both levels require project standards, procedures, and process descriptions. In level 2,
they might be unique to a project. In level 3, they are tailored from broader
organizational standards. It is expected in level 3 that processes will be described in
more detail and with more rigor. Management is expected to understand relationships
between processes and to collect detailed metrics of performance.

Maturity Level 4: Managed (in CMMI, Quantitatively Managed)
Notes Level 4 is about introducing precise measurements into the process. Maturity level 4
organizations use quantitative metrics, including statistics, to control key processes and
subprocesses. Numeric goals are established for quality and performance, and are
used in process management. Detailed measures of performance are collected,
analyzed, and archived for future reference. The critical distinction between level 3 and
level 4 organizations is predictable performance. Level 4 organizations control
performance with feedback based on quantitative information. When processes vary
outside the normative performance, the sources of performance degradation are
identified and corrective measures are applied.
Maturity Level 5: Optimizing

Organizations at maturity level 5 have developed continually improving process
performance, based on a detailed understanding of the relationships between the
processes and quantitative monitoring of process performance. Process performance
improvement might be based on incremental improvements in existing processes, or
through the introduction of technological innovations. Quantitative goals for process
improvement for the organization are established, revised as business requirements
change, and used in the managing projects. Process improvements are identified,
analyzed, and implemented to address the organization’s most common problems. To
be successful at level 5, organizations must motivate and empower employees in
alignment with the organization’s business objectives and values. A key distinction
between level 4 and level 5 is the types of process variation that are addressed. At level
4, the concern is with individual projects experiencing delays and variations. Level 5
organizations develop processes to address the common causes of process delay and
variation, and to change processes to improve performance.
7.7 ISO 9000

A Quality assurance system may be defined as the organizational structure,
responsibilities, procedures, processes, and resources for implementing quality
management. ISO 9000 describes quality assurance elements in generic terms that can
be applied to any business regardless of the products or services offered.
To become registered to one of the quality assurance system models contained in
ISO 9000, a company's quality system and operations are scrutinized by third party
auditors for compliance to the standard and for effective operation. Upon successful
registration, a company is issued a certificate from a registration body represented by
the auditors. Semiannual surveillance audits ensure continued compliance to the
standard.
Moving Through Maturity Levels

The expected course of development for an organization implementing CMMI is
sequential progress through the levels. The firm needs to stabilize at a given maturity
level before advancing. Because each level builds upon the foundation of the previous
level, skipping levels can be counterproductive. Organizations with mismatched levels
in different process areas in a single project can put improvements at risk. For example,
a maturity level 3 engineering process is more likely to fail if maturity level 2
management practices make for poorly planned schedules or a lack of change control.
The ISO Approach to Quality Assurance Systems

The ISO 9000 quality assurance models treat an enterprise as a network of
interconnected processes. For a quality system to be ISO-compliant, these processes
must address the areas identified in the standard and must be documented and
practiced as described. Documenting a process helps an organization understand,
control, and improve it. It is the opportunity to understand control and improve the

process network that offers, perhaps, the greatest benefit to organizations that design
and implement ISO compliant quality systems.
Notes
ISO 9000 describes the elements of a quality assurance system in general terms.
These elements include organizational structure, procedures, processes, and resources
needed to implement quality planning, quality control, quality assurance, and quality
improvement. However, ISO 9000 does not describe how an organization should
implement these quality system elements, Consequently, the challenge lies in designing
and implementing a quality assurance system that meets the standard and fits the
company's products, services, and culture.
The ISO 9001 Standard

ISO 9001 is the quality assurance standard that applies to software engineering. The
standard contains 20 requirements that must be present for an effective quality
assurance system. Because the ISO 9001 standard is applicable to all engineering
disciplines, a special set of ISO guidelines (ISO 9000-3) have been developed to help
interest the standard for use in the software process.
The 20 requirements delineated by ISO 9001 address the following topics:
1. Management responsibility
2. Quality system
3. Contract review
4. Design control
5. Document and data control
6. Purchasing
7. Control of customer supplied product
8. Product identification and tractability
9. Process control
10. Inspection and testing
11. Control of inspection, measuring, and test equipment
12. Inspection and test status
13. Control of nonconforming product
14. Corrective and preventive action
15. Handling, storage, packaging, preservation, and delivery
16. Control of quality records
17. Internal quality audits
18. Training
19. Servicing
20. Statistical techniques
In order for a software organization to become registered to ISO 9001, it must
establish policies and procedures to address each of the requirements noted above and
then be able to demonstrate that these policies and procedures are being followed.
7.8 Summary
A formal inspection is a formal, scheduled activity where a designer presents material
about a design and a selected group of peers evaluates the technical aspects of the
design. The moderator selects the team, conducts the inspection, and reports the
results. The reader is often not the producer of the product; however, the reader will
guide the team through the work product during the inspection meeting. The recorder
maintains the records of the inspection and accurately reports each defect. The

producer is the one who originally produced the product. His or her role is to answer
questions during the inspection. The producer is also responsible for correcting any
Notes problems identified in the inspection. He or she then reports the corrections to the
moderator. When the producer satisfies the entrance criteria, the inspection is
scheduled. The producer then conducts an overview. It acquaints the rest of the
inspection team with the product to be inspected. The inspection team members study
the product. The time spent in preparing is controlled based on the size of the product in
KLOC. The moderator supervises the inspection meeting.
Some approaches use a reader other than the producer to actually conduct the
inspection. The producer reviews the report and corrects the product. The moderator
reviews the report and the correction. If it satisfies the exit criteria, the inspection is
completed. If not, the moderator can either have the producer rework the product or
reinspection can be scheduled. A checklist is a list of items that should be checked
during the review. Sometimes the items are expressed as questions to be answered.
The error rate is the inverse of the time between errors. The error rate can be used as
an estimate of the probability of failure, F(1). Rayleigh’s defect prediction model is
useful in determining the number of defects that are likely to occur during execution of a
project in the early stages. Defect removal effectiveness is a very important aspect of
product quality. A good defect removal process promotes the release of products with
lower latent defects, generating high customer confidence.

Multiple Choice Questions
1. CMM stands for
(a) Capability Management Module
(b) Conservative Maturity Model
(c) Capability Maturity Module
(d) Capability Maturity Model
2. Which of the following is not a maturity level in CMM?
(a) Design
(b) Repeatable
(c) Managed
(d) Optimizing
3. Which of the following is not a phase of “bath tub curve” of hardware reliability?
(a) Useful Life
(b) Burn-in
(c) Wear-out
(d) Time
4. How is reliability and failure intensity related to each other?
(a) direct relation
(b) inverse relation
(c) no relation
5. How many product quality factors are proposed in McCall quality model?
(a) 2
(b) 3
(c) 11
(d) 8

6. Which one of the following is not a software quality model?
(a) ISO 9000
Notes
(b) McCall model
(c) Boehm model
(d) ISO 9126
7. What is MTTF?
(a) Maximum time to failure
(b) Mean time to failure
(c) Minimum time to failure
(d) None of the mentioned
8. How is software reliability defined?
(a) time
(b) efficiency
(c) quality
(d) speed
9. Suitability, Accuracy, Interpolability and security are what type quality attribute of
ISO 9126?
(a) Reliability
(b) Efficiency
(c) Functionality
(d) Usability
10. Time Behavior and Resource Behavior fall under which quality attribute of ISO
9126?
(a) Reliability
(b) Efficiency
(c) Functionality
(d) Usability

1. What is the formal inspection? What distinguishes a formal inspection from other
reviews?
2. Describe the Rayleigh model. What is its role of this model? What is the goal of
inspections?
3. Explain the Weibull model. What do you mean by defect removal effectiveness?
4. What are the basic roles that most inspections use? What are the basic steps in an
inspection?
5. “CMM is the widely used and preferred software method of evaluation.” Justify.
6. Explain software reliability models
7. What are the various applicable product categories?
8. Explain the concept of Defect Removal Effectiveness.
7.11 Key Terms

z Moderator: The moderator selects the team, conducts the inspection, and reports
the results.
z Reader: The reader is often not the producer of the product; however, the reader
will guide the team through the work product during the inspection meeting.

z Recorder: The recorder maintains the records of the inspection and accurately
reports each defect.
Notes z Producer: The producer is the one who originally produced the product. His or her
role is to answer questions during the inspection.
z Rework: The producer reviews the report and corrects the product.
z Checklists: A checklist is a list of items that should be checked during the review.
Sometimes the items are expressed as questions to be answered.
z Error Rates: The error rate is the inverse of the time between errors (inter-error
time). The error rate can be used as an estimate of the probability of failure, F(1).
Check Your Progress: Answers

1. (d) Capability Maturity Model
2. (c) Managed
3. (d) Time
4. (b) inverse relation
5. (b) 3
6. (a) ISO 9000
7. (b) Mean time to failure
8. (a) time
9. (c) Functionality
10. (b) Efficiency

z Vasudeva Varma, Varma Vasudeva, Software Architecture: A Case Based
Approach, Pearson Education India, 2009
z Jibitesh Mishra, Software Engineering, Pearson Education, 2011
z Rajib Mall, Fundamentals Of Software Engineering, PHI Learning Pvt. , 2009
z Pankaj Jalote, A Concise Introduction to Software Engineering, Springer Science &
Business Media, 2008

Software Module 4

Uploaded by

Document Informationclick to expand document information

Copyright:

Available Formats

Software Module 4

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Software Module 4

Uploaded by

Copyright:

Available Formats

108 Software Engineering

Unit 6: Software Metrics

6.2 Software Metrics

Amity Directorate of Distance and Online Education

Advantage of Software Metrics

Limitation of Software Metrics

6.3 Size Metrics

Amity Directorate of Distance and Online Education

6.4 Classification of Metrics

Amity Directorate of Distance and Online Education

6.4.1 Size-oriented Metrics Notes

Figure 6.1: Size-oriented Metrics

Three people worked on the development of software for project alpha.

Amity Directorate of Distance and Online Education

6.4.2 Function-oriented Metrics

Figure 6.2: Computing Function Point

Amity Directorate of Distance and Online Education

FP = Count total × [0.65 + 0.01 × Σ (Fi)] Notes

6.4.3 Extended Function Point Metrics

Amity Directorate of Distance and Online Education

Figure 6.2: Determining the Complexity of a Transformation for 3D Function Point

where I, O, Q, F, E, T, and R represent complexity weighted values for the elements

Amity Directorate of Distance and Online Education

6.4.4 Cyclomatic Complexity

Construct Decisions Reasoning

Amity Directorate of Distance and Online Education

Loop While|Until +1 There is a decision at the end of the Do..Loop.

Variations: CC, CC2 and CC3

CC2 Cyclomatic complexity with Booleans ("extended cyclomatic complexity")

Amity Directorate of Distance and Online Education

CC3 Cyclomatic complexity without Cases ("modified cyclomatic complexity")

Metric Name Boolean Select Case Alternative name

Values of Cyclomatic Complexity

Amity Directorate of Distance and Online Education

CC Type of procedure Risk

Bad Fix Probability

Cyclomatic Complexity and Select Case

TCC Total Cyclomatic Complexity

Amity Directorate of Distance and Online Education

DECDENS Decision Density

6.4.5 Metrics for Software Quality

Amity Directorate of Distance and Online Education

An Overview of Factors that Affect Quality

Amity Directorate of Distance and Online Education

Defect Removal Efficiency

Amity Directorate of Distance and Online Education

6.4.6 Design Metrics

Data Structure Metrics

Amity Directorate of Distance and Online Education

Information Flow Metrics

Procedure Complexity = Length * (FAN-IN * FANOUT)**2

Architectural Design Metrics

Amity Directorate of Distance and Online Education

HKM = length(i) x [fin(i) + fout(i)]2

Figure 6.3: Morphology Metrics

Amity Directorate of Distance and Online Education

6.4.7 Object Oriented Software Metrics

Amity Directorate of Distance and Online Education