Software

Software Engineering Concepts

Software Characteristics
Software Applications
Software Metrics
Size Metrics
Halstead’s Theory
Function-Point Analysis

Unit 1
Software Engineering Fundamentals

Learning Objectives
After reading this unit, you should appreciate the following:
 Software
 Software Engineering Concepts
 Software Characteristics
 Software Applications
 Software Metrics
 Size Metrics
 Halstead’s Theory
 Function Point Analysis

Top

Software
Before 1970, very few people knew what "computer software" meant. But now a
days, professionals and many members of the public at large understand what the
software means.
If we think about the description of software, it will take the following form: Software
is
(1) basically instructions, (computer logical programs) that when these instructions
are executed then we can perform desired functions and maintain the performance,
(2) data structures that enable the programs to adequately manipulate information
for the required results, and
(3) documents that describe the operation and use of the programs for the better
understandability of the user of the program.
2 SOFTWARE ENGINEERING

Top

Software Engineering Concepts

The era of electronic computers started in 1940s. The initial efforts of improvement
were mainly focused on hardware. With the improvement in the field of electronics,
hardware became very effective by 1960s. At this time, programming techniques
available were not very effective and so, we were not exploiting hardware capabilities
fully. The software development techniques were adhoc and programming-centered.
These adhoc or programming-centered approach may work for small problems, but
for the large and complex problems/projects, these techniques generally do not work.
As a result of this, computing world found itself in a crisis, which is known as
“software crisis”. If we have to control this software crisis, some scientific and
systematic approach is needed for software development. To overcome this problem
of software crisis, NATO science committee held two conferences in the 1960s in
Europe. This is where the term ‘software engineering’ was coined.
Software engineering is defined as the systematic and scientific approach to develop,
operate, maintain and to retire the software product. Software product means
software for a large/medium size and complex problem. We get the real advantage of
software engineering when it is applied to a project. Though it can also be used for
the development of programs/small assignments.
Another definition of software engineering may be:
Software engineering is the application of science and mathematics, by which the
computer hardware is made useful to the user via software (computer programs,
procedures, and associated documentation).
The main objective of software engineering is to produce good quality software with
minimum cost and within the limited allowed time period.
The discipline of software engineering provides methodologies, which make software
development process closer to the scientific method and away from being an art.
That is, these methodologies are repeatable. It means that if different people with the
same requirements apply the methodology, similar software will be produced.
The phrase useful to user emphasizes the needs of the user and the software's
interface with the user. It means that user needs should be given due importance in
the development of software, and the final software product should give importance
to the user interface.

Student Activity 1.1

Before reading the next section, answer the following questions.
1. Define software engineering.
2. What are software engineering concepts?
If your answers are correct, then proceed to the next section.
SOFTWARE ENGINEERING FUNDAMENTAL 3

Top

Software Characteristics
For a better understanding of the software, it is important to examine the
characteristics of software that make it different from other things that human beings
build. When hardware is built, the human creative process (analysis, design,
construction, testing) is ultimately translated into a physical form. If we build a new
computer, our initial sketches, formal design drawings, and bread boarded prototype
evolve into a physical product (chips, circuit boards, power supplies, etc.).
Since software is purely logical rather than a physical system element, it therefore,
has characteristics that are entirely different than those of hardware:
1. Software is developed or engineered but it is not manufactured in the classical
sense: Although some similarities exist between software development and
hardware manufacture, the two activities are fundamentally different. In both
activities, high quality is achieved through good design, but the manufacturing
phase for hardware can introduce quality problems that are nonexistent (or
easily corrected) for software. Both activities are dependent on people, but the
relationship between people applied and work accomplished is entirely different.
Both activities require the construction of a "product" but the approaches are
different. Software costs are concentrated in engineering. This means that
software projects cannot be managed as if they were manufacturing projects.
Software doesn't "wear out."

FIGURE 1.1:HARDWARE FAILURE CURVE

Figure 1.1 shows failure rate as a function of time for hardware. The relationship,
often called the "bathtub curve," indicates that hardware exhibits relatively high
failure rates early in its life (these failures are often attributable to design or
manufacturing defects); defects are corrected and the failure rate drops to a
steady-state level (ideally, quite low) for some period of time. As time passes,
however, the failure rate rises again as hardware components suffer from the
cumulative affects of dust, vibration, abuse, temperature extremes, and many
other environmental maladies. Stated simply, the hardware begins to wear out.
4 SOFTWARE ENGINEERING

Software is not susceptible to the environmental maladies that cause hardware

to wear out. In theory, therefore, the failure rate curve for software should take
the form of the "idealized curve" shown in Figure 1.2. Undiscovered defects will
cause high failure rates early in the life of a program. However, these are
corrected (ideally, without introducing other errors) and the curve flattens as
shown. The idealized curve is a gross over-simplification of actual failure models
for software. However, the implication is clear, software doesn't wear out. But it
does deteriorate!
This seeming contradiction can best be explained by considering the "actual
curve" shown in Figure 1.2. During its life, software will undergo change
(maintenance). As the changes are made, it is likely that some new defects will
be introduced, causing the failure rate curve to spike as shown in Figure. Before
the curve can return to the original steady-state failure rate, another change is
requested, causing the curve to spike again. Slowly, the minimum failure rate
level begins to rise-the software is deteriorating due to change.
Another aspect of wear illustrates the difference between hardware and software.
When a hardware component wears out, it is replaced by a spare part. There are
no software spare parts. If any software fails then it indicates an error in design
or an error in the process through which design was translated into machine
executable code then it means some compilation error. So it is very much clear
that, software maintenance involves more complexity than hardware
maintenance or we can say that software maintenance is a more complex
process than hardware maintenance.

FIGURE 1.2: SOFTWARE IDEALIZED AND ACTUAL FAILURE CURVES

2. Consider the manner in which the control hardware for a computer-based product
is designed and built: The design engineer draws a simple schematic of the
digital circuitry, does some fundamental analysis to assure that proper function
will be achieved, and then goes to the shelf where catalogs of digital components
exist. Each integrated circuit (called an IC or a chip) has a part number, a defined
and validated function, a well-defined interface, and a standard set of integration
guidelines. After each component is selected, it can be ordered off the shelf.
SOFTWARE ENGINEERING FUNDAMENTAL 5

According to the standard engineering discipline, a collection of standard design

components is created. Standard screws and off-the-shelf integrated circuits are
only two of thousands of standard components that are used by mechanical and
electrical engineers as they design new systems. The reusable components have
been created so that the engineer can concentrate on the truly innovative
elements of a design, that is, the parts of the design that represent something
new. In the hardware world, component reuse is a natural part of the engineering
process. In the software world, it is something that has only begun to be
achieved on a broad scale. In the end, we can say that software design is a
complex and sequential process.
A software component should be designed and implemented so that it can be
reused in different programs since it is a better approach, according to finance
and manpower. In the 1960s, we built scientific subroutine libraries that were
reusable in a broad array of engineering and scientific applications. These
subroutine libraries reused well-defined algorithms in an effective manner but
had a limited domain of application. Today, we have extended our view of reuse
to encompass not only algorithms but also data structure. Modern reusable
components encapsulate both data and the processing applied to the data,
enabling the software engineer to create new applications from reusable parts.
For example, today's graphical user interfaces are built using reusable
components that enable the creation of graphics windows, pull-down menus, and
a wide variety of interaction mechanisms. The data structure and processing
detail required to build the interface are contained with a library of reusable
components for interface construction.

Top

Software Applications
Software may be applied in any situation for which a pre-specified set of procedural
steps (i.e., an algorithm) has been defined. Information content and determinacy are
important factors in determining the nature of a software application. Content refers
to the meaning and form of incoming and outgoing information. For example, many
business applications use highly structured input data (e.g., a database) and produce
formatted "reports." Software that controls an automated machine (e.g., a numerical
control) accepts discrete data items with limited structure and produces individual
machine commands in rapid succession.
Information determinacy refers to the predictability of the order and timing of
information. An engineering analysis program accepts data that have a predefined
order, executes the analysis algorithm(s) without interruption, and produces resultant
data in report or graphical format. Such applications are determinate. A multi-user
operating system, on the other hand, accepts inputs that have varied content and
arbitrary timing, executes algorithms that can be interrupted by external conditions,
and produces output that varies as a function of environment and time. Applications
with these characteristics are indeterminate.
System software: System software is a collection of programs and utilities for
providing service to other programs. Other system applications (e.g., operating
system components, drivers, telecommunications processors) process largely
indeterminate data. In either case, the system software area is characterized by
6 SOFTWARE ENGINEERING

heavy interaction with computer hardware; heavy usage by multiple users;

concurrent operation that requires scheduling, resource sharing, and sophisticated
process management; complex data structures; and multiple external interfaces.
Real-time software: Software for the monitors/analyzes/controls real-world events as
they occur is called real time. Elements of real-time software include a data-gathering
component that collects and formats information from an external environment, an
analysis component that transforms information as required by the application, a
control/output component that responds to the external environment, and a
monitoring component that coordinates all other components so that real-time
response can be maintained.
Business software: Business information processing is the largest single software
application area. In a broad sense, business software is an integrated software
and has many components related to a particular field of the business.
Discrete "systems" for example, payroll, accounts receivable/payable, inventory have
evolved into management information system (MIS) software that accesses one or
more large databases containing business information. Applications in this area
restructure existing data in a way that facilitates business operations or management
decision-making. In addition to conventional data processing application, business
software applications also encompass interactive computing.
Engineering and scientific software: Engineering and scientific software have been
characterized by "number crunching" algorithms. Applications range from astronomy
to volcano logy, from automotive stress analysis to space shuttle orbital dynamics,
and from molecular biology to automated manufacturing. However, modern
applications within the engineering/scientific area are moving away from
conventional numerical algorithms. Computer-aided design, system simulation, and
other interactive applications have begun to take on real-time and even system
software characteristics.
Embedded software: Embedded software resides in read-only memory and is used to
control products and systems for the consumer and industrial markets. Embedded
software can perform very limited and esoteric functions (e.g., keypad control for a
microwave oven) or provide significant function and control capability (e.g., digital
functions in an automobile such as fuel control, dashboard displays, and braking
systems).
Personal computer software: The personal computer is the type of computer, which
gave revolution to the information technology. The personal computer software
market has burgeoned over the past two decades. Word processing, spreadsheets,
computer graphics, multimedia, entertainment, database management, personal and
business financial applications, external network, and database access are only a few
of hundreds of applications.
Web-based software: The Web pages processed by the browser are the software that
incorporates executable instructions (e.g., CGI, HTML, PERL, or Java), and data (e.g.
hypertext and a variety of visual and audio formats). In essence, the network
becomes a massive computer providing an almost unlimited software resource that
can be accessed by anyone with a modem.
Artificial intelligence software: Artificial intelligence (AI) software is the software,
which thinks and behaves like a human. AI software makes use of non-numerical
SOFTWARE ENGINEERING FUNDAMENTAL 7

algorithms to solve complex problems that are not amenable to computation or

straightforward analysis. Expert systems, also called knowledge-based systems,
pattern recognition (image and voice), artificial neural networks, theorem proving,
and game playing are representative of applications within this category.

Student Activity 1.2

Before reading the next section, answer the following questions.
1. What do you understand by software characteristic?
2. Define different types of software.
If your answers are correct, then proceed to the next section.

Top

Software Metrics
Without software, computer hardware is of no use. A major share of the computing
budget is incurred on software development or its purchase, by each organization.
So, software systems are very precious and important products for both software
developers and users. Software is not a single attribute product but it has many
characteristics, which one can measure. For example, the size in lines of code, the
cost of development and maintenance in rupees, the time for development in person
- months, the size of memory required in bytes, and so on. Still, it is quite obvious
that different observers of the same computer program may get different results,
even when the same characteristic is measured.
For example, consider the lines of code property of a computer program. One
observer may count all the lines present in the program including blank lines and
comments. Another observer may drop comments and blank lines from the count by
realizing that these do not affect the performance of the program. Therefore, a
standard and precise definition of the line of code metric is required, so that for the
same program, different persons may get identical counts. Only under such standard,
identical and homogenous conditions, we can compare the results of empirical
studies conducted by different people at different times or places.
From time-to-time, different software metrics have been developed to quantify
various attributes of a software product. Broadly speaking, these may be grouped
into two categories. These are:
i. Product metrics
ii. Process metrics
The software metrics, like size, which can be derived from the software itself, are
called product metrics. While, all those measurements of a software product which
depend upon the development environment are called process metrics. Such metrics
do not require the analysis of the program itself and are related to the development
process. For example, measurement of the time required by a programmer to design,
code and test a program is a process metric. This metric depends upon many things
including the complexity of the problem, the knowledge and ability of the developer,
the type of algorithm used, and the availability of the computer time during the
8 SOFTWARE ENGINEERING

development process etc. Therefore, if one computer program is to be developed by

different programmers under different conditions, then their development time (for
the same program) cannot be identical. Such metrics, like development time and
effort estimation, may not be reproducible exactly. But, it does not mean that these
are not useful and informative. In fact, these are the most important, useful,
informative and interesting software metrics.

Top

Size Metrics
For solving different problems on computer, programs are developed, written and
implemented by different programmers. For achieving different objectives, programs
are written in different programming languages. Some programs are written in C, C+
+, few in Pascal and FORTRAN, some in COBOL, while others in C++, VB, VC++, Java,
Ada languages and so on. Some programs are of good quality, well documented and
written with latest software engineering techniques. While others are written in a
“quick-and-dirty” way with no comments and planning at all. Despite all these, there
is one common feature which all programs share - all have size.
Size measure is very simple, and important metric for software industry. It has many
useful characteristics like:
 It is very easy to calculate, once the program is completed.
 It plays an important role and is one of the most important parameter for many
software development models like cost and effort estimation.
 Productivity is also expressed in terms of size measure.
 Memory requirements can also be decided on the basis of size measure.
The principal size measures, which have got more attention than others, are:
1. Lines of Code (LOC)
2. Token count
3. Function count

Lines of Code
It is one of the earliest and the simplest metric for calculating the size of a computer
program. It is generally used in calculating and comparing the productivity of
programmers. Productivity is measured as LOC / man-month. Among researchers,
there is no general agreement what makes a line of code. Due to lack of standard and
precise definition of LOC measure, different workers for the same program may
obtain different counts. Further, it also gives an equal weightage to each line of code.
But, in fact some statements of a program are more difficult to code and comprehend
than others. Despite all this, this metric still continues to be popular and useful in
software industry because of its simplicity.
The most important characteristic of this metric is its precise and standard definition.
There is a general agreement among researchers that this measure should not
SOFTWARE ENGINEERING FUNDAMENTAL 9

include comment and blank lines because these are used only for internal
documentation of the program. Their presence or absence does not affect the
functionality, efficiency of the program. Some observers are also of the view that only
executable statements should be included in the count, because these only support
the functions of the program.
The predominant definition of LOC measure used today by various software personnel
is:
“Any line of program text excluding comment or blank lines, regardless of the
number of statements or parts of statements on the line, is considered a line of code
(LOC). It excludes all lines containing program headers, declarations, and non-
executable statements and includes only executable statements.”

Token Count
The drawback in LOC size measure of treating all lines alike can be solved by giving
more weight to those lines, which are difficult to code and have more “stuff”. One
natural solution to this problem may be to count the basic symbols used in a line
instead of lines themselves. These basic symbols are called “tokens”. Such a scheme
was used by Halstead in his theory of software science. In this theory, 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. 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 occurrences of operands

An operator can be defined as a symbol or keyword, which specifies an action.
Operators consist of arithmetic, relational symbols, punctuation marks, special
symbols (like braces, =), reserve-word/keywords (like WHILE, DO, READ) and function
names like printf (), scanf () etc. A token, which receives the action and is used to
represent the data, is called an operand. Operands include variables, constants and
even labels.
In terms of the total tokens used, the size of the program can be expressed as:
N = N1 + N 2
At present, there is no general agreement among researchers on counting rules for
the classification of these tokens. These rules are made by the programmer for
his/her convenience. The counting rules also depend upon the programming
language.

Function Count
The size of a large software product can be estimated in a better way, through a
larger unit called module, than the LOC measure. A module can be defined as
segment of code, which may be compiled independently. For large software systems,
10 SOFTWARE ENGINEERING

it is easier to predict the number of modules than the lines of code. For example, let a
software product require n modules. It is generally agreed that size of the module
should be about 50 - 60 lines of code. Therefore, size estimate of this software
product is about n x 60 lines of code. But, this metric requires precise and strict rules
for dividing a program into modules. Due to the absence of these rules, this metric
may not be so useful.
A module may consist of one or more functions. In a program, a function may be
defined as a group of executable statements, which performs a definite task. The
number of lines of code for a function should not be very large. It is because human
memory is limited and a programmer cannot perform a task efficiently if the
information to be manipulated is large.

Top

Halstead’s Theory
Researchers generally agree that simple size measures like lines of code (LOC) are
not adequate for determining software complexity and development effort. They are
of the view that, for this purpose, a programming process model is needed. This
model should be based upon manageable number of factors, which affect the
complexity and quality of the software systems. A number of researchers including
Halstead, McCabe have attempted to define such programming models.
Halstead’s model also known as theory of software science is based on the
hypothesis that program construction involves a process of mental manipulation of
the unique operators (n1) and unique operands (n2). It means that a program of N1
operators and N2 operands is constructed by selecting among n 1 unique operators
and n2 unique operands. By using this model, Halstead derived a number of
equations related to programming such as program level, the implementation effort,
language level and so on. Also, it is one of the most widely studied theories and has
been supported by a number of empirical studies.
An important and interesting characteristic of this model is that a program can be
analysed for various features like size, effort etc. by simply counting its basic
parameters n1, n2, N1 and N2.

Program vocabulary is defined as

N = n1 + n2

And program actual length as

N = N1 + N 2

One of the hypotheses of this theory is that the length of a well - structured program
is a function of n1 and n2 only. This relationship is known as length prediction equation
and is defined as

Nh= n1 log2 n1 + n2 log2 n2

SOFTWARE ENGINEERING FUNDAMENTAL 11

This length equation estimates the size of the program from the counts of unique
operators (n1) and unique operands (n 2). If the actual length (N) agrees well with the
estimated value (Nh), then the program is considered as well structured.

Program Volume (V)

The programming vocabulary n = n 1 + n2 (set of unique operators and operands)
used in writing a program, leads to another size measure which may be defined as

V = N log2 n

It is called as the volume of the program. It may be interpreted as the number of

mental comparisons needed to write a program of length N. The unit of measurement
for program volume, V, is binary digit i.e. bit. Thus, total number of bits required to
represent a program of length N would be N. log 2 n.

It is assumed that during programming process, the human mind follows binary
search technique in selecting the next token from the vocabulary of size n.

Potential Volume (V*)

It is clear that an algorithm can be implemented through many different but
equivalent programs. Out of these programs, one, which has the minimum size, is
said to have the potential volume ( V*). It may be defined as:

V* = (n1 * + n2 * ) log2 (n1 * + n2 * )

Where

n1 * is the minimum number of operators and n 2 * is the minimum number of

operands for an implementation.

Minimum number of operators, n1 *, for any procedure is two–the procedure name

and a grouping symbol that separates the procedure name from its parameters.

So, for any procedure

V* = (2 + n2 * ) log2 (2 + n2 * )

The minimum number of operands, n2 *, is the number of unique input and output
parameters. For small, simple programs, it can be calculated easily but for large,
complex programs like compiler, operating system, it is difficult to compute.

Program Level (L)

An algorithm may be implemented in many different but equivalent ways. But, it is
the level of the program, which makes two implementations different and is defined
as

L = V* / V

The maximum value for program level, L, is 1. A program with L = 1 is said to be

written at the highest possible level (i.e. with minimum size). Because, it is very
12 SOFTWARE ENGINEERING

difficult to determine potential volume (V*), so Halstead gave an alternate formula for
program level as:

L = ( 2 n2 ) / ( n 1 N 2 )

Programming Difficulty (D)

The difficulty involved in writing a program can be defined as the inverse of the
program level (L) and can be expressed as:
D=1/L
For a program, as the volume V increases, the program level L decreases and the
difficulty D increases.

Programming Effort (E)

As already stated, the total number of mental comparisons required for writing a
program of length N is N.log 2 n. Further, for one mental comparison, the human mind
has to perform a number of elementary mental discriminations (e.m.d.). Therefore,
the effort required to implement a computer program increases as the size of the
program increases. The programming effort E measure can be defined as:
E = V/L
The unit of measurement of E is e.m.d. (Elementary Mental Discriminations).
It is clear that more effort is required to implement a program at a lower level (higher
difficulty) than another equivalent implementation at a higher level (lower difficulty).

Programming Time (T)

According to John Stroud [3,36], human mind can make a limited number of
elementary mental discriminations per second. Halstead called this number as Stroud
number and denoted it as B. Stroud claimed that the value of B ranges between 5
and 20. By using this number, time taken by a programmer to complete a
programming task can be estimated in seconds as
T=E/B
Generally, the value of B is taken as 18, since this number has given the best results
for Halstead’s earlier experiments.

Language Level (L)

At present, a number of programming languages are being used. Therefore, a
software measure is required that expresses the power of the language. For this
purpose, another metric, called language level is defined by Halstead as
L = L V* = L2 V
This metric is based on the hypothesis that for a given programming language, as V*
increases, L decreases in such a way that LV* remains constant.
For the validation of Halstead’s software metrics, it is necessary that programs should
be devoid of any kind of impurity or redundancy. Impurities in an implementation
SOFTWARE ENGINEERING FUNDAMENTAL 13

may be incorporated due to poorly designed, poorly structured, lengthy and complex
module. In a program, the following types of impurities may be included [15, 36]:
 Complementary Operations
 Ambiguous Operands
 Redundant Conditions
 Dead Code
 Synonymous Operands
 Common Sub-expressions
 Unwarranted Assignment, and
 Unfactored Expressions.
It is important that a program should not be ‘just’ a working program, but it must be
a good quality program. Earlier, we have explained various characteristics of a good
quality program and devoid of impurities is another step for it.
Though, the theory of software science metrics is very useful for the quantification of
various aspects of a program. These metrics have, also, been supported by many
experimental studies. But, it reflects only one type of program complexity–size. It
does not take into account the structure properties of the program or the modular
interactions of the program. Therefore, it cannot be used to measure the overall
complexity of a program.

McCabe’s Cyclomatic Complexity Metric

The basis of this measure is the control flow graph of a program. Due to its simplicity,
it is one of the most useful and accepted metric. McCabe interprets a computer
program as a set of strongly connected directed graph. Nodes represent parts of the
source code having no branches and arcs represent possible control flow transfers
during program execution. The notion of program graph has been used for this
measure and it is used to measure and control the number of paths through a
program. The complexity of a computer program can be correlated with the
topological complexity of a graph.
McCabe proposed the cyclomatic number, V (G) of graph theory as an indicator of
software complexity. The cyclomatic number is equal to the number of linearly
independent paths through a program in its graph representation. For a program
control graph G, the cyclomatic number, V (G), is given as:
V (G) = E- N + P
Where
E: The number of edges in graph G,
N: The number of nodes in graph G, and
P: The number of connected components in graph G.
14 SOFTWARE ENGINEERING

For a strongly connected graph G, the value of P = 1. A graph G is said to be strongly

connected if its each node is reachable from the every other node.
It can be easily shown that the cyclomatic complexity measure, V (G), can be
calculated by the number of control structures (like if.then.else, while.do etc.) plus 1.
Due to its ease of computation, it is one of the simplest, and the most widely
accepted measure. Besides its simplicity, this measure has several other important
features as described below:
 It is independent of program size.
 It depends only on decisions.
 V (G) >= 1.
 V (G) = 1 for a linear sequence of code of any length.
 It is equal to the maximum number of linearly independent paths in graph G.
 V (G) is unaffected by adding or deleting non-branching statements.
The cyclomatic number, V (G), can also be computed just by knowing the number of
decision structures involved in the source code. It is intuitive that number of errors is
correlated to the number of control structures included in a software module. So, this
measure may also be used for the estimation of errors (faults) in a computer
program.
As stated earlier, due to its simplicity, McCabe’s V (G) is one of the most widely
accepted complexity measures. However, it is not entirely convincing as a program
complexity measure. One of its important shortcomings is the failure to account for
the complexity due to unconditional GOTO’s. Because no decision is involved, so
these are not counted. It, also, does not take into account the complexity due to
linear sequence of statements and the nesting of control structures. So, several
researchers [46-50] have suggested modifications to the use of this measure.
McCabe’s measure, V (G), depends upon the flow of control only and is insensitive to
other parameters of program complexity such as size. McCabe observed that if the
value of V (G) for a module becomes more than 10, then that module is more likely to
be unreliable. So, such a module should be broken further to keep its V (G) <= 10.
This upper bound for V (G) for controlling the complexity of module seems
reasonable, but it needs further empirical verification.

Student Activity 1.3

Before reading the next section, answer the following questions.
1. What is role of metrics in software engineering?
2. Differentiate between process & products?
3. Define size-based metrics, complexity metrics.
If your answers are correct, then proceed to the next section.

Top
SOFTWARE ENGINEERING FUNDAMENTAL 15

Function-Point Analysis
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 as 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.
Function points are computed by completing the table shown in Figure 1.3. Five
information domain characteristics are determined and counts are provided in the
appropriate table location. Information domain values are defined in the following
manner:
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.
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.
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.
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.
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.
Weighting factor

Measurement parameter Count Simple Average Complex

Number of user inputs x 3 4 6 =

Number of user outputs x 4 5 7 =

Number of user inquiries x 3 4 6 =

Number of files x 7 10 15 =

Number of external interfaces x 5 7 10 =

Count total
16 SOFTWARE ENGINEERING

FIGURE 1.3: COMPUTING FUNCTION POINTS

To compute function points (FP), the following relationship is used:

FP = count total x [0.65 + 0.01  sum [Fi]]
Where count total is the sum of all FP entries obtained from Figure 1.3.
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 re-usable?
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 (4.1) 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:
 Errors per FP.
 Defects per FP.
 Rs per FP.
 Pages of documentation per FP.
 FP per person-month.
SOFTWARE ENGINEERING FUNDAMENTAL 17

Student Activity 1.4

Answer the following questions.
1. Describe Halstead’s Theory.
2. What is function point analysis?

Summary
 Software engineering is the systematic approach to the development, operation,
maintenance, and retirement of software.
 Software is a logical rather than a physical system element. Therefore, software
has characteristics that are considerably different than those of hardware.
 A software component should be designed and implemented so that it can be
reused in many different programs.
 Modem reusable components encapsulate both, data and the processing applied
to the data, enabling the software engineer to create new applications from
reusable parts
 Within the software engineering context, a measure provides a quantitative
indication of the extent, amount, dimension, capacity, or size of some attribute of
a product or process. Measurement is the act of determining a measure. The
metrics is a quantitative measure of the degree to which a system, component,
or process possesses a given attribute.
 Project metrics are used to minimize the development schedule by making the
adjustments necessary to avoid delays and mitigate potential problems and
risks. They are also used to assess product quality on an ongoing basis and,
when necessary, modify the technical approach to improve quality.
 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.
 Function points are derived using an empirical relationship based on countable
(direct) measures of software's information domain and assessments of software
complexity.
 Complexity metrics can be used to predict critical information about reliability and
maintainability of software systems from automatic analysis of source code or
procedural design information. Complexity metrics also provide feedback during
the software project to help control the design activity.
18 SOFTWARE ENGINEERING

Self-assessment Questions

Solved Exercise
I. True or False
1. Function point and LOC measurements for the size of software are not
correlated.
2. In today’s computer systems, hardware is much costlier than software.
3. Both, McCabe and Halstead metrics, measure complexity of a program.
4. Software becomes old or aged without being worn out.
5. Artificial intelligence softwares make use of numerical algorithms.
II. Fill in the blanks.
1. A _________ system is heavily constrained on time of execution.
2. ________ is an example of private metric.
3. Minimum number of bits necessary to represent a program is known as
__________ of the program.
4. FP per month may be used as a metric for _________ of a programmer.
5. The number of statements between two successive references of a variable
is known as _______.

Answers
I. True or False.
1. False
2. False
3. True
4. True
5. False
II. Fill in the blanks.
1. real-time
2. defect-rate/module
3. Volumes
4. productivity
5. span

Unsolved Exercise
SOFTWARE ENGINEERING FUNDAMENTAL 19

I. True or False.
1. Information determinacy refers to the predictability of the order and timing
of information.
2. Function point metric is an absolute measure of a software characteristic.
3. McCabe metric is an absolute measure of a software complexity.
4. Software product and software process are two names for the same thing.
5. Variable span and program complexity are directly proportional to each
other.

II. Fill in the blanks.

1. A _________ software usually resides in the ROM of the memory.
2. Ease of reading or writing is defined as (n 1 * N2)/(2 * n2), where n1, n2 and N2
are _________, __________ and _________ respectively.
3. A variable between its first and last reference is known as __________
variable.
4. There are _ numbers of complexity adjustment factors in FP calculation.
5. The maximum adjusting factor in an FP count can be ________.

Detailed Questions
1. Describe software metrics & different types of metric models.
2. Define the following:
a. Size metric
b. Complexity metric
c. Function point analysis
3. Describe software characteristics.
4. Describe Halstead’s theory in details and use in software engineering.
5. What are size metrics? How is function point metric advantageous over LOC
metric? Explain.
6. What is Halstead’s theory of software science? For a given program having
number of operators, n1 = 16 and number of operands n 2 = 32 determine the
following:
i. Program length (through estimator)
ii. Program volume
iii. Program level
iv. Language level
20 SOFTWARE ENGINEERING

v. Effort and time