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.
Top
2
SOFTWARE ENGINEERING
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.
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
SOFTWARE ENGINEERING FUNDAMENTAL
3
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.
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,
4
SOFTWARE ENGINEERING
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.
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
SOFTWARE ENGINEERING FUNDAMENTAL
5
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
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
6
SOFTWARE ENGINEERING
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 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
SOFTWARE ENGINEERING FUNDAMENTAL
ii.
7
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 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.
8
SOFTWARE ENGINEERING
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 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 + N2
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, 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
SOFTWARE ENGINEERING FUNDAMENTAL
9
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 n1 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 + N2
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
This length equation estimates the size of the program from the counts of unique operators (n 1) and unique
operands (n2). 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 = n1 + 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. log2 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.
10
SOFTWARE ENGINEERING
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 n2 * 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 difficult to determine potential volume (V*), so
Halstead gave an alternate formula for program level as:
L = ( 2 n2 ) / ( n1 N2 )
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.log2 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
SOFTWARE ENGINEERING FUNDAMENTAL
11
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 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
12
SOFTWARE ENGINEERING
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.
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.
SOFTWARE ENGINEERING FUNDAMENTAL
13
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
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
14
SOFTWARE ENGINEERING
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
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:
SOFTWARE ENGINEERING FUNDAMENTAL

Errors per FP.

Defects per FP.

Rs per FP.

Pages of documentation per FP.

FP per person-month.
15
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.
16
SOFTWARE ENGINEERING
Complexity metrics also provide feedback during the software project to help control the design
activity.
Self-assessment Questions
Solved Exercise
I.
II.
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.
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
_______.
Answers
I.
II.
True or False.
1.
False
2.
False
3.
True
4.
True
5.
False
Fill in the blanks.
1.
real-time
2.
defect-rate/module
3. Volumes
4.
productivity
5.
span
as
SOFTWARE ENGINEERING FUNDAMENTAL
17
Unsolved Exercise
I.
II.
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.
Fill in the blanks.
1.
A _________ software usually resides in the ROM of the memory.
2.
Ease of reading or writing is defined as (n1 * N2)/(2 * n2), where n1, n2 and N2
_________, __________ 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 ________.
are
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, n 1 =
16 and number of operands n2 = 32 determine the following:
i.
Program length (through estimator)
ii.
Program volume
iii.
Program level
iv.
Language level
v.
Effort and time