www.neerajbooks.
com
INTRODUCTION TO
SOFTWARE ENGINEERING
DEVELOPMENT OF SRS
Characteristics of SRS
Neeraj
Software Requirement Specification (SRS) is a
requirement specification for the software that forms
the basis for the development of a software product,
program or set of programs that perform the desired
Publications
functions. Depending on the writer of the SRS, various
purposes could be served. It could be used by the
following:
Customer and users for understanding what is
www.neerajbooks.com
expected from them.
Developer for writing the desired software
product that is to be built.
Testers for performing testing activities.
Managers for estimating and planning the
project to be delivered.
Maintenance team for maintain the software
in future.
SRS minimizes the time consumed by developers
in developing as it becomes an ease in understanding
the software project which in turn leads to less
development cost. A good SRS will define all the
software requirements correctly. No design and
implementation details should be present in a SRS.
SRS should only define ‘WHAT’ a system does
and not ‘HOW’ it is done.
CHARACTERISTICS OF SRS
The SRS should be correct, unambiguous,
complete, consistent, ranked for importance and/or
stability, verifiable, modifiable and traceable.
www.neerajbooks.com
1
In this chapter, we will discuss the following
characteristics:
Completeness
Unambiguity
Inconsistency
COMPLETENESS
The SRS is complete if, and only if, it has the
following properties:
1. Description of all significant requirements
relating to functionality, performance, design,
attributes or external interfaces.
2. Definition of the response of the software
system for all the situations.
3. All the diagrams, tables and figures should be
fully labelled and referenced.
4. All the abbreviations should be defined
properly.
This is most difficult to achieve as it is difficult to
specify all the system requirements at the beginning.
Missing requirements are difficult to trap since they are
not visible.
UNAMBIGUITY
The SRS is said to be unambiguous if every stated
requirement has only one interpretation independent of
the person or the time when the interpretation is done.
The SRS needs to be unambiguous for all the users who
will create and use the document that is to the authors,
the users, the reviewers as well as developers and testers.
A sentence in the SRS is said to be ambiguous if given
to few people and asked for the interpretation and there
is more than one interpretation. In cases, if a term that is
 www.neerajbooks.com

to be used for particular context has multiple meanings,
the term should be included in the glossary where all
the meanings should be specified.
Some of the issues related to ambiguity are as
follows:
1. Requirements are often written in natural
language. Natural language being imprecise
and ambiguous in nature, so any SRS written
in natural language should be reviewed by an
independent party to identify the ambiguity in
SRS and correct the language.
2. Ambiguity can be avoided by writing the SRS
in a particular requirement specification
language, which has a processor that
automatically detects any lexical, syntactic and
semantic errors. However, there is a
disadvantage associated with it. It takes a lot
of time to learn such language and sometimes
(a) One requirement states that two numbers
should be added while the other says that they
should be multiplied.
(b) One requirement says that “A” should always
follow “B” whereas the other says that “A and
B” occur simultaneously.
(c) In time sheet one requirement says that the
work must be done by the end of the week
(Sunday) whereas in other, it states that the
work should be done by the last working day
of the week (Friday).
3. The requirements describing same real world
entity may have different terminologies. For example,
a program’s request for a user input may be called a
“prompt” in one requirement or “cue” in another. In
one requirement start of week may be used as Monday
whereas in another it may be used as Sunday.
The use of standard terminology and definitions

Neeraj
it is not even understood by the users or
customers.
3. The requirements could also be depicted using
diagrams, tables or flow charts. These
techniques improve the precision of the
promotes consistency.
IEEE SRS
The Institute of Electrical and Electronics Engineers
(IEEE) has published the guidelines and standards to
organize an SRS document. The SRS should be selected

Publications
requirements, but it is a bit difficult to convert
or defined at the beginning of all the activities. Different
the requirements.
projects require differently organized requirements thus,
INCONSISTENCY
the SRS should be selected accordingly.
The SRS should not be inconsistence. The SRS is
The general organization of an SRS is as follows:

www.neerajbooks.com
consistence if, and only if, no requirements described
in it conflicts. Any conflict between the described 1. Introduction
requirements should be identified and resolved. There 1.1 Purpose
are three types of conflicts that are likely to be seen 1.2 Scope
between the requirements. They are as follows: 1.3 Definitions, Acronyms and Abbreviations
1. Characteristics of real world objects interacting 1.4 References
with the system may conflict. For example: 1.5 Overview
(a) Format of an output report can be described 2. The Overall Description
in tabular form in one requirement whereas in 2.1 Product Perspective
other it can be stated in textual form. 2.1.1 System Interfaces
(b) One requirement may state that all lights are 2.1.2 Interfaces
red whereas other states that the colour of all 2.1.3 Hardware Interfaces
lights is blue. 2.1.4 Software Interfaces
(c) In a time sheet system one requirement states 2.1.5 Communication Interfaces
that a worker cannot work more than 16 hours 2.1.6 Memory Constraints
a day whereas in other requirement it may 2.1.7 Operations
assume that a worker can work for 24 hours a 2.1.8 Site Adaption Requirements
day. 2.2 Product Functions
2. Two specific items can have logical or 2.3 User Characteristics
temporal conflict between them. For example: 2.4 Constraints

www.neerajbooks.com
 www.neerajbooks.com
2.5 Assumptions and Dependencies
2.6 Apportioning of Requirements
3. Specific Requirements
3.1 External Interfaces
3.2 Functions
3.3 Performance Requirements
3.4 Logical Database Requirements
3.5 Design Constraints
3.5.1 Standards Compliance
3.6 Software System Attributes
3.6.1 Reliability
3.6.2 Availability
3.6.3 Security
3.6.4 Maintainability
3.6.5 Portability
3.7 Organizing the Specific Requirements
3.7.1 System Mode
Neeraj
3.7.2 User Class
3.7.3 Objects
3.7.4 Feature
3.7.5 Stimulus
3.7.6 Response
Publications
3.7.7 Functional Hierarchy
4. Change Management Process
5. Document Approvals
6. Supporting Information
www.neerajbooks.com
Now we will study the explanation of the above
SRS format.
Introduction: The sub-sections of this topic will
provide an overview of the entire SRS.
Purpose: In this sub-section identify the purpose
of the SRS and specify its intended audience.
Scope: In this sub-section we will:
(i) Identify the names of the software product to
be produced.
(ii) Tell about what and what not a software
product will do.
(iii) Application of the software being specified is
being described along with the relevant
benefits, objectives and goals.
(iv) Be consistent with similar statements in higher-
level specifications, if they exist.
Definitions, Acronyms and Abbreviations: This
section provides the definitions of all the terms,
acronyms and abbreviations that are required to
understand the SRS. This information may be provided
by referring the document or an Appendix.
www.neerajbooks.com
References: This sub-section will:
(i) Provide a complete list of all documents that
are referenced in the SRS.
(ii) Identify the document by title, report number,
date and publishing organization.
(iii) Sources from which the references are obtained
should be specified.
Overview: This sub-section will include:
(i) Description of the rest of the SRS.
(ii) Explanation of how SRS is organized.
The Overall Description: The factors that affect
the product and its requirements are being described
here. This section does not state specific requirements
instead it makes easier to understand the requirements
that are stated later as it provides background for those
requirements.
Product Perspective: Product is being put into
perspective with other related products. Independent and
self-contained product should be stated here. If the
product defined in the SRS is a component of a larger
system, then this sub-section relates the requirements
of the larger system to functionality of the software
interfaces between the system and the software is being
identified.
System Interfaces: All system interfaces are listed
and the functionality of the software to accomplish the
system requirement and the interface description to
match the system is being identified.
Interfaces: In this sub-section, we will specify:
(i) The logical characteristics of each interface
between the software product and its users.
(ii) All the aspects of optimizing the interface with
the person who must use the system.
Hardware Interfaces: The logical characteristics
of each interface between the product and the hardware
component of the system are specified. Configuration
characteristic is also included. It also tells about what
and how devices are to be supported and protocols.
Software Interfaces: The required software
products and interfaces with other application system
are specified. The required software product includes
the following:
(i) Name
(ii) Mnemonic
(iii) Specification number
(iv) Version number
(v) Source
Each interface provides:
 www.neerajbooks.com
(i) The software relating to the software product
is being discussed.
(ii) The interface in terms of message content and
format is defined.
Communications Interfaces: This sub-section
specifies the various interfaces to communications.
Memory Constraints: The applicable character-
istics and limits on primary and secondary memory are
specified.
Operations: In this sub-section, we will specify
the normal and special operations that are required by
the user. Some of them are:
(i) Modes of operation in user organization.
(ii) Periods of interactive and unattended
operations.
(iii) Data processing support functions.
(iv) Backup and recovery operations.
Site Adaptation Requirements: In this sub-section:
Neeraj
(i) The requirements specific to a given site,
mission, or operational mode for any data or
initialization sequences is defined.
(ii) The site that should be modified to adapt the
software for particular installation is specified.
Publications
Product Functions: In this section, we will provide
the major functionality that the software will perform.
Sometimes the function summary is taken from the
section of higher level specification that allocates the
www.neerajbooks.com
functions to a software product.
For clarity:
(i) The functions should be organized in such a
way that they are understandable and readable
by the customer or anyone who is reading the
information for the first time.
(ii) Different functions and their relationships
could be shown using textual or graphical
methods.
User Characteristics: It describes the
characteristics of the intended users of the product that
is the educational level, experience and technical
expertise. It also tells about why a specific requirement
is discussed later in the SRS.
Constraints: Provide a general description of those
items that could limit the options for developers. They
can include regulatory policies, hardware limitations (for
example, signal timing requirements), interface to other
applications, parallel operation, audit functions, control
functions, higher-order language requirements, signal
www.neerajbooks.com
handshake protocols ( for example, XON-XOFF, ACK-
NACK), reliability requirements, criticality of the
application and safety and security considerations.
Assumptions and Dependencies: All the
requirements that are affected in the SRS are listed.
These factors are the changes to the design constraints
that can affect the requirements in the SRS. For example,
an assumption might be that a specific operating system
would be available on the hardware designated for the
software product but instead it is not present, so the
SRS has to change accordingly.
Apportioning of Requirements: The requirements
that may be delayed until the future versions of the
system are identified.
Specific Requirements: This section contains all
the detailed information of the software requirements
required by the designers to design the system, for tester
to test the system for those software requirements.
Throughout the section the requirements stated are
perceived by the user, operators or both. These should
include at least a small description of every input, output
and functions performed by the system.
The following principles apply:
(i) Requirements should be stated in accordance
with the characteristics of a good SRS, that is
it should be, correct, unambiguous, complete,
consistent, ranked for importance and/or
stability, verifiable, modifiable and traceable.
(ii) Requirements should be cross-referenced to
earlier requirements that relate.
(iii) For maximum readability of the SRS the
requirements should be organized carefully.
External Interfaces: This sub-section contains all
the information of all inputs and outputs of the system.
It contains both content and format as follows:
Name of item
Description of purpose
Source of input or destination of output
Valid range, accuracy and/or tolerance
Units of measure
Timing
Relationships to other inputs/outputs
Screen formats/organization
Window formats/organization
Data formats
Command formats
End messages.
 www.neerajbooks.com
Functions: In this sub-section, we will describe
the fundamental actions that need to be taken for
processing the inputs and generating the outputs and
are listed as “shall” statements like “the system shall….”
These include validity checks on inputs, exact
sequence of operations, response to abnormal situation
(including overflow, communication facilities, error
handling and recovery), effect of parameters,
relationship of outputs to inputs (including input/output
sequence, formulas to input to output conversion).
It is appropriate to partition it into sub-functions.
Performance Requirements: This sub-section
will tell about the static and dynamic numerical
requirements placed on the software or on human
interaction. Static numerical requirements may include:
(i) The number of terminals that are supported.
(ii) The number of simultaneous user.
(iii) Amount and type of information to be handled.
Neeraj
Dynamic numerical requirements may include the
number of transactions and tasks and the amount of
data to be processed within certain time periods under
all conditions.
Logical Database Requirements: This sub-
Publications
section will describe the logical requirements for the
information that is to be placed in the database. This
may include, types of information used by various
functions, frequency of use, accessing capabilities, data
entities and their relationships, integrity constraints and
www.neerajbooks.com
data retention requirements.
Design Constraints: All the imposed design
constraints are specified in this sub-section.
Standard Compliance: The requirements that are
derived from existing standards or regulations are
specified which may include, report format, data
naming, accounting procedures, audit tracing.
For example, the requirements for software to
processing activities could be specified.
For example, in an audit trace requirement it is
stated that all the changes in the payroll should be
recorded in the database with before and after values.
Software System Attributes: There are number
of quality attributes that can serve as a requirement for
the software whose achievements could be verified.
Some of the quality attributes with their definitions are
as follows:
Correctness- extent to which program fulfills
user’s objectives.
www.neerajbooks.com
Efficiency- amount of code and resources
required to perform function.
Testability- effort needed to test the product.
Usability- effort required to learn, operate the
system.
Reliability: Specify the extent to which program
performs with required precision.
Availability: Specify the factors that tell that the
specific level is available for the system such as
checkpoints, recovery and restart.
Security: It specifies the factors that will protect
the software from destruction or abnormal access.
Maintainability: This will specify the effort
required to locate and fix an error during operation.
Portability: This will specify the effort needed to
transfer the hardware or software from one environment
to another. This may include percentage of components
with host-independent code, use of a particular operating
system, use of a particular compiler or language subset,
etc.
Organizing the Specific Requirements: The
requirements should be organized in a manner that is
optimal for understanding the detailed requirements.
There is no optimal organization for all systems.
Different systems have different organizations some of
which are described below:
System Mode: System behaves differently
depending on the mode of operation that is dependent
or independent.
User Class: Different functions are provided to
different classes of users.
Objects: Objects are real world entities that exist
in the system. Objects are associated with set of attributes
and functions. Number of objects that share the same
set of attributes and function can be grouped together
and called as class.
Feature: Feature is generally described as a
sequence of stimulus-response pair and is externally
desired service by the system.
Stimulus: Specify functions in terms of stimuli.
Response: Systems are organized by describing
their function in terms of response.
Functional Hierarchy: The overall functionality
of the system can be organized in a hierarchy of functions
by their common inputs or outputs.
Change Management Process: This section will
identify the change management process that is used to
 www.neerajbooks.com
identify, log, evaluate and update the SRS to reflect
changes in project scope and requirements as changes
to requirements are unavoidable.
Document Approval: The document approvers
of the SRS are identified whose name, signature and
date should be used.
Supporting Information: This section makes the
SRS easier for use. It includes:
Table of contents
Index
Appendices.
Appendices not always forms the part of actual
requirements specification and are not even necessary.
Appendices include:
(i) Sample I/O formats, descriptions of cost
analysis studies, result of user surveys.
(ii) Supporting or background information that
helps the readers of the SRS.
Neeraj
(iii) Description of the problems that are solved by
the software.
(iv) Special packaging instructions for the code and
media to meet certain requirements such as
security, export, etc.
Publications
Tables can provide different ways to structure the
SRS on the specific requirements.
Problems in SRS: There are various features that
make requirements analysis difficult. These are
www.neerajbooks.com
discussed below:
1. Complete requirements are difficult to uncover.
In recent trends in engineering, the processes are
automated and it is practically impossible to understand
the complete set of requirements during the
commencement of the project itself.
2. Requirements are continuously generated.
Defining the complete set of requirements in the starting
is difficult. When the system is put under run, the new
requirements are obtained and need to be added to the
system. But, the project schedules are seldom adjusted
to reflect these modifications. Otherwise, the
development of software will never commence.
3. The general trends among software developer
shows that they have over dependence on CASE tools.
Though these tools are good helping agents, over
reliance on these requirements engineering tools may
create false requirements. Thus, the requirements
corresponding to real system should be understood and
only a realistic dependence on tools should be made.
www.neerajbooks.com
4. The software projects are generally given tight
project schedules. Pressure is created from customer
side to hurriedly complete the project. This normally
cuts down the time requirements analysis phase, which
frequently leads to disaster(s).
5. Requirements engineering is communication
intensive. User and developers have different
vocabularies, professional backgrounds and psychology.
User writes specifications in natural language and
developer usually demands precise and well-specified
requirement.
6. In present time, the software development is
market driven having high commercial aspect. The
software developed should be a general purpose one to
satisfy anonymous customer and then it is customized
to suit a particular application.
7. The resources may not be enough to build
software that fulfils all the customer’s requirements. It
is left to the customer to prioritize the requirements and
develop software fulfilling important requirements.
Q. 1. What do you mean by SRS?
Ans. SRS stands for system requirement
specification. SRS is the documentation of the
requirements which is used by the user or customer for
reviewing or understanding the system.
Q. 2. List the other five characteristics of the
SRS? Briefly explain each of them?
Ans. Five characteristics of a good SRS are as
follows:
1. Correct: SRS is said to be correct if and only
if it all the requirements stated in it are required
for the software.
2. Ranked for importance and/or stability: It
is ranked for importance and/or stability if each
requirement in it has an identifier to indicate
either the importance or stability of that
particular requirement. This can also be done
by classifying the requirements under essential,
conditional and optional categories.
3. Verifiable: SRS is verifiable if all the
requirements stated within it are verifiable. A
requirement is verifiable if any process or
machine can check if the requirement is desired
for the project that is it meets the requirement
of the software.
 www.neerajbooks.com

4. Modifiable: SRS is modifiable if and only if to be imposed on the software before imple-
any change in the requirement is easily, mentation is seen?
completely and consistently reflected in the Q. 7. Give the organization of the SRS?
SRS without affecting its structure. Ans. Organization of the SRS by IEEE format is
5. Traceable: SRS is traceable if and only if the as follows:
origin of the requirement is clear and it 1. Introduction
facilitates the referencing of each requirement 1.1 Purpose
in future development. One can do backward 1.2 Scope
as well as forward traceability. 1.3 Definitions, Acronyms and Abbre-
Q. 3. When is the SRS called complete? viations
Ans. The SRS is said to be complete if it includes 1.4 References
all the requirements related to functionality, 1.5 Overview
performance, design constraints, etc. SRS is complete 2. The Overall Description
when all the terms, diagrams, tables and responses of 2.1 Product Perspective
the software in all classes of situations are defined. 2.1.1 System Interfaces
Q. 4. Why consistency is a desired characteristic 2.1.2 Interfaces
of SRS? 2.1.3 Hardware Interfaces
Ans. Consistency is a desired characteristic of SRS 2.1.4 Software Interfaces

Neeraj
because if there is any conflict between requirements 2.1.5 Communication Interfaces
of the SRS then the SRS will not produce the correct 2.1.6 Memory Constraints
product as it will lead to a conflict as to which 2.1.7 Operations
requirement is correct and which is not. SRS can be 2.1.8 Site Adaption Requirements
consistent if it resolves all the conflicts between the 2.2 Product Functions
2.3 User Characteristics

Publications
requirements of the SRS which may lead to better
understanding and ease to read the SRS. 2.4 Constraints
Q. 5. What do you mean by unambiguity in SRS? 2.5 Assumptions and Dependencies
2.6 Apportioning of Requirements
Ans. SRS is said to be unambiguous if the
3. Specific Requirements
requirements stated in the SRS have only one meaning.

www.neerajbooks.com
3.1 External interfaces
Each sentence in the SRS should have unique
3.2 Functions
interpretation. If one requirement has more than one
3.3 Performance Requirements
meaning in different context then it should be specified
3.4 Logical Database Requirements
in the glossary with each of its meaning.
3.5 Design Constraints
Q. 6. What are the issues that SRS writer will
3.5.1 Standards Compliance
address?
3.6 Software System Attributes
Ans. Issues that a SRS writer will address are as
3.6.1 Reliability
follows:
3.6.2 Availability
1. Functionality: What the software is supposed
3.6.3 Security
to do?
3.6.4 Maintainability
2. External Interfaces: How the software will 3.6.5 Portability
interact with people, hardware or other 3.7 Organizing the Specific Requirements
software? 3.7.1 System Mode
3. Performance: At what speed, response time, 3.7.2 User Class
availability, etc. various functions will work. 3.7.3 Objects
4. Attributes: What are the considerations for 3.7.4 Feature
portability, security, reliability, etc.? 3.7.5 Stimulus
5. Design constraints imposed on an imple- 3.7.6 Response
mentation: Are there any constraints that have 3.7.7 Functional Hierarchy.

www.neerajbooks.com
 www.neerajbooks.com
4. Change Management Process.
5. Document Approvals.
6. Supporting information.
Q. 8. Mention the problems in SRS.
Ans. The problems in SRS are as follows:
1. All the requirements are difficult to be known
at the start of the project. As the project
enhances new requirements are being
discovered which are to be added in the
process. Sometimes these changes are not
incorporated in the process which is not
acceptable by the customer.
2. It is difficult to uncover all the requirements
during the enhancement of the project. Now-
a-days, processes are being automated so it is
difficult to understand the requirements in the
entire course of the project.
Neeraj
Publications
www.neerajbooks.com
www.neerajbooks.com
3. Too much dependence on the CASE tools
sometimes does not cover the requirements
corresponding to real system which should be
understood properly and only a realistic
dependence on tools should be made.
4. Due to tight project schedules the time
allocated to requirement analysis phase is less
which leads to disasters as the requirements
for the project are not understood and
determined properly.
5. There is a language barrier between the user
and the developer which results in
requirements not being understood properly.
6. Resources are not enough to build software that
fulfils all the customer’s requirements. So it is
left for the customer to prioritize the
requirements and only important requirements
are being fulfilled in software development.
 www.neerajbooks.com
Function Oriented Modelling
Function oriented modelling is practiced informally
since programming began. Many systems have been
developed using this approach and is directly supported
by many programming languages. This approach relies
on decomposing the system into a set of interacting
Neeraj
functions with a centralized system state which is shared
by these functions. This is shown in the following figure:
Publications
www.neerajbooks.com
A functional approach to design is successful when
the amount of system state information is minimized
i.e. where the system is concerned with processing
independent actions whose outcomes are not affected
by previous actions and information sharing is explicit.
In this chapter we will discuss the following:
1. Data Flow Diagram: This shows how data is
transferred between different functions of the
system.
2. Entity Relationship Diagram: This is the
logical representation of data of an
organization.
www.neerajbooks.com
2
3. Structure Chart: This chart shows the
breakdown of the system to its lowest
manageable levels.
4. SRS: System Requirement Specification as
discussed in previous chapter tells us what the
system is intended to do.
5. Data Dictionaries: It contains the data about
the data that is metadata.
DATA FLOW DIAGRAM (DFD)
As information moves through software, it is
modified by a series of transformations. A data flow
diagram is a graphical representation that depicts the
information flow and transforms that are applied as data
move from input to output. A data flow diagram provides
a visual representation of the data flow. Users can see
where and when the data and information can be
accessed at various stages of its life cycle. It is useful to
include clickable information on responsibilities of the
centers, schedules, data formats, data volumes, etc.
Access to the data at intermediate points in the data flow
and information on data and product delivery can also
be provided through these diagrams. It is used widely
for many years prior to invent of computers.
It provides a clear picture of a business function
which starts with the first step of creating an overview
of the system and continues by analyzing each of the
functional aspect of the system. This further can be
elaborated to the level the details are required. DFD is
also known as a data flow chart or a bubble chart. The
basic form of data flow diagram for cash withdrawal
from a bank is shown below:
 www.neerajbooks.com

Neeraj
Source: www.schools.ash.org.au
DFD have the following important observations:
1. In name in DFD should be unique which makes
it easier to be referenced.

Publications
or
2. It is not a flow chart as it does not tell the order
of events instead it tells about the flow of data
that is why it is also known as data flow chart.
3. No logical decisions are shown in a DFD. 3. Data Store: It is a repository of data, also referred
to as files sometimes, which can be used at any later

www.neerajbooks.com
4. Describe the details of the requirements at each
level according to the demand. stage or by the other processes in a different order. It is
Advantages of DFD are as follows: represented as a set of parallel lines.
1. Since it is a graphical representation so it is
easier to understand the flow of data.
2. It has properly described system boundaries. Data Store
3. At each level of abstraction data can be
represented precisely.
Notations of DFD 4. External Entity (Source or Sink): External
The notations that are used for creating a DFD are entities are the objects outside the system with which
as follows: the system communicates. Source acts as the source of
1. Process: It is represented as a circle or bubble input and sink act as the destination of the output in the
that transforms the input data into output data. system. They are represented as rectangle.

2. Data Flow: It is used to connect various Levels of DFD: The DFD is used to represent a
processes to each other, to source or to sink with the system at any level of abstraction. A DFD can be
arrowhead indicating the flow of data in the system. It partitioned into a number of levels to which the
is shown as follows: information or function detail is required.

www.neerajbooks.com
 www.neerajbooks.com
A level-0 DFD, also called the context diagram,
represents the functionality of the entire system in a
single bubble with incoming and outgoing arrows
indicating the input and output data, respectively. It also
shows the interface between the system and external
entities. Thus context diagram aims at system boundary
and clears the scope of analysis precisely.
For example, a context level diagram is shown
below:
Neeraj
Source: www.smartdraw.com
A context diagram is expanded into a number of
inter-related processes. Each process may be further
Publications
expanded into a set of inter-connected sub processes.
This procedure of expanding a DFD is known as
levelling. The higher the level more details of each
function is described. Level-1 DFD tells about all the
major functions of the system. Level-2 or higher gives
www.neerajbooks.com
the details about each functions in specific.
Types of DFD: There are two types of DFD -
Physical and Logical DFD.
(a) Physical DFD: The data flow diagrams which
represent the model of the current system
(manual or computerised), are known as
physical DFD. These diagrams are drawn,
when the analyst studies the current working
system in detail.
(b) Logical DFD: The data flow diagrams which
represent the model of the proposed system,
are known as logical DFD. These diagrams are
drawn from the physical DFD.
Each of these DFD can be further categorised into
different levels like zero level (context diagram), first
level, second level and third level. Each higher level
DFD is drawn by adding more details to each process
of lower level, by a technique called ‘Exploding DFD’.
Steps to Draw DFD: A DFD can be drawn using
the following steps:
1. Identify external entities and data flows of the
current system and draw physical context
diagram.
www.neerajbooks.com
2. Identify data stores and processes of the system
and draw first level physical DFD.
3. Explore the processes of first level and draw
second level DFD.
4. Explore the processes of second level and draw
third level DFD.
5. Derive the logical view of each physical DFD
by the following ways:
(a) Remove documents and show actual data
in data flow.
(b) Remove registers and use files as data
stores.
(c) Remove unnecessary processes.
(d) Remove data flow between external
entities (if any) and show data flow
through processes.
ENTITY RELATIONSHIP DIAGRAM ERD
Entity Relationship diagram also referred as E-R
Diagram is another tool of requirement analysis. An E-
R Diagram is a logical representation of data of an
organization which uses three main i.e. entities,
relationships and attributes. It uses different symbols to
represent the above type of information. Boxes are used
to represent an entity. Diamonds are used to represent
relationship and ellipse to depict the attributes.
Entities: An entity is a fundamental thing of the
organization about which data is maintained. It has an
independent existence and can be uniquely identified
which makes each entity separate from each other. When
we say entity we normally say for an aspect that exist in
real world and is distinguished from the other real world
aspects. An entity can be anything like physical object,
concept or an event.
A set of similar types of entity is called the entity
sets which have certain attributes that apply to it.
It is represented as a rectangle with capital letters
used to name the entity type. The name is placed inside
the rectangle representing the entity.
ENTITY SET NAME
For example, a university offers two kinds of
programme that is regular and correspondence and
enrolls both national and international students.
Here STUDENT and PROGRAMME are the entity
set and national and international are the entities of
STUDENT and regular and correspondence are the
entities of PROGRAMME.
This is shown below:
STUDENT PROGRAMME
 www.neerajbooks.com

Attributes: Each entity set has a set of attributes associated with it. An attribute is a property or characteristic
that defines the entity that is of interest.
Notation for attribute is:

Attribute name

Attribute
Attributes in E-R Diagram are represented as an ellipse with the name of the attribute written in it and are
connected to the entity set with a line joining the attribute and the entity set.
For example, for a STUDENT entity set we can have Student_ID, Name, Address, Age, Phone_num as some
of the characteristics or attributes that can be associated with the entity set.
The following diagram shows the representation for a STUDENT entity set using E-R Diagram notations:

Neeraj
Publications
Candidate Keys and Identifier: Every entity set
has an attribute or a set of attributes that distinguish
one instance from the other of the same type. Candidate

www.neerajbooks.com
key is an attribute that uniquely identifies each instance
of an entity set. Candidate key can be a single or a group
of attributes that uniquely identifies every instance of
an entity set.
For example, Student_ID is the candidate key for
the STUDENT entity set.
One entity set can have more than one candidate
key. The designer has to choose the most appropriate
candidate key for that entity set as the identifier. An
identifier is the candidate key that is selected to uniquely
identify the instances of the entity set. It is depicted in
Relationships: Relationship is the association
E-R Diagram as follows:
between two entity sets that is it tells how the data is
being shared between any two entities. It is sometimes
also referred to as binary relationship as it is the
association between two entity sets. Sometimes more
than two entities can also be associated with each other.
Relationship is represented as a diamond in the E-R
For example, the candidate key and the identifier,
Student_ID for the STUDENT entity set, will be Diagram with the relation name written in between the
represented as follows: diamond. Notation for the relationship is:

www.neerajbooks.com
 www.neerajbooks.com

For example, an EMPLOYEE works for a DEPARTMENT can be represented as follows:

Let us consider another example in which, each student of a university is registered for a programme that the
university is offering. This is shown as follows:

Neeraj
Publications
The arrows in the above diagram show “many to one relationship” that is many students can be registered for

www.neerajbooks.com
a programme and there can be a number of programmes that are offered by a university.
We also have “one to one relationship” and “many to many relationship”. Examples of these are:

This is one to one relationship.

This is many to many relationship.

Degree of Relationship: It means that how many entity sets are participating in the relationship that is the
number will tell the degree of the relation. We can have unary, binary and ternary relationship.
Unary Relationship: This is also known as recursive relationship. In this relationship only one entity set is
involved. There can be many instances of the same entity type that are being involved in the relationship.
For example: An employee is being supervised by another employee of a company. This can be shown as
follows:

www.neerajbooks.com
 www.neerajbooks.com

In the above diagram, it shows that an employee is being supervised by another employee who is the supervisor.
This means that here only one entity set is participating but with different instances of it that are worker and
supervisor.
Binary Relationship: It is a relationship between two entity sets. Mostly binary relationships exist in the E-R
Diagrams. For example, a student can enroll for a programme of a university. This is shown as follows:

Neeraj
Ternary Relationship: In this relationship three entity sets are participating.
For example, the relationship “may have” could be associated with three entities STUDENT, SUBJECT and
TEACHER. This is many to many relationship. This is shown as follows:

Publications
www.neerajbooks.com
There is also n-ary relationship. It is when with a single relationship n- entities participate.
Cardinalities: Cardinality is the number of instances of an entity set that participates in a relationship with the
other entity set.
For example, a STUDENT can be registered for more than one SUBJECT.

Hence, in this example only one instance of STUDENT entity set is there whereas many instances of SUBJECT
entity set are participating. Thus, this is one-to many relationship.
The minimal cardinality is the minimum number of instances that participate in a relationship. If the minimum
number of instances that are associated with the other entity set is zero then we say it is an optional participant but
if the cardinality is 1 then it is a mandatory participant. The maximum cardinality is the maximum number of
instances that are associated with the other entity set and it is referred as many.
The cardinality of relationship is shown below:

www.neerajbooks.com
 www.neerajbooks.com
Benefits of ERD: Data modelling and the entity-
Neeraj
relationship diagram provides the analyst with a concise
notation for examining data within the context of a data
processing application. In most cases, the data modelling
approach is used to create one piece of the analysis
model, but it can also be used for database design and
to support any other requirement analysis method.
Publications
STRUCTURE CHART
It is the most commonly used method for system
design. A Structure Chart (SC) in software engineering
and organizational theory is a chart which shows the
www.neerajbooks.com
breakdown of a system to its lowest manageable levels.
They are used in structured programming to arrange
program modules into a tree. Each module is represented
by a box, which contains the module’s name. The tree
structure visualizes the relationships between modules.
A structure chart is a design tool that pictorially shows
the relation between processing modules in the software.
It describes the hierarchy of component modules and
www.neerajbooks.com
the data are transmitted between them. It includes
analysis of input-to-output transformations and also the
analysis of transaction.
It shows which module within a system interacts
and graphically depicts the data that are communicated
between various modules.
Structure charts are developed prior to the writing
of program code. They identify the data passes existing
between individual modules that interact with one
another. They are not intended to express procedural
logic. This task is left to flowcharts and pseudo code.
They don’t describe the actual physical interface
between processing functions.
The modules are connected with each other with
the help of lines. The lines show the connection between
the activity and its sub-activity. The top level module
calls the modules at lower level. The components are
generally read from top-to-bottom and left-to-right and
modules are numbered in hierarchal numbering scheme.
 www.neerajbooks.com

A structure chart depicts the size and complexity of the system, number of readily identifiable functions and
modules within each function and whether each identifiable function is a manageable entity or should be broken
down into smaller components.
Each module acts as a black box where only the functionality is taken into account and not the internal design.
Here, the inputs are given to the black box and outputs are generated by the black box. When a module calls another
it views the module as a black box, passing parameters needed for the called module’s functionality and receiving
answers.
Notations
Control data passed between different modules is represented with a labelled arrow and a filled in circle
whereas the data is depicted with a labelled arrow and an open circle.
When a module is used by many other modules then it is put into the library of modules.
Diamond symbol is used for the conditional call of the module that is the outcome of the module will
depend on the condition that is attached to the diamond.
Repetition of a module is represented by a loop around the control flow arrows and is called the repetition
symbol.
The pictorial notations that are used in structure chart are as follows:

Neeraj
Publications
www.neerajbooks.com

Construction: According to Wolber, “A structure chart can be developed starting with the creating of a structure,
which places the root of an upside-down tree which forms the structure chart. The next step is to conceptualize the
main sub-tasks that must be performed by the program to solve the problem. Next, the programmer focuses on each
sub-task individually, and conceptualizes how each can be broken down into even smaller tasks. Eventually, the
program is broken down to a point where the leaves of the tree represent simple methods that can be coded with just
a few program statements”.
An example of structure chart is shown below:

www.neerajbooks.com
 www.neerajbooks.com
Neeraj
Publications
(SRS) www.neerajbooks.com
SOFTWARE REQUIREMENTS SPECIFICATION
Software Requirements Specification (SRS) is the
starting point of the software development activity. Little
importance was attached to this phase in the early days
of software development. The emphasis was first on
coding and then shifted to design. As systems grew more
complex it became evident that the goals of the entire
system cannot be easily comprehended. Hence, the need
for the requirement analysis phases arose. Now, for large
software systems, requirement analysis is perhaps the
most difficult activity and also the most error prone.
Many software engineers believe that the software
engineering discipline is weakest in this critical area.
The SRS is a means of translating the ideas in the
minds of the clients, into a formal document (the output
of the requirements phase). Thus, the output of the phase
is a set of formally specified requirements, which
hopefully are complete and consistent, while the input
has none of these properties. Clearly, the process of
specifying requirements cannot be totally formal. Any
www.neerajbooks.com
formal translation process producing a formal output
must have a precise and unambiguous input. A procedure
for identifying requirements can therefore be at best set
of guidelines.
The requirement specification phase consists of two
basic activities: problem or requirement analysis and
requirement specification.
Role of SRS: A good SRS provides many benefits.
Some of goals it accomplishes are:
1. Establishing the basis for agreement between
client and supplier on what the software product will
do.
2. Reducing the development cost. The preparation
of the SRS forces rigorous specification of the
requirements before the design begins. Careful
development of an SRS can reveal omissions,
inconsistencies and mis-understandings early in the
development cycle, which can considerably reduce cost.
3. Providing a reference for validation of the final
product. The SRS assists the client in determining if the
software meets the requirements.
 www.neerajbooks.com
Outline of SRS: The SRS outline is given below:
1. Introduction
(i) Purpose
(ii) Scope
(iii) Definitions, acronyms and abbreviations
(iv) References
(v) Overview.
2. Overall description
(i) Product perspective
(ii) Product functions
(iii) User characteristics
(iv) Constraints
(v) Assumptions and dependencies.
3. Specific requirements
(i) External Interfaces
(ii) Functional requirements
(iii) Performance requirements
(iv) Logical database requirements
(v) Design constraints
Neeraj
(vi) Software system attributes
(vii) Organizing the specific requirements
(viii) Additional comments.
4. Supporting information
(i) Table of contents and index
Publications
(ii) Appendixes.
Characteristics of an SRS: To properly satisfy the
basic goals, an SRS should have certain properties and
should contain different types of requirements. A good
SRS is:
www.neerajbooks.com
1. Understandable: A SRS produces a document
upon which the client, the users and the developers can
agree. Since multiple parties need to understand and
approve the SRS, it is of utmost importance that the
SRS should be understandable.
2. Unambiguous: A SRS is unambiguous if and
only if every requirement stated has one and only one
interpretation. Requirements are often written in natural
language, which are inherently ambiguous. If the
requirements are specified in a natural language, the
SRS writer has to be especially careful to ensure that
there are no ambiguities. One way to avoid ambiguities
is to use some formal requirements specification
language.
3. Complete: A SRS is complete if everything the
software is supposed to do is in the SRS. A complete
SRS defines the responses of the software to all classes
of input data. For specifying all the requirements, the
requirements relating to functionality, performance,
design constraints, attributes and external interfaces
must be specified.
www.neerajbooks.com
4. Verifiable: A SRS is verifiable, if there exists
some cost-effective process that can check if the final
software meets that requirement. A SRS is verifiable if
and only if every stated requirement is verifiable. This
implies that the requirements should have as little
subjectivity as possible because subjective requirements
are difficult to verify.
5. Consistent: A SRS is consistent if there is no
requirement that conflicts with another. Terminology can
cause inconsistencies; for example, different
requirements may use different terms to refer to the same
object. There may be logical or temporal conflict
between requirements causing inconsistencies. This
occurs if the SRS contains two or more requirements
whose logical or temporal characteristics cannot be
satisfied together by any software system.
6. Modifiable: Writing an SRS is an iterative
process. Even when the requirements of a system are
specified, they are later modified as the needs of the
client change with time. Hence, an SRS should be easy
to modify. An SRS is modifiable if its structure and style
is such that any necessary change can be made easily,
while preserving the completeness and consistency.
7. Traceable: A SRS is traceable if the origin of
each of its requirements is clear and if it facilitates the
referencing of each requirement in future development.
Forward traceability means that each requirement should
be traceable to some design and code elements.
Backward traceability requires that it should be possible
to trace design and code elements to the requirements
they support. Traceability aids verification and
validation.
Components of a SRS: Completeness of
specifications is difficult to achieve and even more
difficult to verify. Having guidelines about what different
things an SRS should specify will help in completely
specifying the requirements. Here, we describe some
of the system properties that an SRS should specify.
The basic issues which an SRS must address are:
1. Functionality: Functional requirements specify
which outputs should be produced from the given inputs.
They describe the relationship between the input and
output of the system. For each functional requirement,
a detailed description of all the data inputs and their
source, the units of measure and the range of valid inputs
must be specified. An important part of the specification
is the system behaviour in abnormal situations, like
invalid input or error during computation. The functional
requirement must clearly state what the system should
do if such situations occur.
 www.neerajbooks.com
2. Performance: This part of SRS specifies the
performance constraints on the software system. All the
requirements relating to the performance characteristics
of the system must be clearly specified. There are two
types of performance requirements–static and dynamic.
(i) Static requirement: These do not impose
constraint on the execution characteristics of
the system. These include requirements like
the number of terminals to be supported and
number of simultaneous users to be supported,
number of files and their sizes that the system
has to process.
(ii) Dynamic requirement: These specify
constraints on the execution behaviour of the
system. These typically include response time
and throughput constraints on the system.
Response time is the expected time for the
completion of an operation under specified
circumstances. Throughput is the expected
Neeraj
number of operations that can be performed
in a unit time.
3. Design Constraints: There are number of factors
present in the client’s environment that may restrict the
choices of designer. Such factors include: standards that
Publications
must be followed, resource limits, operating
environment, reliability and security requirements and
policies that may have an impact on the design of the
system.
(i) Standards Compliance: This specifies the
www.neerajbooks.com
requirements for the standards that the system
must follow. The standards may include the
report format and accounting procedures.
There may be audit tracing requirements,
which require certain kinds of changes or
operations that must be recorded in an audit
file.
(ii) Hardware Limitations: The software may have
to operate on some existing or pre-determined
hardware, thus imposing restrictions on the
design. Hardware limitations can include the
type of machines to be used, operating system
available on the system, languages supported,
and limits on primary and secondary storage.
(iii) Reliability and Fault Tolerance: Fault
tolerance requirements can place a major
constraint on how the system is to be designed.
Fault tolerance requirements often make the
system more complex and expensive.
Requirements about system behaviour in the
face of certain kinds of faults are specified.
www.neerajbooks.com
Recovery requirements are often an integral
part here, detailing what the system should do
if some failure occurs in order to ensure certain
properties.
(iv) Security: Security requirements are
particularly significant in defense systems and
many database systems. Security requirements
place restrictions on the use of certain
commands, control access to data, provide
different kinds of access requirements for
different people require the use of passwords
and cryptography techniques and maintain a
log of activities in the system.
4. External Interface: All the possible interactions
of the software with people, hardware and other software
should be clearly specified. For the user interface, the
characteristics of each use interface of the software
product should be specified. User interface is
increasingly becoming more important and must be
given proper attention. A preliminary user manual should
be created with all user commands, screen formats, an
explanation of how the system will appear to the user,
and feedback and error messages. Like, other
specifications these requirements should be precise and
verifiable.
Problems in SRS: There are various features that
make requirements analysis difficult. These are
discussed below:
1. Complete requirements are difficult to uncover.
In recent trends in engineering, the processes are
automated and it is practically impossible to understand
the complete set of requirements during the
commencement of the project itself.
2. Requirements are continuously generated.
Defining the complete set of requirements in the starting
is difficult. When the system is put under run, the new
requirements are obtained and need to be added to the
system. But, the project schedules are seldom adjusted
to reflect these modifications. Otherwise, the
development of software will never commence.
3. The general trends among software developer
shows that they have over dependence on CASE tools.
Though, these tools are good helping agents, over
reliance on these requirements engineering tools may
create false requirements. Thus, the requirements
corresponding to real system should be understood and
only a realistic dependence on tools should be made.
4. The software projects are generally given tight
project schedules. Pressure is created from customer
side to hurriedly complete the project. This normally
 www.neerajbooks.com
cuts down the time requirements analysis phase, which
frequently leads to disaster(s).
5. Requirements engineering is communication
intensive. User and developers have different
vocabularies, professional backgrounds and psychology.
User writes specifications in natural language and
developer usually demands precise and well-specified
requirement.
6. In present time, the software development is
market driven having high commercial aspect. The
software developed should be a general purpose one to
satisfy anonymous customer, and then it is customized
to suit a particular application.
7. The resources may not be enough to build
software that fulfils all the customer’s requirements. It
is left to the customer to prioritize the requirements and
develop software fulfilling important requirements.
THE DATA DICTIONARY
The analysis model includes representations of data
Neeraj
objects, functions and control. In each representation,
data objects and/or control items play a role. An
organized approach for representing the characteristics
of each data object and control item is done by the data
dictionary.
Publications
The data dictionary is a quasi-formal grammar for
describing the contents of the objects defined during
the structured analysis.
It is an organized listing of all the data elements
that are pertinent to the system, with precise, rigorous
www.neerajbooks.com
definitions so that both the user and system analyst will
have a common understanding of inputs, outputs,
components of stores and (even) intermediate
calculations.
Thus data dictionary is a set of meta-data which
contains the definition and representation of data
elements. It gives a single point of reference of data
repository of an organization. Data dictionary lists all
data elements but does not say anything about
relationships between data elements.
The data dictionary is always implemented as part
of a CASE “structured analysis and design tool”.
Although, the format of dictionaries varies from tool to
tool, most have the following information:
(a) Name: the primary name of the data or control
item, the data store, or an external entity.
(b) Alias: other names used for the first entry.
(c) Where-used/how-used: a listing of the
processes that use the data or control the items
and how it is used (e.g., input to the process,
www.neerajbooks.com
output from the process, as a store, as an
external entity)
(d) Content description: a notation for
representing content
(e) Supplementary information: other
information about data types, present values
(if known), restrictions or limitations, etc.
Once a data object or control item name and its
aliases are entered into the data dictionary, consistency
in the name can be enforced. That is, if an analysis team
member decides to name a derived data item xyz, but
xyz is already in the dictionary, the CASE tool
supporting the dictionary posts warn to indicate
duplicate names. This improves the consistency of the
analysis model and helps to reduce errors.
“Where-used/how-used” information is recorded
automatically from the flow models. When a dictionary
entry is created, the CASE tool scans DFDs and CFDs
to determine which processes use the data or control
information and how it is used. It is one of the most
important benefit of the dictionary.
The mathematical operators used in data dictionary
are as follows:
Notation Meaning
X= a+b X consists of data elements a
and b
X= [a/b] X consist of either data element
a or b
X= a X consists of an optional data
element a
X= y{a} X consists of y or more
occurrences of data element a
X= {a}z X consists of z or fewer
occurrences of data element a
X= y{a}z X consists of some occurrences
of data element a which are
between y and z
The data dictionary can be used for:
1. Create an ordered listing of all data items.
2. Create an ordered listing of subset of data items.
3. Find a data item from a description.
4. Design the software and test cases.
Q. 1. What is Data Modelling? How does it differ
from DFD?
Ans. DATA Modelling–Data modelling answers
specific questions that are relevant to any data
 www.neerajbooks.com
processing application. What are the primary data
objects to be processed by the system? What is the
composition of each data object and what attributes
describe the object? Where do the object currently
reside? What are the relationships between objects?
What is the relationship between the objects and the
processes that transform them?
To answer these questions, data modelling
methods make use of the Entity Relationship Diagram
(ERD). The ERD allows a software engineer to identify
data objects and their relationships using a graphical
notation. In structured analysis, the ERD defines all data
that are input, stored, transformed and produced within
an application.
The entity-relationship diagram focuses solely on
data (and therefore satisfies the first operational analysis
principle), representing a “data network” that exists for
a given system. The ERD is especially useful for
Neeraj
Objects Attributes
Publications
B/w TV
www.neerajbooks.com
ID number Colour
Figure 3 : Data objects, attributes, and relationships
A data object can be an external entity (e.g.,
anything that produces or consumes information), a
thing (e.g., a report or a display), an occurrence (e.g., a
visit) or event (e.g., an accident), a role (e.g., student),
an organizational unit (e.g., computers department), a
place (e.g., a house), or a structure (e.g., a folder). For
example, a person or a TV (Figure 3) can be viewed as
a data object in the sense that either can be defined in
terms of a set of attributes. The data object description
incorporates the data object and all of its attributes.
Data objects are related to one-another. For
example, a person can own TV set where the
relationship own connotes a specific connection between
person and TV. The relationships are always defined
by the context of the problem that is set being
analyzed.
www.neerajbooks.com
applications in which data and the relationships that
govern data are complex. Unlike the data-flow diagram,
data modelling considers data independently of the
processing that transforms the data.
Q. 2. Write short notes on:
(1) Data Objects
(2) Attributes
(3) Relationships.
Ans. The data model consist of three interrelated
items of information : the data object, the attributes that
describe the data object, and the relationships that
connect data objects to one–another.
(i) Data Objects: A data object is a representation
of almost any composite information that must be
understood by software. Composite information means
something that has a number of different properties or
attributes. Therefore “height” (a single value) would not
be a valid data object, but area (in cooperating length
and width) could be defined as an object.
Relationships:
Name
Address
Age
Profession
Make Colour
Model TV
A data object encapsulates data only—there is no
reference within a data object to operations that act on
the data. Therefore, the data object can be represented
as a table as shown in following Figure 4. The headings
in the table reflect attributes of the object. The body of
the table represents specific instances of the data object.
For example, a BPL Flat TV is an instance of the data
object TV set.
(ii) Attributes: Attributes define the properties of
a data object and take one of three different
characteristics. They can be used to
(1) name an instance of the data object,
(2) describe the instance, or
(3) make reference to another instance in another
table. One or more of the attributes must be defined as
an identifier—that is, the identifier attribute becomes a
“key”, when an instance of the data object is to be found.
 www.neerajbooks.com

Naming
attributes
  Ties one data object to another in this case, owner

Descriptive Referential


Identifier  
attributes
 
attributes


Fig. 4. Tabular representation of data objects

In some cases, values for the identifier (s) are
unique, although, this is not a requirement. Referring to
the data object a reasonable identifier might be the
Model No.
The set of attributes that is appropriate for a given
data is determined through an understanding of the
problem context.
(iii) Relationships: Data objects are connected to
one-another in a variety of different ways. Consider two
data objects, book and library. These objects can be
represented using the simple notation illustrated in
following Figure. (a). A connection is established
between book and library because the two objects are
related. To determine the relationship

Neeraj
Publications (a) A basic connection between objects

www.neerajbooks.com

(b) Relationship between objects

the role of books and library is to be understand to be built. We can define a set of object-relationship pairs that
define the relevant relationships. For example,
— a library orders books
— a library displays books
— a library stocks books
— a library lends books
— a library purchases books
The relationships orders, displays, stocks, lands and purchases define the relevant connections between book
and library. above Figure (b) shows these object-relationship pairs graphically.

www.neerajbooks.com
 www.neerajbooks.com
Object-relationship pairs are bi-directional; that
is, they can be read in either direction. A library lends
books or books are lent by a library.
Q. 3. What is cardinality and modality? How
do they differ from each other?
Ans. Cardinality and Modality: The basic
elements of data modelling–data objects, attributes and
relationships–provide the basis for understanding for
information domain of a problem.
We have a set of objects and the object-
relationship pairs that bind them. But a simple pair that
states : object X relates to object Y does not provide
enough information for software engineering purposes.
We must understand how many occurrences of object
X are related to how many occurrences of object Y. A
data modelling concept called cardinality helps.
Cardinality: The data model must be capable of
representing the number occurrences of objects in a
given relationship. Tillmann defines the cardinality of
Neeraj
an object-relationship pair in the following way :
Cardinality is the specification of the number of
occurrences of one [object] that can be related to the
Publications
www.neerajbooks.com
Cardinality and Modality
Modality: The modality of a relationship is zero
if there is no explicit need for the relationship to occur
or the relationship is optional. The modality is 1 if an
occurrence of the relationship is mandatory. To illustrate,
consider, software that is used by a local telephone
company to process requests for field service. A
customer indicates that there is a problem. If the problem
is diagnosed as relatively simple, a single repair action
occurs. However, if the problem is complex, multiple
www.neerajbooks.com
number of occurrences of another [object]. Cardinality
is usually expressed as simply ‘one’ or ‘many.’ For
example, a husband can have only one wife (in most
cultures), while a parent can have many children. Taking
into consideration all combinations of ‘one’ and ‘many,’
two [objects] can be related as:
— One-to-one (1 : 1): An occurrence of [object]
‘A’ can related to one and only one occurrence
of [object] ‘B,’ and an occurrence of ‘B’ can
relate to only one occurrence of ‘A.’ For
example, one man-one vote.
— One-to-many (1 : N): One occurrence of
[object] ‘A’ can relate to one or many
occurrences of [object] ‘B’, but an occurrence
of ‘B’ can relate to one or more occurrences
of ‘A.’ For example, teacher-student.
Cardinality defines “the maximum number of
object relationships that can participate in a
relationship.” It does not, however, provide an indication
of whether or not a particular data object must participate
in the relationship. To get this information, the data
model adds modality to the object-relationship pair.
repair actions may be required. Previous figure
illustrates the relationship, cardinality and modality
between the data objects customer and repair action.
In the figure, a 1 to many cardinality relationship
is established. That is, a single customer can be provided
with zero or many repair actions. The symbols on the
relationship connection closest to the data object
rectangles indicate cardinality. The vertical bar indicates
1, and the three-pronged fork indicates many. Modality
is indicated by the symbols that are further away from
 www.neerajbooks.com

the data object rectangles. The second vertical bar on the left indicates that there must be a customer for a repair
action to occur. The circle on the right indicates that there may be no repair action required for the type problem
reported by the customer.
Q. 4. Briefly explain Entity-Relationship Diagram?
Ans. Entity-Relationship Diagram: The object-relationship pair is the cornerstone of the data model. These
pairs can be represented graphically using the Entity-Relationship Diagram (ERD). A set of primary components
are identified for the ERD: data objects, attributes, relationships and various type indicators. The primary purpose
of the ERD is to represent data objects and their relationships.
Data objects are represented by a labelled rectangle. Relationships are indicated with a labelled line connecting
objects. In some variations of the ERD, the connecting line contains a diamond that is labelled with the relationship
connection between data objects and relationship are established using a variety of special symbols that indicate
cardinality and modality.
The relationship between data objects TV set and manufacturer would be represented as shown following in
figure. One manufacturer makes one or many TV sets. Given the context implied by the ERD, the specification of

Neeraj ID# Model Body size Channels .............

Publications (a) A simple ERD and data object table

www.neerajbooks.com

(b) An expanded ERD

www.neerajbooks.com
 www.neerajbooks.com

the data object TV set would be the earlier specification. By examining the symbols at the end of the connection
line between objects, it can be seen that the modality of both occurrences is mandatory (the vertical lines).
Expanding the mode, we can represent simplified ERD (Figure (b)) of the distribution element of the TV
business. New data objects, transports, contracts, licenses and stocks–indicate how the data objects shown in the
figure associate with one-another.
In addition to the basic ERD notation the analyst can represent data object type hierarchies. In many instances,
a data object may actually represent a class or category of information. For example, the data object TV can be
categorized as Indian or imported. The ERD notation shown in Figure (c) represents this categorization in the form
of a hierarchy.
ERD notation also provides a mechanism that represents the associatively between objects as in figure
associated with the data object TV set.
Data modelling and the entity-relationship diagram provide the analyst with a concise notation for examining
data within the context of a data processing application. In most cases, the data modelling approach is used to
create one piece of the analysis model, but it can also be used for database design and to support any other requirements
analysis method.

Neeraj
Publications
www.neerajbooks.com

www.neerajbooks.com
 www.neerajbooks.com

Q. 5. Explain DFD along with its use in Software Development?

Ans. Data Flow Diagram: As data goes through software, it is modified by a series of transformations. A Data
Flow Diagram (DFD) is a graphical technique that depicts information flow and the transforms that are applied as
data move from input to output. The basic form of a data flow diagram is shown in Figure (A). The DFD is also
known as a data flow graph or a bubble chart.
The data flow diagram is used to represent a system or software at any level of abstraction. DFDs may be
partitioned into levels that represent increasing information flow and functional detail. Therefore, the DFDs provides
a mechanism for functional modelling as well as information flow modelling. In so doing, it satisfies the second
operational analysis principle (i.e., creating a functional model).
A level 0 DFD, also called a fundamental system model or a context model, represents the entire software
element as a single bubble with input and output data indicated by incoming and outgoing arrows, respectively.
Additional processes (bubbles) and information flow paths are presented as the level 0.

Neeraj
Publications
Figure (A) : Information flow refinement

www.neerajbooks.com
Figure (B) : Information flow model

A producer or consumer of information that resides outside the bounds

of the system to be modelled.
A transformer of information (a function) that resides within the bounds
of the system to be modelled.

A data object; the arrowhead indicates the direction of data flow.

A repository of data that is to be stored for use by one or more processes;

may be as simple as a buffer or queue or as sophisticated as a relational
database.
Figure (C) : Basic DFD notation

www.neerajbooks.com
 www.neerajbooks.com
DFD is a partitioned to reveal more detail. For
example, a level 1 DFD might contain five or six bubbles
with interconnecting arrows. Each of the processes
represented at level 1 are sub-functions of the overall
system.
The basic notation used in a DFD is shown in
Figure (C). A rectangle is used to represent an external
entity, that is, a system element (e.g., hardware, a person,
another program) or another system that produces
information for transformation by the software or
receives information produced by the software. A circle
represents a process or transform that is applied to data
(or control) and changes it in some way. An arrow
represents one or more data items or data objects. All
arrows on a data flow diagram are labelled. The double
line represents a data store–stored information that is
used by the software. The simplicity of DFD notation is
one reason why structured analysis techniques are the
most widely used.
No explicit indication of the sequence of
Neeraj
processing is supplied by the diagram. Each of the
bubbles may be refined or layered to depict more detail.
A fundamental model for system P indicates the primary
input is A and ultimate output is B. The model is refined
into transforms P1 to P7 information flow continuity is
maintained, that is, input and output to each refinement
Publications
remain the same. This concept, sometimes called
balancing, is essential for the development of consistent
models.
The data-flow diagram is a valuable graphical tool
www.neerajbooks.com
during software requirements analysis. However, its
function should not be confused with the flowchart. A
data-flow diagram depicts information flow without
explicit representation of procedural logic (e.g.,
conditions or loops). It is not a flowchart.
Q. 6. What do you mean by Data Dictionary?
Explain briefly.
Ans. The Data Dictionary: The analysis model
includes representations of data objects, functions and
control. In each representation data objects and/or
control items play a role. An organized approach for
representing the characteristics of each data object and
control item is done by the data dictionary.
The data dictionary is a quasi-formal grammar
for describing the content of objects defined during
structured analysis. This important modelling notation
is defined in the following way :
The data dictionary is an organized listing of all
data elements that are pertinent to the system, with pre-
cise, rigorous definitions so that both user and system
analyst will have a common understanding of inputs,
outputs, components of stores and (even) intermediate
calculations.
www.neerajbooks.com
Today, the data dictionary is almost always im-
plemented as part of a CASE “structured analysis and
design tool.” Although, the format of dictionaries varies
from tool to tool, most have the following information:
— name—the primary name of the data or control
item, the data store, or an external entity
— alias—other names used for the first entry
— where-used/how-used—a listing of the proc-
esses that use the data or control items and how
it is used (e.g., input to the process, output from
the process, as a store, as an external entity)
— content description—a notation for represent-
ing content
— supplementary information—other information
about data types, present values (if known), re-
strictions or limitations, etc.
Once a data object or control item name and its
aliases are entered into the data dictionary consistency
in name can be enforced. That is, if an analysis team
member decides to name derived data item xyz, but xyz
already in the dictionary, the CASE tool supporting the
dictionary posts warning to indicate duplicate names.
This improves the consistency of the analysis model
and helps to reduce errors.
“Where-used/how-used” information is recorded
automatically from the flow models. When a dictionary
entry is created, the CASE tool scans DFDs and CFDs
to determine which processes use the data or control
information and how it is used. It is one of the most
important benefits of the dictionary.
The data dictionary defines information items
unambiguously. For large computer-based systems the
data dictionary grows rapidly in size and complexity.
In fact, it is extremely difficult to maintain a dictionary
manually. For this reason, CASE tools are used.
Q. 7. List the steps for creating a Data Flow
Diagram?
Ans. Creating a Data Flow Model: The Data Flow
diagram (DFD) helps the software engineer to develop
models of the information domain and functional
domain at the same time. As the DFD is refined into
greater levels of detail, the analyst performs an implicit
functional decomposition of the system, thereby
accomplishing the fourth operational analysis principle.
The DFD refinement also results in a corresponding
refinement of data as it moves through the processes
that embody the application.
Guidelines that can help during derivation of a
data-flow diagram are :
(1) The level 0 data-flow diagram should depict
the software/system as a single bubble;
(2) Primary input and output should be carefully
noted;
 www.neerajbooks.com

(3) Refinement should begin by isolating
candidate processes, data objects and stores
to be represented at the next level;
(4) All arrows and bubbles should be labeled
with meaningful names;
(5) Information flow continuity must be
maintained from level to level; and
(6) One bubble at a time should be refined.
Information flow continuity is maintained between
levels 0 and 1. The processes represented at DFD level
1 can be further refined into lower levels.
The refinement of DFDs continues until each
bubble performs a simple function, that is, until the
process represented by the bubble performs a function
that would be easily implemented as a program compo-
nent. Cohension, that can used to assess the simplicity
of a given function.
Q. 8. List the steps for creating an Entity
Relationship Diagram?
as well as external entities that produce or
consume information.
(2) Taking the objects one at a time, the analyst
and customer define whether or not a
connection exists between the data object
and other objects.
(3) Wherever a connection exists, the analyst
and customer create one or more object-
relationship pairs.
(4) For each object-relationship pair, cardinality
and modality are explored.
(5) Steps 2 through 4 are continued iteratively
until all object-relationship pairs have been
defined. New objects and relationships will
invariably be added as the number of
iterations grows.
(6) The attributes of each entity are defined.
(7) An entity-relationship diagram is formalized
and reviewed.

Neeraj
Ans. Entity-Relationship Diagram: The entity-
relationship diagram lets a software engineer fully
specify the data objects that are input and output from a
system, the attributes that define the properties of these
objects, and the relationships between objects. The ERD
is constructed in an iterative manner. The following are
(8) Steps 1 through 7 are repeated until data
modelling is complete.
Q. 9. What is the Degree of Relationship?
Explain with example.
Ans. The number of entities that participate in the
relationship is the degree of the relationship.

Publications
the steps taken :
(1) During requirements gathering, customers
are asked to list “items” that the application
or business process addresses. These items
become list of input and output data objects
We can have unary, binary or ternary relationship.
Unary Relationship: Its degree is 1 as only one
entity set is participating in the relationship with many
instances of the same entity involved in the relationship.
For example: A person is married to another person

www.neerajbooks.com
Binary Relationship: Its degree is 2 since two entity sets will participate.
For example: A student can enroll for a programme of a university.

Ternary Relationship: Its degree is 3 as three entity sets are participating.

For example, the relationship “may have” could be associated with three entities STUDENT, SUBJECT and
TEACHER. This is many to many relationship. This is shown as follows:

www.neerajbooks.com
 www.neerajbooks.com
Object Oriented Modelling
Object Oriented Modelling is a modelling
paradigm used in computer programming. The object-
oriented paradigm is a development strategy in which
the system is built from the reusable components called
objects, instead of separating data and its functionality
Neeraj
as done in structured programming. Object oriented
software is based on the static, or object model: the
things in the system, or, the things outside the system
about which we need to record information, and their
relationships. Thus, it is the most stable view in the
Publications
system. It is why an object oriented model is preferred
by the system software over a long period.
Each object represents some entity of interest in
the system being modelled, and is characterized by its
www.neerajbooks.com
class, its state (data elements), and its behaviour. Various
models can be created to show the static structure,
dynamic behaviour, and run-time deployment of these
collaborating objects. Collaboration between the objects
means sending messages to each other. Sending a
message differs from calling the function as when an
object sends a message, it decides on its own which
function has to be called for the incoming message rather
than choosing a function explicitly. There are a number
of different notations for representing these models,
such as the Unified Modelling Language (UML).
UML INTRODUCTION
The Unified Modelling Language or UML is a
graphical modelling language which is used to express
the designs of the system. It is a standard language used
for specifying, visualizing, constructing and
documenting the artifacts and components of the
software system. It is very important part for developing
www.neerajbooks.com
3
object oriented software and the software development
process. It is not a process instead it describes a notation
that is used in a design process. It mostly uses the
graphical notations to express the design of the software.
Using UML helps the project teams communicate,
explore potential designs and validate the architectural
design of the software.
UML is a modelling syntax used to create a number
of software system and is widely used in a number of
areas. UML possesses the following characteristics:
1. Syntax Only: UML is just a language; it tells
us what model elements and diagrams are
available and the rules associated with them.
It does not tell about what diagrams to create.
2. Comprehensive: It can be used to design
anything.
3. Language Independent: It means that it does
not matter whatever language the program is
written in. Mapping of code is done by the case
tool that is used.
4. Process Independent: The process written for
creating a model is separate from the definition
of the language of the model.
5. Tool Independent: It does not matter what tool
is being used. It is on the choice of the user to
choose a tool for the creation of the software
system.
6. Well Documented: The UML notation guide
is available as a reference to all the syntax
available in the language.
7. Its Application not Understood Properly:
Even though, a guide is available but it is not
sufficient to understand the language. It is on
the user to understand the application they are
building.
 www.neerajbooks.com
Goals of UML: The goals of the UML are:
1. Provide the user with a manual that is
expressive and ready-to-use so that user can
develop and exchange meaningful models.
2. Provide extensibility and specialization
mechanisms to extend the core concepts.
3. It should be language independent.
4. Provide a formal basis for understanding the
language.
5. It should encourage the use of a variety of tools.
6. Support higher-level development concepts
such as collaborations, frameworks, patterns
and components.
7. Respond to the variety of needs of the
organization.
Application Areas of UML: The UML has been
used effectively for such domains as:
Enterprise information systems
Banking and financial services
Neeraj
Telecommunications
Transportation
Defence
Medical electronics
Distributed web based services.
A Conceptual Model of the UML: To form a
Publications
conceptual model of UML, knowledge of three major
elements is required: the UML’s basic building blocks,
the rules that dictate how those building blocks may be
put together and some common mechanisms that apply
www.neerajbooks.com
throughout the UML.
Building Blocks of UML: The vocabulary of UML
encompasses three kinds of building blocks:
1. Things
2. Relationships
3. Diagrams
Things are the abstractions that are first class
citizens in a model; relationships tie these things
together; diagrams group interesting collections of
things.
Things in the UML: There are four kinds of the
things in UML.
1. Structural things.
2. Behavioural things.
3. Grouping things.
4. Annotational things.
These things are used to write well formed models.
Structural Things: Structural things are the nouns
of UML models. These are the mostly static parts of a
model, representing elements that are either conceptual
or physical. In all, there are seven kinds of structural
things. These are:
www.neerajbooks.com
Class: A class is a description of a set of objects
that share the same attributes, operations, relationships,
and semantics. A class implements one or more
interfaces. Graphically a class is rendered as a rectangle,
usually including name, attributes and operations.
Window
Origin
Size
Open ()
Close ()
Move ()
Display ()
Interface: An interface is a collection of
operations that specify a service of a class or component.
An interface therefore describes the externally visible
behaviour of that element. An interface may represent
the complete behaviour of a class or component or only
a part of that behaviour. An interface defines set of
operation specifications (i.e. There signature) but never
a set of operation implementation. Graphically an
interface is rendered as a circle together with its name.
ISpelling
Collaboration: Collaboration defines an
interaction and is a society of roles and other elements
that work together to provide some cooperative
behaviour that’s bigger than sum of all the elements.
Thus collaborations have structural as well as
behavioural dimensions. Graphically collaboration is
represented as an ellipse with dashed lines, usually
including only its name.
Chain of Responsibility
Use Case: A use case is a description of set of
sequence of actions that a system performs that yields
an observable result of value to a particular actor. A use
case is used to structure the behavioral thing in a model.
A use case is realized by collaboration. Graphically a
use case is represented by an ellipse with solid lines,
usually including only its name.
 www.neerajbooks.com
Place Order
Active Class: An active class is a class whose
objects own one or more processes or threads and
therefore can initiate control activity. An active class is
just like a class except that its objects represent elements
whose behaviour is concurrent with other elements.
Graphically an active class is rendered just like a class,
but with heavy lines, usually including its name,
attributes and operations.
Event Manager
Flush ()
Suspend ()
Neeraj
Component: A component is a physical and
replaceable part of the system that conforms to and
provides the realization of a set of interfaces. In a system
there are different kinds of deployment components,
such as COM+ components or java beans, as well as
Publications
components that are artifacts of the development process
such as source code files a component typically
represents physical packaging of logical elements such
as classes, interfaces and collaborations.
www.neerajbooks.com
Order for m.java
Node: A node is a physical element that exists
at run time and represents a computational resource,
generally having at least some memory and often
processing capability. A set of components may reside
on a node. Graphically, a node is represented as a cube,
usually including only its name.
Behavioural Things: These are the dynamic parts
of UML models. These are the verbs of a model,
www.neerajbooks.com
representing behaviour over time and space. There are
two primary kinds of behavioural things. They are:
1. Interaction: An interaction is a behaviour that
comprises a set of message exchanged among
a set of objects within a particular context to
accomplish a specific purpose. An interaction
involves a number of other elements, including
messages. Graphically, a message is rendered
as a directed line, almost always including the
name of its operation. This is shown as follows:
Display
2. State Machine: The state machine is a behaviour
that specifies the sequence of states of an object or an
interaction goes through during its life time in response
to events, together with its responses to those events.
Graphically a state is rendered as a rounded rectangle,
usually including its name and its sub states, if any.
States name
Grouping Things: Grouping things are the
organizational parts of UML models. These are the
boxes into which a model can be decomposed. There is
one primary kind of grouping thing, namely, package.
Package: A package is a general purpose
mechanism for organizing elements into groups.
Structural things, behavioural things and even other
grouping things may be placed in a package. Unlike
components (which exist at run time), package is purely
conceptual (meaning it exists only at development
time). Graphically a package is rendered as a tabbed
folder, usually including only its name and sometimes
its contents.
Business Rules
Annotational Things: Annotational things are the
explanatory parts of UML models. These are the
comments you may apply to describe, illuminate and
remark about any element in a model. There is one
primary kind of annotational thing, called a note. A note
is simply a symbol for rendering constraints and
comments attached to an element or a collection of
elements. Graphically a note is rendered as a rectangle
with a dog eared corner, together with a textual or
graphical comment.
 www.neerajbooks.com
Relationships in UML: There are four kinds of
relationships in the UML:
1. Dependency.
2. Association.
3. Generalization.
4. Realization.
These are the basic relational building blocks of
the UML. These are used to write well formed models.
1. Dependency: A dependency is a semantic
relationship between two things in which a change to
one thing (independent thing) may affect the semantics
of the other thing (dependent thing). Graphically a
dependency is rendered as a dashed line, possibly
directed and occasionally including a label.
Neeraj
2. Association: An association is a structural
relationship that describes a set of links. A link being a
connection among objects. Aggregation is a special kind
of association, representing a structural relationship
between a whole and its parts. Graphically, an
Publications
association is rendered as a solid line, possibly directed,
occasionally including a label and often containing other
adornments, such as multiplicity and role names.
3. Generalization: A generalization is a
www.neerajbooks.com
specification relationship in which objects of the
specialized elements (the child) are substitutable for
objects of the generalized elements (the parent). In this
way the child shares the structure and the behaviour of
the parent. Graphically, a generalization relationship is
rendered as a solid line with a hollow arrowhead
pointing to the parent.
4. Realization: A realization is a semantic
relationship between classifiers, whereas one classifier
specifies a contract that another classifier guarantees to
carry out. Realization relationship is encountered at two
places: between interfaces and the classes or components
that realizes them and between use cases and the
collaborations that realizes them.
www.neerajbooks.com
UML Diagrams: A diagram is a graphical
presentation of a set of elements, most often rendered
as a connected graph of vertices (things) and arcs
(relationships). Diagrams are drawn to visualize a
system from different perspectives, so a diagram is a
projection into a system. There are a number of UML
diagrams that depict different perspectives of the
software system that makes it easier to be understood
by the users. UML diagrams mainly include the
following:
1. Use Case Diagram: It displays the overall
functionality of the software system by displaying the
relationship between the actors and the use cases.
2. Class Diagrams: It is used to describe the types
of objects and their relationship in the system. It models
the class structure and contents using design elements
such as classes, packages and objects.
3. Interaction Diagram: An interaction diagram
shows an interaction, consisting of a set of objects and
their relationships, including the messages that may be
dispatched among them. It includes the following types
of diagrams:
(a) Sequence Diagram: It displays the time
ordering of the messages that participate in the
interaction with time on vertical dimension and
objects on horizontal.
(b) Collaboration Diagram: It displays the
structural organization of the objects that send
and receive messages. Numbers are used to
show the sequence of messages.
4. State Diagram: It describes the state of the
object in interaction goes through when it receives a
stimuli and with its response and actions.
5. Activity Diagram: It illustrate the dynamic
nature of the system by modelling the flow of control
between different activities. An activity diagram
represents the operation on some class in the system
that results in the change of the state in the system. This
diagram focuses on the flows driven by internal
processing.
6. Component Diagram: It displays the static
implementation view of the system they are related to
class diagrams in that a component typically maps to
one or more classes, interfaces or collaboration.
7. Deployment Diagram: It captures the
relationship between the physical components and the
hardware. It displays the configuration of run-time
processing elements and the software components,
processes, and objects that live on them.
 www.neerajbooks.com
Rules of UML: The UML’s building blocks can’t
simply be thrown together in a random fashion. Like
any language, the UML has a number of rules that
specify what a well formed model should look like. A
well formed model is one that is semantically self-
consistent and in harmony with all its related models.
The UML has semantic rules for:
Names
Scope
Visibility
Integrity
Execution.
Common Mechanisms in UML: Drawing the
diagrams in UML is made simpler by four common
mechanisms that apply consistently throughout the
language.
Specification
Adornments
Neeraj
Common divisions
Extensibility mechanisms.
Specifications: The UML is more than just a
graphical language. Rather, behind every part of its
graphical notation there is a specification that provides
Publications
a textual statement of the syntax and semantics of that
building block. For example, behind a class icon is a
specification that provides the full set of attributes,
operations and behaviour that class embodies.
Adornments: Most elements in the UML have a
www.neerajbooks.com
unique and direct graphical notation that provides a
visual representation of the most important aspects of
the elements. A class’s specification may include other
details, such as whether it is abstract or the visibility of
its operations and attributes. Many of these details can
be rendered as graphical or textual adornments to the
class’s basic rectangular notation.
Common Divisions: In modelling object oriented
systems, the world often gets divided in at least a couple
of ways. First there is a division of classes and objects.
Second there is a separation of interface and
implementation.
Extensibility Mechanism: The UML provides a
standard language for writing software blueprints, but
it is not possible for one closed language to ever be
sufficient to express all possible nuances of all models
across all domains across all time. For this reason, the
UML is open ended, making it possible for you to extend
the language in controlled ways. The UML’s
extensibility mechanisms include:
www.neerajbooks.com
Stereotypes
Tagged values
Constraints.
A stereotype extends the vocabulary of the UML,
allowing it to create new kinds of building blocks that
are derived from the existing ones, but they are specific
to the problem. For example, if you are working in a
programming language, such as java or C++, you will
often want to model exceptions. In these languages,
exceptions are just classes, although, they are treated in
very special ways. You can make exceptions as basic
building blocks- by marking them with an appropriate
stereotype.
A tagged value extends the properties of a UML
building block, allowing you to create new information
in that element’s specification. For example, version of
a product is not primitive UML concepts. They can be
added to any building block, such as a class, by
introducing new tagged values to the building block.
A constraint extends the semantics of a UML
building block, allowing it to add new rules or modify
the existing ones. For example, ordered may be the
constraint for the event Queue class so that all additions
are done in order.
USE CASE DIAGRAM
Use Case Diagram in the Unified Modelling
Language is a type of a behavioural diagram whose
purpose is to provide a graphical representation of the
functionality of the software system in terms of actors
and the relationship of them with the use cases. Hence,
a use case diagram captures the functional aspects of a
system. Interaction among the actors is not shown on
the use case diagram.
The diagrams building blocks are the use cases,
actors, system boundary boxes and the relationships.
Use Case: A Use Case is the description of the
interaction of the system and the actors external to the
system. It is initiated by a user with a particular goal in
mind and completes when that goal is satisfied. It is
described by writing the required steps and also
mentioning the alternative actions that can be performed
on each step. For example, the use case for searching a
word is shown as:
1. User enters the word to be searched.
2. User clicks the search button.
3. Search begins.
4. Results are shown.
Alternative: Search Failed. If the search fails at step
3, the user is redirected to the search screen at step 1.
Thus, use case captures who (actor) does what
(interaction) with the system for what purpose (goal)
 www.neerajbooks.com
without dealing with the system internals. It is written
in easy to understand textual format. The users may
validate the use cases and may involve in the process of
requirement gathering and defining the requirements.
It is shown as a oval in the use case diagram. Its notation
is shown below:
There is no standard use case template for writing
the use cases. A template for writing the use case is given
below:
1. Brief Description: Describe the purpose of
the use case.
2. Actors: Name the actors that participate in
the use case.
3. Flow of Events.
3.1 Basic Flow. List the primary events that
Neeraj
will occur when the use case is executed.
3.2 Alternate Flow. Any other possible flow
that will also lead to satisfying the goal will
be listed here. A use case can have many
alternate flows.
4. Special Requirements. Business rules for
Publications
the flow of event should be listed here. Both
success and failure scenarios should be
described here.
5. Pre-conditions. Conditions that need to be
www.neerajbooks.com
satisfied for use case to execute.
6. Post-conditions. Different states that a
system will be in after the execution of the
use case is described here.
7. Extension Points.
Use Case Guidelines: The following are the steps
for creating a use case:
1. Identify the various users of the system.
2. Create a user profile for the users of each
category which includes all the roles that users
play relevantly to the system and identify all
the important goals of the users that the system
will support.
3. For each goal a use case has to be created
following the use case template. Steps in higher
level use cases may be treated as goals for
lower level, sub-use cases.
4. Use cases are to be structured. Over-structuring
should be avoided so that it remains easy to be
understood.
5. Review and validate with the users.
www.neerajbooks.com
Benefits of use cases:
1. Use cases provide the users with a better
understanding of what is expected from the
proposed system and how to interact with the
system.
2. Every requirement is detailed properly.
3. It helps in generation of test cases required for
testing the system product.
4. It ensures that the developers pay more
importance to the “task orientation” of the
system.
5. It can easily be converted into the object
models, for developers using object oriented
design methodologies.
6. Better traceability throughout the system
development process.
7. Quality of the software is improved by
identifying the exception scenarios earlier in
the development process.
8. Easier user validation.
Problems with Use Cases: Some of the pitfalls
that need to be avoided while employing the use case
approach are as follows:
1. Use cases should be ensured that they are
detailed enough and not to abstract. The
interaction with the system should be
visualized by the user.
2. Separate use cases should not be drawn for
every exceptions and alternative. They all
should be included in the same use case.
3. Do not duplicate the same sequence of steps
across multiple use cases. If this situation
occurs that is common steps of sequence occurs
in multiple use cases then make a separate use
case for these steps and using the “include”
relationship refer in each use case these steps
are to be mentioned.
4. Do not include user interface design and data
definitions in use cases.
5. Do not create a use case for each requirement.
It will be very difficult to convert every non-
functional requirement into a use-case.
Actor: The use case diagram allows a designer to
graphically show the use cases and the actors that use
them. An actor is a role that a user plays in the system.
An actor or external agent lies outside the system but
interacts with the system. It can be a person, machine
or an information system that is external to the system.
 www.neerajbooks.com
An actor is represented as a stick figure and is not
part of the system itself. Its notation is shown below:
Actor
Customers, users, external devices or any external
entity interacting with the system are treated as actors.
There can be two types of actors: primary and
secondary. Primary actors are the ones having a goal
requiring the assistance of the system. That is these
actors initiate a use case. While the secondary actors
are the ones from which the system needs assistance
that is they support the use case or receive something
valuable from the use case.
System Boundary Box: A rectangle is drawn
Neeraj
around the use cases, called the system boundary box,
to indicate the scope of system. Anything within the box
represents functionality that is in scope and anything
outside the box is not.
Relationships: There are two types of relationships
Publications
that exist in the use case diagram. They are as follows:
Includes: The use case that is associated with
actors can be very general. Include is a directed
relationship between two use cases, implying
that the behaviour of the included use case is
www.neerajbooks.com
inserted into the behaviour of the including use
case.
The notation is a dashed arrow from the
including to the included use case with the label
of “<<include>>” on it. There are no
parameters or return values. To specify the
location in a flow of events in which the base
use case includes the behaviour of another, you
simply write include followed by the name of
use case you want to include. For example,
the “pump gas” use case that is associated with
the customer includes three use cases: Choose
Gas Type, Fill Tank and Calculate Total.
Extends: In this form of interaction, a given
use case extends the other. The relationship
indicates that the behaviour of the extension
use case may be inserted in the extended use
case under some conditions. The notation is a
dashed arrow from the extension to the
extended use case, with the label “extend”. The
notes or constraints may be associated with this
www.neerajbooks.com
relationship to illustrate the conditions under
which this behaviour will be executed. For
example, some stores may allow for different
payment options like credit card, debit card,
or cash on delivery. These specific
functionalities are extension of the general
“pay for items.”
Example of Use Case Diagram: Software has to
be developed for automating the railway reservation
system. The system should be designed to perform the
following functionalities:
1. Reservation Seat: Passengers should be able
to reserve seats in the train by filling the form
and submitting to the clerk. If the seats are
available then the clerk makes the relevant
entries and asks the passenger to pay the fare
and the tickets are printed otherwise the
passenger is informed about the unavailability
of the seats.
2. Cancel Reservation: A passenger wishing to
cancel the reservation should be able to do that
by filling a form for cancellation and
submitting it to the clerk. Clerk will delete the
entries and update the reservation status.
3. Update Train Information: Only the
administrator enters any changes related to the
train information like change in the train name,
number etc. in the system.
4. Report Generation: The system should be
able to generate reservation chart, monthly
train report, etc.
5. Login: For security reasons all the users of
the system have their id and a password with
the help of which they can enter the system.
6. View Reservation Status: Reservation status
of the seat can be viewed by the user.
7. View Train Schedule: Provision should be
given to see information related to the train
schedules for the entire train network to the
user.
To draw a use case diagram for the above
mentioned problem we have to first identify the use cases
and the actors that will participate and interact with the
system.
The use cases that are there are:
1. Update train information
2. Report generation
3. Login
4. View reservation status
5. View train schedules
 www.neerajbooks.com
6. Reserve seats
7. Cancellations.
The actors that participate are:
1. Administrator or Admin
Neeraj
Publications
www.neerajbooks.com
Class Diagram
A class diagram shows a set of classes, interfaces
and collaborations and their relationships. These
diagrams are the most common diagrams found in
modelling object oriented systems. Class diagrams
address the static design view of a system. Class
diagrams that include active classes address the static
process view of a system. They are widely used to
describe the types of objects in a system and their
relationships. They model the class structure and
contents using the design elements like classes, packages
and objects. It describe three different perspectives when
designing a system they are conceptual, specification
and implementation which become evident as the
diagram is created and will solidify the design. Class
diagrams show the classes of the system, their
interrelationships (including inheritance, aggregation,
www.neerajbooks.com
2. Passenger
3. Clerk.
The use case diagram for the above problem can
be drawn as follows:
and association) and the operations and attributes of
the classes. It can also be used for data modelling.
Packages: A package is a general purpose
mechanism for organizing elements into groups.
Structural things, behavioural things and even other
grouping things may be placed in a package. Unlike
components (which exist at run time), package is purely
conceptual (meaning it exists only at development time).
Graphically, a package is rendered as a tabbed folder,
usually including only its name and sometimes its
contents.
Classes: The core element of the Class Diagram is
the class. In object oriented system, classes are used to
represent entities within the system; entities that often
relate to real world objects. A class is a description of a
set of objects that share the same attributes, operations,
relationships and semantics. A class implements one or
 www.neerajbooks.com
more interfaces. Graphically, a class is rendered as a
rectangle, usually composed of three things i.e. name,
attributes and operations.
Below is an example of class:
As it can be seen from the above diagram that a
class is divided into three sections that are:
Top: Here the name of the class is shown.
Center: It contains the attributes of the class.
Bottom: It shows the operations that can be
Neeraj
performed on the class.
In the system design of a system, a number of
classes are identified and grouped together in a class
diagram which helps to determine the static relations
between those objects. With detailed modelling, the
classes of the conceptual design are often split into a
Publications
number of sub-classes.
Attributes : An attribute is a property of a class. In
the above example, we have shown that customer has a
name, an address, etc. as its attributes. It is generally
www.neerajbooks.com
understood that when implementing the class,
functionality is provided to set and retrieve the
information stored in attributes. Methods to set and
retrieve attribute data are often called accessor methods
and need not be shown in the model as they are usually
inferred.
The syntax for attribute is:
visibility name: type = defaultValue
Order
dateRecieved: Date
isReceived: Boolean
n 1
Number: String
Price: Money
Dispatch()
www.neerajbooks.com
Visibility of the class member (i.e. any method or
attribute) placed before the member’s name is specified
using the following notations:
+ Public
- Private
# Protected
~ Package
/ Derived
In object oriented modelling, it is generally
preferred to keep most attributes private as the accessor
methods allow to control the access to the data.
Name in the syntax is the attribute’s name. Type
refers to the data type which will help in storing the
data i.e., integer or string or any other data type. Default
value is optional.
Operations: The operations listed in the class
diagram show the functions or tasks that can be
performed on the data of that class. For example, in the
above example of customer, we had add() and delete()
as the operations of that class. This means that we can
add() a new customer in the database and can also
delete() an existing customer from the data. Operations
can also be shown with the visibility:
The syntax is: Visibility name (parameters) : type
of value returned.
Relationships
Association: An association represents
relationship between two classes. It is
represented as a line with each end connected
to a class box. Higher order associations are
shown using a central diamond and the ends
are connected to this diamond. An association
can be named at the ends with role names or
indicators or multiplicity or other properties.
Below is an example of association
relationship:
Customer
Association Name: string
Address: string
Credit rating()
Multiplicity
Many value Mandatory
 www.neerajbooks.com
Aggregation: It is an association that
represents a part-whole or part of relationship
in which objects representing the components
of something is associated with an object
representing an entire assembly. The most
significant property of aggregation is
transitivity i.e. if A is part of B and B is part of
C, then A is part of C. Aggregation will not
involve more than two classes. It is also
Composition: Composition usually has a
strong life cycle dependency between instances
of the container class and instances of the
contained class. If the container is destroyed,
Neeraj
normally every instance that it contains is
destroyed as well. It is represented as a solid
diamond in the diagram.
Generalization: The generalization relation-
ship indicates that one of the two related classes
is considered to be a specialized form of the
Publications
other i.e. superclass is the generalization of the
subclass. For example, Equipment is the
superclass of Pump and Tank. Attributes and
www.neerajbooks.com
Realization: A realization relationship is a
relationship between two model elements, in
which one model element realizes the
www.neerajbooks.com
antisymmetric i.e. if A is part of B then B is
not part of A.
Aggregation is drawn like association except a
small diamond indicates the assembly end of the
relationship i.e. the hollow diamond is shown on the
containing class end and the line that connects the
contained class to the connecting class.
For example, a document consists of many
paragraphs, each of which consists of many sentences.
operations that are common to the sub-classes
are attached to the superclass and shared by
all the subclasses. Sub-class contains only
those features that are unique to that class only.
It is also known as the inheritance relationship.
The notation for generalization is a triangle
connecting the superclass to its sub-classes. The
superclass is connectded by a line to the apex of the
triangle. The subclasses are connected by lines to a
horizontal bar attached to the base of the triangle.
For example, a figure superclass can have 0
dimensonal, 1 dimensional and 2 dimiensional as its
sub-classes.
behaviour that the other model element
specifies. It is shown by a dashed line with an
unfilled arrowhead towards the supplier. It is
 www.neerajbooks.com
a relationship between classes, interfaces,
components and packages that connects a
client element with a supplier element.
Dependency: A dependency exists between
two elements if changes to one will affect the
other element. If for example, a class calls an
operation in another class, then a dependency
exists between the two. If the operation is
changed then the dependent class will also have
to change. There should be minimum number
of dependencies existing in the system. It is
shown as a dashed arrow in the diagram. For
example, if there are two classes Car and Wheel
then the Wheel class is dependent on the Car
class.
Multiplicity: Multiplicity specifies how many
instances of one class relate to a single instance
of an associated class. It constrains the number
of related objects. These are shown at the end
Neeraj
of association lines. The most common
multiplicity are:
0..1 No instances, or one instance
Publications
www.neerajbooks.com
www.neerajbooks.com
1 Exactly one instance
0..* or * Zero or more instances
1..* One or more instances
Example of Class Diagram: Class diagrams are
some of the most difficult UML diagrams to draw. When
designing classes consider what attributes and
operations it will have. Then try to determine how
instances of the classes will interact with each other.
For example, the following diagram is an example
of an Order System of an application. So, it describes a
particular aspect of the entire application.
First of all Order and Customer are identified
as the two elements of the system and they have
a one to many relationship because a customer
can have multiple orders.
We would keep Order class is an abstract class
and it has two concrete classes (inheritance
relationship) SpecialOrder and NormalOrder.
The two inherited classes have all the
properties as the Order class. In addition they
have additional functions like dispatch () and
receive ().
 www.neerajbooks.com
Q. 1. What is meant by Object Oriented
Analysis? What tasks must occur for OOA?
Ans. OOA is designed by following set of basic
principles. In order to build an analysis model, five basic
principles are applied:
(1) The information domain is modelled;
(2) Module function is described;
(3) Model behaviour is represented;
(4) The models are partitioned to expose greater
detail; and
(5) Early models represent the essence of the
problem, while later models provide implementation
details. These principles form the foundation for the
approach to OOA.
The aim of OOA is to define all classes (and the
relationships and behaviour associated with them) that
are relevant to the problem to be solved. To achieve
this, a number of tasks must occur:
1. Basic user requirements must be communicated
Neeraj
between the customer and the software engineer.
2. Classes must be identified (i.e. attributes and
methods are defined).
3. A class hierarchy must be established.
4. Object-to-object relationships (object
connections) should be represented.
Publications
5. Object behaviour must be modelled.
6. Tasks 1 through 5 are reapplied iteratively until
the model is complete.
Instead of examining a problem using the classic
input-processing-output (information flow) model or a
www.neerajbooks.com
model derived exclusively from hierarchical information
structures, OOA introduces a number of new concepts.
These new concepts, though a bit unusual, are really
quite natural.
OOA–object-oriented analysis–is based upon
concepts that we first learned in kindergarten: objects
and attributes, classes and members, wholes and parts.
Why it has taken us so long to apply these concepts to
the analysis and specification of information systems is
anyone’s guess–perhaps we’ve been too busy “following
the flow” during the heyday of structured analysis to
consider the alternatives.
Q. 2. What is the objective of object-oriented
analysis? Compare it with structured analysis.
Ans. Object-oriented Analysis: The objective of
object-oriented analysis is to develop a series of models
that describe computer software as it works to satisfy a
set of customer-defined requirements. OOA, like the
conventional analysis methods builds a multipart
analysis model to satisfy this objective.
Conventional Vs OO Approaches: Object-
oriented analysis is totally different from the structured
www.neerajbooks.com
analysis approach. Fichman and Kemerer address the
question in these words :
We conclude that the object-oriented analysis
approach .... represents a radical change over process-
oriented methodologies such as structured analysis, but
only an incremental change over data-oriented
methodologies such as information engineering.
Process-oriented methodologies focus attention away
from the inherent properties of objects during the
modelling process and lead to a model of the problem
domain that is orthogonal to the three essential principles
of object-orientation: encapsulation, classification of
objects and inheritance.
Structured analysis takes a distinct input-process-
output way of requirements. Data are considered
separately from the processes that transform the data.
System behaviour, although important, tends to play a
secondary role in structured analysis. The structured
analysis approach makes heavy use of functional
decomposition object-oriented analysis provides a
rational process. It combines the system’s behaviour and
data and regards them as integrated objects. It is an
iteration between analyzing the behaviour and
information of the system. It is based on natural objects
found in the problem domain. The objects hold data
and have behaviour in terms of which entire system
behavior can be expressed.
Q. 3. What does UML stands for?
Ans. UML stands for unified modelling language.
The UML is a standard language for writing software
blueprints. The UML may be used to visualize, specify,
construct and document the artifacts of the software –
intensive system. The UML is a very expressive
language, addressing all the views needed to develop
and then deploy such systems. Even though, it is
expressive, the UML is not difficult to understand and
to use. The UML is process independent, although,
optimally it should be used in a process that is use case
driven, architecture centric, iterative and incremental.
Q. 4. What are the application areas of UML?
Ans. The UML has been used effectively for such
domains as:
1. Enterprise Information Systems: UML is a
broadly accepted modelling language for the
development of software systems and applications. The
so called, “object oriented community” also attempts
to use UML for enterprise modelling purposes. Here,
the emphasis is placed on the usage of enterprise objects
or business objects from which complex enterprise
systems are made. A collection of these objects and the
interactions between them can represent a complex
business system. UML focuses on the business objects
 www.neerajbooks.com
mainly. These are called “enterprise building blocks”
and include resources, processes, goals, rules and meta-
models.
2. Banking and Financial Services: Today banks
and financial institutions are continuously facing
challenges of various forms and degrees. Customer
acquisition and retention, regulatory pressures, pricing
pressures, tighter credit markets, global markets and the
need to deliver profits quarter after quarter, are some of
the challenges banks and financial institutions are facing.
Coupled with the challenges, the demand to keep costs
under control, maintain growth through factors like
productivity, information availability, product and
service differentiation and new investment products.
UML’s Banking and Financial Services consultants have
partnered with banks and financial institutions
nationwide to achieve their objectives. By partnering
with UML one can gain access to technology and
functional experts who specialize in asset and wealth
Neeraj
management, front office, middle office, back office,
cards and payments, investment banking and brokerage,
security services, consumer lending, etc.
3. Telecommunications: For real-time modelling,
UML-RT extends the UML by three concepts that is
Publications
capsules, ports and connectors. UML-RT does not offer
support for modelling priority layers. Hence, an
extension to UML-RT is proposed that introduces one
or more layers of capsule, which are associated with a
specific priority in execution. Eith this extension UML-
www.neerajbooks.com
RT is a candidate for modelling real-time systems in
telecommunication domain.
4. Transportation: Transportation is the movement
of people, cattle, animals and goods from one location
to another. Modes of transport include air, rail, road,
water, cable, pipeline and space. The field can be divided
into infrastructure, vehicles and operations. Transport
is important since it enables trade between peoples,
which in turn establishes civilizations. UML presents
this information graphically and symbolically which
facilitate the review process and makes it easier to
modify after the construction of the software.
5. Defence: The OSU-UML seeks to bridge the
gaps between Defence, Industry and Academia in a large
number of areas, bringing them together and enablling
collaboration that highlights the best aspects of all three.
OSU-UML will accomplish this task through robust
partnerships. With a number of partnerships and
contracts already in place, one will strive to develop
more with effective processes that allow the capabilities
www.neerajbooks.com
to rapidly address shortfalls and requirements. Currently
the OSU-UML is actively working in the Chemical
Biological Radiological Nuclear and Explosive
(CBRNE) Defense, Command Control Communications
Computers Cyber Intelligence Surveillance and
Reconnaissance (CISR), and Unmanned Arial Vehicles
(UAV) Systems and Payloads areas.
6. Medical Electronics: The complexity of medical
device software is increasing. An MDD environment
based on UML helps enable visualization of textual
requirements and strengthens the design process. It
empowers teams to break down complex requirements
and communicate more effectively with the project team
and government agencies. The semantics of the model
help to manage change by maintaining consistent
information in multiple views. Quality and safety goals
can be met using validation, performed early in the
design cycle to identify errors when they are the least
costly to address. For medical device developers, a
model-driven approach integrates the different phases
of the product life cycle-helping improve a company’s
ability to deliver innovative medical device software
while gaining a competitive edge.
7. Distributed Web Services: As the number of
available web services is steadily increasing, there is a
growing interest for reusing basic web services in new,
composite web services. A method is proposed that uses
UML Activity models to design web service
composition, and OMG's Model Driven Architecture
(MDA) to generate executable specifications in different
composition languages. The method utilizes standard
UML constructs with a minimal set of extensions for
web services. An important step in the method is the
transformation of WSDL descriptions into UML. This
information is used to complete the composition models.
Another key aspect of the method is its independence
of the web service composition language. The user can
thus select his preferred composition language – and
execution engine – for realizing the composite web
service.
Q. 5. What are the building blocks of UML?
Ans. The building blocks of UML are:
1. Things: These are the basic entities in the model.
They are the abstractions that are first class citizens in a
model. It is of four types namely structural, behavioural,
grouping and annotational.
2. Relationships: They tie things together. They
are of four types that is association, dependency,
generalization and realization.
 www.neerajbooks.com
3. Diagrams: It groups interesting collections of
things that is it is a graph of things and their relationships.
It is of nine types namely class diagram, object diagram,
use case diagram, collaboration diagram, sequence
diagram, state chart diagram, component diagram,
activity diagram and deployment diagram.
Its pictorial representation is shown below:
Neeraj
Publications
www.neerajbooks.com
www.neerajbooks.com
Q. 6. What is use case diagram?
Ans. A use case diagram shows a set of use cases
and actors and their relationships. Use case diagrams
address the static use case view of a system. These
diagrams are especially important in organizing and
modelling the behaviours of a system. Thus, use case
diagram is a behavioural diagram whose purpose is to
provide a graphical representation of the functionality
of the software system. Hence, a use case diagram
captures the functional aspects of a system. It does not
show the interaction between the actors.
Q. 7. What are the benefits of use cases?
Ans. The benefits of use cases are:
1. It provides a good understanding to the user
of what is expected from the system and how
the system will interact with each other.
2. Detailing of every requirement is done here.
3. Test cases are being generated easily that are
useful for testing the system product.
4. More importance to the “task orientation” of
the system is being ensured through it.
5. Using object oriented design methodologies
it can easily be converted into the object
models.
6. Ensures better traceability throughout the
system development process.
7. By identifying the exception scenarios earlier
in development process, a good quality
software can be made.
8. User validation is easier.
Q. 8. What is class diagram?
Ans. Class diagrams are the backbone of almost
every object-oriented method including UML. A class
diagram shows a set of classes, interfaces and
collaborations and their relationships. These diagrams
are the most common diagrams found in modelling
object oriented systems. They describe the static
structure of a system. Classes represent an abstraction
of entities with common characteristics. Associations
represent the relationships between classes. Classes are
shown with rectangles divided into compartments. The
name of the class is placed in the first partition (centered,
bolded and capitalized), list of the attributes in the
second partition and operations are written into the third.
In the system design of a system, a number of classes
are identified and grouped together in a class diagram
which helps to determine the static relations between
those objects. With detailed modelling, the classes of
the conceptual design are often split into a number of
sub-classes.
 www.neerajbooks.com
DESIGN AND TESTING
Function Oriented Design
Function-oriented design has been practiced
informally since programming began. Programs were
decomposed into subroutines which were functional in
nature and with a centralized system state which is
shared by these functions. This is shown in the following
figure:
Neeraj
Publications
www.neerajbooks.com
Function-oriented design conceals the details of an
algorithm in a function but system state information is
not hidden. Problems can be caused due to this because
a function can change the state in a way which other
functions do not expect. Changes to a function and the
way in which it uses the system state may cause
unanticipated changes in the behaviour of other functions.
A functional approach to design is successful when
the amount of system state information is minimized
i.e. where the system is concerned with processing
independent actions whose outcomes are not affected
by previous actions and information sharing is explicit.
Many transaction-processing systems and business
data-processing systems fall into this class. In essence,
they are concerned with record processing where the
processing of one record is not dependent on any
previous processing.
In this chapters, we will discuss the following:
1. Constructing solution to a problem: It will tell
us how we can structure our problem that is
www.neerajbooks.com
4
what strategy of design should be followed to
organize the modules.
2. Identifying components and their interaction:
Here, all the design notations will be discussed.
3. Visualizing the solution: Here, how the solution
will be visualized that is function procedural
layers will be discussed.
4. Characteristics of a good function oriented
design will be discussed.
CONSTRUCTING SOLUTION TO PROBLEM
The design activity begins when the SRS document
for the software to be developed is available. It has two
levels. At first level, the focus is on deciding which
modules are needed for the system, their specification
of these modules and how the modules should be
interconnected.
Function oriented design is an approach to software
design where the design is decomposed into a set of
interacting units where each unit has a clearly defined
function. Thus, the system is designed for a functional
view-point. Solution of a problem can be given using
the following three principles. They are:
1. Partitioning: When solving a small problem, it
can be solved all at once. For solving larger problems,
the problem is divided into smaller pieces so that each
piece can be conquered separately. Therefore, the goal
of the software design is to break the problem into
smaller pieces so that each piece could be solved
separately.
Problem partitioning can be divided into two
categories:
(i) Vertical Partitioning: It is also known as
factoring. It suggests that control and work
should be distributed from top-down in
programming structure. The top level module
will perform the control function and will do
the actual processing work. Modules of the
lower level are the workers that perform all
the input, all the functions and outputs tasks.
 www.neerajbooks.com

(ii) Horizontal Partitioning: It defines separate branches of modular hierarchy for each major program
function. It defines three partitions. One for input, other for data transformation and the third one for
output. Partitioning it this way has several benefits. They are:
Software is easier to test.
Software is easier to maintain.
Software is easier to extend.

Neeraj
Propagation of fewer side effects.
One disadvantage of this approach is that it can complicate the overall control of program flow.

Publications
www.neerajbooks.com

2. Abstraction: Abstraction is a concept related to problem partitioning. When is used during design, the
design activity focuses on one part of the system at a time. Since the part being designed interacts with other parts
of the system, a clear understanding of the interaction is essential for properly designing the part. An abstraction of
a system or a part defines the overall behaviour of the system at an abstract level without giving the internal details.
While working with a part of the system, a designer needs to understand only the abstractions of the other parts with
which the part being designed interacts. The use of abstraction allows the designer to practice the divide and
conquer technique effectively by focusing on one part at a time, without worrying about the details of other parts.
3. Top-Down and Bottom-Up design
Bottom-Up design: A common approach is to identify modules that are required by many programs. This
is a style of design where we decide how to combine the modules to provide larger ones; to combine those
to provide even larger ones, and so on, until we arrive at a one big module which is the whole of the
desired program. This method works with the layers of abstraction. Since the design progressed from
bottom layer to upwards, this method is called bottom-up design. The diagrammatic representation is as
follows:

www.neerajbooks.com
 www.neerajbooks.com
Top-Down design: An approach that starts by identifying the major modules of the system, decomposing
them into their lower level modules and iterating until the desired level of detail is achieved. It is a
stepwise refinement; starting from an abstract design and moving to a concrete level at each step of
refinement until a level where no more refinement is needed and the design can be implemented directly
is reached.
Neeraj
Publications
IDENTIFYING COMPONENTS
AND THEIR INTERACTION
During the design phase, there are two things that
are of interest that is the design of the system and the
process of designing. It is for the latter that the methods,
www.neerajbooks.com
components and their interaction are needed. They are
largely used during the process of design and are used
to represent the design or design decisions. For a
function oriented design, the design can be graphically
or mathematically represented as follows:
1. Data Flow Diagram
2. Data Dictionaries
3. Structure Chart
4. Pseudo code.
They are described below:
Data Flow Diagram (DFD): As information
moves through software, it is modified by a series of
transformations. A data flow diagram is a graphical
representation that depicts the information flow and
transforms that are applied as data move from input to
output. A data flow diagram provides a visual
representation of the data flow. Users can see where
and when the data and information can be accessed at
various stages of its life cycle.
A DFD will tell about what data will be input and
output to the system. It will also tell about where the
data is stored and where it comes from and goes to that
is it will tell about all the movement of data in the system.
www.neerajbooks.com
Let us understand the data flow diagram with the
help of an example of student result management. The
problem statement of the student result management is
as follows:
“A university conducts a 4-semester M.Tech.(IT)
program. The students are offered four theory papers
and two Lab papers (practicals) during 1st, 2nd and 3rd
semesters. The theory papers offered in these semesters
are categorized as either ‘Core’ or ‘Elective’. Core
papers don‘t have an alternative subjects whereas
elective papers have two other alternative subjects. Thus
a student can study any subject out of three choices
available for an elective paper. In 1st, 2nd and 3rd
semesters 2 core and 2 elective papers are offered to
each student. In 4th semester the students have to give
a seminar and submit a dissertation on a topic/subject
area of their interest.
Every subject has some credit points assigned to it.
If the total marks of a student are >=50 in a subject, he/
she is considered ‘Pass’ in that subject otherwise the
student is considered ‘Fail’ in that subject. If a student
passes in the subject, he/she earns all the credit points
assigned to that subject. It is required to develop a system
that will manage information about subjects offered in
various semesters, students enrolled in various
semesters, elective(s) opted by students, marks and
credit points obtained by students in different semesters.
The system will also generate printable mark sheets for
each student.”
 www.neerajbooks.com

The context diagram for the above problem is given below:

Source: www.itprofessionalsrocks.blogspot.com
The persons that are interacting with the student result management are administrator, marks entry operator,

Neeraj
data entry operator and coordinator.
The level-1 DFD gives a detailed description of the flow of data in the system which is given below:

Publications
www.neerajbooks.com

Source: www.itprofessionalsrocks.blogspot.com

www.neerajbooks.com
 www.neerajbooks.com

The level 2 DFD’s gives a detailed flow of every function that is there in the system and can be represented as follows:

Neeraj
Source: www.itprofessionalsrocks.blogspot.com
Here is an example of data
dictionary. Consider the following

Publications
problem statement
“The business is a sweet factory
called ‘ABC’. The business buys raw
ingredients from several suppliers and
keeps a monthly record of the purchases.

www.neerajbooks.com ABC has several employees who

prepare the ingredients or make sweets
in three of the company’s departments.
The products are sold to a number of
retail stores, and the sales are recorded
in an inventory on a monthly basis. The
company would like to keep track of
purchases of raw ingredients and their
suppliers as well as employees and their
wages. The employees specialize in
different area of the sweet
manufacturing process and have
Source: www.itprofessionalsrocks.blogspot.com
different job descriptions. The company
Similarly the rest of the DFD’s can be drawn. sells their products to a number of
Data Dictionary: Data dictionary is a set of meta-data which different retailers in various cities. They
contains the definition and representation of data elements. It gives a would like to keep track of this
single point of reference of data repository of an organization. Data information. Company will also like to
dictionary lists all data elements but does not say anything about keep track of the value and fate of sales
relationships between data elements. The information that is stored in and purchases as well as who bought or
data dictionary includes name of the data item, aliases (other names for sold what to them. They would also like
items), description/Purpose, related data items, range of values and data to keep track of where employees live
Structure definition/form. with the aim of letting go of employees
who live too far away.”

www.neerajbooks.com
 www.neerajbooks.com

Neeraj
Publications
www.neerajbooks.com

www.neerajbooks.com
 www.neerajbooks.com

Structure Chart: It is the most commonly used method for system design. It is a chart which shows the
breakdown of the system to its lowest manageable levels. It is a top-down modular approach in which the root is the
entire system which is then broken into smaller modules highlighting each functionality which are further broken
till the lowest level is reached. Structure chart can be explained with the help of the following example:

Neeraj
Publications
www.neerajbooks.com
Here the main system is to process the customer
transaction. Then the structure chart is broken down in
several levels to give the detail how the transaction of a
customer is being processed.
Pseudo Code: “Pseudo” means imitation or false
and “Code” means the instructions written in a
programming language. Its notation can be used both
in the preliminary and detailed design phases. Using it,
the designer describes the system characteristics using
Advantages of Pseudo Code
short, concise, English language phrases that are
structured by the key words such as If-Then-Else, While-
Do and End. Flow of control is described by the
indentation and keywords whereas the processing
actions are described by the English phrases.
Pseudo code is also known as program design
language or structure English. It should have the
following characteristics:
A fixed syntax of keywords that provide for
all structure constructs data declarations and
modularity characteristics.
A free syntax for natural language that
describes processing feature.
Data declaration facility
Calling technique and definition of sub-
routine.
1. Conversion of pseudo code to a programming
language is easier.
2. Easy to modify the pseudo code of program
logic whenever modifications are to be made.
3. Less time and effort consuming.
4. It is easy to write as it is methods that has only
few rules to follow.

www.neerajbooks.com
 www.neerajbooks.com

Disadvantages of Pseudo Code (4) Information hiding.

1. A graphic representation is not available. These are explained below:
2. No standard rules to follow in using a pseudo Coupling: It is the measure of degree of
code. independence between modules. Two modules with high
3. For beginners it’s difficult to write a pseudo coupling are strongly interconnected to each other that
code as compared to drawing a flow chart. is they are dependent on each other and the systems
VISUALIZING THE SOLUTION which have these modules are known as “highly coupled
The function oriented problem can be visualized systems” whereas two modules that are independent of
as the functional procedure layers. Here, we will tell at each other are “loosely coupled”. Modules that are
what level what tasks are being performed. The completely independent of each other are called as
functional procedure layers are as follows: “uncoupled”. They are shown diagrammatically below:
1. Functions are built in layers; additional notations
are used to specify details.
2. Level 0
Mention the function or procedure name.
What is its relationship to other system
components (e.g., part of which system, called
by which subroutine, etc.)

Neeraj
A brief description of the function’s purpose
is mentioned.
Author’s name and date is mentioned.
3. Level 1
Here, function parameters are being defined

Publications
(i.e. problem variables, types, purpose, etc.)
Global variables are declared (i.e. problem
variable, type, purpose, sharing information
etc.)
Loosely Coupled Highly Coupled
What routines are called by the functions is

www.neerajbooks.com
mentioned.
Mention the side effects.
Mention all the input/output assertions.
A good design will have low coupling. It is
measured by the number of interconnections between
the modules. It increases with the number of calls
4. Level 2
between modules increases, or the amount of shared
Local data structures (variables etc.)
Timing constraints data increases. High coupled systems will have high
Exceptional handling is done (i.e. conditions, error rate. Loose coupling on the other hand minimizes
responses, events) the interdependence amongst modules. This is achieved
Any other limitation is told. in the following ways:
5. Level 3 Controlling the number of parameters passed
Body is defined (i.e. structured chart, pseudo amongst modules.
code, decision tables, flow charts, etc.) Avoid passing undesired data to calling
CHARACTERISTICS OF A GOOD FUNCTION module.
ORIENTED DESIGN Maintain parent/child relationship between
Some of the characteristics of a good function calling and called module.
oriented design are: Pass data, not the control information.
(1) Cohesion Types of Coupling: There are six types of coupling.
(2) Coupling They are coupled in number of ways depending on two
(3) Function independence procedures A and B:

www.neerajbooks.com
 www.neerajbooks.com

1. Data Coupling: The dependency between 4. External Coupling: It is a form of coupling in

module A and B is said to be data coupled if it is based
on the fact that they communicate by only passing of
data and other than that they are independent. A good
strategy is to ensure that no module communication
contains “tramp data”. Module dependency can be
minimized by ensuring only necessary data is being
communicated between modules.
2. Stamp Coupling: When complete data structure
is passed from one module to another say from module
A to B, stamp coupling occurs. Stamp coupling involves
tramp data that is if one procedure only needs a part of
a data structure, calling module should pass just that
part and not the complete data structure.
3. Control Coupling: Module A and B are said to
be control coupled if they communicate by passing of
control information. It is accomplished by means of flags
that are set by one module and reacted upon by the
which a module has a dependency to the other module,
external to the software being developed or to a
particular type of hardware. It is basically related to the
communication to the external tools and devices.
5. Common Coupling: In this type of coupling,
the modules have a shared data. Global data areas are
commonly found in programming languages. Making a
change to the common data means that to go back to all
the modules accessing that data and evaluating the effect
of change. With this, it is difficult to determine which
module is responsible for having set of variable to a
particular value. How it works is shown below
diagrammatically:

Neeraj
dependent module.

Publications
www.neerajbooks.com
6. Content Coupling: It occurs when module A changes data of module B or when control is passed from one
module to the middle of another. This is shown below:

Module B A

Go to Temp
B C
Module D
E
Go to temp D

Temp

www.neerajbooks.com
 www.neerajbooks.com
Cohesion: It is a measure of the degree to which the elements of a module are functionally related. A strong
cohesive module implements functionality that is related to the solution and requires little or no interaction with the
other module. This is shown below:
Neeraj
Cohesion may be viewed as glue that binds the
modules together. The goal is to maximize the module
cohesion and minimize the module coupling.
Types of Cohesion
Publications
There are seven types of cohesion that are described
between two operations X and Y of a procedure. They
are:
1. Functional Cohesion: X and Y are part of single
www.neerajbooks.com
functional task. This is the reason for them to be
contained in the same procedure. This module
transforms a single input datum into a single output
datum. For example, ‘calculate current GPA’ or
‘cumulative GPA’.
2. Sequential Cohesion: X outputs some data
which is the input to Y and for this reason they are
combined in one procedure. For example, addition of
marks of individual subject is treated as the input for
calculating the percentage for preparing the result of
students. A component is made of parts that need to
exchange data from one source for different functional
purposes. They are together in a component for
communicational convenience.
3. Communicational Cohesion: X and Y both
operate on the same input data or contribute towards
the same output data.
4. Procedural Cohesion: X and Y are both
structured in same way. Thus procedural cohesion occur
in modules whose instructions in spite performing
www.neerajbooks.com
different tasks are combined together because there is a
specific order in which the tasks must be completed.
Since modules consist of instructions that accomplish
several tasks that are virtually unrelated the modules
tend to be less maintainable.
5. Temporal Cohesion: X and Y both must perform
around the same time. Temporal cohesion is exhibited
when it contains tasks that are related by the fact that all
tasks must be executed in the same time span. The set
of functions responsible for initialization, start up
activities or control flags associated with programs
exhibit temporal cohesion.
6. Logical Cohesion: X and Y perform logically
similar functions. Thus, logical cohesion occurs in
modules where instructions that appear to be related
fall into the same logical class of functions. Duplication
can exist in the logical strength level.
7. Coincidental Cohesion: X and Y are having no
other conceptual relationship except for shared code.
Therefore this type of cohesion occurs in modules that
contain instructions that have little or no relationship to
one another. That is instead of creating two components
each for one part; only one component is made with
two unrelated parts. It is avoided as far as possible.
Functional Independence: The concept of
functional independence is a direct outcome of
modularity and the concepts of abstraction and
information hiding. Refinement techniques enhance
module independence.
 www.neerajbooks.com
Functional independence is achieved by
developing modules with “single minded” function and
an “aversion” to excessive interaction with other
modules. The software is designed such that each
module addresses a specific sub-function of
requirements and has a simple interface when viewed
from other parts of the program structure. Such
independence is important. Software with effective
modularity (i.e., independent modules), is easier to
develop because function may be compartmentalized
and interfaces are simplified. Independent modules are
easier to maintain (and test) because secondary effects
caused by design/code modification are limited, error
propagation is reduced, and reusable modules are
possible. Thus, functional independence is a key to good
design, and design is the key to software quality.
Independence is measured using two qualitative-
criteria cohension and coupling. Cohesion is a measure
of the relative functional strength of a module. Coupling
Neeraj
is a measure of relative interdependence among the
modules.
Information Hiding: The concept of modularity
leads every software designer to a fundamental question
: “How do we decompose a software solution to obtain
the best set of modules ?” The principle of information
Publications
hiding suggests that modules be “characterized by
design decisions that (each) hides from all others.” In
other words, modules should be specified and designed
so that information (procedure and data) contained
within a module is inaccessible to other modules that
www.neerajbooks.com
have no need for such information.
Hiding implies that effective modularity can be
achieved by defining a set of independent modules that
communicate with one-another only that information
that is necessary to achieve software function.
Abstraction helps to define the procedural entities that
comprise the software. Hinding defines and enforces
access constraints to both procedural detail within a
module and any local data structure by the module.
The use of information hiding as a design criterion
for modular systems provides its greatest benefits when
modifications are required during testing and later,
during software maintenance. Because most data and
procedure are hidden from other parts of the software,
inadvertent errors introduced during modification are
less likely to affect other locations within the software.
Q. 1. What is partitioning? Explain briefly.
Ans. A large system cannot be handled as a whole,
and so for design it is partitioned into smaller systems.
www.neerajbooks.com
This partitioning process can continue further till we
reach a stage where the components are small enough
to be designed separately. This divide and conquer
method is essential for handling large projects and all
design methodologies provide methods to partition the
problem effectively.
Q. 2. What is abstraction?
Ans. Abstraction is a concept related to problem
partitioning. When it is used during design, the design
activity focuses on one part of the system at a time.
Since the part being designed interacts with other parts
of the system, a clear understanding of the interaction
is essential for properly designing the part. An
abstraction of a system or a part defines the overall
behaviour of the system at an abstract level without
giving the internal details. While working with a part of
the system, a designer needs to understand only the
abstractions of the other parts with which the part being
designed interacts. The use of abstraction allows the
designer to practice the divide and conquer technique
effectively by focusing on one part at a time, without
worrying about the details of other parts.
Q. 3. Explain DFD along with its use in software
development?
Ans. Data Flow Diagram: As data goes through
software, it is modified by a series of transformations.
A Data Flow Diagram (DFD) is a graphical technique
that depicts information flow and the transforms that
are applied as data move from input to output. The basic
form of a data flow diagram is shown in Figure (a). The
DFD is also known as a data flow graph or a bubble
chart.
The data flow diagram is used to represent a
system or software at any level of abstraction. DFDs
may be partitioned into levels that represent increasing
information flow and functional detail. Therefore, the
DFDs provides a mechanism for functional modeling
as well as information flow modelling. In so doing, it
satisfies the second operational analysis principle (i.e.,
creating a functional model).
A level 0 DFD, also called a fundamental system
model or a context model, represents the entire software
element as a single bubble with input and output data
indicated by incoming and outgoing arrows,
respectively. Additional processes (bubbles) and
information flow paths are presented as the level 0.
 www.neerajbooks.com

Figure (a) : Information flow refinement

Neeraj
Publications
Figure (b) : Information flow model

A producer or consumer of information that resides outside the bounds

www.neerajbooks.com
of the system to be modelled

A transformer of information (a function) that resides within the bounds

of the system to be modelled.

A data object; the arrowhead indicates the direction of data flow

A repository of data that is to be stored for use by one or more processes;

may be as simple as a buffer or queue or as sophisticated as a relational
database
Figure (c) : Basic DFD notation

DFD is a partitioned to reveal more detail. For example, a level 1 DFD might contain five or six bubbles with
interconnecting arrows. Each of the processes represented at level 1 are sub-functions of the overall system.
The basic notation used in a DFD is shown in Figure (c). A rectangle is used to represent an external entity,
that is, a system element (e.g., hardware, a person, another program) or another system that produces information
for transformation by the software or receives information produced by the software. A circle represents a process
or transform that is applied to data (or control) and changes it in some way. An arrow represents one or more data
items or data objects. All arrows on a data flow diagram are labelled. The double line represents a data store–stored

www.neerajbooks.com
 www.neerajbooks.com
information that is used by the software. The simplicity
of DFD notation is one reason why structured analysis
techniques are the most widely used.
No explicit indication of the sequence of
processing is supplied by the diagram. Each of the
bubbles may be refined or layered to depict more detail.
A fundamental model for system P indicates the primary
input is A and ultimate output is B. The model is refined
into transforms P1 to P7 information flow continuity is
maintained, that is, input and output to each refinement
remain the same. This concept, sometimes called
balancing, is essential for the development of consistent
models.
The data-flow diagram is a valuable graphical tool
during software requirements analysis. However, its
function should not be confused with the flowchart. A
data-flow diagram depicts information flow without
explicit representation of procedural logic (e.g.,
conditions or loops). It is not a flowchart.
Neeraj
Q. 4. What do you mean by data dictionary?
Explain briefly.
Ans. The Data Dictionary: The analysis model
includes representations of data objects, functions and
control. In each representation, data objects and/or
Publications
control items play a role. An organized approach for
representing the characteristics of each data object and
control item is done by the data dictionary.
The data dictionary is a quasi-formal grammar
for describing the content of objects defined during
www.neerajbooks.com
structured analysis. This important modelling notation
is defined in the following way:
The data dictionary is an organized listing of all
data elements that are pertinent to the system, with pre-
cise, rigorous definitions so that both user and system
analyst will have a common understanding of inputs,
outputs, components of stores and (even) intermediate
calculations.
Today, the data dictionary is almost always im-
plemented as part of a CASE “structured analysis and
design tool.” Although, the format of dictionaries varies
from tool to tool, most have the following information:
— name—the primary name of the data or control
item, the data store, or an external entity
— alias—other names used for the first entry
— where-used/how-used—a listing of the proc-
esses that use the data or control items and how
it is used (e.g., input to the process, output from
the process, as a store, as an external entity)
— content description—a notation for represent-
ing content
www.neerajbooks.com
— supplementary information—other information
about data types, present values (if known),
restrictions or limitations, etc.
Once a data object or control item name and its
aliases are entered into the data dictionary consistency
in name can be enforced. That is, if an analysis team
member decides to name derived data item xyz, but xyz
already in the dictionary, the CASE tool supporting the
dictionary posts warning to indicate duplicate names.
This improves the consistency of the analysis model
and helps to reduce errors.
“Where-used/how-used” information is recorded
automatically from the flow models. When a dictionary
entry is created, the CASE tool scans DFDs and CFDs
to determine which processes use the data or control
information and how it is used. It is one of the most
important benefits of the dictionary.
The data dictionary defines information items
unambiguously. For large computer-based systems the
data dictionary grows rapidly in size and complexity.
In fact, it is extremely difficult to maintain a dictionary
manually. For this reason, CASE tools are used.
Q. 5. List the steps for creating a Data Flow
Diagram?
Ans. Creating a Data Flow Model: The Data Flow
Diagram (DFD) helps the software engineer to develop
models of the information domain and functional
domain at the same time. As the DFD is refined into
greater levels of detail, the analyst performs an implicit
functional decomposition of the system, thereby
accomplishing the fourth operational analysis principle.
The DFD refinement also results in a corresponding
refinement of data as it moves through the processes
that embody the application.
Guidelines that can help during derivation of a
data-flow diagram are :
(1) The level 0 data-flow diagram should depict
the software/system as a single bubble;
(2) Primary input and output should be carefully
noted;
(3) Refinement should begin by isolating
candidate processes, data objects and stores
to be represented at the next level;
(4) All arrows and bubbles should be labeled
with meaningful names;
(5) Information flow continuity must be
maintained from level to level; and
(6) One bubble at a time should be refined.
Information flow continuity is maintained between
levels 0 and 1. The processes represented at DFD level
1 can be further refined into lower levels.
 www.neerajbooks.com
The refinement of DFDs continues until each
bubble performs a simple function, that is, until the
process represented by the bubble performs a function
that would be easily implemented as a program compo-
nent. Cohension, that can used to assess the simplicity
of a given function.
Q. 6. What is a pseudo code?
Ans. Pseudo code is a detailed yet readable
description of what a computer program or algorithm
must do, expressed in a formally-styled natural language
rather than in a programming language. Pseudo code is
sometimes used as a detailed step in the process of
developing a program. It allows designers or lead
programmers to express the design in great detail and
provides programmers a detailed template for the next
step of writing code in a specific programming language.
Because pseudo code is detailed yet readable, it
can be inspected by the team of designers and
Neeraj
programmers as a way to ensure that actual
programming is likely to match the design specifications.
Finding errors in the pseudo code stage is less costly
than finding them later in the development process. Once
the pseudo code is accepted, it is rewritten using the
Publications
vocabulary and syntax of a programming language.
Pseudo code is sometimes used in conjunction with
computer-aided software engineering-based
methodologies.
www.neerajbooks.com
* * * * * * * *
Moderate levels of cohesion are relatively close
to one-another in the degree of module independence.
When processing elements of a module are related and
must be executed in a specific order, procedural
cohesion exists. When all processing elements
concentrate on one area of a data structure,
communicational cohesion is present. High cohesion
is characterized by a module that performs one distinct
procedural task.
It is unnecessary to determine the precise level of
cohesion. Rather it is important to strive for high
www.neerajbooks.com
It is possible to write programs that will convert a
given pseudo code language into a given programming
language.
Q. 7. What is cohesion?
Ans. Cohension is natural extension of the
information hiding concept. A cohesive module
performs a single task within a software procedure,
requiring little interaction with procedures being
performed in other parts of a program. Stated simply, a
cohesive module does just one thing.
Cohension can be shown as a “spectrum” as in
Figure. We always strive for high cohension, although
the mid-range of the spectrum is often acceptable. The
scale of cohesion is non-linear. That is, low-end
cohesiveness is much “worse” than the middle range,
which is nearly as “good” as high-end cohension. In
practice, a designer need not be concerned with
categorizing cohension in a specific module. Rather, the
overall concept should be understood and low levels of
cohension should be avoided when modules are
designed.
A module that performs a set of tasks that relate
to each-other loosely, if at all, is termed coincidentally
cohesive. A module that performs tasks that are related
logically (e.g., a module that produces all output
regardless of type) is logically cohesive. When a module
contains tasks that are related by the fact that all must
be executed within the same span of time, the module
exhibits temporal cohesion.
* * * * * * * * * * * *
Fig. : Cohesion
cohension and recognize low cohesion so that software
design can be modified to achieves greater functional
independence.
Q. 8. What is coupling?
Ans. Coupling is a measure of interconnection
among modules in a program structure. Like cohesion,
coupling may be represented on a spectrum as shown
in Figure (a). Coupling depends on the interface
complexity between modules, the point at which entry
or reference is made to a module, and what data pass
across the interface.
 www.neerajbooks.com
* * * * * * * * * *
Neeraj
Publications
In software design, we strive for lowest possible
coupling. Simple connectivity among modules results
in software that is easier to understand and less prone
www.neerajbooks.com
to a “ripple effect” caused when error at one location
and propagate through a system.
Figure (a) shows examples of different types of
module coupling. Modules a and d are sub-ordinate to
different modules. Each is unrelated and therefore no
direct coupling occurs. Module c is subordinate to
module a and is accessed via a conventional argument
list through which data are passed. As long as a simple
argument list is present (i.e., simple data are passed; a
one-to-one correspondence of items exists), low
coupling (data coupling on the spectrum) is exhibited
in this portion of structure. A variation of data coupling,
called stamp coupling, is found when a portion of a data
structure is passed via a module interface. This occurs
between modules b and a.
At moderate levels coupling is characterized by
passage of control between modules. Control coupling
www.neerajbooks.com
* * * * * * * * * *
Fig. (a) : Coupling
Figure (b) : Types of coupling
is very common in most software designs and is shown
in Figure (b), where a “control flag” (a variable that
controls decisions in a sub-ordinate or superordinate
module) is passed between modules d and e.
Relatively high levels of coupling occur when
modules are tied to an environment external to software.
Diagnosing problems in structures with considerable
common coupling is time-consuming and difficult.
However, this does not mean that the use of global data
is necessarily “bad.” It does mean that a software
designer must be global data is necessarily “bad.” It
does mean that a software designer must be aware of
potential consequences of common coupling and take
special care to guard against them.
The highest degree of coupling, content coupling,
occurs when one module makes use of data or control
information maintained within the boundary of another
module. Secondarily, content coupling occurs when
branches are made into the middle of a module. This
mode of coupling can and should be avoided.
 www.neerajbooks.com
Q. 9. What is Functional Independence?
Ans. Functional Independence: The concept of
functional independence is a direct outcome of
modularity and the concepts of abstraction and
information hiding. Refinement techniques enhance
module independence.
Functional independence is achieved by
developing modules with “single minded” function and
an “aversion” to excessive interaction with other
modules. The software is designed such that each
module addresses a specific sub-function of
requirements and has a simple interface when viewed
from other parts of the program structure. Such
independence is important. Software with effective
Neeraj
Publications
www.neerajbooks.com
www.neerajbooks.com
modularity (i.e., independent modules), is easier to
develop because function may be compartmentalized
and interfaces are simplified. Independent modules are
easier to maintain (and test) because secondary effects
caused by design/code modification are limited, error
propagation is reduced, and reusable modules are
possible. Thus, functional independence is a key to good
design, and design is the key to software quality.
Independence is measured using two qualitative-
criteria cohension and coupling. Cohesion is a measure
of the relative functional strength of a module. Coupling
is a measure of relative interdependence among the
modules.
 www.neerajbooks.com

Object Oriented Design

Object oreinted technique allows users to
understand the overall environment which they are
attempting to model. Indentifying the components of
the environment and detailing the relationship that exists
between them helps to achieve this aim. Object oriented
models are very useful for understanding problems,
5
3. Identifying the objects and their attributes.
4. Identifying the services that each object in
expected to provide.
5. Establishing inter connections between the
objects in terms of services required and services
rendered.

Neeraj
communicating with application experts, modelling
enterprises, preparing documentation and designing
programs.
To describe the system, the OMT methodology uses
three kinds of models–Object Model, Dynamic model

Publications
and Functional model.
In this system, the object model describe the
structure of an object, their identity their relationships
to other objects, their attributes and their operations.
To design a system, the object model provides the

www.neerajbooks.com
essential framework into which the dynamic and
functional model can be placed.
In this chapter, we mainly describe the object
modelling technique which is the part of analysis
system. We also describe the relationship among these
models.

IDENTIFICATION AND SPECIFICATION Problem Understanding: The first step in the

PROBLEM DOMAIN STATIC OBJECTS
Object oriented analysis provides us with a simple,
powerful mechanism for identifying objects building
block of the software to be developed. The analysis is
basically concerned with the decomposition of a
problem into its component parts and establishing a
logical model to describe the system functions.
The object oriented analysis approach consists of
the following steps:
1. Understanding the problem.
2. Drawing the specification of requirements of the
user and the software.
analysis process is to understand the problem of the user.
The problem statement should be refined in terms of
computer system engineering that could suggest a
computer based solution. The problem statement should
be stated, as far as possible, in a single grammatically
correct sentences. The problem statement provides the
basis for drawing the requirements specification of both
the user and the software.
Requirements Specification: Once the problem is
clearly defined, the next step is to understand what the
proposed system is required to do. It is important at this
stage to generate a list of user requirements. A clear

www.neerajbooks.com
 www.neerajbooks.com

understanding should exist between the user and the
developer of what is required. Based on the user
requirements, the specification for the software should
be drawn. The developer should state clearly:
What outputs are required?
What processes are involved to produce these
outputs?
What inputs are necessary?
What resources are required?
These specification often serve as a reference to
test the final product for its performance of the intended
tasks.
Identification of Objects: Objects can often be
identified in terms of the real world objects as well as
the abstract objects. Therefore, the application may be
analyzed by using one of the following approaches:
(i) Data Flow Diagrams (DFD).
(ii) Textual Analysis (TA).
Data Flow Diagrams: The application can be
For example, a car can be described as an object
and it has sub-components of which engine is one. The
engine can also be described as an object comprised of
other objects.
Classes: A class describes group of objects with
some properties (data structure or attributes), common
behaviour (methods or operations) common relation-
ships to other objects and common semantics.
For example, mango, apple and orange are member
of the class fruit.
Object Diagrams: The object modelling concept
basically based on the objects and classes. For
describing the concept, we need a formalism for
expressing object model that is coherent precise and
easy to formulate.
There are two types of object diagrams:
(i) Class diagram.
(ii) Instance diagram.

Neeraj
Class Diagram: To describe the classes in a
represented in the form of a data flow diagram indicating graphical notations, we use class diagrams. A class
how the data moves from one point to another is the diagram is a schema pattern, or template for describing
system. many possible instances of data.
Textual Analysis: This approach is based on the
textual description of the problem or proposed solution.

Publications
The description may be one or two sentences or one or
two paragraphs depending on the type and complexity
of the problem.
Identification of Services: Once the object in the
solution space have been identified, the next step is to

www.neerajbooks.com
identify a set of services that each object offer. Services
are identified by examining all the verbs and verb
phrases is the problem description statement.
Working out the Application Logic Objects:
Graphical notations are an essential part of any design Instance Diagram: The graphical representation
and development process and object oriented design is of object of a class can be denoted by instance diagrams.
no exception. We need notations to represent classes An instance diagram describes how a particular set of
objects, sub-classes and their inter-relationships. objects relates to each other.
Objects and Classes: The Object modelling is The OMT symbol for an instance is a rounded box.
based on these two concepts-objects and class. The The class name is parentheses is at the top of the object
objects correspond to real world entities and classes are
box is bold face.
the collection of the similar objects or entities.
Objects: An object is a concept, abstraction or a
real world thing with strict boundaries and meaning for
an applications.
The concept of an object provides two basic
purposes in the system:
The objects provides understanding of the real Links and Association: Links and associations are
worlds. the means for building the relationships among the
The objects provides a practical basis for objects and classes.
computer implementation.

www.neerajbooks.com
 www.neerajbooks.com
Links: In the object modelling links provides a
relationship between the objects. These objects or
instance may be same or different in data structure and
behaviour.
For example, Ram works for IBM company. In this
example, “Works - for” is the link between “Ram” and
“IBM Company”. We can use this example also, Ram
is employee of IBM Company. Here, employee is used
as a link between Ram and IBM Company.
Associations: The object modelling describes as a
group of links with common structure and common
semantics. All the links among the object are the forms
of association among the same classes.
For example, Ram works for IBM Company here
Ram is an object of person class and IBM Company is
the object of Company class and here the relationship
Neeraj
called links.
But ‘Person works for company’ in this example.
Publications
Person and company both are classes, thus, the
relationship between them is called association.
Aggregation: The aggregation is an extention of
association mean aggregation is a strong form of
www.neerajbooks.com
association in which an aggregate object is made of
components. Components are part of the aggregate. Thus
aggregation is the “part-whole” or “a-part of”
relationships. For eg., keyboard is a part of computer
or we can say keys are part of keyboard.
IDENTIFICATION OF NECESSARY
UTILITY OBJECTS
The object design phase determines the full
definitions of the classes and associations used in the
implementation, as well as the interfaces the algorithms
of the methods used to inplement operations. The object
design phase adds internal objects for implementation
and optimize data structure and algorithms.
During the object design phase, the designer must
perform the following steps for identification for utility
objects:
(i) Grouping the Three Models: After completion
of analysis phase, we have the three models: Object
Model, Dynamic Model and Functional Model but the
object is the main framework around which the design
is constructed.
www.neerajbooks.com
(ii) Designing Algorithms: Each operation from
the analysis model must be assigned an algorithm that
implements it clearly and efficiently, according to the
optimization goals selected during system design.
The designer of algorithms must:
Choose algorithms that minimize the cost of
inmplementing operations.
Define a new internal classes and operation as
neccassry.
Select data structures appropriate to the
algorithms.
(iii) Design Optimization: We optimize the model
which is made with the help of system design and
analysis. During the design optimization, the designer
must:
Add redudant associations to minimize access
cost and maximize convenicence of accessing.
Rearrange the computation for greater
efficiency and rearrange the order of execution
of appropriate algorithm.
(iv) Design of Associations: Association provides
access paths between objects. There are conceptual
entities useful for modelling and analysis. Association
subsume many implementation technique under a single
uniform notation during analysis but they can be
implemented as painters with in objects or distinct
objects depending on their access patterns.
(v) Object Representation: Classes can be defined
Interms of other classes, but everything must be
implemented in terms of built in primitive data types.
Supplied by the programming language. Some classes
can be combined.
(vi) Physical Packaging: Programs are mode of
discreate physical units that can be edited, compiled,
imported or otherwise manipulated. Object oriented
languages have various degrees of packaging.
Packaging involves the following issues:
Hiding internal information from outside view.
Coherence of entities.
Constructing physical modules.
METHODOLOGY OF IDENTIFICATION
OF OBJECTS
There are several popular software engineering
approaches for developing the softwares. The current
object oriented design methodologies are subjective and
informal. These methodologies suggest a few guidelines,
leaving the exact application of the design procedure
largely to the discretion of the designer.
(i) A Generic Object Oriented Development
Paradigm: Identification of objects and their attributes
 www.neerajbooks.com
is the first step in any object oriented design approach.
Our generic object oriented program development
paradigm consists of the following main steps:
1. Develop an informal solution strategy by
studying the problem description.
2. Identify the different objects and functions
needed to implement the system by analyzing the
extended problem description.
3. Map the methods identified in step to appropriate
objects.
4. Identify the data associated with each of the
identified objects.
5. Determines the class hierarchies.
6. Identify other relationship existing among objects
such as reference composition and association.
7. Determine how the client classes will use the
services of the server class i.e. specify the object
interfaces.
8. Representation the design using a popular
Neeraj
graphical relation.
9. Implement all objects.
10. All objects of the systems are integrated and
the system is tested against its requirements.
(ii) Object Identification: One of the most
Publications
important steps in any object oriented design
methodology is the identification of objects infact the
quality of the final design depends to a great extent on
the appropriateness of the object identified. However,
no formal methodology exists for identification of
www.neerajbooks.com
objects. These can be classified into the following broad
classes:
Grammatical analysis of the problem
description.
Derivation from data flow.
Derivation from the entity relationship diagram.
The identification approaches based on derivation
from the data flow diagram and entity relationship model
are still being evolved.
(iii) Booch’s Object Identification Method:
Booch’s object identification requires a processing
narrative of the given problem to be first developed.
The processing narrative describes the problem and
discusses how it can be solved. The objects are identified
by noting down the nouns in the processing narrative. A
potential object found after lexical analysis is usually
considered legitimate only if it satisfies the following
criteria:
Retained Information: Some information about
the object should be remembered for the system to
function.
www.neerajbooks.com
Multiple Attributes: Usually objects have multiple
attributes and support multiple methods. It is very rare
to find useful objects which store only a single data
element or support only a single method because an
object having only a single data element or method is
usually implemented as the part of another object.
Common Operations: A set of operations can be
defined for the potential objects. If these operations
apply to all occurrences of the object then we can define
a class. An attribute or operation defined for a class
must apply to each instances of the class. If some of the
attributes or operations apply only to some specific
instances of the class, then we need to have one or more
sub-classes for these special objects.
CASE STUDIES
The software to be designed will control a simulated
Automated Teller Machine (ATM) having a magnetic
stripe reader for reading an ATM card, a customer
console (keyboard and display) for interaction with the
customer, a slot for depositing envelopes, a dispenser
for cash (in multiples of $ 20), a printer for printing
customer receipts, and a key-operated switch to allow
an operator to start or stop the machine. The ATM will
communicate with the bank’s computer over an
appropriate communication link. (The software on the
latter is not part of the requirements for this problem.)
The ATM will service one customer at a time. A
customer will be required to insert an ATM card and
enter a Personal Identification Number (PIN) – both of
which will be sent to the bank for validation as part of
each transaction. The customer will then be able to
perform one or more transactions. The card will be
retained in the machine until the customer indicates that
he/she desires no further transactions, at which point it
will be returned – except as noted below:
The ATM must be able to provide the following
services to the customer:
1. A customer must be able to make a cash
withdrawal from any suitable account linked to the card,
in multiples of $ 20.00. Approval must be obtained from
the bank before cash is dispensed.
2. A customer must be able to make a deposit to
any account linked to the card, consisting of cash and/
or checks in an envelope. The customer will enter the
amount of the deposit into the ATM, subject to manual
verification when the envelope is removed from the
machine by an operator. Approval must be obtained from
the bank before physically accepting the envelope. A
customer must be able to make a transfer of money
between any two accounts linked to the card.
 www.neerajbooks.com
A customer must be able to make a balance inquiry
of any account linked to the card. A customer must be
able to abort a transaction in progress by pressing the
Cancel key instead of responding to a request from the
machine.
The ATM will communicate each transaction to the
bank and obtain verification that it was allowed by the
bank. Ordinarily, a transaction will be considered
complete by the bank once it has been approved. In the
case of a deposit, a second message will be sent to the
bank indicating that the customer has deposited the
envelope. (If the customer fails to deposit the envelope
within the time-out period, or presses cancel instead,
no second message will be sent to the bank and the
deposit will not be credited to the customer.)
If the bank determines that the customer’s PIN is
invalid, the customer will be required to re-enter the
PIN before a transaction can proceed. If the customer
is unable to successfully enter the PIN after three tries,
Neeraj
the card will be permanently retained by the machine,
and the customer will have to contact the bank to get it
back. If a transaction fails for any reason other than an
invalid PIN, the ATM will display an explanation of the
problem, and will then ask the customer whether he/she
wants to do another transaction.
Publications
Use Cases for Example ATM System
www.neerajbooks.com
www.neerajbooks.com
The ATM will provide the customer with a printed
receipt for each successful transaction, showing the date,
time, machine location, type of transaction, account(s),
amount and ending and available balance(s) of the
affected account (“to” account for transfers).
The ATM will have a key-operated switch that will
allow an operator to start and stop the servicing of
customers. After turning the switch to the “on” position,
the operator will be required to verify and enter the total
cash on hand. The machine can only be turned off when
it is not servicing a customer. When the switch is moved
to the “off” position, the machine will shut down, so
that the operator may remove deposit envelopes and
reload the machine with cash, blank receipts, etc.
The ATM will also maintain an internal log of
transactions to facilitate resolving ambiguities arising
from a hardware failure in the middle of a transaction.
Entries will be made in the log when the ATM is started
up and shut down, for each message sent to the Bank
(along with the response back, if one is expected), for
the dispensing of cash, and for the receiving of an
envelope. Log entries may contain card numbers and
dollar amounts, but for security will never contain a PIN.
 www.neerajbooks.com

Initial Functional Test Cases for Example ATM System: The following initial test cases can be identified
early in the design process as a vehicle for checking that the implementation is basically correct. No attempt has
been made at this point to do thorough testing, including all possible errors and boundary cases. That needs to come
later. These cases represent an initial check that the functionality specified by the use cases is present.
Some writers would argue for developing test cases like these in place of use cases. Here, they are presented as
a vehicle for “fleshing out” the use cases, not as a substitute for them.

Use Case Function Being Initial System Input Expected Output

Tested State
System System is started System is off Activate the “on” System requests initial
Startup when the switch is switch cash amount
turned “on”
System System accepts System is
Startup initial cash amount requesting cash Enter a legitimate System is on
amount amount
System Connection to the System has just Perform a System output should
Startup bank is established been turned on legitimate inquiry demonstrate that a
transaction connection has been

Neeraj
established to the bank
System System is shut- System is on Activate the “off” System is off
Shutdown down when the and not switch
switch is turned servicing a
“off” customer
System Connection to the System has just Verify from the bank

Publications
Shutdown bank is terminated been shutdown side that a connection to
when the system is the ATM no longer
shut down exists
Session System reads a System is on Insert a readable Card is accepted;

www.neerajbooks.com
customer’s ATM and not card System asks for entry of
card servicing a PIN
customer
Session System rejects an System is on Insert an Card is ejected;
unreadable card and not unreadable card System displays an
servicing a error screen;
customer System is ready to start
a new session
Session System accepts System is Enter a PIN System displays a menu
customer’s PIN asking for entry of transaction types
of PIN
Session System allows System is Perform a System asks whether
customer to displaying transaction customer wants another
perform a menu of transaction
transaction transaction
types
Session System allows System is Answer yes System displays a menu
multiple asking whether of transaction types
transactions in one customer wants
session another
transaction

www.neerajbooks.com
 www.neerajbooks.com

Use Case Function Being Initial System Input Expected Output

Tested State
Session Session ends when System is asking Answer no System ejects card and is
customer chooses whether customer ready to start a new
not to do another wants another session
transaction transaction
Transaction Individual types of
transaction will be
tested below
Transaction System handles an A readable card Enter an incorrect The Invalid PIN Extension
invalid PIN has been entered PIN and then is performed
properly attempt a transaction
Withdrawal System asks Menu of Choose withdrawal System displays a menu of
customer to choose transaction types transaction account types
an account to is being
withdraw from displayed
Withdrawal System asks Menu of account Choose checking System displays a menu of

Neeraj
customer to choose types is being account possible withdrawal
a dollar amount to displayed amounts
withdraw
Withdrawal System performs a System is Choose an amount System dispenses this
legitimate displaying the that the system amount of cash;

Publications
withdrawal menu of currently has and System prints a correct
transaction withdrawal which is not greater receipt showing amount
properly amounts than the account and correct updated
balance balance; System records
transaction correctly in the

www.neerajbooks.com
log (showing both
message to the bank and
approval back)

Withdrawal System verifies that System has been Choose an amount System displays an
it has sufficient cash started up with greater than what the appropriate message and
on hand to fulfill the less than the system currently has asks customer to choose a
request maximum Choose an amount different amount
withdrawal that the system
amount in cash currently has
on hand;
System is
requesting a
withdrawal
amount

www.neerajbooks.com
 www.neerajbooks.com

Use Case Function Being Initial System Input Expected Output

Tested State
Withdrawal System verifies that System is Choose an amount System displays an
customer’s balance requesting a that the system appropriate message
is sufficient to fulfil withdrawal currently has but and offers customer the
the request amount which is greater option of choosing to do
than the account another transaction or
balance not.
Withdrawal A withdrawal System is Press “Cancel” key System displays an
transaction can be displaying menu appropriate message
cancelled by the of account types and offers customer the
customer any time option of choosing to do
prior to choosing the another transaction or
dollar amount not.
Withdrawal A withdrawal System is Press “Cancel” key System displays an
transaction can be displaying menu appropriate message
cancelled by the of dollar and offers customer the
customer any time amounts option of choosing to do

Neeraj
prior to choosing the another transaction or
dollar amount not.
Deposit System asks Menu of Choose deposit System displays a menu
customer to choose transaction types transaction of account types
an account to deposit is being

Publications
to displayed
Deposit System asks Menu of account Choose checking System displays a
customer to enter a types is being account request for the customer
dollar amount to displayed to type a dollar amount

www.neerajbooks.com
deposit
Deposit System asks System is Enter a legitimate System requests that
customer to insert an displaying a dollar amount customer insert an
envelope request for the envelope
customer to type
a dollar amount
Deposit System performs a System is Insert an envelope System accepts
legitimate deposit requesting that envelope;
transaction properly customer insert System prints a correct
an envelope receipt showing amount
and correct updated
balance; System records
transaction correctly in
the log (showing
message to the bank,
approval back, and
acceptance of the
envelope)

www.neerajbooks.com
 www.neerajbooks.com

Use Case Function Being Initial System Input Expected Output

Tested State
Deposit A deposit transaction System is Press “Cancel” key System displays an
can be cancelled by displaying menu appropriate message
the customer any time of account types and offers customer the
prior to inserting an option of choosing to
envelope do another transaction
or not.
Deposit A deposit transaction System is Press “Cancel” key System displays an
can be cancelled by requesting appropriate message
the customer any time customer to enter and offers customer the
prior to inserting an a dollar amount option of choosing to
envelope do another transaction
or not.
Deposit A deposit transaction System is Press “Cancel” key System displays an
can be cancelled by requesting appropriate message
the customer any time customer to and offers customer the
prior to inserting an insert an option of choosing to

Neeraj
envelope envelope do another transaction
or not.
Deposit A deposit transaction System is Wait for the request System displays an
is cancelled requesting to time out appropriate message
automatically if an customer to insert and offers customer the

Publications
envelope is not an envelope option of choosing to
inserted within a do another transaction
reasonable time or not.

Transfer System asks customer Menu of Choose Transfer System displays a

www.neerajbooks.com
to choose an account
to transfer from
transaction types
is being
displayed
transaction menu of account types
specifying transfer
from
Transfer System asks customer Menu of account Choose checking System displays a
to choose an account types to transfer account menu of account types
to transfer to from is being specifying transfer to
displayed
Transfer System asks customer Menu of account Choose savings System displays a
to enter a dollar types to transfer account request for the
amount to transfer to is being customer to type a
displayed dollar amount
Transfer System performs a System is Enter a legitimate System prints a correct
legitimate transfer displaying a dollar amount receipt showing
transaction properly request for the amount and correct
customer to type updated balance;
a dollar amount System records
transaction correctly in
the log (showing both
message to the bank
and approval back)

www.neerajbooks.com
 www.neerajbooks.com

Use Case Function Being Initial System Input Expected Output

Tested State
Transfer A transfer transaction System is Press “Cancel” key System displays an
can be cancelled by the displaying menu appropriate message
customer any time prior of account types and offers customer
to entering dollar specifying the option of choosing
amount transfer from to do another
transaction or not.
Transfer A transfer transaction System is Press “Cancel” key System displays an
can be cancelled by the displaying menu appropriate message
customer any time prior of account types and offers customer
to entering dollar specifying the option of choosing
amount transfer to to do another
transaction or not.
Transfer A transfer transaction System is Press “Cancel” key System displays an
can be cancelled by the requesting appropriate message
customer any time prior customer to enter and offers customer
to entering dollar a dollar amount the option of choosing

Neeraj
amount to do another tran-
saction or not.
Inquiry System asks customer Menu of Choose Inquiry System displays a
to choose an account to transaction types transaction menu of account types
inquire about is being displayed

Publications
Inquiry System performs a System is Choose checking System prints a correct
legitimate inquiry displaying menu account receipt showing
transaction properly of account types correct balance;
System records

www.neerajbooks.com
transaction correctly
in the log (showing
both message to the
bank and approval
back)
Inquiry An inquiry transaction System is Press “Cancel” key System displays an
can be cancelled by the displaying menu appropriate message
customer any time prior of account types and offers customer
to choosing an account the option of choosing
to do another
transaction or not.
Invalid PIN Customer is asked to re- Enter an incorrect Customer is asked to
Extension enter PIN PIN; re-enter PIN
Attempt an inquiry
transaction on the
customer’s check-
ing account
Invalid PIN Correct re-entry of PIN Request to re- Enter correct PIN Original transaction
Extension is accepted enter PIN is being completes successfully
displayed

www.neerajbooks.com
 www.neerajbooks.com

Use Case Function Being Initial System Input Expected Output

Tested State
Invalid PIN A correctly re-entered An incorrect PIN Perform another This transaction
Extension PIN is used for has been re- transaction completes successfully
subsequent tran- entered and as well
sactions transaction
completed
normally
Invalid PIN Incorrect re-entry of Request to re- Enter incorrect PIN An appropriate message
Extension PIN is not accepted enter PIN is being is displayed and re-entry
displayed of the PIN is again
requested
Invalid PIN Correct re-entry of Request to re- Enter incorrect PIN Original transaction
Extension PIN on the second try enter PIN is being the first time, then completes successfully
is accepted displayed correct PIN the
second time
Invalid PIN Correct re-entry of Request to re- Enter incorrect PIN Original transaction

Neeraj
Extension PIN on the third try is enter PIN is being the first time and completes successfully
accepted displayed second times, then
correct PIN the
third time
Invalid PIN Three incorrect re- Request to re- Enter incorrect PIN An appropriate message

Publications
Extension entries of PIN result in enter PIN is being three times is displayed;
retaining card and displayed Card is retained by
aborting transaction machine;
Session is terminated

www.neerajbooks.com
Analysis Classes: An initial reading of the use cases suggests that the following will be part of the system:
A controller object representing the ATM itself (managing the boundary objects listed below.)
Boundary objects representing the individual component parts of the ATM:
Operator panel.
Card reader.
Customer console, consisting of a display and keyboard.
Network connection to the bank.
Cash dispenser.
Envelope acceptor.
Receipt printer.
Controller objects corresponding to use cases. (Note: class ATM can handle the Startup and Shutdown use
cases itself, so these do not give rise to separate objects here.)
Session.
Transaction (abstract generalization, res-ponsible for common features, with concrete specializations
responsible for type-specific portions).
An entity object representing the information encoded on the ATM card inserted by customer.
An entity object representing the log of transactions maintained by the machine.
This leads to the following diagram of analysis classes:

www.neerajbooks.com
 www.neerajbooks.com

Neeraj
State Charts for Example ATM System: Three
of the objects we have identified have behaviour that is
sufficiently complex to warrant developing a State Chart
for them. (These are the objects that were identified as
the major controller objects.)
The object representing the machine itself

Publications
(responsible for the System Startup and
Shutdown use cases).
Objects representing a customer session (one
per session) (responsible for the Session use

www.neerajbooks.com
case).
Objects representing an individual transaction
(one per transaction) (responsible for the
Transaction use case, use cases for the specific
types of transaction and Invalid PIN extension).

www.neerajbooks.com
 www.neerajbooks.com
Probably the best way to start using these pages is
to begin with the requirements and work through the
entire analysis, high-level design and detailed design
process.
1. Begin with the Requirements and User
Interface Document: The first task that must be
performed in any project is clearly understanding the
requirements. This series of pages starts with a statement
of the overall requirements for the software, without
attempting to discuss the process of actually arriving at
them. For a problem of this size, identifying the
requirements is fairly straightforward. In a real system,
however, identifying the requirements will generally be
a non-trivial task. That, however, is not the focus of this
set of pages.
2. Then view the Use Cases and Further
Analysis: Analysis is begun by identifying the use cases
that follow from the requirements, and detailing a flow
of events for each. Further analysis identifies the key
Neeraj
classes that are suggested by the use cases, and considers
how each use case can be carried out by an interaction
between objects belonging to these classes:
The Use Case document has a use case
diagram and a series of flows of events, one for
each use case. Each use case also has a link to a
Publications
Sequence Diagram (part of the Design phase)
which shows how it is realized; these links can
be followed while studying the design phase to
see how the analysis phase flows into the design
phase.
www.neerajbooks.com
The Further Analysis document deals with both
the “big picture” and the details of the various
use cases. The former is provided by an Analysis
Class Diagram, with each class having a link to
its CRC card; the latter by a discussion of how
the key objects objects would need to interact
in order to implement the use case.
These two documents represent two different ways
of viewing the overall system, which continue into the
next phase. The use case document presents a use-case
centric view of the system, focussing on the specific
functions it provides. The further analysis document
presents a class centric view of the system, focussing
on how will be built.
3. This example uses CRC Cards and Sequence
Diagrams for high level Design: There are certainly
other tools that might be used – e.g. the ATM Example
referred to above makes use of Collaboration Diagrams
and State Charts as well.
The responsibilities of each class that arise from
the use cases are recorded on a CRC card for
www.neerajbooks.com
each class. The CRC cards could be created by
“walking through” each use case, assigning the
responsibility for each task to some class.
There is a sequence diagram for each use case,
showing how the use case is realized by
interaction of the major objects.
A class diagram shows how the various classes
are related to one another. It also shows several
additional classes that were “discovered” during
the process of creating the sequence diagrams
– i.e. classes needed to actually build the system,
though not evident in the original analysis. On
this diagram, the class icon is linked to a detailed
design for that class.
4. Detailed design is done by using a detailed UML
diagram for each class, showing its attributes and
operations. As noted above, although, I have not
included the actual implementation in Java code, I have
included the Javadoc documentation for the classes to
“flesh out” the information in the UML diagrams.
5. A demonstration executable version of the the
system, in the form of a Java Applet. This version is
limited, because the Java mechanisms to protect against
malicious code limit access to the file system on the
host computer. For this reason, it is not possible to use
the “Open”, “Save”, or “Save As” features of the
demonstration – attempting to do so will result in an
error dialog.
6. No actual code or complete executable version
of this system is provided. The ATM Example System
does provide both of these; but since I use the
implementation of this system as a programming project,
putting the code online would make the project just a
bit too simple!)
7. A page of maintenance ideas suggests changes
that might be made to improve the system. These
changes would necessarily involve modifying many of
the sample documents, not just modifying code.
Q. 1. What do you mean by “Role Names”?
Ans. A role is one end of an association. A binary
association has two roles, each of which may have a
role name. A role name is a name that uniquely identifies
one end of an association.
For e.g.
 www.neerajbooks.com

This example shows how person and company

participate in association “works for”. A person assumes
the role of “Employee” with respect to a company. A
company assumes the role of “Employees” with respect
to a person.
Role names are neccessary for asssociations
between two objects of the same class. For example, Q. 2. Object classes are given below. Draw a
“Manager” and “Worker’ distinguish the two employee object diagram you can use association names,
participating in the managers association in person class.attributes name.
Object classes, files system, file, directory, file name, ASCII file, executable file, directory file, disk
drive, etc.
Ans.

Neeraj
Publications
www.neerajbooks.com
Q. 3. Prepare an object diagram for the dining
philosopher’s problem. There are 5 philosophers
and 5 forks around a circular table. Each
philosopher has access to 2 forks on either side. Each
fork is shared by 2 philosophers. Each fork may be
either on the table or in use by one philosopher. A
philosopher must have 2 forks to eat.
Ans. Object Diagram to philosopher’s Problem
Q. 4. What is relationship and difference
between OOA (Object Oriented Analysis) and OOD
(Object Oriented Design)?
Ans. Pure object oriented development requires that
object oriented techniques be used during the analysis,
design and implementation of the system. However,
much of the focus of the object oriented approach to
software development has been OOA and OOD.
The fundamental differences between OOA & OOD
is that, the OOA deals with the problem domain, while
OOD deals with the solution domain.
The similarity of OOA and OOD is basic contracts
i.e. object and classes. The objectives of path OOA and
OOD is to model some domain frequently the OOA and
OOD methodologies and the representations look quite
similar.

www.neerajbooks.com
 www.neerajbooks.com
Q. 5. What is a software design pattern?
Ans. A design pattern is a solution to a general
software problem within a particular context.
Context: A recurring set of situations where the
pattern applies.
Problem: A system of forces (goals and
constraints) that occur repeatedly in this context.
Solution: A description of communicating
Neeraj
objects and classes (collaboration) that can be
applied to resolve those forces.
Design patterns capture solutions that have evolved
over time as developers strive for greater flexibility in
their software. Whereas class libraries are reusable
Publications
source code and components are reusable packaged
objects, patterns are generic, reusable design
descriptions that are customized to solve a specific
problem. The study of design patterns provides a
common vocabulary for communication and
www.neerajbooks.com
documentation, and it provides a framework for
evolution and improvement of existing patterns.
Q. 6. Why is the study of patterns important?
Ans. As initial software designs are implemented
and deployed, programmers often discover
improvements which make the designs more adaptable
to change. Design patterns capture solutions that have
evolved over time as developers strive for greater
flexibility in their software, and they document the
solutions in a way which facilitates their reuse in other,
possibly unrelated systems. Design patterns allow us to
reuse the knowledge of experienced software designers.
Moreover, the study of design patterns provides a
common vocabulary for communication and
documentation and it provides a framework for
evolution and improvement of existing patterns. As an
analogy, consider that during a discussion among
programmers, the words “stack” and “tree” can be used
freely without explanation. Software developers
understand fundamental data structures such as a “stack”
www.neerajbooks.com
because these data structures are well-documented in
textbooks and are taught in computer science courses.
The study of design patterns will have a similar (but
more profound) effect by allowing designers to say
“composite pattern” or “observer pattern” in a particular
design context, without having to describe all classes,
relationships, and collaborations which make up the
pattern. Patterns raise the level of abstraction when
discussing and documenting software designs.
Q. 7. How do I document a design pattern?
Ans. A pattern description must address the
following major points:
Pattern Name and Classification: A short,
meaningful name for the pattern, usually only
one or two words. Names provide a vocabulary
for patterns, and they have implied semantics –
choose names carefully. Following the GoF
book, we can also group patterns into higher
level classifications such as creational,
structural, and behavioural patterns.
Problem: A general description of the problem
context and the goals and constraints that occur
repeatedly in that context. A concrete
motivational scenario can be used to help
describe the problem. The problem description
should provide guidance to assist others in
recognizing situations where the pattern can be
applied.
Solution: The classes and/or objects that
participate in the design pattern, their structure
(e.g., in terms of a UML class diagram), their
responsibilities and their collaborations. The
solution provides an abstract description that
can be applied in many different situations.
Sample Code in an object-oriented language can
be used to illustrate a concrete realization of
the pattern.
Consequences: A discussion of the results and
tradeoffs of applying the pattern. Variations and
language-dependent alternatives should also be
addressed.
Known Uses: Examples of the pattern in real
systems. Look for applications of the pattern in
language libraries and frameworks, published
system descriptions, text books, etc. Not every
good solution represents a pattern. A general
rule of thumb is that a candidate pattern (also
called a “proto-pattern”) should be discovered
 www.neerajbooks.com
in a minimum of three existing systems before
it can rightfully be called a pattern.
The following quote by Robert Martin highlights
the importance of providing pattern descriptions: “The
revolutionary concept of the GoF book is not the fact
that there are patterns; it is the way in which those
patterns are documented. ... Prior to the GoF book, the
only good way to learn patterns was to discover them in
design documentation, or (more probably) code.”
Q. 8. What is an example of a design pattern?
Ans. Following the lead of the “Gang of Four”
(GoF), design pattern descriptions usually contain
multiple sections including:
Intent
Motivation
Applicability
Structure
Participants
Neeraj
Collaborations
Consequences
Implementation
Sample Code
Known Uses
Related Patterns.
Publications
A complete discussion of even a small pattern is
beyond the scope of a simple FAQ entry, but it is possible
to get the idea by examining an abbreviated discussion
of one of the simplest and most easily understood
www.neerajbooks.com
patterns. Consider the singleton pattern, whose intent
reads as follows:
Intent: Ensure that a class has one instance, and
provide a global point of access to it.
Almost every programmer has encountered this
problem and formulated an approach for solving it in a
general way – some solutions are better than others.
www.neerajbooks.com
The solution offered by the GoF would look something
like the following when coded in Java.
public class Singleton
{
private static Singleton instance = null;
public static Singleton getInstance()
{
if (instance == null)
instance = new Singleton();
return instance;
}
protected Singleton() { ... }
// possibly another constructor form
public void someMethod() { ... }
//... other methods
}
The programmer would access the single instance
of this class by writing something similar to
Singleton.getInstance().someMethod()
or similar to
Singleton s = Singleton.getInstance();
s.method1();
...
s.method2();
Q. 9. What are the differences between analysis
patterns and design patterns?
Ans. Analysis pattern are for domain architecture,
and design pattern are for implementation mechanism
for some aspect of the domain architecture. In brief,
analysis pattern are more high level and more (end-user)
functional oriented.
 www.neerajbooks.com
Testing Techniques
A testing technique specifies the strategy used in
testing to select input test cases and analyze test results.
Different techniques reveal different quality aspects of
a software system, and there are two major categories
of testing techniques, functional and structural.
Neeraj
Functional Testing: The software programme or
system under test is viewed as a “black box”. The
selection of test cases for functional testing is based on
the requirement or design specification of the software
entity under test. Examples of expected results
Publications
sometimes are called test oracles, include requirement/
design specifications, hand calculated values and
simulated results. Functional testing emphasizes on the
external behaviour of the software entity.
www.neerajbooks.com
Structural Testing: The software entity is viewed
as a “white box”. The selection of test cases is based on
the implementation of the software entity. The goal of
selecting such test cases is to cause the execution of
specific spots in the software entity, such as specific
statements, programme branches or paths. The expected
results are evaluated on a set of coverage criteria.
Examples of coverage criteria include path coverage,
branch coverage, and data-flow coverage. Structural
testing emphasizes on the internal structure of the
software entity.
SOFTWARE TESTING
Software testing is the process of testing the
software product. Thus, testing is the process of
executing a program with intent to find errors. This
means while we are testing a software product we are
locating the errors in the software product. Thus, testing
will not show the absence of errors but will show that
www.neerajbooks.com
6
errors exist in the software product. In this process, we
execute a program with a set of given inputs and record
the outputs. These are then matched with the expected
outputs, if the actual output and the expected output
match with each other then the software product is said
to behave in the expected manner otherwise some error
exist in the program which need to be located and
corrected. It is an important but expensive process. If
we launch a software product without testing then the
cost will potentially be much higher than the cost of
testing the software, especially in systems in which
human safety is involved. Thus, testing the software plays
an important role. Even if the software product
undergoes the testing process.
One popular equation of software testing is:
Software Testing = Software Verification +
Software Validation.
As per IEEE definition:
Software Verification: “It is the process of
evaluating a system or component to determine whether
the product of a given development phase satisfy the
conditions imposed at the start of that phase.”
This means that it is a process of confirming that
software meets its specification.
Software Validation: “It is the process of
evaluating a system or component during or at the end
of development process to determine whether it satisfies
the specified requirements. It involves executing the
actual software. It is computer based testing process.”
This means that it is a process of conforming that
software meets the customer’s requirements.
Some terminologies that will be studied in this
chapter are:
Error, Mistake, Bug, Fault and Failure:
People make error. A good synonym is mistake.
 www.neerajbooks.com
This may be syntax error or misunderstanding
of the specifications. Sometimes, there are
logical errors. When mistakes are made while
coding then these mistakes are called bugs.
Errors tend to propagate from one level to
another. Requirement errors are magnified in
design phase and amplified still more in the
coding.
An error may lead to one or more fault. A missing
or incorrect statement in a program resulting from an
error is a fault. It is a representation of error, where
representation is the mode of expression, narrative text,
etc. Defect is a good synonym for fault.
Failure occurs when a fault in the program gets
executed.
So, Error (or mistake or bug)  Fault (or Defect)
 Failure
Test Case ID:
Neeraj
Section- 1
(Before Execution)
Purpose:
Pre condition: (if any)
Inputs:
Publications
Expected Outputs:
Post conditions:
Written by:
Date:
www.neerajbooks.com
Test suite is a collection of test cases that is used
for validating bug fixes within a logical or physical area
of a product.
Alpha Testing, Beta Testing and Acceptance
Testing: Acceptance testing is done when the
software is to be developed for a specific
customer. A series of tests are conducted to
enable the customer to validate all
requirements. The discovered errors will be
fixed and better quality software will be
delivered to the customer. Alpha and beta
testing are done for a product for anonymous
customer. Alpha testing is done by the customer
at the developer’s site whereas beta testing is
done by customers at their sites.
Software Reliability is the probability that
software will not undergo a failure for a specified time
under specified conditions. Reliability is essentially the
level of confidence one can place in the software and
www.neerajbooks.com
Test, Test Case and Test Suite: Testing is
concerned with errors, faults, failures and
incidents. A test is the act of exercising
software with test cases. A test has two goals-
to find failures or to demonstrate correct
execution.
Test case describes an input description and an
expected output description. It has an identity and is
associated with the program behaviour. During testing
the preconditions are set and the required inputs are
given to the program. Execute the program. Compare
the observed output with the expected output of the
program. If the expected and observed outputs are
different then there is a failure which should be recorded
properly in the test case with the cause of the error. If
both are same then the program behaved in the expected
manner. The template for a test case is as follows:
Section- 2
(After Execution)
Execution History:
Result:
If fails, any possible reason (Optional):
Any other observation:
Any suggestion:
Run by:
Date:
this level is dependent on time. Simply specifying a
reliability number (such as 0.98) is not meaningful until
a time period is specified. A proper specification could
be that the reliability for a ten hour operation should be
0.981. Reliability can also be defined in terms of Mean
Time To Failure (MTTF), which specifies the average
time between the occurrences of two failures. If a
reliability function is given, the MTTF can be obtained
from the function.
The goal of all Verification and Validation (V&V)
activities is to make software more reliable. In software,
unreliability is caused by the presence of faults. The
fewer the faults in a software, the less likely is that a
failure will occur during execution. This is unlike other
engineering disciplines where failures are often caused
due to “wear and tear”; faults are the only cause of
unreliability. Most of the V&V activities can be
classified as static or dynamic. Static methods are where
the behaviour of the system is not observed by executing
 www.neerajbooks.com
the system. Examples of static methods are reviews,
program proving and code reading. In all these cases
the system to be verified is not executed. In dynamic
methods, the behaviour of the system is observed by
executing the system. The prime example of this method
is testing. That is why testing is sometimes called
dynamic testing. Both types of methods take different
approaches for improving software reliability.
During the testing process, only failures are
observed, by which the presence of faults is deduced.
The actual faults are identified by separate activities,
commonly referred to as “debugging”. This one of the
reasons why testing is an expensive method for
identification and removal of faults, as compared to
static methods which directly observe faults. The
specifications of a system often specify many properties,
although, some are considered more important than
others. If a failure that violates a less important property,
Neeraj
it is considered more severe than a failure that violates
a less important property. To capture this concept of
severity of failures, often error-classifications is used,
in which errors or faults are classified according to the
type and severity of failures they cause.
Publications
Testing is the major quality control measure
employed during software development. Its basic
function is to detect errors in the software. This phase
has to uncover errors during the coding, but also errors
www.neerajbooks.com
introduced during the previous phases. The goal of
testing is to uncover requirement, design and coding
errors in the programs. The starting point is off-course
the unit testing, but gradually the modules are integrated
into sub-systems and are then subjected to the integration
testing. After the system is ready, the system testing is
performed. The whole of the system is tested against
the system requirements. Finally, the acceptance testing
is performed to demonstrate to the clients, on the real
life data of the client. For testing to be successful, proper
selection of test cases is essential. There are two different
approaches for selecting test cases–functional testing
and structural testing.
Levels of Testing: The basic levels of testing are
unit testing, integration testing, system and acceptance
testing. These different levels of testing attempt to detect
different types of faults. The relation of the faults
introduced in different phases and the different levels
of testing are:
www.neerajbooks.com
1. Unit Testing: In this type of testing, different
modules are tested against the specifications produced
during design for the modules. Unit testing is essentially
for verification of the code produced during the coding
phase and hence the goal is to test the internal logic of
the modules.
2. Integrated Testing: In this type of testing, many
tested modules are combined into sub-systems which
are then tested. The goal here is to see if the modules
can be integrated properly, the emphasis being on testing
interfaces between modules. This testing activity can
be considered as testing the design and hence the
emphasis on testing module interactions.
3. System Testing: The reference document for this
process is the requirements document and the goal is to
see if the software meets its requirements. This is
essentially a validation exercise and in many cases is
the only validation activity.
Functional Testing: It is also known as Black Box
testing. The term black box refers to the software which
is treated as a black box. Here testing is based on the
functionality of the software program. Thus, functional
testing refers to testing, which involves observation of
the output for certain input values. The code is not
considered in functional testing. The internal structure
of the program is ignored. Functionality of black box is
understood completely in terms of inputs and outputs
as shown below:
There are a number of strategies that can be used
to design test cases for performing black box testing to
find out the errors in the program.
1. Boundary Value Analysis: It is a black box
testing technique that believes that more errors will
propagate at the boundaries. Here boundary condition
means that an input value may be on the boundary or
just above or below the boundary and a nominal value.
That is {min, min+, nom, max-, max}. Suppose we have
an input variable x with a range of 1 to 100 then the
boundary values for this variable will be 1, 2, 50, 99
and 100. The domain is shown below:
 www.neerajbooks.com

(a) Boolean and logical variables are a problem

for BVA.
(b) BVA assumes variables are independent which
is not possible always.
(c) Test cases obtained in BVA are rudimentary.
Example: A program for determination of the
nature of roots of a quadratic equation is considered
with the input variables a, b and c and the values ranging
from 0 to 100. The program will output that the equation
has real roots, imaginary roots, equal roots or it is not a
quadratic equation. We have to design the test cases for
the above problem using Boundary Value Analysis.
It is based on a critical assumption that is known as Solution to the problem stated above is as follows:
‘Single fault assumption theory’. According to this Quadratic equation will be of type:
assumption, the test cases are derived on the basis that ax2 + bx + c = 0
failures do not occur due simultaneous occurrence of Roots are real if (b2 – 4ac) > 0
two or more faults. So the test cases are derived by Roots are imaginary if (b2 – 4ac) < 0
keeping all the variables constant except one for which Roots are equal if (b2 – 4ac) = 0

Neeraj
the fault is taken in care.
If there are n variables in a program then all the
variables will be at their nominal value except for the
one variable which will have the values of boundaries.
The number of test cases that Boundary Value Analysis
Equation is not quadratic if a = 0
As we can see we have three variables a, b and c,
i.e. n = 3
Therefore the number of test cases BVA will have
is (4n + 1) = 4*3 + 1= 12+1=13 test cases.

Publications
will have for n variables is (4n + 1) test cases.
Limitations of Boundary Value Analysis (BVA)
The BVA test cases are:
Test Case A B C Expected Output

www.neerajbooks.com
1 0 50 50 Not Quadratic
2 1 50 50 Real Roots
3 50 50 50 Imaginary Roots
4 99 50 50 Imaginary Roots
5 100 50 50 Imaginary Roots
6 50 0 50 Imaginary Roots
7 50 1 50 Imaginary Roots
8 50 99 50 Imaginary Roots
9 50 100 50 Equal Roots
10 50 50 0 Real Roots
11 50 50 1 Real Roots
12 50 50 99 Imaginary Roots
13 50 50 100 Imaginary Roots

2. Robustness Testing: It is the extension of the value. This is also single fault assumption theory. Thus
boundary value analysis. Here we consider not only the the values that are considered for testing are {min-, min,
boundary values but also values slightly greater than min+, nom, max-, max, max+}. The domain for the
the maximum value and slightly less than the minimum problem is shown below:

www.neerajbooks.com
 www.neerajbooks.com

2. With it we can focus on exceptional handling

For a program with n- variables, the number of test
cases that robustness testing will have is (6n + 1) test
cases. In robustness testing we will go outside the
legitimate boundary of the input domain. This type of
testing is quite common in electric and electronic
circuits.
because we try to cross legitimate boundaries.
Example: A program for determination of the
nature of roots of a quadratic equation is considered
with the input variables a, b and c and the values ranging
from 0 to 100. The program will output that the equation
has real roots, imaginary roots, equal roots or it is not a
quadratic equation. We have to design the test cases for
the above problem using Robustness Testing.
Solution to the problem stated above is as follows:
Quadratic equation will be of type:
ax2 + bx + c = 0
Roots are real if (b2 – 4ac) > 0
Roots are imaginary if (b2 – 4ac) < 0
Roots are equal if (b2 – 4ac) = 0
Equation is not quadratic if a = 0
As we can see we have three variables a, b and c,
i.e. n = 3
Therefore, the number of test cases BVA will have

Neeraj
Advantages of Robustness Testing: 1. It is easy is (6n + 1) = 6*3 + 1= 18+1=19 test cases.
to develop test case because it has no recognition of
data or logical dependencies.

The robustness test cases are:

Publications
Test Case A B C Expected Output
1 –1 50 50 Invalid Input
2 0 50 50 Not Quadratic
3 1 50 50 Real Roots

www.neerajbooks.com
4 50 50 50 Imaginary Roots
5 99 50 50 Imaginary Roots
6 100 50 50 Imaginary Roots
7 101 50 50 Invalid Input
8 50 –1 50 Invalid Input
9 50 0 50 Imaginary Roots
10 50 1 50 Imaginary Roots
11 50 99 50 Imaginary Roots
12 50 100 50 Equal Roots
13 50 101 50 Invalid Input
14 50 50 –1 Invalid Input
15 50 50 0 Real Roots
16 50 50 1 Real Roots
17 50 50 99 Imaginary Roots
18 50 50 100 Imaginary Roots
19 50 50 101 Invalid Input

www.neerajbooks.com
 www.neerajbooks.com

3. Worst-Case Testing: In this testing technique
the single fault assumption theory is rejected and more
than one variable has an extreme value. It requires more
effort. Here we remain within the legitimate boundary
of our range. We take the Cartesian product of the sets
{min, min+, nom, max-, max}. We assume multiple fault
assumption, i.e. more than one variable has an extreme
value and the domain of our problem is shown below:
A program with n- variables the number of test cases
worst case testing will have will have 5n test cases.
Example: A program for determination of the
nature of roots of a quadratic equation is considered
with the input variables a, b and c and the values ranging
from 0 to 100. The program will output that the equation
has real roots, imaginary roots, equal roots or it is not a
quadratic equation. We have to design the test cases for
the above problem using worst case testing.
Solution to the problem stated above is as follows:
Quadratic equation will be of type:
ax2 + bx + c = 0
Roots are real if (b2 – 4ac) > 0
Roots are imaginary if (b2 – 4ac) < 0
Roots are equal if (b2 – 4ac) = 0
Equation is not quadratic if a = 0
As we can see we have three variables a, b and c,
i.e. n = 3
Therefore, the number of test cases BVA will have

Neeraj
is 5n = 125 test cases.

The worst case test cases are:

Test Case A B C Expected Output

Publications
1 0 0 0 Not Quadratic
2 0 0 1 Not Quadratic
3 0 0 50 Not Quadratic
4 0 0 99 Not Quadratic
5
6 www.neerajbooks.com
0
0
0
1
100
0
Not Quadratic
Not Quadratic
7 0 1 1 Not Quadratic
8 0 1 50 Not Quadratic
9 0 1 99 Not Quadratic
10 0 1 100 Not Quadratic
11 0 50 0 Not Quadratic
12 0 50 1 Not Quadratic
13 0 50 50 Not Quadratic
14 0 50 99 Not Quadratic
15 0 50 100 Not Quadratic
16 0 99 0 Not Quadratic
17 0 99 1 Not Quadratic
18 0 99 50 Not Quadratic
19 0 99 99 Not Quadratic
20 0 99 100 Not Quadratic
21 0 100 0 Not Quadratic

www.neerajbooks.com
 www.neerajbooks.com

Test Case A B C Expected Output

22 0 100 1 Not Quadratic
23 0 100 50 Not Quadratic
24 0 100 99 Not Quadratic
25 0 100 100 Not Quadratic
26 1 0 0 Equal Roots
27 1 0 1 Imaginary Roots
28 1 0 50 Imaginary Roots
29 1 0 99 Imaginary Roots
30 1 0 100 Imaginary Roots
31 1 1 0 Real Roots
32 1 1 1 Imaginary Roots
33 1 1 50 Imaginary Roots
34 1 1 99 Imaginary Roots
35 1 1 100 Imaginary Roots
36 1 50 0 Real Roots

Neeraj
37 1 50 1 Real Roots
38 1 50 50 Real Roots
39 1 50 99 Real Roots
40 1 50 100 Real Roots

Publications
41 1 99 0 Real Roots
42 1 99 1 Real Roots
43 1 99 50 Real Roots
44 1 99 99 Real Roots

www.neerajbooks.com
45 1 99 100 Real Roots
46 1 100 0 Real Roots
47 1 100 1 Real Roots
48 1 100 50 Real Roots
49 1 100 99 Real Roots
50 1 100 100 Real Roots
51 50 0 0 Equal Roots
52 50 0 1 Imaginary Roots
53 50 0 50 Imaginary Roots
54 50 0 99 Imaginary Roots
55 50 0 100 Imaginary Roots
56 50 1 0 Real Roots
57 50 1 1 Imaginary Roots
58 50 1 50 Imaginary Roots
59 50 1 99 Imaginary Roots
60 50 1 100 Imaginary Roots
61 50 50 0 Real Roots

www.neerajbooks.com
 www.neerajbooks.com

Test Case A B C Expected Output

62 50 50 1 Real Roots
63 50 50 50 Imaginary Roots
64 50 50 99 Imaginary Roots
65 50 50 100 Imaginary Roots
66 50 99 0 Real Roots
67 50 99 1 Real Roots
68 50 99 50 Imaginary Roots
69 50 99 99 Imaginary Roots
70 50 99 100 Imaginary Roots
71 50 100 0 Real Roots
72 50 100 1 Real Roots
73 50 100 50 Equal Roots
74 50 100 99 Imaginary Roots
75 50 100 100 Imaginary roots
76 99 0 0 Equal Roots

Neeraj
77 99 0 1 Imaginary Roots
78 99 0 50 Imaginary Roots
79 99 0 99 Imaginary Roots
80 99 0 100 Imaginary Roots

Publications
81 99 1 0 Imaginary Roots
82 99 1 1 Imaginary Roots
83 99 1 50 Imaginary Roots
84 99 1 99 Imaginary Roots

www.neerajbooks.com
85 99 1 100 Imaginary Roots
86 99 50 0 Real Roots
87 99 50 1 Real Roots
88 99 50 50 Imaginary Roots
89 99 50 99 Imaginary Roots
90 99 50 100 Imaginary Roots
91 99 99 0 Real Roots
92 99 99 1 Real Roots
93 99 99 50 Imaginary Roots
94 99 99 99 Imaginary Roots
95 99 99 100 Imaginary Roots
96 99 100 0 Real Roots
97 99 100 1 Real Roots
98 99 100 50 Imaginary Roots
99 99 100 99 Imaginary Roots
100 99 100 100 Imaginary Roots
101 100 0 0 Equal Roots

www.neerajbooks.com
 www.neerajbooks.com

Test Case A B C Expected Output

102 100 0 1 Imaginary Roots
103 100 0 50 Imaginary Roots
104 100 0 99 Imaginary Roots
105 100 0 100 Imaginary Roots
106 100 1 0 Real Roots
107 100 1 1 Imaginary Roots
108 100 1 50 Imaginary Roots
109 100 1 99 Imaginary Roots
110 100 1 100 Imaginary Roots
111 100 50 0 Real Roots
112 100 50 1 Real Roots
113 100 50 50 Imaginary Roots
114 100 50 99 Imaginary Roots
115 100 50 100 Imaginary Roots
116 100 99 0 Real Roots

Neeraj
117 100 99 1 Real Roots
118 100 99 50 Imaginary Roots
119 100 99 99 Imaginary Roots
120 100 99 100 Imaginary Roots

Publications
121 100 100 0 Real Roots
122 100 100 1 Real Roots
123 100 100 50 Imaginary Roots
124 100 100 99 Imaginary Roots

www.neerajbooks.com
125 100 100 100 Imaginary Roots

4. Equivalence Class Testing: In this method,
input domain of a program is partitioned into a finite
number of equivalence classes such that one can
reasonably assume, but not be absolutely sure, that the
test of a representative value of each class is equivalent
to a test of any other value. That is, if one test case in a
class detects an error, all other test cases in the class
would be expected to find same error. Furthermore, if
this single representative test case did not detect any
error then it is assumed that no other test case of this
class can detect error. In this method both the valid and
the invalid input domain is considered. The idea of this
testing is to identify one element from each equivalence
class which should be chosen wisely so that the potential
redundancy among the test cases can be reduced.
Two steps are required in implementing this
method. These are as follows:
(a) The equivalence classes are identified by
taking each input condition and partitioning
them into valid and invalid classes. For
example if a variable has an input domain of
1<variable<100, then the classes that will be
formed are one valid class 1<variable<100 and
two invalid classes those are variable<1 and
variable>100.
(b) Generate the test case using all the valid and
invalid equivalence classes identified in the
above step. This ensures that no two invalid
classes mask each other.
The domain of our problem is shown below:

www.neerajbooks.com
 www.neerajbooks.com

Do not forget to have equivalence classes for invalid Solution to the problem stated above is as follows:
inputs as they are the best source of bugs. In fact different Quadratic equation will be of type:
types of invalid inputs should be tested in order to get ax2 + bx + c = 0
more errors. Hence, we should design equivalence Roots are real if (b2 – 4ac) > 0
classes based on input and output domains. Roots are imaginary if (b2 – 4ac) < 0
Example: A program for determination of the Roots are equal if (b2 – 4ac) = 0
nature of roots of a quadratic equation is considered Equation is not quadratic if a = 0
Thus the output domain equivalence class test cases

Neeraj
with the input variables a, b and c and the values ranging
can be identified as follows:
from 0 to 100. The program will output that the equation
O1= {<a, b, c>: Not a quadratic equation if a = 0}
has real roots, imaginary roots, equal roots or it is not a
O2= {<a, b, c>: Real roots if (b2 – 4ac) > 0}
quadratic equation. We have to design the test cases for
O3= {<a, b, c>: Imaginary roots if (b2 – 4ac) < 0}
the above problem using Equivalence class testing.
O4= {<a, b, c>: Equal roots if (b2 – 4ac) = 0}

Publications
The Output Domain test cases are as follows:
Test Case a b c Expected Output
1 0 50 50 Not a Quadratic Equation
2 1 50 50 Real Roots
3
4 www.neerajbooks.com
50
50
50
100
50
50
Imaginary Roots
Equal Roots

The other set of test cases is based on input domain. I6= {b: b<0}
I1= {a: a=0} I7= {b: b>100}
I2= {a: a<0} I8= {c: 0<=c<=100}
I3= {a: 1<=a<=100} I9= {c: c<0}
I4= {a: a>100} I10= {c: c>100}
I5= {b: 0<=b<=100}
Input Domain test cases are:
Test Case a b c Expected Output
1 0 50 50 Not a quadratic equation
2 –1 50 50 Invalid Input
3 50 50 50 Imaginary Roots
4 101 50 50 Invalid Input
5 50 50 50 Imaginary Input
6 50 –1 50 Invalid Input

www.neerajbooks.com
 www.neerajbooks.com

Test Case a b c Expected Output

7 50 50 101 Invalid Input
8 50 50 50 Imaginary Input
9 50 50 –1 Invalid Input
10 50 50 101 Invalid Input

Here, test cases 5 and 8 are redundant but if choose under varying sets conditions. We would like to show
any other value other than the nominal value then these that how these may be applied to the testing and how
test cases will not be redundant. Hence, we will have a tester adopts the principles to the situation.
total of 10 + 4 = 14 test cases in this example of A decision table has four portions, namely:
equivalence class testing. (a) Stub Portion
5. Decision Table Based Testing: Decision tables (b) Entry Portion
are a precise and compact way to model complicated
(c) Condition portion, and
logic. They are useful for describing the situations in
which a number of combinations of actions are taken (d) Action portion.
Rules
Condition Stub Condition Entry

Neeraj
Action Stub Action Entry

A column in the entry portion is a rule. Rules will is called as limited entry decision table. If conditions
indicate what action has to be performed depending on have several rules then the tables are called extended
the condition indicated in the condition portion of the entry decision table.
rule. Decision table in which all conditions are binary

Publications
Some of the basic term is shown below:

Condition Entry
Stub c1 True False

www.neerajbooks.com
c2
c3 True
True
False True
False
False True
True
False
False
-
Action a1 X X X
Stub a2 X X X
a3 X X
a4 X X X

In the above, table when conditions c1, c2 and c3
are all true then actions a1 and a2 occur. When conditions
c1 and c2 are true and c3 is false actions a1 and a3 will
occur and so on.
To identify test cases with decision table certain
steps are to be followed:
Step1: For a module identify the input conditions
(input or cause) and the actions (output or effect).
Sometimes conditions end up referring to equivalence
of inputs and actions refers to major functional
processing portions of the item that is being tested.
Step 2: Rules are interpreted as test cases.
Each column of the decision table represents a test
case. That is:
Number of Test Cases = Number of Rules
For a limited entry decision table if there are n-
variables then there will be 2n rules or test cases.
Advantages of Decision Tables
(a) This type of testing works iteratively. The table
that is drawn in the first iteration acts as a
stepping stone to derive new decision tables,
if the first table is unsatisfactory.
(b) It follows completeness property. This property
promise a form of complete testing.

www.neerajbooks.com
 www.neerajbooks.com

(c) They are declarative. There is no particular
order for conditions and actions to occur.
Disadvantages of Decision Tables
They do not scale up well. There is a lot of
redundancy which has to be removed.
Applications of Decision Tables
(a) Prominent if-then-else logic
(b) Logical relationships among input variables
Solution to the problem stated above is as follows:
The decision table for the triangle problem is shown below:
(c) Calculations involving subsets of input
variables.
Example: A program to classify a triangle is taken
in consideration. Its input is a triple of positive integers
(say x, y, z) and the range of these inputs is from 0 to
100. The program output will be scalene, isosceles,
equilateral or not a triangle. Design the test cases using
decision tables based testing.

c1: x, y, z are sides of a triangle? N Y

c2: x=y? - Y N
c3: x=z? - Y N Y N
c4: y=z? - Y N Y N Y N Y N
a1: Not a triangle X
a2: Scalene X
a3: Isosceles X X X

Neeraj
a4: Equilateral X
a5: Impossible X X X
The modified decision table is given below:
Conditions
c 1: x< y + z? F T T T T T T T T T T

Publications
c 2: y < x + z? - F T T T T T T T T T
c 3: z < x + y? - - F T T T T T T T T
c 4: x = y? - - - T T T T F F F F
c 5: x = z? - - - T T F F T T F F

www.neerajbooks.com
c 6: y = z? - - - T F T F T F T F
a 1: Not a triangle X X X
a 2: Scalene X
a 3: Isosceles X X X
a 4: Equilateral X
a 5: Impossible X X X
The test cases for the above decision table are:
Test Case x y z Expected Output
1 4 1 2 Not a triangle
2 1 4 2 Not a triangle
3 1 2 4 Not a triangle
4 5 5 5 Equilateral
5 ? ? ? Impossible
6 ? ? ? Impossible
7 2 2 3 Isosceles
8 ? ? ? Impossible
9 2 3 2 Isosceles
10 3 2 2 Isosceles
11 3 4 5 Scalene

www.neerajbooks.com
 www.neerajbooks.com

6. Cause-Effect Graphing Technique: It is a technique that helps in selecting a high yield set of test cases.
It has a beneficial effect in pointing out incompleteness and ambiguities in the specifications.
A ‘cause’ represents a distinct input condition that brings an internal change in the system whereas an ‘effect’
shows an output condition that is a state resulting from the combination of causes. The steps to derive the test cases
are as follows:
(a) Identify the cause and effect for the problem.
(b) Draw a Boolean graph that is the cause effect graph.
(c) Convert the graph into limited entry decision table.
(d) The columns in the decision table are converted into test cases.
The basic notations used in the graph are:
NOT
Identity
c1 e1 c1 e1

c1 OR AND
c1

e1 e1
c2

Neeraj
V
c2
c3

Here, each node has a value of 0 or 1. 0 represents issued. Draw the cause effect graph for above

Publications
the absence of state and 1 represents the present state. problem.
The Identity function states that if c1 is 0 the e1 is 0 Solution to the problem stated above is as follows:
otherwise both are 1. The NOT function states that if c1 Step1: Identify the cause and the effect.
is 0 then e1 is 1 otherwise vice versa. The OR function The causes are:
states that if c1 or c2 or c3 is 1 then e1 is 1 otherwise it is c1: Character in column 1 is A

www.neerajbooks.com
0 and the AND function states that if c1 and c2 are 1 c2: Character in column 1 is B
then e1 is 1 otherwise its 0. c3: Character in column 2 is a digit
Example: The characters in column 1 must be an The effects are:
A or B. the character in column 2 must be a digit. In this e1: update made
situation the file update is done. If the character in e2: message x is issued
column 1 is incorrect then message x is issued. If the e3: message y is issued
character in column 2 is incorrect then message y is Step 2: Draw its cause effect graph

e1
c1
V

e2
c2

e3
c3

www.neerajbooks.com
 www.neerajbooks.com
Structural Testing: It is also known as white box
testing. White box testing is a way of testing the external
functionality of the code by examining and testing the
program code that realizes the external functionality. It
lets us examine the internal structure of the program
that is the code is visible in white box testing. The test
cases are derived by examining the program’s logic
without paying attention to the specifications. There are
two kinds of white box testing. They are:
Dynamic White Box Testing: It means testing a
running program by looking into the program, examining
the code and watching it as it runs.
Static White Box Testing: It means to test a
program without running it that is examining and
reviewing it before running. There are many techniques
of white box testing. They are as follows:
1. Path Testing: It is the name given to a group of
test techniques which selects a set of test paths through
the program. It requires the complete knowledge of the
program structure in order to perform unit testing on it.
Neeraj
Publications
Sequence If-then-else
DD path Graph: After flow graph generation a
While Loop
www.neerajbooks.com
DD path graph is drawn from the flow graph. It is the
decision to decision path graph that is here the
concentration is on decision nodes only. The nodes that
are in sequence are combined in one node only. Hence,
DD path graph is a directed graph in which nodes are
sequences of statements and edges represent control
flow between nodes.
Independent Paths: The DD path graph drawn in
the previous step is used to find the independent paths.
It is a through the DD path graph that introduces at least
one new set of processing statements or new conditions.
Therefore, an independent path will have at least one
node that is different and has not been traversed in each
defined path.
Independent paths are used to ensure:
(a) Every statement in the program has been
executed at least once.
(b) Every branch has a true and a false condition.
Example
Consider the program for the determination of the
nature of roots of a quadratic equation. Its input is a
triple of positive integers (say a, b and c) and values
www.neerajbooks.com
Its effectiveness decreases as the size of the software
under test increases. This type of testing involves:
(a) Generate a set of paths that will cover every
branch in the program.
(b) Finding a set of test cases that will execute
every path in the set of program paths obtained
above.
Path generation (Step a) can be performed through
the static analysis of the program control flow and can
be automated.
Flow Graph: The control flow of a program can
be analysed using the graphical representation known
as Flow Graph. The flow graph is a directed graph in
which nodes are the entire statements or fragments of
statements and edges represent the flow of control. If a
and b are two nodes and there is an edge between them
then it can be said that statement or fragment of statement
corresponding to node b can immediately be executed
after statements of node a. It can be generated from the
code of any program. The basic constructs of flow graph
are:
Repeat-until loop Switch Statement
may be from interval [0,100]. The program is given
below:
#include <stdio.h>
#include <conio.h>
#include <math.h>
1 int main()
2 {
3 int a, b, c, validInput=0, d;
4 double D;
5 printf (“Enter the ‘a’ value: ”);
6 scanf(“%d”, &a);
7 printf (“Enter the ‘b’ value: ”);
8 scanf(“%d”, &b);
9 printf (“Enter the ‘c’ value: ”);
10 scanf(“%d”, &c);
11 if ((a>=0) && (a<=100) && (b>=0) &&
(b<=100) && (c>=0) && (c<=100))
{
12 validInput = 1;
13 if (a == 0)
{
14 validInput = -1;
15 }
 www.neerajbooks.com

16 } 30 }
17 if (validInput == 1) { 31 else if ( validInput == -1) {
18 d = b*b – 4*a*c; 32 printf (“Not a quadratic equation”);
19 if ( d== 0){ 33 }
20 printf (“Equal roots and are r1 = r2 = %f\n”, – 34 else {
b/(2*(float)a)); 35 printf (“Invalid Input”);
21 } 36 }
22 else if ( d > 0 ) { 37 getche();
23 D=sqrt (d); 38 return 1;
24 printf (“Real roots and are r1=%f and 39 }
r2=%f\n”, (-b-D) / (2*a), (-b + D) / (2*a)); The output will be one out of the following:
25 } 1. Not a quadratic equation
26 else { 2. Real roots
27 D= sqrt(-d) / (2*a); 3. Imaginary roots
28 printf (“Imaginary roots and are r1 = (%f, %f) 4. Equal roots
and r2 = (%f, %f)\n”, -b / (2*a), D, - 5. Invalid input.
b / (2*a), -D); We have to draw the flow graph and DD path graph
29 } and also find the independent paths from DD path graph.
The solution to the above problem is:

Neeraj
The flow graph is given below:

Publications
www.neerajbooks.com

www.neerajbooks.com
 www.neerajbooks.com

DD Path Graph is given below:

Neeraj
Publications
www.neerajbooks.com
The mapping table for DD path graph is:
Flow Graph nodes DD Path graph Remarks
corresponding
nodes
1 to 10 A Sequential nodes
11 B Decision node
12 C Intermediate node
13 D Decision node
14,15 E Sequential nodes
16 F Two edges are combined here
17 G Two edges are combined and decision node
18 H Intermediate node
19 I Decision node
20, 21 J Sequential nodes
22 K Decision node

www.neerajbooks.com
 www.neerajbooks.com

Flow Graph nodes DD Path graph Remarks

corresponding
nodes
23 to 25 L Sequential nodes
26 to 29 M Sequential nodes
30 N Three edges are combined
31 O Decision node
32, 33 P Sequential nodes
34 to 36 Q Sequential nodes
37 R Three edges are combined
38, 39 S Sequential nodes with exit node.
Independent paths are: There will be five independent paths for the above
(i) ABGOQRS flow graph as the Cyclomatic complexity is 5. The
(ii) ABGOPRS independent paths are:
(iii) ABCDFGOQRS 1. a c f
(iv) ABCDEFGOPRS 2. a b e f

Neeraj
(v) ABGHIJNRS 3. a d c f
(vi) ABGHIKLNRS 4. a b e a c f or a b e a b e f
(vii) ABGHIKMNRS. 5. a b e b e f
2. Cyclomatic Complexity: It is also known as Properties of Cyclomatic Complexity
structural complexity because it gives the internal view 1. V(G) >= 1
of the code. With the help of this technique it is easy to 2. V(G) is the maximum number of independent

Publications
find the number of independent paths in the graph. It paths in graph G.
tells about the upper bound for the number of tests that 3. Inserting and deleting functional statements to
must be conducted to ensure all statements have been G does not affect V(G)
executed at least once and every condition node is 4. G has only one path if V(G) =1

www.neerajbooks.com
checked on its true and false side.
McCabe’s Cyclomatic metric V(G) of a graph G
with n vertices, e edges and P connected components is
V(G) = e – n + 2P.
For example, consider the following graph and
using that graph we will calculate the Cyclomatic
complexity and find the independent paths.
The Cyclomatic complexity can be calculated for
the graph given below as:
V(G) = e – n + 2P
Here e = 9, n = 6 and P=1
Therefore, V(G) = 9 – 6 + 2*1= 9 – 6 + 2 = 5
5. Inserting a new row in G increases V(G) by
unity
6. V(G) depends only on decision structure of G.
There are two alternate methods to calculate the
Cyclomatic complexity. They are:
1. Cyclomatic complexity V(G) of a graph is equal
to the number of decision (predicate) nodes plus one
that is V(G) =  + 1.
Here,  is the number of predicate nodes contained
in the flow graph G. A predicate node is the one which
have two outgoing edges i.e. one for true condition and
other for false. If there are more than two outgoing edges
then the graph is to be changed such that each decision
node have two outgoing edges and if this is not possible
then this formula won’t be applicable.
2. Cyclomatic complexity is equal to the number
of regions of the flow graph.
Example: Consider the following flow graph and
calculate the Cyclomatic complexity by all three
methods.

www.neerajbooks.com
 www.neerajbooks.com
The solution to the above problem is:
Neeraj
Cyclomatic complexity can be calculated as
follows:
Publications
1 2
www.neerajbooks.com 3
It is a tabular representation of a flow graph. If we
assign weight to each entry then such a matrix with
weights is called connection matrix. If there is a
connection then weight 1 is assigned otherwise 0 is
assigned for no connection. The connection matrix is
also used to find the Cyclomatic complexity. To calculate
the Cyclomatic complexity from the connection matrix
we will sum each row and subtract 1 from each row.
Then add the column of result and add 1 to the sum of
column of result. This will give the V(G).
Each entry in the graph matrix represents a relation
between the pair. Squaring a matrix will give a new
matrix that expresses the relation between each pair of
nodes through one intermediate node with the
assumption that the node is transitive. Square matrix
represents all paths of two links long. The kth power of
matrix represents all paths of k links long.
www.neerajbooks.com
1. V(G) = e – n + 2P
= 13 – 10 + 2= 5
2. V(G) =  + 1= 4 + 1= 5
3. V(G) = number of regions = 5
3. Graph Matrices: In graph matrix based testing,
we convert our flow graph into a square matrix with
one row and one column for every node in a graph. The
size of the matrix is equal to the number of nodes in the
flow graph. The objective is to trace all links of the
graph at least once. The aim is to find the Cyclomatic
complexity V(G) and the independent paths. If the size
of the graph increases then it is difficult to do path tracing
manually.
In the graph matrix there is a place to put every
possible direct connection between any node and any
other node. A connection from node i to node j does not
tell that there is a connection between node j and node
i. If there are several links between any two nodes then
they are represented with a ‘+’ sign in the graph matrix.
For example:
Example: Consider the following flow graph and
draw the graph and connection matrices. Also find out
the Cyclomatic complexity and two link paths from a
node to any other node.
1
3
5 4
2
 www.neerajbooks.com

The solution to the above problem is: (b) Usage node: Node n  G(P) is a usage node
The graph and connection matrices are: of the variable v  V written as USE(v, n) if
1 2 3 4 5 and only if the value of variable v is used at
a 1 the statement fragment corresponding to node
2 n.
(c) Definition use( du-path): A definition use
d b 3
path with respect to a variable v is a path in
c f 4 PATHS(P) such that for some v ? V there are
g e h 5 define and usage nodes DEF (v, m) and USE(v,
Graph Matrix (A) n) such that m and n are the initial and final
nodes of the path.
1 2 3 4 5 Connections
(d) Definition clear(dc- path): A definition clear
1 1–1 = 0 path with respect to a variable v is a definition
1 2 use path in PATHS(P) with initial and final
nodes DEF(v, m) and USE(v, n) such that no
3 2–1= 1
1 1 other node in the path is a defining node of v.
1 1 4 2–1= 1 The objective of this testing is to find all the du- paths
1 1 1 5 3–1= 2 and then identify all those du- paths that are not dc-
paths.
Connection Matrix 4+1= 5

Neeraj
The steps that are followed are given below:
To find two link paths, generate a square of graph (a) Draw the program flow graph.
matrix [A] is required. (b) Find the DD path Graph.
1 2 3 4 5 (c) Prepare a table for define/use status of all
1 ad ab variables.
2 (d) Find all du paths

Publications
3 bc bf (e) Identify du-paths that are not dc paths.
4 fg fe fh Example: Consider the program for the determination
5 ed + hg he eb h2 of the nature of roots of a quadratic equation. Its input
is a triple of positive integers (say a, b and c) and values
[A2] may be from interval [0,100]. The program is given

www.neerajbooks.com
4. Data Flow Testing: It is another form of below:
structural testing. Here concentrate on the usage of #include <stdio.h>
variables and the focus points are: #include <conio.h>
(a) Statements where variables receive values. #include <math.h>
(b) Statements where these values are used or 1 int main()
referenced. 2 {
Flow graphs are used as a basis for data flow testing. 3 int a, b, c, validInput = 0, d;
Since the variable is defined and referenced throughout 4 double D;
the program there are a few define/reference anomalies: 5 printf (“Enter the ‘a’ value: ”);
(a) A variable is defined but not used. 6 scanf(“%d”, &a);
(b) A variable is used but not defined. 7 printf (“Enter the ‘b’ value: ”);
(c) A variable is defined twice before its use. 8 scanf(“%d”, &b);
Some definitions are required to be defined for data 9 printf (“Enter the ‘c’ value: ”);
flow testing. These definitions refer to the program P 10 scanf(“%d”, &c);
that has a graph G(P) and a set of variables V. The G(P) 11 if ((a>=0) && (a<=100) && (b>=0) &&
has a single entry and a exit node. The set of all paths (b<=100) && (c>=0) && (c<=100))
in P is PATHS(P). {
(a) Defining node: Node n  G(P) is a defining 12 validInput = 1;
node of the variable v  V written as DEF(v, n) 13 if (a == 0)
if and only if the value of variable v is defined {
at the statement fragment corresponding to 14 validInput = -1;
node n.

www.neerajbooks.com
 www.neerajbooks.com

15 } 30 }
16 } 31 else if ( validInput == -1) {
17 if (validInput == 1) { 32 printf (“Not a quadratic equation”);
18 d = b*b - 4*a*c; 33 }
19 if ( d== 0){ 34 else {
20 printf (“Equal roots and are r1 = r2 = %f\n”, - 35 printf (“Invalid Input”);
b/(2*(float)a)); 36 }
21 } 37 getche();
22 else if ( d > 0 ) { 38 return 1;
23 D=sqrt (d); 39 }
24 printf (“Real roots and are r1=%f and The output will be one out of the following:
r2=%f\n”, (-b-D) / (2*a), (-b + D) / (2*a)); 1. Not a quadratic Equation
25 } 2. Real roots
26 else { 3. Imaginary roots
27 D= sqrt(-d) / (2*a); 4. Equal roots
28 printf (“Imaginary roots and are r1 = (%f, %f) 5. Invalid input
and r2 = (%f, %f)\n”, -b / (2*a), D, - Find all du paths and identify those du-paths that are
b / (2*a), -D); definition clear.
29 }

Neeraj
The solution to the above problem is:
The flow graph is given below:

Publications
www.neerajbooks.com

www.neerajbooks.com
 www.neerajbooks.com

DD Path Graph is given below:

Neeraj
Publications
www.neerajbooks.com
Define/Use nodes for all variables are given below:
Variable Defined at node Used at node
a 6 11, 13, 18, 20, 24, 27, 28
b 8 11, 18, 20, 24, 28
c 10 11, 18
d 18 19, 22, 23, 27
D 23, 27 24, 28
Valid Input 3, 12, 14 17, 31
The du-paths are identified and are named by their beginning and ending nodes and even checked whether
definition clear or not.
Variable Path (beginning, end) nodes Definition clear?
a 6,11 Yes
6,13 Yes
6,18 Yes

www.neerajbooks.com
 www.neerajbooks.com

Variable Path (beginning, end) nodes Definition clear?

6, 20 Yes
6, 24 Yes
6, 27 Yes
6, 28 Yes
b 8, 11 Yes
8, 18 Yes
8, 20 Yes
8, 24 Yes
8, 28 Yes
c 10, 11 Yes
10, 18 Yes
d 18, 19 Yes
18, 22 Yes

Neeraj
18, 23 Yes
18, 27 Yes
D 23, 24 Yes
23, 28 Pathe not possible
27, 24 Path not possible

Publications
27, 28 Yes
Valid input 3, 17 No
3, 31 No

www.neerajbooks.com
12, 17 No
12, 31 No
14, 17 Yes
14, 31 Yes

Total du-paths are 26 out of which 4 paths are not
dentition clear path and two are impossible paths. We
should generate test cases for all 26 du-paths and if not
possible then at least generate 4 test cases for 4 du-paths
that are not definition clear paths.
5. Mutation Testing: Mutation testing is a fault
based testing. In this technique the changes are made in
certain statements in the source code and it is checked
if the test code is able to find any errors. It is used to
access the quality of the test case, i.e. whether they can
reveal certain types of faults.
For example, SDLC is viewed as a root finding
procedure. That is, a designer submits an initial guess which
is then iteratively tested for validity until a correct solution
is obtained. This is the principle of meta-induction.
The changed statements are called the mutants.
They are produced by applying the mutant operator. An
operator is essentially a grammatical rule that changes
a single expression to another. If more than one mutant
operator are applied then the result set of mutants will
be large, all of which must be killed by the test cases.
These mutants are run with an input data from a given
test set. If the mutant produces a different result than
the original program than the mutant is said to be killed
otherwise the mutant is said to be a live mutant. A mutant
is live if it is same as the original program, i.e. the
functionally identical to the original program or the test
data is inadequate to kill the mutant.
One difficulty associated with whether a mutant will
be killed is the problem of reaching the location; if a

www.neerajbooks.com
 www.neerajbooks.com
mutant is not executed it cannot be killed. Thus, special
test cases are to be designed to reach a mutant.
The manner by which a test suite is evaluated
through mutation testing is as follows:
For a specific test suite and a specific set of mutants,
there will be three types of mutants in the code, killed
or dead, live or equivalent. The sum of number of live,
killed and equivalent mutants will be the total number
of mutants created. The score associated with a test suite
T and mutants M is simply
#killed * 100%
# total - # equivalent
This equation allows us to determine the likelihood
that for a particular mutation adequate test suite will
catch real faults based on how well the suite killed
mutants.
Q. 1. What are the objectives of Software Testing?
Neeraj
Ans. Glen Myers states a number of rules that can
serve well as testing objectives :
1. Testing is a process of executing a program with
the intent of finding an error.
2. A good test case is one that has a high probability
Publications
of finding an as-yet undiscovered error.
3. A successful test is one that uncovers an as-yet
undiscovered error.
The above objectives imply a dramatic change in
view-point. They move counter to the commonly held
www.neerajbooks.com
view that a successful test in one in which no efforts are
found. Our objective is to design tests that systematically
uncover different classes of errors and do so with a
minimum amount of time and effort.
Successful testing will uncover errors in the
software. As a secondary benefit, testing demonstrates
that software functions appear to be working according
to specification and that performance requirements
appear to have been met. Also, data collected testing
provides a good indication of software reliability and
some indication of software quality as a whole.
However, testing cannot show the absence of
defects, it can only show that software errors are present.
It is important to keep this gloomy statement in mind as
testing is being conducted.
Q. 2. Write a short note on Black Box Testing?
Ans. It is also called Functional testing. The black
box refers to the software which is treated as a black
box. Here, testing is entirely based on the functionality
of the software program. Thus, functional testing is
related to testing, which involves observation of the
www.neerajbooks.com
output for certain input values. The code is never
considered in functional testing. The internal structure
of the program is ignored. Working of black box is
understood completely in terms of inputs and outputs
as shown below:
Q. 3. Write a short note on White Box Testing?
Ans. White-Box Testing–White-box testing, also
called glass-box testing, is a test case design method
that uses the control structure of the procedural design
to derive test cases. Using white-box testing methods,
the software engineer can derive test cases that:
(1) guarantee that all independent paths within a
module have been exercised at least once;
(2) exercise all logical decisions on their true and
false sides;
(3) execute all loops at their boundaries and within
their operational bounds; and
(4) exercise internal data structures to assure their
validity.
These tests are necessary in view of:
Logic errors and incorrect assumptions are
inversely proportional to the probability that a program
path will be executed. Errors tend to creep into our work
when we design and implement function, conditions, or
control that are out of the mainstream.
We often believe that a logical path is not likely to
be executed when, in fact, it may be executed on a
regular basis. The logical flow of a program is
sometimes counterintuitive, meaning that our uncon-
scious assumptions about flow of control and data may
leads us to make design errors that are uncovered only
once path testing commences.
Typographical errors are random. When a program
is translated into programming language source code,
it is likely that some typing errors will occur. Many will
be uncovered by syntax checking mechanisms, but other
will go undetected until testing begins. It is as likely
that a type will exist on an obscure logical path as on a
mainstream path.
Each of these reasons is a good reason for
conducting white-box tests. Black-box testing, no matter
how thorough, may miss the such errors. As Beizer has
stated : “Bugs lurk in corners and congregate at
boundaries.” White-box testing is far more likely to
uncover them.
 www.neerajbooks.com
Q. 4. What is equivalence partitioning?
Ans. Equivalence partitioning–Equivalence
partitioning is a black-box testing method that divides
the input domain of a program into classes of data from
which test cases can be derived. An ideal test case single-
handedly uncovers a class of errors (e.g., incorrect
processing of all character data) that might otherwise
required many cases to be executed before the general
error is observed. Equivalence partitioning tries to define
a test case that uncovers classes of errors, thereby
reducing the totals numbers of test cases that must be
developed.
Test case design for equivalence partitioning is
based on an evaluation of equivalent classes for an input
condition. If a set of objects can be linked by
relationships that are symmetric, transitive and
reflexive, an equivalence class is present. An
equivalence class represents a set of valid or invalid
states for input conditions. Typically, an input condition
Neeraj
is either a specific numeric value, a range of values, a
set of related values, or a Boolean condition.
Equivalence classes may be defined according to the
following guidelines:
1. If an input condition specifies a range, one valid
and two invalid equivalence classes are defined.
Publications
2. If an input condition requires a specific value,
one valid and two invalid equivalence classes are
defined.
3. If an input condition specifies a member of a set,
www.neerajbooks.com
one valid and invalid equivalence class are defined.
4. If an input condition is Boolean, one valid and
one invalid class are defined.
Applying the guidelines for the derivation of
equivalence classes, test cases for each input domain
data item could be developed and executed. Test cases
are selected so that the largest number of attributes of
an equivalence class are exercised at once.
Q. 5. Write a short note on Boundary Value
Analysis?
Ans. Boundary Value Analysis—For reasons that
are not entirely clear, a greater number of errors tend to
occur at the boundaries of the input domain than in the
“center.” It is for this reasons that Boundary Value
Analysis (BVA) has been developed as a testing
technique. Boundary values analysis leads to a section
of test cases that exercise bounding values.
Boundary value analysis is a test case design
technique that complements equivalence partitioning.
Rather than selecting any element of an equivalence
class, BVA leads to the section of test cases at the
“edges” of the class. And instead focusing only on input
www.neerajbooks.com
conditions, BVA derives test cases from the output
domain as well.
Guidelines for BVA are same in many respects as
provided for equivalence partitioning:
1. If an input condition specifics a range bounded
by values a and b, test cases should be designed
with values a and b, just below a and b,
respectively.
2. If an input condition specifies a number of
values, test cases should be developed that
exercise that minimum and maximum numbers.
Values just above and below minimum and
maximum are also tested.
3. Conditions (1) and (2) are applied to output
conditions also. Thus, if a temperature versus.
pressure table is required as output from a
engineering analysis program. Test cases
should be designed to create an output report
that produces the maximum (and minimum)
allowable number of table entries.
4. If internal program data structures have
specified boundaries (e.g., an array has a
defined limit of 100 entries), be certain to
design a test case to exercise the data structure
at its boundary.
Most software engineers intuitively perform BVA
to some degree. With above the guidelines, boundary
testing becomes more complete, and there is higher
likelihood for error detection.
Q. 6. Explain the use of basis Path Testing. What
is Cyclomatic Complexity?
Ans. Basis Path Testing–Basis path testing is a
white-box testing technique first proposed by Tom
McCabe. The basis path method enables the test case
designer to derive a logical complexity measure of a
procedural design and use this measure as a guide for
defining a basis set of execution paths. Test cases derived
to exercise the basis set are guaranteed to execute every
statement in the program at least once during testing.
Cyclomatic Complexity–Cyclomatic complexity
is a software metric that provides a quantitative measure
of the logical complexity of a program. When this metric
is used in the context of the basis path testing method,
the value computed for cyclomatic complexity defines
the number of independent paths in the basis set of a
program and provides an upper bound for the number
of tests that must be conducted to ensure that all
statements have been executed at least once.
Here, independent path is any path through the
program that introduces at least one new set of
processing statements or a new condition.
 www.neerajbooks.com
Q. 7. What is Data Flow Testing?
Ans. Data Flow Testing–The data flow testing
method chooses test paths of a program according to
the locations of definitions and uses of variables in the
program. There are number of data flow testing
strategies.
The data flow testing approach can be explained
with example. Each statement in a program be assigned
a unique statement number. Each function does not
modify its parameters or global variables. For a
statement with N as its statement number,
DEF (N) = {X | statement
N contains a definition of X}
USE (N) = {X | statement
N contains a use of X}
If statement N is an if or loop statement, its DEF
set is empty and its USE set is based on the condition of
statement N. The definition of variable X at statement
N is said to be live at statement N if there exists a path
Neeraj
from statement N to statement N that does not contain
any other definition of X.
A definition-use chain (or DU chain) of variable
X is of the form [X, N, N] , where N and N are statement
numbers, X is in DEF (N) and USE (N), and the
Publications
definition of X in statement N is live at statement N.
One simple data flow testing strategy is to require
that every DU chain be covered at least once. This
strategy is called the DU testing strategy. It has been
shown that DU testing does not guarantee the coverage
www.neerajbooks.com
www.neerajbooks.com
of all branches of a program. However, branch is not
guaranteed to be covered by DU testing only in rare
situations such as if-then-else constructs in which the
then part has no definition of any variable and else part
does not exist. In this situation, the else branch of the
above if statement is not necessarily covered by DU
testing.
Data flow testing strategies are useful for selecting
test paths of a program containing nested if and loop
statements.
Since the statements in a program are related to
each-other according to the definitions and uses of
variables, the data flow testing approach is effective for
error protection. However, the problems of measuring
test coverage and selecting test paths for data flow
testing are more difficult than the corresponding
problems for condition testing.
Q. 8. What do you mean by Loop Testing?
Ans. Loop Testing–Loops are the cornerstone for
the vast majority of all algorithms implemented in
software. Loop testing is a white-box testing technique
that deals exclusively with the validity of loop
constructs. For different classes of loops can be defined:
simple loops, concatenated loops, nested loops, and
unstructured loops.
(a) Simple loops–The following set of tests should
be applied to simple loops, where n is the maximum
number of allowable passes through the loop.
1. Skip the loop entirely.
2. Only one pass through the loop.
3. Two passes through the loop.
 www.neerajbooks.com
4. m passes through the loop where m < n.
5. n – 1, n, n + 1 passes through the loop.
(b) Nested loops–If we were to extend the test
approach for simple loops to nested loops, the number
of possible tests would grow geometrically as the level
of nesting increases. This would result in an impractical
number of tests.
1. Start at the innermost loop. Set all other loops
to minimum values.
2. Conduct simple loop tests for the innermost
loop while holding the outer loops at their
minimum iteration parameter (e.g., loop
counter) values. Add other tests for out-of-
range or excluded values.
3. Work outward, conducting tests for the next
loop, but keeping all other outer loops at
Neeraj
Publications
www.neerajbooks.com
www.neerajbooks.com
minimum values and other nested loops to
“typical” values.
4. Continue until all loops have been tested.
(c) Concatenated loops–Concatenated loops can
be tested using the approach defined for simple loops if
each of the loops is independent of the other. However,
if two loops are concatenated and the loop counter for
loop 1 is used as the initial value for loop 2, then the
loops are not independent. When the loops are not
independent the approach applied to nested loops is
recommended.
(d) Unstructured loops–Whenever possible, this
class of loops should be redesigned to reflect the use of
the structured programming constructs.
 www.neerajbooks.com
Development and Execution of Test Cases
Software testing accounts for the largest percentage
of technical effort in the software process. The objective
of software testing is to uncover errors. To fulfil this
objective, a series of test steps-unit, integration,
validation and system tests-are planned and executed.
Neeraj
Unit and integration tests concentrates on functional
verification of a component and incorporation of
components into a program structure whereas validation
testing demonstrates traceability to software
requirements and system testing validates software once
Publications
it is incorporated into the larger system. In a software
development project, errors can be injected at any stage
during the development. We have already discussed the
ways of locating the errors in the software product. Here,
www.neerajbooks.com
we will discuss the method of locating and correcting
the errors that are found in the software product. This
process is known as debugging which is viewed as an
art. Beginning with the symptomatic indication of a
problem, the debugging activity must track down the
cause of an error. Of the many resources available during
debugging the most valuable is the counsel of other
members of software engineering staff.
Program testing and fault detection can be aided
significantly by testing tools and debuggers. Testing/
debug tools include features such as:
Program monitors, permitting full or partial
monitoring of program code including
instruction set simulator, permitting complete
instruction level monitoring and trace
facilities, program animation, permitting step-
by-step execution and conditional breakpoint
at source level or in machine code and code
coverage reports.
www.neerajbooks.com
7
Formatted dump or symbolic debugging, tools
allowing inspection of program variables on
error or at chosen points.
Automated functional GUI testing tools are
used to repeat system-level tests through the
GUI.
Benchmarks, allowing run-time performance
comparisons to be made.
Performance analysis (or profiling tools) that
can help to highlight hot spots and resource
usage.
In this chapter, we will study about the debugging
process, testing tools and different types of test cases
and test plans.
DEBUGGING
The goal of testing is to identify the errors in the
program. The testing process tells that there is an error
whereas a program’s failure guarantees the presence of
an error. After this the cause and place of error is being
found. This process is called debugging. Hence,
debugging is the process of locating and correcting the
errors. Debugging is not testing but always occurs as a
consequence of testing. The outcome of the debugging
process can be any one of the following:
(i) The cause will be found, corrected and
removed, or
(ii) The cause will not be found.
While performing debugging guidelines that are to
be followed are:
1. Debugging is a process of solving a problem.
The cause of the error should be understood
before the debugging process starts.
 www.neerajbooks.com
2. Experimentation should not be done while
debugging because they may add new errors
instead of removing the previous ones.
3. If there is an error in one segment of a program
then there will be error in other parts of the
program also, so the program should be
examined properly.
4. Regression testing must be performed to ensure
that the new code added in the program to
remove errors is correct.
Debugging Process: During debugging errors are
encountered that range from less damaging to
catastrophic.
To debug an error found in the system following
steps should be performed:
Neeraj
Publications
www.neerajbooks.com
Debugging checks the correctness and the performance of software to do fault detection.
Difference between software testing and debugging can be shown as follows:
S. No. Software Testing
1. It is the process of executing the
program with the intent of finding faults.
2. It is a phase of Software Development
Life Cycle (SDLC).
3. Once code is written testing starts.
4. It comprises of verification and
validation of software.
5. It uses unit, integration and
system level testing.
www.neerajbooks.com
1. Identify the errors.
2. Design error report.
3. Analyze the errors.
4. Debugging tools are used.
5. Fix the errors.
6. Retest the software.
After the errors are fixed, the software is tested
again using regression testing in order to find out that
the new code inserted to correct a bug does not introduce
new errors. The debugging process starts with the
execution of a test case which when on failure will lead
to locate the cause of failure. Once the error is found
the cause of the error is found and corrected. This is
shown below with the help of a diagram:
Debugging
It is an activity of locating and correcting errors.
It is a consequence of testing.
It begins with the execution of test cases.
It attempts to match symptom with cause thereby
leading to error correction.
It checks the correctness and performance of the
software.
 www.neerajbooks.com
Debugging Approaches: Following are the
approaches for debugging the Software Under Test (SUT):
1. Brute Force Method: This method is most
common and least efficient for isolating the
cause of a software error. We apply this method
when all other fail. In this method, a printout
of all registers and relevant memory locations
is obtained and studied. All dumps should be
well documented and retained for possible use
on subsequent problems.
2. Trial and Error: This is a slow and a wasteful
approach. In this approach, the debugger looks
at the error symptoms and makes a judgement
to where the error will be located in the
program and jumps into and roam around in
the program with one or more debugging
techniques.
3. Backtracking: This approach is used to
examine the error symptoms to see where they
are noticed first. Then we back track the
Neeraj
program till the point where no symptoms are
seen. Generally, this program will tell the
location of the errors that occur in the program.
4. Insert Watch Points: Watch points or output
statements could be inserted at different places
Publications
in the program. In this approach, when we
insert the output statements we can trace a lot
of errors easily as if one watch point executes
without any problem then there is no error in
the program before that watch point. This will
www.neerajbooks.com
thus eliminate the problems involved with
adding adhoc-debugging statements to the
program manually.
www.neerajbooks.com
5. Induction and Deduction Approach:
Inductive Approach: The inductive approach
comes from the formulation of a single working
hypothesis based on the data, on the analysis
of existing data and on especially collected
data to prove or disprove the working
hypothesis. It can be performed by following
steps:
(a) Locate the Pertinent Data: It is the
enumeration of all the information i.e. what
the program did correct or incorrect that led
the system to have an error. Additional valuable
clues are provided by similar, but different, test
cases that do not cause the symptoms to appear.
(b) Organize the Data: Here, structuring of the
data is done to observe the patterns.
(c) Devise a Hypothesis: Here, the relationship
among the clues and devise using the patterns
that are observed in the previous step that cause
error is studied. Devise a theory amongst the
multiple theories that are possible and obtained
by devising and executing additional test cases.
(d) Prove the Hypothesis: This is the most
important step before fixing the error that
occurred in the program. It is vital to prove
the reasonableness of the hypothesis before
proceeding. The hypothesis is proved by
comparing it to the actual data making sure
that the hypothesis completely explains the
existence of the clues. If it does not either the
hypothesis is invalid, or the hypothesis is
incomplete or multiple errors are present.
It’s shown diagrammatically below:
 www.neerajbooks.com
Deductive Approach: This process begins with
enumerating all causes or hypothesis which is possible.
Then one by one particular causes are ruled out until a
single one remains for validation. The steps are as
follows:
(a) Enumerate The Possible Causes or
Hypothesis: In this step, we develop a list of
all causes of the error. They need not be
complete explanations.
(b) Use the Data to Eliminate Possible Causes:
By a careful analysis of the data, particularly
by looking for contradictions, one attempts to
eliminate all but one of the causes. If all causes
are eliminated then additional data will be
needed to devise new theories. If more than
one cause remains then the most probable one
is selected.
Neeraj
Publications
Debugging Tools: Each of the debugging approach
www.neerajbooks.com
can be supplemented with debugging tools. For it, we
can apply a wide variety of debugging tools such as
debugging compilers, dynamic debugging aids,
automatic test case generators, memory dumps and cross
reference maps.
TESTING TOOLS AND ENVIRONMENTS
To improve the quality and quantity of testing the
program should be made as pleasant as possible for the
tester. This means that tools should be concise, powerful
and natural as possible.
Since testing is of two types:
(i) Static testing
(ii) Dynamic testing.
So the two broad categories of software testing tools
are:
(i) Static tools
(ii) Dynamic tools.
Static testing tools seek to support the static testing
process whereas dynamic testing tools support the
dynamic testing process.
www.neerajbooks.com
(c) Refine the Remaining Hypothesis: The
possible cause at this point may be correct, but
it is unlikely to be specific enough to pinpoint
the error. In this step, the available clues are
refined to something more specific.
(e) Prove the Remaining Hypothesis: This is the
most important step before fixing the error that
occurred in the program. It is vital to prove
the reasonableness of the hypothesis before
proceeding. The hypothesis is proved by
comparing it to the actual data making sure
that the hypothesis completely explains the
existence of the clues. If it does not either the
hypothesis is invalid, or the hypothesis is
incomplete or multiple errors are present.
This is shown diagrammatically below:
Software testing tools are frequently used to ensure
consistency, thoroughness and efficiency in testing
software products and to fulfil the requirements of
planned testing activities. There are different types of
tools available and some of them are:
1. Static analysers, which examines program
systematically and automatically.
2. Code inspectors, who inspect the program to
ensure that they adhere to minimum quality
standards.
3. Standard enforcers, they impose simple rules
on the developer.
4. Coverage analysers, they measure the extent
of the coverage.
5. Output comparators, it will tell whether the
output of the program is appropriate or not.
6. Test file or data generators, they are used to
set up test inputs.
7. Test harness, they are used to simplify test
operations.
8. Test archiving systems, they are used to
provide documentation about the program.
 www.neerajbooks.com
The categories of testing tools are:
Static Testing Tools: Static testing tools are those
that are used to perform analysis of the programs without
executing them.
They may include the following:
Static Analysers: It operates from a precomputed
database of descriptive information derived from the
source text of the program. It is used to prove the
allegations which are claim about the analysed programs
that can be demonstrated by systematic examination of
all the cases. These are language dependent and need
high initial tool investment costs.
Code Inspectors: A job of enforcing standards in
a uniform way for many programs is done by code
inspector. These can be single or multiple statement
rules. It is also possible to build code inspector
assistance programs that force the inspector to do a good
job by linking to the process through an interactive
Neeraj
environment.
Standard Enforces: It is similar to code inspector
except that the rules here a bit simpler. It looks only at
the single statements instead of looking at the entire
program as done by the static analyser. Since only single
Publications
statements are involved the standards enforced tend to
be cosmetic ones because they enhance the readability
of the programs.
Other Tools: The related tools are used to catch
bugs indirectly through listings of the program that
www.neerajbooks.com
highlight the mistakes.
Dynamic Testing Tools: They support the dynamic
testing process. Besides individual tools that accomplish
these functions, a few integrated systems group the
functions under a single implementation.
A test consists of single invocation of the test object
and all the execution that ensures till the point when
test object returns control to the point where invocation
was made. Subsidiary modules can be real or even
simulated by testing stubs.
A series of tests are required to test a single or a
set of modules. Test support tools must perform the
following functions:
(i) Input Setting: Selection of test data that the
test object will read when called.
(ii) Stub Processing: When the stub is called it
handles outputs and selects inputs.
(iii) Results Display: Values produced by test
objects are provided so that they can be
validated.
www.neerajbooks.com
(iv) Test Coverage Measurement: In terms of the
structure of the program test effectiveness is
determined.
(v) Test Planning: Tests are being planned so they
are both efficient and effective at forcing
discovery of errors.
They may include the following:
Coverage Analyser: It is an execution verifier that
is most common and important tool for testing. CI
coverage the most common strategy for testing involves
declaring a minimum level of coverage that is expressed
in percentage of the elemental segments that are
exercised in aggregate during the testing process.
It is difficult to perform coverage analysis when
there is too little space or when non real-time operation
is equivalent to real-time operation.
Output Comparators: They are used in dynamic
testing both single and multiple module varieties to
check that predicted and actual outputs are equivalent.
It is also done during regression testing. Its objective is
to find the differences between two files; the old and
the new output from the program.
Test Files Generators: It creates a file of
information that is used as the program and does so
based on commands given by the user and or from data
descriptions program’s data definition section.
Test Data Generators: It is present for which no
general solution exists. On the other hand, there is a
practical need for methods to generate test data that meet
a particular objective, normally to execute a previously
unexercised segment in the program.
Test Harness Systems: It is the one that is bound
around the test object and that permits easy modification
and control of test inputs and outputs and provide for
online measurement of CI coverage. Some of them are
batch oriented, but the high degree of interaction
available in a full-interactive system makes it seem very
attractive in practical use.
Test-archiving Systems: Its goal is to keep track
of series of tests and to act as the basis for documenting
that the tests that have been done and that no defects
were found during the process.
TYPES OF TEST CASES AND TEST PLANS
Testing is concerned with errors, faults, failures and
incidents. A test is the act of exercising software with
test cases. A test has two goals-to find failures or to
demonstrate correct execution.
Test case describes an input description and an
expected output description. It has an identity and is
associated with the program behaviour. During testing
 www.neerajbooks.com
the preconditions are set and the required inputs are
given to the program. Execute the program. Compare
the observed output with the expected output of the
program. If the expected and observed outputs are
Test Case ID:
Section- 1
(Before Execution)
Purpose:
Pre-condition: (if any)
Inputs:
Expected Outputs:
Post conditions:
Written by:
Date:
The different types of test cases are as follows:
1. Integration Test Case
Neeraj
2. Functional Test case
3. Non-Functional Test cases (which include
security, performance and usability)
4. User Acceptance Test cases (end to end
scenario).
Validation Test Case: Here, all the above stated
Publications
techniques of test cases fall under validation test cases
itself; there is no separate test case for validation, when
we execute all the above test cases we can conclude we
have done the entire validation too.
www.neerajbooks.com
Verification Test Cases: After writing the entire test
cases, there will be some dedicated people who review
these test cases to check whether these test cases written
according to the requirements or not, in such a case it is
called verification test case and when we are executing
those test cases it is called validation test cases.
In a simple way expected results are verification
and actual results are validation.
Integration Test Case: Here, we execute test cases
which just tells about the connectivity from one module
to other module and integrating one application to other
application and how the application moves from parent
node to child node and vice versa.
Functional Test Case: Here, we execute test cases
which tell about the functionality of the application and
talks about the desired output to be seen. Internally we
have different type of test cases when we write here
like range, output values, BVA, ECP and so on. We give
input and expect some output according to the SRS.
Here we check individual module completely by
checking each and every tab, text box and buttons and
so on.
www.neerajbooks.com
different then there is a failure which should be recorded
properly in the test case with the cause of the error. If
both are same then the program behaved in the expected
manner. The template for a test case is as follows:
Section- 2
(After Execution)
Execution History:
Result:
If fails, any possible reason (Optional):
Any other observation:
Any suggestion:
Run by:
Date:
Non-Functional Test Case: Test cases related to
User friendliness like font, image, colour, how easy to
navigate etc, performance related, security related comes
under here.
User Acceptance Test Case: These test cases are
crucial and very important to client side people, because
these test case talks about their business and approach
of the application to complete a particular client task
which is also called as End-End-Business scenario test
case. Here we won’t be doing testing related to UI,
Functional or Non-Functional, we talk about business
and scenario which the application is made for.
A Software Test Plan is a document describing the
testing scope and activities. It is the basis for formally
testing any software product in a project.
Depending on the product and the responsibility
of the organization to which the test plan applies, a test
plan may include one or more of the following:
Design Verification or Compliance Test: To
be performed during the development or
approval stages of the product, typically on a
small sample of units.
Manufacturing or Production Test: To be
performed during preparation or assembly of
the product in an ongoing manner for purposes
of performance verification and quality
control.
Acceptance or Commissioning Test: To be
performed at the time of delivery or installation
of the product.
Service and Repair Test: To be performed as
required over the service life of the product.
 www.neerajbooks.com
Regression Test: To be performed on an
existing operational product, to verify that
existing functionality didn’t get broken when
other aspects of the environment are changed.
According to the IEEE standards the test plan
should contain the following:
Test Plan Identifier: It provides a unique identifier
for the document.
Introduction: It provides an overview of the test
plan. It also specify the goals/objectives and any
constraints.
References: It lists the related documents, with
links to them if available, including the project plan and
configuration management plan.
Test Items: It lists the test items (software/products)
and their versions.
Features to be tested: It lists the features of the
software product to be tested and provide references to
Neeraj
the requirements and or design specifications of the
features to be tested.
Features not to be tested: It lists the features of
the software product which will not be tested and specify
the reasons why these features won’t be tested.
Approach: It will mention the overall approach to
Publications
testing and specify the testing levels, testing types and
the testing methods.
Item pass/fail criteria: It will specify the criteria
that will be used to determine whether each test item
www.neerajbooks.com
i.e. software or product has passed or failed the testing
process.
Suspension Criteria and Resumption
Requirements: It will specify the criteria to be used to
suspend the testing activity. It also specifies the testing
activities which must be redone when testing is resumed.
Test Deliverables: It will list the rest of the
deliverables, and links to them if available including
test plan, test cases, test scripts, defect or enhancement
logs and test reports.
Test Environment: It will specify the properties
of test environment i.e. hardware, software, communi-
cations etc. It will also list any testing or related tools.
Estimate: It will provide a summary of test
estimates i.e. cost or effort and or provide a link to the
detailed estimation.
Schedule: It will provide a summary of the
schedule, specifying key test milestones and or provide
a link to the detailed schedule.
Staffing and Training Needs: It will specify the
staffing needs by role and required skills. It will also
www.neerajbooks.com
identify training that is necessary to provide those skills,
if not already acquired.
Responsibilities: It will list the responsibilities of
each team or role or an individual.
Risks: It will list all the risks that have been
identified in the software product. It will also specify
the mitigation plan and the contingency plan for each
risk that has been identified.
Assumptions and Dependencies: It will list the
assumptions that have been made during the preparation
of this plan. It will also list the dependences that are
present in the software or the product.
Approvals: It will specify the names and roles of
all the persons who must approve the plan that has been
made for the software product. If the document is printed
then it should provide space for signatures and dates.
There can be following types of test plans:
1. Master Test Plan: A single high-level test plan
for a project/product that unifies all other test
plans.
2. Testing Level Specific Test Plans: Plans for
each level of testing:
Unit Test Plan: Here, only one module or a
unit is considered.
Integration Test Plan: Here, the interaction
between one or more modules is considered.
System Test Plan: Here, the entire system is
in consideration.
Acceptance Test Plan: Here, the test plans
are taken in consideration from the point of
customers for whom the software product is
being made.
3. Testing Level Specific Test Plans: Plans are
major types of testing like Performance Test
Plan and Security Test Plan.
Q. 1. What is Debugging? Explain Debugging
Process?
Ans. Debbuging occurs as a consequence of
successful testing. That is, when a test case uncover an
error, debugging is the process that results in the removal
of the error. Although, debugging can and should be an
orderly process, it is still very much an art. A software
engineer, evaluating the results of a test, is often
confronted with a “symptomatic” indication of a
software problem. That is, the external manifestation
of the error and the internal cause of the error may have
no obvious relationship to one-another. The poorly
understood mental process that connects a symptom to
a cause is debugging.
 www.neerajbooks.com
Debugging
The Debugging Process: Debugging is not testing,
Neeraj
but it always happens as a consequence of testing. As
shown in above figure the debugging process begins
with the execution of a test case. Results are assessed
and a lack of corresponding data is a symptom of an
underlying cause as yet hidden. The debugging process
tries to match symptom with cause thereby leading to
Publications
error correction.
The debugging process will always have one of two
outcomes:
(i) The cause will be found, corrected and removed,
www.neerajbooks.com
or
(ii) the cause will not be found. In the latter case,
the person performing debugging may suspect
a cause, design a test case to help validate his or
her suspicion and work towards error correction
in an interactive fashion.
Q. 2. Why is Debugging difficult? Also mention
the characteristics of bugs that are encountered in
the Testing Process?
Ans. Debugging is considered difficult. But human
psychology has more to do with it than does software
technology. A few characteristics of bugs provide some
clues:
(i) The symptom and the cause may be
geographically remote. That is, the symptom
may appear in one part of a program, while the
cause may actually be located at a site that is far
removed. Highly coupled program structures
create this situation.
(ii) The symptom may disappear (temporarily less)
when another error is corrected.
(iii) The symptom may actually be caused by non-
errors (e.g., round-off inaccuracies).
www.neerajbooks.com
(iv) The symptom may be caused by human error
that is not easily traced.
(v) The symptom may be a result of timing problem,
rather than processing problems.
(vi) It may be difficult to accurately reproduce input
conditions (e.g.,a real-time application in which
input ordering is in-determinate).
(vii) The symptom may be intermittent. This is
particularly common in embedded systems that
couple hardware and software inextricably.
(viii) The symptom may be due to causes that are
distributed across a number of tasks running on
different processors.
During debugging, errors are found that range from
mildly annoying (e.g., an incorrect output format) to
catastrophic (e.g., the system fails, causing serious
economic or physical damage). As the consequences of
an error increase, the amount of pressure to find the
cause also increases. Often, pressure forces a software
developer to fix one error and at the same time introduce
two more.
Q. 3. Mention the different approaches of
Debugging?
Ans. Debugging Approaches: The objectives of
debugging is to find and correct the cause of a software
error. The objective is realized by a combination of
systematic evaluation, intuition, and luck. Bradley
describes the debugging approach in these words:
Debugging is a straight forward application of the
scientific method that has been developed over 2,500
years. The basis of debugging is to locate the problem’s
source by binary partitioning, through working
hypotheses that predict new values to be examined.
 www.neerajbooks.com

In general, there are three categories of debugging
approaches:
1. Brute force
2. Backtracking
3. Cause elimination.
1. The brute force debugging is probably the most
common and least efficient method for isolating the
cause of a software error. It is used, when all else fails.
Using a “let the computer find the error” philosophy,
memory dumps are taken, run-time traces are invoked,
and the program is loaded with WRITE statements.
Although, the mass of information produced may
ultimately lead to success, it more frequently leads to
wasted effort and time.
2. Backtracking is a fairly common debugging
approach used successfully in small programs.
Beginning at the site where a symptom has been
uncovered, the source code is traced backward
(manually) until the site of the cause is found. However,
as the number of source lines increases, the number of
potential backward paths may become unmanagebly
large.
3. The third approach to debugging: cause
elimination– is manifested by induction or deduction
and introduces the concept of binary partitioning. Data
related to the error occurrence are organized to isolate
potential causes. A “cause hypothesis” is devised and
the data are used to prove or disprove the hypothesis.
Alternatively, a list of all possible causes is developed
and tests are conducted to eliminate each. If initial tests
indicate that a particular cause hypothesis shows
promise, the data are refined in an attempt to isolate the
bug.
Each of the above debugging approaches can be
supplemented with debugging aids (“tracers”),
automatic test case generators, memory dumps and cross
references maps are used. However, tools are not a
substitute for careful evaluation based on a complete
software design document and clear source code.
Also, we can take help of other people in finding
the bugs.

Neeraj
Q. 4. Give the template for Test Case?
Ans. The template of the Test Case is as follows:
Test Case ID:
Section- 1 Section- 2

Publications
(Before Execution) (After Execution)
Purpose: Execution History:
Pre condition: (if any) Result:
Inputs: If fails, any possible reason (Optional):

www.neerajbooks.com
Expected Outputs: Any other observation:
Post conditions: Any suggestion:
Written by: Run by:
Date: Date:

Q. 5. Give the template for Test Plan? 3.7. Documentation Test

Ans. The template for test plan is as follows: 3.8. Beta Test
1. Introduction 3.9. User Acceptance Test
1.1. Test Plan Objectives 4. Environment Requirements
2. Scope 4.1. Data Entry workstations
2.1. Data Entry 4.2 Main Frame
2.2. Reports File Transfer 5. Test Schedule
2.3. File Transfer 6. Control Procedures
2.4. Security 6.1 Reviews
3. Test Strategy 6.2 Bug Review meetings
3.1. System Test 6.3 Change Request
3.2. Performance Test 6.4 Defect Reporting
3.3. Security Test 7. Functions to Be Tested
3.4. Automated Test 8. Resources and Responsibilities
3.5. Stress and Volume Test 8.1. Resources
3.6. Recovery Test 8.2. Responsibilities

www.neerajbooks.com
 www.neerajbooks.com

9. Deliverables 13.2. Technical

10. Suspension/Exit Criteria 13.3. Management
11. Resumption Criteria 13.4. Personnel
12. Dependencies 13.5 Requirements
12.1 Personnel Dependencies 14. Tools
12.2 Software Dependencies 15. Documentation
12.3 Hardware Dependencies 16. Approvals
12.3 Test Data & Database Q. 6. What is the difference between Static
13. Risks Testing and Dynamic Testing?
13.1. Schedule Ans. The difference between them is as follows:
Static Testing V/S Dynamic Testing
S. No. Static Testing Dynamic Testing
1. It does not require the actual execution It involves testing the software by actually
of software. executing it.
2. It is more cost effective. It is less cost effective.
3. It may achieve 100% statement It achieves less than 50% statement coverage
coverage in relatively short time. because it finds bugs only in part of codes

Neeraj
that are actually executed.
4. It usually takes shorter time. It may involve running several test cases,
each of which may take longer time than compilation.
5. It may uncover a variety of bugs. It uncovers limited types of bugs that are

Publications
explorable through execution.
6. It can be done before compilation. It can take place after executables are ready.

Q. 7. What are the different types of Testing i.e. they do not test the actual execution of the software.
Tools? They include the following:

www.neerajbooks.com
Ans. Different types of tools are:
1. Static analyzers, which examines program
systematically and automatically.
2. Code inspectors, who inspect the program to
ensure that they adhere to minimum quality
standards.
3. Standard enforcers, they impose simple rules
on the developer.
4. Coverage analyzers, they measure the extent
of the coverage.
5. Output comparators, it will tell whether the
output of the program is appropriate or not.
6. Test file or data generators, they are used to
set up test inputs.
7. Test harness, they are used to simplify test
operations.
8. Test archiving systems, they are used to
provide documentation about the program.
Q. 8. What are the Static Test Tools?
Ans. These tools do not involve actual input and
output rather they take a symbolic approach to testing
(a) Flow Analyzers: They ensure consistency in
data flow from input to output.
(b) Path Tests: They find unused code and code
with contradictions.
(c) Coverage Analyzers: It ensures that all logic
paths are tested.
(d) Interface Analysers: It examines the effects
of passing variables and data between modules.
Q. 9. What are Dynamic Test Tools?
Ans. These tools test the software system with ‘live’
data. They include the following:
(a) Test Drivers: It inputs data into a module-
under-test.
(b) Test Beds: It simultaneously displays source
code along with the program under execution.
(c) Emulators: The response facilities are used
to emulate parts of the system not yet
developed.
(d) Mutation Analyzers: The errors are
deliberately ‘fed’ into the code in order to test
fault tolerance of the system.

www.neerajbooks.com
 www.neerajbooks.com

SOFTWARE ENGINEERING CONCEPTS

Software Development Models

8

Software is not merely a collection of computer PROGRAM VERSUS SOFTWARE

programs. There is a distinction between a program and
a programming system product. A program is generally
complete in itself and is generally used only by the
author of the program. There is usually little
documentation or other aids which can help other people
use the program. Since the author is the user, the
Software is not just programs, it includes programs,
documentation of any facet of the program and the
procedures used to set up and operate the software
system. We can study the components of the software
systems in the Fig.1.1.

Neeraj
presence of bugs is not a major concern; if the program
crashes, the author will fix the program and start using
it again. These programs are not designed with such
big issues as portability, reliability and usability in mind.
However, a programming system product is used
largely by people other than the developers of the

Publications
system. The users may be from different backgrounds,
so a proper user interface is provided. There is sufficient
documentation to help these diverse users use the
system. Programs are thoroughly tested before put into
operation use, because users do not have the luxury of
fixing bugs that may be detected. Since the product may
Fig. 1.1. Components of Software
Software = Program + Documentation +
Operating Procedures
Any program is a subset of software and it becomes
software only if documentation and operating procedure

www.neerajbooks.com
be used in a variety of environments, perhaps on a manuals are prepared. A combination of source code
variety of hardware, portability is a key issue. and object code is known as program.
Documentation includes various types of manuals which are given below:
Formal Specification
Analysis / Context-Diagram
Specification
Data Flow
Diagrams

Flow Charts
Design
Entity Relationship
Diagrams
Documentation manuals
Source Code Listings

Implementation Cross-reference Listings

Test Data

Testing Test Results

www.neerajbooks.com
 www.neerajbooks.com

Operating procedures explains instructions to set up and use the software system and instructions on how to
react to system failure. We can study the list of operating procedures manuals/documents as follows:
System Overview
User Manuals Beginner’s Guide Tutorial

Reference Guide

Operating Procedure
Installation Guide

Operational Manuals System

Administration Guide
Software Process: The way in which we produce
software is known as the software process. This varies
from organization to organization. Beside hiring smart
and knowledge developers and buying the latest
development tools we also need to use effective software
time we spend developing better ways to work tomorrow
is not available for today’s project. But, software
organizations should not give up, but should take
motivation from long term benefits that many
organizations have enjoyed from sustained software

Neeraj
development processes, so that developers can
systematically use the best technical and managerial
practices to successfully complete their projects in the
highly competitive software business. To improve the
quality, productivity, predictability of their software
development and maintenance, organizations are
process improvement initiatives.
Software Characteristics: The software has a very
special characteristic and its nature is quite different
from other products. Various important characteristics
of software are:
1. Software does not Wear Out: In reliability

Publications
following software process improvement. Many
organizations are unable to achieve significant
improvements in the way they conduct their projects. It
is due to the following reasons:
studies for hardware products, there is a well known
bath tub curve. The shape of this curve is like bath tub
and so it is known as bath tub curve.

www.neerajbooks.com
1. Lack of time: Schedules are impractical which
leave insufficient time to do the significant project work.
Customers and senior managers demand higher quality
software in minimum possible time. Hence, there is
always lack of time.
2. Insufficient Knowledge: Many software
developers are not aware of industry best practices.
Software developers generally do not spend time reading
the literature to find out about the best known ways of
software development.
3. Wrong Motivations: At times, organizations
launch process improvement initiatives for the wrong
reasons. The basic motivation for software pros
improvement should be to avoid some of the current
difficulties faced on the project. People should be There are three phases for the life of the hardware
motivated to meet their commitments, improving product. Initial phase is burn-in phase; during this stage
customer satisfaction and delivering excellent products failure intensity is high. The second phase is the useful
that meet customer expectations. life phase and is called useful life of a product; failure
4. Lack of Commitment: Sometime, due to lack intensity is approximately constant during this stage.
of true commitment, the software process improvement Third phase is called the wear out phase where failure
fails. The investment we make in process improvement intensity will increase due to wearing out of components.
will not work on current productivity; it is because the The curve for software is:

www.neerajbooks.com
 www.neerajbooks.com
2. Software is not Manufactured: The life of the
software is from concept exploration to the retirement
of the software product. It takes one time effort to
develop the software and is maintained continuously to
keep it operational.
3. Reusability of Components: If we have to
manufacture a computer we may purchase picture tube
from one vendor, cabinet from other, design card from
Neeraj
third and other electronic component from fourth
vendor. We will assemble every party and test the
product thoroughly to produce a good quality computer.
In software, every project is a new project. We have to
start from the scratch to design a unit of the software
product. It requires huge effort to develop the software
Publications
which further increases the cost of the software product.
Effort has been made to design standard components
that may be used in new projects. Software reusability
has introduced another area and is known as component
based software engineering.
www.neerajbooks.com
4. Software is Flexible: A program can be
developed to do almost anything. Sometimes, this
characteristic is the best and helps to accommodate any
kind of change. We feel that software is flexible.
Software Applications: Software has become
integral part of each organization. Software applications
are grouped into eight areas which are as follows:
(i) System Software: Under this category
infrastructure software comes like compilers,
operating systems, editors, drivers etc. It is a
collection of programs to give service to other
programs.
(ii) Real Time Software: This software is used to
monitor, control and analyze real world events
as they take place. For example, the software
may be used for weather forecasting. Such
software will collect and process the status of
temperature, humidity and other environmental
parameters to forecast the weather.
(iii) Embedded Software: It controls the various
functions of the product and is placed in Read-
www.neerajbooks.com
Only-Memory (ROM): of the product. The
product can be aircraft, automobile, signalling
system, security systems, etc. It is also known
as intelligent software.
(iv) Business Software: It is the largest application
area. The software designed to process
business applications is known as business
software for example, payroll, file monitoring
system, employee management, account
management, management information
system, enterprise resource planning, etc.
(v) Personal Computer Software: The software
used in personal computers is Personal
Computer Software (PCS). For example, word
processors, computer graphics, multimedia and
animating tools, database management,
compute games, etc.
(vi) Artificial Intelligence Software: It uses non-
numerical algorithms to solve complex
problems that are not amenable to computation
or straight forward analysis. For example,
expert systems, signal processing software, etc.
(vii) Web Based Software: The software related
to web application is web based software. For
example, CGI, HTML, JAVA, Perl, DHTML
etc.
(viii) Engineering and Scientific Software:
Scientific and engineering application software
comes under this category. Huge computing is
normally required to process data. For
example, CAD/CAM package, Engineering
Pro, Circuit analyser etc.
DEFINITION OF SOFTWARE ENGINEERING
Software: Software is a critical important
infrastructure component. It is a key enabler for
militarily, economically, scientifically and culturally but
usually very expensive and of poor quality.
Software is often divided into two categories:
1. Systems Software: Includes the operating
system and all the utilities that enable the computer to
function.
2. Applications Software: Includes programs that
do real work for users. For example, word processors,
spreadsheets and database management systems fall
under the category of applications software.
At the first conference on software engineering in
1968, Fritz Bauer defined software engineering as “The
establishment and use of sound engineering principles
in order to obtain economically developed software that
is reliable and works efficiently on real machines.”
Stephen Schach defined it as “A discipline whose aim
 www.neerajbooks.com
is the production of quality software, software that is
delivered on time, within budget and that satisfies the
requirements”. It was meant to provoke thought
regarding perceived “software crisis”.
Software Crisis: The term is used to describe the
impact of rapid increases in computer power and the
complexity of the problems that could be tackled. It
refers to the difficulty of writing correct, understandable
and verifiable computer programs. Software crisis is
characterized by inability to develop the desired
Software Project because of the following problems:
Projects running over-budget.
Projects running over-time.
Software is inefficient.
Software is of low quality.
Software does not meet requirements.
Project is unmanageable/code difficult to
maintain.
The roots of the software crisis are complexity,
expectations and change. To avoid software crisis,
Neeraj
software engineering principles and process are applied
strictly.
Many software failure have been seen in past. Some
of them are:
(i) The Y2K problem: It was the most crucial
Publications
problem of the century. Earlier we used to write
only last two digits of the year. The 4 digit date
format, like 1987 was shortened to 2 digit
format like 87. The developers could not
visualize the problem of year 2000. Millions
www.neerajbooks.com
of rupees have been spent to handle this
problem.
(ii) The ‘star wars’ program of USA produced
‘Patriot missile’ and was used first time in Gulf
war but these missiles failed to hit the target.
So a review team was constituted to find out
the reason of failure and result was a software
bug.
Software Engineering: Software engineering is the
application of a systematic, disciplined, quantifiable
approach to the development, operation and
maintenance of software and study of the application
of engineering to software.
It is also defined as the systematic approach to the
analysis, design, assessment, implementation test, and
maintenance and re-engineering of software.
The objective of software engineering is to solve
the problems of cost, timeliness, maintenance and
quality by producing good quality, maintainable
software, on time, within budget. For this objective to
be achieved, one should take care of the quality of the
product and the process used to develop the product.
www.neerajbooks.com
Objectives of Software Engineering: Following
are the objectives of software engineering:
Understanding user conceptual models and
development of better specifications.
Improvement in design languages and reusable
code.
Participatory design and interactive debugging.
Specification of interface and mockup to
confirm specifications.
Software engineering aims at clarification and
fluidity of development.
This is software engineering separated out as
facilitation: the requirements are given and the
material is given (the limits and possibilities
of computation as elucidated by computer
science) – software engineering is left between
as the systematic activity to join these together.
The best it can do, then, is more fluidly
construct what we think we want, and more
clearly show what we have actually built. Think
of software engineering as a very broad kind
of tool. Its purpose is to be a tool that goes
easily where you point it and shows you clearly
where it is pointing – it lets you make what
you want, and shows you what you are making.
But this is just the essence of software; it is
what software does anyway. Software
engineering aims at clarity and fluidity because
these are what software essentially and
distinctively is about. A bit is precisely 0 or 1,
and easily changeable between them. Software
is clarity and fluidity.
This is a derivation of the aim of software
engineering from the other side – the material,
not the requirements. It tries to keep us close
to what software is.
SDLC MODELS
The goal of software engineering is to provide
models and processes that lead to the production of well-
documented maintainable software in a manner that is
predictable. When developing a software product,
software development organizations, follow some
processes. In immature organization the process is not
written down whereas in a mature organization the
process is in written and is actively managed. The
process is based on the life cycle model which is the
key component of any software development process.
The particular life cycle model can significantly affect
overall life cycle costs associated with a software
product. Life cycle starts from conceptual explanation
and ends at the retirement of the software.
 www.neerajbooks.com

In IEEE standard glossary of software engineering

terminology, the software life cycle is:
“The period of time that starts when a software
product is conceived and ends when the product is no
longer available for use. The software life cycle typically
includes requirement phase, design phase, implementation
phase, test phase, installation and check out phase,
operation and maintenance phase and sometimes
retirement phase.”
It is also called as Software Development Life
Cycle. This approach may work properly on small
Varieties of life cycle models have been proposed programming say for 100 or 200 lines long. There is no
and are based on tasks involved in developing and space for design or any aspect of development process
maintaining software. Some of them are as follows: to be carried out in a structure or detailed way. Cost for
1. Build and Fix Model: At times product is development using this approach is very high and even
constructed without specifications or any attempt at maintenance is an issue without the specification or
design. Instead the developer simply builds a product design documents.
that is corrected as many times as necessary to satisfy 2. The Waterfall Model: It is a sequential model.
the client. It is an adhoc approach and not defined This model has five phases. They are:
properly. It is a two phase model. First phase is to write

Neeraj
Requirement analysis and specification
code and the second phase is to fix the errors that are Design
encountered in the first phase or adding of new Implementation and unit testing
functionalities. This process is repeated many times till Integration and system testing
the product is not satisfactory. This is shown below with Operation and maintenance.
the help of a diagram:

Publications
The phases always occur in this order and do not overlap. Each phase must be completed before the next phase
begins. It is called as “Waterfall Model” since its diagrammatic representation is like a cascade of waterfalls.
The diagrammatic representation is shown below:

www.neerajbooks.com
Requi rement Analysis
and Specification

Design

Implementation and
Uni t Testing

Integration and
System Testing

Operation and
Maintenance

Waterfall Model

www.neerajbooks.com
 www.neerajbooks.com
The phases of waterfall model are described below:
1. Requirement Analysis and Specification: The
goal of this phase is to understand the exact requirements
of the customer and document them properly. Its
objective is to document all functions, performance and
interfacing requirements for the software and is executed
together with the customer. It describes “what” of the
system and not the “how” that is a large document,
written in natural language, contains the description of
what the system will do without describing how it will
be done. This document is called the software
requirement specification document. Thus, SRS for the
product is prepared in this phase.
2. Design Phase: The main goal of this phase is to
transform the requirements specification into a structure
that is suitable for implementation in some programming
language. Here, definition of the overall software
Neeraj
architecture is given and the high level and detailed
design work is performed. The documentation of this
work is known as Software Design Description (SDD)
document.
3. Implementation and Unit Testing Phase: The
Publications
design is implemented in this phase. The implementation
or coding phase begins on the completion of SDD
because all the information needed is contained in the
SDD. Here, small modules are tested first in isolation
www.neerajbooks.com
from the rest of the software product. Problems related
to how to test a single module in isolation without
anything to call it are solved in this phase and modules
are tested after writing some overhead code.
4. Integration and System Testing Phase: It is an
important phase. Effective testing will yield a higher
quality software product which will have more satisfied
users, lower maintenance costs and more accurate and
reliable results. It is an expensive activity as it consumes
almost half of the cost required to develop a software
product. Integration testing is performed to check
whether the interactions between module are correct or
not. System testing involves the testing of entire system,
whereas software is the part of the system.
5. Operation and Maintenance Phase: Software
maintenance is a task that every development group has
to face, when the software is delivered to the customer’s
site, installed and is operational. Time and effort required
www.neerajbooks.com
to keep the software operational after release is very
significant. Maintenance of software includes error
correction, enhancement of capabilities, deletion of
obsolete capabilities and optimization. The purpose of
this phase is to preserve the value of software over time.
Advantages of Waterfall Model are:
(a) Well defined phases with well defined output.
(b) It recognizes the sequence of software
engineering activities that shall result in a
software product.
Problems of Waterfall Model are:
(a) Difficult to define all the requirements at the
beginning of the project.
(b) Not suitable for accommodating any changes.
(c) Working model is not seen until late in the
project’s life.
(d) Does not scale up well for large projects.
(e) Real projects are rarely sequential.
3. Prototyping Model: A problem with waterfall
model that is the working model is not visible until late
in the project’s life thus delaying the discovery of serious
error is being overcome here. This is done by creating a
working prototype of the software instead of actually
developing the actual software. This working model is
developed according to the current working
requirements. The developers use this prototype to refine
the requirements and prepare the final requirement
specification document. The prototype once created is
handed to the customer for reviewing. This will help to
correct the requirements and remove uncertainties from
the software product. This is done iteratively for the
clarity of the software.
The prototype may be a usable program but it is
not suitable for the final software product because of
its poor performance, maintainability or overall quality.
It is a throw away prototype. Hence, developing of
prototype involves greater cost but overall cost will be
less than the one in the waterfall model.
The developers should develop the prototype as
early as possible to speed up the software development
process. A prototype is made just to know the actual
requirements of the customer for the software. Once
the requirements are gathered and documented in the
 www.neerajbooks.com

SRS the prototype is thrown away and the waterfall computers and therefore are unable to envisage
model approach is followed to develop the software. the features they need.
(b) The proposed system is expected to have
This model produces a good quality software but it
considerable user interface.
requires active participation of the customer which is (c) The development environment supports the
not possible always. quick creation of a prototype.
The diagrammatic representation of this model is (d) The proposed system has complex algorithms
shown in the following figure: or outputs that need to be refined.
Disadvantages of the Model are:
Requirements (a) Users on seeing working prototype expect to
see the actual system soon.
(b) If the prototype is not good enough the users
Quick Design get disappointed with the prototype and loose
interest in the system being developed.
Refinement of (c) Prototypes are made in hurry, often without
Implement requirements as per
suggestions evaluating all options, or understanding the full
implication of the technical choices made.
4. Iterative Enhancement Model: It has the
Customer Evaluation same phases as the waterfall model with few restrictions.

Neeraj
Not ac cepted by customer
The phases occur in the same order as in waterfall but
Accepte d by custome r
in several cycles. A usable product is released at the
Design end of each cycle with each release providing additional
functionality. During the first requirement analysis phase
as many requirements as possible are specified and a

Publications
Imple mentation and Unit SRS document is prepared. Then these requirements
Testing are being prioritized. Specific requirements are being
implemented in one or more cycles of design,
Integration and S ystem implementation and test based on defined priorities. This
model delivers an operational quality product at each

www.neerajbooks.com
Testing

release, but one that satisfies only a subset of the

Operation and customer’s requirements. The complete product is
Maintenanc e divided into releases and the product is delivered release
by release to the customer. With this model first release
is available within few weeks whereas with waterfall
Advantages of Prototype Model are: and prototype model it takes months or years to receive
(a) Users are unable to specify their requirements a product. The diagrammatic representation of this
or have no previous edge or experience of model is shown below:

Requirements Design Implementation Inte ration and Operation

and Unit Testing System Testing (Install)
Release 1

Design Implementation Integration and Operation

and Unit Testing System Testing (Install)

Release 2
Design Implementation Integration and Operation
and Unit Testing System Testing (Install)

Iterative Enhancement Model Release 3

www.neerajbooks.com
 www.neerajbooks.com
Advantages of Iterative Enhancement Model
are:
(a) Early delivery of parts of the functionality for
use.
(b) Feedback from the ‘live’ usage of the delivered
enhancements. This feedback can be used to
prevent similar issues in later releases.
(c) Staggered cash flows both for the user
organization and software organization.
(d) High priority features are incorporated in early
releases.
(e) Re-prioritization is possible in the course of
the project.
(f) Essential features can be released with smaller
teams.
Disadvantages of the Model are:
(a) Development cost gets higher.
(b) Time period for delivery of the entire product
is high.
(c) Planning the delivery enhancements is critical
to the success.
Neeraj
(d) First few releases need to be designed for
compatibility with subsequent releases.
5. Evolutionary Development Model: It
resembles iterative enhancement model. It has the same
phase as for waterfall model but here in a cyclical
fashion. It differs from iterative enhancement model int
Publications
www.neerajbooks.com
www.neerajbooks.com
the sense that it does not require a useable product at
the end of each cycle. Here, requirements are
implemented by category rather than priority.
For example, in a simple database application, one
cycle might implement Graphical User Interface (GUI);
another file manipulation; another queries and another
updates. All four cycles must complete before there is
working product available.
Evolutionary development and iterative
enhancement are somewhat interchangeable.
Evolutionary development should be used when it is
not necessary to provide a minimal version of the system
quickly.
It is used for projects using new technology that is
not well understood. It is used for complex projects
where all functionality must be delivered at one time,
but the requirements are unstable or not well understood
at the beginning.
6. Spiral Model: The problem with software
process models is that they do not deal sufficiently with
the uncertainty, which is there in the software projects.
Projects have failed because project risks are being
ignored. Barry Boehm recognized this and incorporated
it into a life cycle model. This model was known as
spiral model and was presented in 1986.
The Diagrammatic representation of the Spiral
Model is shown below:
 www.neerajbooks.com

The radial direction of the model represents the
cumulative cost. Increased cost is indicated by each path
around the spiral. The progress made in completing each
cycle is represented by the angular dimension. Each loop
of the spiral from X-axis clockwise through 360°
represents one phase. One phase is split into four phases.
They are:
1. Planning: It determines objectives, alter-
natives and constraints. Here, planning is done,
risks are analysed, prototypes are built and
customers evaluate the prototype.
2. Risk Analysis: It evaluates alternatives and
identifies and resolves the risks involved. In
this phase a more refined prototype is built,
requirements are documented and validated
and customers are involved in assessing the
prototype.
3. Development: In this phase, risks are known.
Here, product development and testing of
individual or groups of persons. If the developed plan
fails the spiral gets terminated otherwise it terminates
with the initiation of new or modified software.
Advantages of Spiral Model:
(a) Risk analysis is the integral part of the life cycle
and is performed in every spiral leading to
increased confidence in the software.
(b) The model is flexible and can be tailored for a
variety of situations.
(c) It incorporates software quality objectives into
software development.
Disadvantages of Spiral Model:
(a) Lack of explicit process guidance in
determining objectives, constrains and
alternatives.
(b) Proving more flexibility than required for many
applications.
7. Rapid Application Development Model: This

Neeraj
product is done. model was proposed by IBM in 1980 through the book
4. Assessment: In this phase, customer of James Martin entitled “Rapid Application
evaluation is done. Development”. In this model, the involvement of user
Identification of problems and classification of is essential from the starting till end that is from
these into different risk levels is the main focus of this requirement phase till the delivery of product.

Publications
model. An important feature of the spiral model is that
each phase is completed with a review by the people
concerned with the project. It includes review conducted
for all the products developed till that point and also
the plans for the next cycle. These plans may include a
The process is started with building a prototype
which is given to the user for evaluation. User gives the
feedback and the prototype is refined accordingly. This
process continues till the requirements of the product
have been finalized. Once the requirements are finalized

www.neerajbooks.com
partition of the product in smaller portions for
development or components that are implemented by
the SRS and design documents are prepared with the
association of users.
There are Four Phases of this Model they are shown below:

The phases of RAD model are:

1. Requirements Planning Phase: Using any one of the elicitation techniques requirements are being gathered
with the active involvement of the user for understanding the project.
2. User Description: Joint teams developers and users are constituted to prepare, understand and review the
requirements. Automated tools are being used to capture information from other users. Here, a prototype
is developed, evaluated and modified, till everyone agrees that the prototype fulfills the user’s needs.
3. Construction Phase: This phase combines the detailed design, coding and testing phase of waterfall
model. Here, the developers refine the prototype to create the production version of the system. The user
manual and docu-mentation required to maintain the system is developed in this phase.

www.neerajbooks.com
 www.neerajbooks.com

4. Cut Over phase: This phase incorporates
acceptance testing by users, installation of the
system and user training.
Advantages of RAD Life Cycle Model are:
(a) Reduces the amount of time taken to develop
database applications that have extensive user
interface.
(b) User participation in testing and development
of the software.
(c) RAD facilitates communication, so developers
can build better applications faster.
Disadvantages of RAD Life Cycle Model are:
(a) Difficult to achieve consistency within and
between applications developed by different
teams.
The Selection of the Model is based on the following:
(b) Design and coding standards are difficult to
implement and often ignored.
(c) Systems developed using RAD method tends
to be inefficient and weak in housekeeping
functions of the application.
Selection of a Life Cycle Model: The selection of
a suitable model is based on the following characteristics
(i) Requirements
(ii) Development team
(iii) Users
(iv) Project type and associated risk.
Requirements: Requirements are very important
for the selection of an appropriate model.

Requirements Waterfall Prototype Iterative Evolutionary Spiral RAD

enhancement development

Neeraj
Requirements are Yes No No No No Yes
easily understood and
defined
Requirements are No Yes No No Yes No
changed often?

Publications
Can requirements be Yes No Yes Yes No Yes
defined early in the
life cycle?
Are requirements No Yes Yes Yes Yes No

www.neerajbooks.com
indicating a complex
system to be built?
Development Team: The status of it is in term of availability, effectiveness, knowledge intelligence, etc., is
very important for the success of the project. Appropriate Life Cycle Model is choosen from the following:

Development team Waterfall Prototype Iterative Evolutionary Spiral RAD

enhancement development
Less experience on No Yes No No Yes No
similar projects
Domain knowledge is Yes No Yes Yes Yes No
less
Experience on tools is Yes No No No Yes No
less
Is training required? No No Yes Yes No Yes
Involvement of Users: Involvement of users increases the understandability of the project. Hence, user
participation is available plays a very significant role in the selection of an appropriate life cycle model. It is shown
below:

www.neerajbooks.com
 www.neerajbooks.com

Involvement of Users Waterfall Prototype Iterative Evolutionary Spiral RAD

enhancement de velopment
User involvement in No Yes No No No Yes
all phases
User participation is Yes No Yes Yes Yes No
limited
Users have no No Yes Yes Yes Yes No
previous experience of
participation in similar
projects
Users are experts of No Yes Yes Yes No Yes
problem domain
Type of Project And Associated Risk: Very few models incorporate risk assessment. Project type is also
important for selection of a model. It is shown below:
Project type and risk Waterfall Prototype Ite rative Evolutionary Spiral RAD
enhancement development
Project is the No No Yes Yes No Yes

Neeraj
enhancement of the
existing system
Funding is stable for Yes Yes No No No Yes
the project
High reliability No No Yes Yes Yes No

Publications
requirements
Project schedule is No Yes Yes Yes Yes Yes
tight
Use of reusable No Yes No No Yes Yes

www.neerajbooks.com
components
Are resources scarce? No Yes No No Yes No

communication of information (networks) and the

Q. 1. What do you mean by Software?
Ans. Software is:
(1) instructions (computer programs) that when
executed provide desired function and performance,
(2) data structures that enable the programs to
adequately manipulate information, and
(3) documents that describe the operation and use
of the programs. Software has a dual role. It is product
and at the same time, the means for delivering a product.
As a product, it delivers the computing potential of
computer hardware. Whether it resides within a cellular
phone or operates inside a mainframe computer,
software is an information transformer–producing
information that can be simple or complex. As the means
used to deliver the product, software is the basis for the
control of the computer (operating systems), the
creation and control of other programs (software tools
and environments).
Software delivers what many believe will be the
most important product of the 21st century–information.
Software transforms personal data (e.g. an individual’s
financial transactions) so that the data can be more useful
and it also provides the means for acquiring information
in all its forms.
Q. 2. Define Software Engineering?
Ans. Software engineering and encompasses
technologies that populate the software process –
technical methods and automated tools.
Software engineering is performed by creative,
knowledgeable people who should work within a
defined and mature software process. Software
engineering is the establishment and use of sound

www.neerajbooks.com
 www.neerajbooks.com

engineering principles to obtain economically software

that is reliable and works efficiently on real machines.
The IEEE has developed a more comprehensive
definition than above definition by Bayer. It states that
Software Engineering is :
The application of a systematic, disciplined,
quantifiable approach to the development, operation,
and maintenance of software; that is, the application of
engineering to software.
Q. 3. Mention the Software characteristics?
Ans. To have an understanding of software and
software engineering, it is important to know the
characteristics of software that make it different from Figure 1 : Failure curve for hardware
other things that human beings build. When hardware
is built, the human creative process (analysis, design, Software is not affected to the environmental
construction, testing) is ultimately translated into a problems that cause hardware to wear out. In theory,
therefore, the failure rate curve for software should take
physical form.

Neeraj
Software is a logical rather than a physical system
element. Therefore, software has characteristics that are
different from those of hardware :
1. Software is developed or engineered, it is not
the form shown in following Figure 2. Undiscovered
defects may cause high failure rates early in the life of a
program. However, these are corrected and the curve
flattens as shown. The curve is a simplification of actual
failure models for software. However, the meaning is
clear–software doesn’t wear out. But it does deteriorate!

Publications
manufactured. Although some similarities exist
between software development and hardware
manufacture, the two activities are entirely different. In
both high quality is achieved through good design, but

www.neerajbooks.com
the manufacturing phase for hardware can introduce
quality problems that are non-existent for software. Both
activities depend on people, but the relationship between
people applied and work accomplished is entirely
different. Software costs are concentrated in
engineering. This means that software projects cannot
be managed as if they were manufacturing projects.
2. Software doesn’t “wear out.”. Figure 1 depicts Figure 2 : Failure curve for software (Simplified)
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 attributes to design or
manufacturing defects); defects are corrected and the
failure rate drops to a steady-state level. As time passes
however, the failure rate rises again as hardware
components suffer from the cumulative affects of dust,
vibration, abuse, temperature extremes and other
Figure 3 : Failure curve for software (Simplified)
maladies. The hardware thus begins to wear out.

www.neerajbooks.com
 www.neerajbooks.com
This contradiction can best be explained by
considering Figure 3. During its life, software undergoes
change (maintenance). It is possible that some new
defects are introduced, causing the failure rate curve to
spike as shown in Figure. 3
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.
Also 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. Therefore, software maintenance
is more complexity than hardware maintenance.
3. Most software is custom-built, rather than
being assembled from existing components: Software
designers cannot assemble software. There are no
catalogs of software components. Off-the-shelf software
Neeraj
is a complete unit, not components that can be
reassembled into new programs.
Q. 4. Explain the Software Application Areas?
Ans. Software Application Areas: Software can
be used in any situation with defined set of procedural
Publications
steps (i.e., an algorithm except expert systems and
artificial neural network software). Information content
and determinacy are factors that decide the nature of a
software application. Content refers to the meaning and
www.neerajbooks.com
form of incoming and outgoing information.
Information determinacy refers to the predictability
of the order and timing of information. It is not easy to
define categories for software applications. As software
complexity grows, the dividing line disappears. The
following software areas indicated the scope of potential
applications:
System Software: System software is a group of
programs written to service other programs. Some
system software (e.g., compilers, editors and file
management utilities) processes complex, but
determinate, information structures. Other systems
applications (e.g., operating system components,
drivers, communications processors) process largely
indeterminate data.
Real-time Software: Programs that monitor/
analyze/control real world events as they take place are
called real-time software. Real-time software has a data
gathering component that collects and formats
information from an external environment, an analysis
www.neerajbooks.com
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 (typically ranging from 1 millisecond
to 1 minute) can be maintained.
Business Software: Business information
processing is the largest single software application area.
Discrete “systems” (e.g., payroll, accounts receivable/
payable, inventory, etc) have evolved into Management
Information System (MIS) software that accesses one
or more large databases containing business information.
Business software applications also use interactive and
client/server computing (e.g., point-of-sale transaction
processing).
Engineering and Scientific Software:
Engineering and scientific software are characterized
by “number crunching” algorithms. Applications range
from astronomy to oceanology, from chemical analysis
to spacecraft dynamics, and from particle acceleration
to autocad. However, new applications 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: Intelligent products are now
common in almost every consumer and industrial
market. 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., key pad control for a microwave oven) or provide
significant function and control capability (e.g., digital
functions in a TV set etc).
Personal Computer Software: The personal
computer software market is fastest growing market.
Word processing, spreadsheets, computer graphics,
multimedia, entertainment, database management,
personal and business financial applications,
and Internet access are only a few of hundreds of
applications.
Artificial Intelligence Software: Artificial
intelligence (AI) software makes use of non-numerical
algorithms to solve complex problems that are not
amendable to computation or straightforward analysis.
An active AI area is expert systems also called
knowledge-based systems. Other applications areas for
 www.neerajbooks.com

AI software are pattern recognition (image and voice), definition, technical development, solution integration
theorem proving, and game playing. In recent years, a coexist simultaneously at some level of detail. Given
new branch of AI software, called artificial neural the recursive nature Figure (b) the four stages apply
networks, is in vogue. A neural network simulates the equally to the analysis of a complete application and
structure of brain processes (the functions of the the generation of a small segment of code.
biological neuron) and may ultimately lead to a new Raccoon suggests a “Chaos model” that describes
class of software than can recognize complex patterns “software development (as) a continuum from the user
and learn from past experience. There are many other to the developer to the technology.”
software application areas. New applications are being
found virtually everyday.
Q. 5. What is software engineering paradigm?
Ans. To solve actual problems in an industry setting,
a software engineer or a team of engineers must
incorporate a development strategy that encompasses
the process methods and tools layers. This strategy is
often referred to as a process model or a software
engineering paradigm. A process model of software
engineering is chosen based on the nature of the project

Neeraj
and application, the methods and tools to be used and
the controls and deliverables that are required.
All software development can be characterized as
a problem solving loop in which four distinct stages are
encountered; status quo, problem definition, technical Figure (a) : The phases of a problems solving loop

development, and solution integration. Status quo

Publications
“represents the current state of affairs” problem
definition identifies the specific problem to be solved;
technical development solves the problem through the
application of some technology, and solution integration

www.neerajbooks.com
delivers the results (e.g., documents, programs, data,
new business function, new products to those who
requested the solution the first place. The generic
software engineering phases and steps map into these
stages.
The problem solving loop applies to software
engineering work at many different levels of resolution.
It can be used at the macro level when the entire
application is considered; at a middle level when
program components are being engineered and even at Figure (b) : The phases within phases of the problem-solving
the line of code level. Therefore, a fractal representation loop
can be used to provide an idealized view of process. In Q. 6. What do you mean by waterfall model?
Figure (b), each stage in the problem solving loop Ans. The waterfall model is also called Linear
contains an identical problem solving loop, which Sequential Model or ‘classic life-cycle.’
contains still another problem solving loop (this It suggests a systematic, sequential approach to
continues to some rational boundary; for software, a software development that starts right from system level
line of code). and goes through analysis, design, coding, testing and
This simplified view leads to very important idea : maintenance. Modelled after the conventional
Regardless of the process model that is chosen for a engineering cycle, the linear sequential model covers
software project, all the stages–status quo, problem the following activities :

www.neerajbooks.com
 www.neerajbooks.com
System/Information engineering and
Modelling: Software is always part of a larger system
(or business) hence work begins by establishing
requirements for all system elements and then allocating
Neeraj
some subset of these requirements to software. This
system view is essential when software must interface
with other elements such as hardware, people, and
databases. System engineering and analysis encom-
passes requirements gathering at the system level with
Publications
a small amount of top-level analysis and design.
Information engineering encompasses requirements
gathering at the strategic business level and at the
business area level.
www.neerajbooks.com
Software Requirements Analysis: The
requirements gathering process is intensified and
focused specifically on software. To understand the
nature of the programme(s) to be built, the software
engineer must understand the information domain for
the software, as well as required function, behaviour,
performance, and interfacing. Requirements for both the
system and the software are documented and reviewed
with the customer.
Design: Software design is actually a multistep
process that focuses on four distinct attributes of a
program: data structure, software architecture, interface
representations, and procedural (algorithmic) detail. The
design process translates requirements into a
representation of the software that can be assessed for
quality before code generation begins. The design is
documented and is part of the software configuration.
Code Generation: The design must be translated
into a machine readable form. The code generation step
performs this task.
www.neerajbooks.com
Testing: The testing process focuses on the logical
internals of the software, assuring that all statements
have been tested, and on the functional externals – that
is, conducting tests to uncover errors and ensure that
defined input will produce actual results that agree with
required results.
Maintenance: Software will undoubtedly
undergo change after it is delivered to the customer.
Change will occur because errors have been
encountered, because the software must be adapted to
accommodate changes in its external environment or
because the customer requires functional or performance
enhancements. Software maintenance reapplies each of
the preceding phases to an existing programme rather
than a new one.
Q. 7. What do you mean by prototyping model?
Ans. In general a customer defines a set of
objectives for software, but does not identify detailed
input, processing, or output requirements. In other cases,
the developer may be unsure of the efficiency of an
algorithm, the adaptability an operating system or the
form the human machine interaction should have.
In such situations, a prototyping paradigm offers
the best approach. The prototyping paradigm (Figure
below) starts with requirements gathering. Developer
and customer define the overall objectives for the
software, identify requirements and outline areas where
further definition is necessary. A “quick design” then
focuses on aspects of the software that are visible to the
customer/user (e.g., input approaches and output
formats). The quick design leads to the construction of
a prototype. The prototype is evaluated by the customer/
user and is used of refine requirements for the software
 www.neerajbooks.com
to be developed. Iteration occurs as the prototype is
developed to satisfy the needs of the customer and
enabling the developer to better understanding what
needs to be done.
The prototype serves as a mechanism for
identifying software requirements. If a working
prototype is built, the developer uses existing program
fragments or applies tools (e.g., report generators,
window managers, etc.) to make working programs
quickly.
According to Brooks, “In most projects, the first
system built is barely usable. It may be too slow, too
Neeraj
Publications
www.neerajbooks.com Figure : The Prototyping Paradigm
Q. 8. What is incremental model?
Ans. The Incremental Model: The incremental
model brings together elements of the linear sequential
model (applied repetitively) with the iterative philosophy
of prototyping. As figure below shows, the incremental
model applies linear sequences in a staggered fashion
as time moves. Each linear sequence produces a
deliverable “increment” of the software. For example,
word-processing software developed using the
incremental paradigm might deliver basic file
management, editing and document production functions
in the first increment; more sophisticated editing and
document production capabilities in the second
increment; spelling and grammar checking in the third
increment; and advanced page layout capability in the
www.neerajbooks.com
big, awkward in use or all three. There is no alternative,
but to start again, smarting but smarter and build a
redesigned version in which these problems are solved
.... When a new system concept or new technology is
used, one has to build a system to throw away, for even
the best planning is not so omniscient as to get it right
the first time. The management question, therefore, is
not whether to build a pilot system and throw it away.
You will do that. The only question is whether to plan
in advance to build a throwaway, or to promise to deliver
the throwaway to customers ....”
fourth increment. The process for any increment can
incorporate the prototyping paradigm.
In first increment is often a core product. That is,
basic requirements are addressed, but many
supplementary features (some known, others unknown)
remain undelivered. The core product undergoes
detailed review. As a result a plan is developed for the
next increment. The plan addresses the modification of
the core product of better meet the needs of the customer
and the delivery of additional features and functionality.
This process is repeated following the delivery of each
increment until the complete product is produced.
The incremental process model, like prototyping
and other evolutionary approaches, is iterative in
nature.
 www.neerajbooks.com

Neeraj
Fig.: The Incremental Model

Q. 9. What is spiral model?

Ans. The spiral model, proposed by Boehm, is an
evolutionary software process model that couples the
iterative nature of prototyping with the controlled and

Publications
systematic aspects of the linear sequential model. It
provides the potential for rapid development of
incremental versions of the software. In the spiral model,
software is developed in a series of incremental releases.

www.neerajbooks.com
The spiral model is divided into a number of
framework activities, also called task regions. Typically,
there are three to six task regions. Figure below shows
a spiral model that contains six task regions :
— customer communication tasks required to
establish effective communication between developer
and customer.
— planning tasks required to define resources,
timelines and other project related information.
— risk analysis tasks required to assess both
technical and management risks.
— engineering tasks required to build one or more
representations of the application.
— construction and release tasks required to
construct, test, install and provide user support (e.g.,
documentation and training).
— customer evaluation tasks required to obtain
customer feedback based on evaluation of the software
representations created during the engineering stage and
implemented during the installation stage.
Each of the regions has a series of work tasks that
are adapted to the characteristics of the project to be
undertaken. For small projects, the number of work tasks
and their formality is slow. For larger projects each task
region has more work tasks that are with higher level of
formality. In all cases, the umbrella activities (e.g.,
software configuration management and software
quality assurance) are applied.
The software engineering team moves around the
spiral in a clockwise direction, beginning at the core.
The first circuit may result in the development of a
product specification; subsequent passes around the
spiral may develop a prototype and then progressively
more sophisticated versions of the software. Each pass
through the planning region results in adjustments to
the project plan. Cost and schedule are adjusted based
on feedback derived from customer evaluation. Also

www.neerajbooks.com
 www.neerajbooks.com
the project manager adjusts the planned number of
iterations required to complete the software.
Unlike classical process models that end when
software is delivered, the spiral model can be adapted
to apply throughout the life of the computer software.
In essence the spiral remains operative until the
software is retired. There are times when the process is
dormant, but whenever a change is initiated, the process
starts at the appropriate entry point (e.g., product
enhancement).
The spiral model is a realistic approach to the
development of large scale systems and software.
Because software involves as the process progresses,
the developer and customer better understand and react
to risks at each evolutionary level. The spiral model
uses prototyping as a risk reduction mechanism. The
developer can apply the prototyping approach at any
stage in the evolution of the product.
Neeraj
However, the spiral model is also not a panacea. It
may be difficult to convince customers that the
evoluntionary approach is controllable. It demands
considerable risk assessment expertise, and relies on
this expertise for success. If a major risk is not uncovered
Publications
and managed, problems undoubtedly occur. The model
is relatively new and has not been used as widely as the
linear sequential or prototyping paradigms.
Q. 10. Mention the problems with waterfall
www.neerajbooks.com
model?
Ans. The linear sequential (waterfall) model is the
oldest and the most widely used paradigm for software
engineering. Among the problems that are sometimes
encountered within model are :
1. In practice, do not follow the sequential flow.
Although, the linear model can accommodate iteration,
it does so indirectly. As a result, changes can cause
confusion as the project proceeds.
2. It is often difficult for the customer to state all
requirements explicitly. The linear sequential model
requires this and has difficulty accommodating the
natural uncertainty that exists at the beginning of many
projects.
3. The customer must have patience. A working
version of the program(s) is available late in the project
time-span. A major blunder, if undetected until the
working program is reviewed, can be disastrous.
4. Developers are often delayed unnecessarily.
www.neerajbooks.com
Bradac found that the linear nature of the class life-cycle
leads to “blocking states” in which some project team
member must wait for other members of the team to
complete dependent tasks. In fact, the time spent waiting
can exceed the time spent on productive work. The
blocking states tend to be more prevalent at the
beginning and end of a linear sequential process.
Each of these problems is real. However, the
classific life-cycle paradigm has a definite and important
place in software engineering work. It provides a
template into which methods for analysis, design,
coding, testing and maintenance can be placed. The
classic life-cycle remains the most widely used process
model for software engineering. While it does have
weaknesses, it is much better than a haphazard approach
to software development.
Q. 11. Mention the problems with prototyping
model?
Ans. The prototype serves as “the first system.”
The one that Brooks asks us we throw away. But this is
an idealized view. It is true that both customers and
developers like the prototyping paradigm. Users get a
feel for the actual system and developers get to build
something immediately. Yet, prototyping is also be
problematic for the following reasons :
(1) The customer sees what looks-like a working
version of the software. He does not know that the
prototype is held together by “gene and wire,” and in
the rush to get it working no consideration for overall
software quality or long-term maintainability has been
given. He may ask that “a few fixes” be applied to make
the prototype a working product. Many times software
development management relents and quality suffers.
(2) The developer often compromises to get a
prototype working quickly. An inappropriate operating
system or programming language may be used simply
because it is available and known; an inefficient
algorithm may be used simply to show capability. After
a time, the developer may forget the reasons why they
were inappropriate. The choice then becomes integral
part of the system.
Inspite of such problems prototyping is an effective
paradigm for software engineering. The key is to define
the rules of the game at the beginning; that is, the
customer and developer must both agree that the
prototype is built to serve as a mechanism for defining
requirements. It is then discarded and the actual software
is engineered with desired and maintainability.
 www.neerajbooks.com

(i) Portability: It is the effort required to transfer

Q. What are the three P’s of the software the software from one hardware configuration
product? to another.
Ans. We can specify three dimensions of the (ii) Reusability: It is the extent to which parts of
product whose quality is to be assessed: the software can be reused in other related
1. Product Operations: The first factor of product applications.
operation deals with quality factors such as correctness, (iii) Interoperability: It is the effort required to
couple the system with other systems.
reliability and efficiency.
3. Product Revision: The product revision is
(i) Correctness: It is the extent to which a program
concerned with those aspects related to modification of
satisfies its specifications.
programs and includes factors like maintainability,
(ii) Reliability: It is the property which defines how
flexibility and testability.
well the software meets its requirements.
(i) Maintainability: It is the effort required to
(iii) Efficiency: It is a factor in all issues relating to
locate and fix errors in operating programs.
the execution of software and includes such
(ii) Flexibility: It is the effort required to modify
considerations as response time, memory
an operation program (perhaps to enhance its
requirements and throughput.
functionality).
(iv) Usability: It is the effort required to learn and

Neeraj
(iii) Testability: It is the effort required to test, to
operate the software properly. Hence, it is an
ensure that the system or a module performs its
important property that emphasizes the human
intended function.
aspect of the system.
2. Product Transition: The second factor of
product transition deals with equality factors like

Publications
portability and interoperability.

www.neerajbooks.com

www.neerajbooks.com
 www.neerajbooks.com
Software Project Management Concepts
Project management is the exercise of planning,
executing, organizing, securing and managing resources
to achieve specific goals. A project is a temporary
Neeraj
attempt with a defined beginning and end (usually time-
constrained and often constrained by funding or
deliverables), undertaken to meet unique goals and
objectives, typically to bring about beneficial change
or added value. The temporary nature of projects stands
Publications
in contrast with business as usual (or operations), which
are repetitive, permanent, or semi-permanent functional
activities to produce products or services. The
management of these two systems is often quite different
www.neerajbooks.com
and as such requires the development of distinct
technical skills and management strategies.
The primary challenge of project management is
to achieve all of the project goals and objectives with
taking in consideration the preconceived constraints.
Typical constraints are scope, time and budget. The
secondary and more ambitious challenge is to optimize
the allocation and integrate the inputs necessary to meet
pre-defined objectives.
Thus project management is the science and art of
organizing the components of a project that is whether
the project is development of a new product or the
launch of a new service or a marketing campaign or a
wedding. A project isn’t something that’s part of normal
business operations. It’s typically created once, it’s
temporary, and it’s specific. As one expert notes, “It
has a beginning and an end.” A project consumes
resources whether people, cash, materials, or time and
it has funding limits. Software project management is a
sub-discipline of project management in which software
projects are planned, monitored and controlled.
www.neerajbooks.com
9
Later in this chapter we will discuss about software
metrics that is a measure of some property of a piece of
software or its specifications and also the application of
PERT and GANTT charts.
PLANNING
After the finalization of SRS, one would like to
estimate size, cost and development time of the project
and sometimes even before the finalization of the SRS
one would like to know the cost and development time
of the project. Hence, it is a crucial decision for the
project and these are the key issues of the project
planning.
Planning is an aspect of project management, which
comprises of various processes whose aim, is to ensure
that various project tasks are well coordinated and they
meet the various project objectives including timely
completion of the project. Project Planning helps in:
Facilitating communication
Monitoring/measuring the project progress, and
Provides overall documentation of assumptions/
planning decisions.
Project planning generally consists of:
Determining how to plan (e.g. by level of detail
or rolling wave);
Developing the scope statement;
Selecting the planning team;
Identifying deliverables and creating the work
breakdown structure;
Identifying the activities needed to complete
those deliverables and networking the activities
in their logical sequence;
Estimating the resource requirements for the
activities;
 www.neerajbooks.com
Estimating time and cost for activities;
Developing the schedule;
Developing the budget;
Risk planning;
Gaining formal approval to begin work.
Project Planning is an ongoing effort throughout
the Project Lifecycle.
Software managers are responsible for planning and
scheduling project development. They supervise the
work and monitor the progress to check that
development is on time and within the budget. It must
incorporate the major issues like size and cost
estimation, scheduling, project monitoring and reviews,
The various steps of Project Planning Activities are shown below:
Size Estimation
Neeraj
Cost Estimation
Publications Resources Requirements
www.neerajbooks.com
EXECUTION
The Project Execution Phase is the next phase in
the project life cycle. In this phase, one will build the
physical project deliverables and present them to the
customer for signoff. The Project Execution Phase is
usually the longest phase in the project life cycle and it
typically consumes the most energy and the most
resources.
Execution consists of the processes used to
complete the work defined in the project plan to
accomplish the project’s requirements. Execution
process involves coordinating people and resources, as
well as integrating and performing the activities of the
project in accordance with the project management plan.
www.neerajbooks.com
personnel selection and evaluation and risk
management.
To have a successful software project one must
understand:
Scope of work to be done
The risk to be incurred
The resources required
The task to be accomplished
The cost to be expended
The schedule to be followed.
Planning the software begins before the technical
work starts, continues as the software evolves and
culminates when the software retires.
Development Time
Project Scheduling
The deliverables are produced as outputs from the
processes performed as defined in the project
management plan and other frameworks that might be
applicable to the type of project at hand.
To enable one to monitor and control the project
during this phase, they will need to implement a range
of management processes. These processes help them
to manage time, cost, quality, change, risks and issues.
They also help them to manage procurement, customer
acceptance and communications.
MONITORING
Monitoring consists of those processes performed
to observe project execution so that potential problems
can be identified in a timely manner and corrective
 www.neerajbooks.com
action can be taken, when necessary, to control the
execution of the project. The key benefit is that project
performance is observed and measured regularly to
identify variances from the project management plan.
Monitoring includes:
1. Measuring the ongoing project activities
(where we are).
2. Monitoring the project variables (cost, effort,
scope, etc.) against the project management
plan and the project performance baseline
(where we should be).
3. Identify corrective actions to address issues
and risks properly (How can we get on track
again).
4. Influencing the factors that could circumvent
integrated change control so only approved
changes are implemented.
In multi-phase projects, the monitoring process also
provides feedback between project phases, in order to
Neeraj
implement corrective or preventive actions to bring the
project into compliance with the project management
plan.
Project maintenance is an ongoing process, and it
includes:
Publications
Continuing support of end-users
Correction of errors
Updates of the software over time.
In this stage, auditors should pay attention to how
effectively and quickly user problems are resolved.
www.neerajbooks.com
Over the course of any construction project, the
program may change. Change is a normal and expected
part of the construction process. Changes can be the
result of design modifications, differing site conditions,
material availability, contractor-requested changes,
value engineering and impacts from third parties, etc.
Beyond executing the change in the field, the change
normally needs to be documented to show what was
actually constructed and what it has been after the
change. This is referred to as change management.
Hence, the owner usually requires a final record to show
all changes or, more specifically, any change that
modifies the portions of the finished work that is some
part of the existing program. The record is made on the
contract documents – usually, but not necessarily limited
to, the design drawings. The end product of this effort
is what the industry terms as-built drawings, or more
simply, “as built.” The requirement for providing them
is a norm in construction contracts.
When changes are introduced to the project, the
viability of the project has to be re-assessed. It is
www.neerajbooks.com
important not to lose sight of the initial goals and targets
of the projects. When the changes accumulate, the
forecasted result may not justify the original proposed
investment in the project.
CONTROL OF SOFTWARE PROJECTS
Project controlling should be established as an
independent function in project management. It
implements verification and controls functions during
the processing of a project in order to reinforce the
defined performance and formal goals. The tasks of
project controlling are:
1. The creation of infrastructure for the supply
of the right information and its update.
2. The establishment of a way to communicate
disparities of project parameters.
3. The development of project information
technology based on an intranet or the
determination of a project Key Performance
Index system (KPI).
4. Divergence analyses and generation of
proposals for potential project regulations.
5. The establishment of methods to accomplish
an appropriate project structure, project
workflow organization, project control and
governance.
6. Creation of transparency among the project
parameters.
Fulfillment and implementation of these tasks can
be achieved by applying specific methods and
instruments of project controlling. Some of the following
methods of project controlling can be applied to achieve
the tasks:
Investment analysis
Cost-benefit analysis
Value benefit analysis
Expert surveys
Simulation calculations
Risk-profile analyses
Surcharge calculations
Milestone trend analysis
Cost trend analysis
Target/actual-comparison.
Project control is that element of a project that keeps
it on-track, on-time and within budget. Project control
begins early in the project with planning and ends late
in the project with post-implementation review, having
a thorough involvement of each step in the process. Each
project should be assessed for the appropriate level of
control needed: too much control is very time consuming
and too little control is very risky. If it is not implemented
 www.neerajbooks.com
correctly, the cost to the business should be taken into
account in terms of errors fixes and additional audit
fees.
Control systems are needed for cost, risk, quality,
communication, time, change, procurement and human
resources. In addition, auditors should consider how
important the projects are to the financial statements,
how reliant the stakeholders are on controls and how
many controls exists. Auditors should review the
development process and procedures for how they are
implemented. The process of development and the
quality of the final product may also be assessed if
needed or requested. A business may want the auditing
firm to be involved throughout the process to catch
problems earlier on so that they can be fixed more easily.
An auditor can serve as a controls consultant as part of
the development team or as an independent auditor as
part of an audit.
Sometimes businesses use formal systems
Neeraj
development processes. These help in assuring that
systems are developed successfully. A formal process
is more effective in creating strong controls and auditors
should review this process to confirm that it is well
designed and is followed properly. A good formal
Publications
systems development plan outlines:
A strategy to align development with the
organization’s broader objectives.
Standards for new systems.
Project management policies for timing and
www.neerajbooks.com
budgeting.
Procedures describing the process.
Evaluation of quality of change.
SOFTWARE METRICS
According to Goodman software metric can be
defined as “The continuous application of measurement
based techniques to the software development process
and its product to supply meaningful and timely
management information, together with the use of those
techniques to improve that process and its products”.
Thus, it is a measure of some property of the software
or its specifications. Since quantitative measurements
are essential in all sciences, there is a continuous effort
by computer science practitioners and theoreticians to
bring similar approaches to software development. The
goal is obtaining objective, reproducible and
quantifiable measurements, which may have numerous
valuable applications in schedule and budget planning,
cost estimation, quality assurance testing, software
debugging, software performance optimization and
www.neerajbooks.com
optimal personnel task assignments. It is applicable in
the entire development of life cycle that is from
initiation, when cost must be estimated, to monitoring
the reliability of the end product and the way the product
changes over time with the enhancements made to it. It
also covers the techniques of monitoring and controlling
the progress of the software development. Motivations
of the metrics are as follows:
Estimate the cost and schedule of future
projects.
Evaluate the productivity impacts of new tools
and techniques.
Establish productivity trends over time.
Improve software quality.
Forecast future staffing needs.
Anticipate and reduce future maintenance
needs.
Areas of Application: The most well known area
of software metric is cost and size estimation techniques.
Many packages are available that provide estimates of
software system size, cost to develop a system and the
duration of the development or enhancement of the
project. These packages are based on estimation models,
like COCOMO, COCOMO-II developed by Barry
Boehm. A great deal of interest is generated in
controlling software development projects through
measurement and it has become more relevant with
software developers.
Another area where software metrics play an
important role is the prediction of quality levels for
software, often in terms of reliability.
The use of software metrics to provide quantitative
checks on software design is also a well established area.
This area is also used to control software products which
are in place and are subject to enhancement.
Software metrics are also used to provide
management information. It includes information about
productivity, quality and process effectiveness. It should
be seen as an ongoing activity. All this shows that
software metrics is a vast field and have a wide variety
of applications throughout the software life cycle.
Problems during Implementation: It is difficult
to implement software metrics of any size in an
organization. There are many problems that need to be
overcome and decisions to be made with a little amount
of information available. The first decision concerns
with the scope of the work. This tells that not too much
and too less work should be done on the software
metrics.
 www.neerajbooks.com
Another problem during implementation arises if
one starts measuring the performance of individuals.
Using measurement in this way is a worst mistake that
was made by the organizations as it is counterproductive,
divisive and simply ensures that developers will rig the
data they supply.
According to Goodman, some simple statements
that could be made by many in the industry together
with interpretation of current management trends will
illustrate the following points:
Statement: Software development is so
complex; it cannot be managed like other parts
of the organization.
Management view: Forget it, we will find
developers and managers who will manage that
development.
Statement: I am only six months late with this
project.
Management view: Fine, you are only out of
Neeraj
the job.
Statement: But you cannot put reliability
constraints in the contract.
Management View: Then we may not get the
contract. This list is endless and the message
is clear.
Publications
Software metrics cannot solve all our problems, but
they can enable managers to prove their processes, to
improve the productivity and quality, to improve the
probability of survival. But this is not an easy option.
Hence the use of software metrics does not ensure
www.neerajbooks.com
survival but it improves the probability of survival.
Categories of Metrics: There are three categories
of software metrics which are:
1. Product Metrics: It describes the
characteristics of the product such as size, complexity,
design features, performance, efficiency, reliability,
portability, etc.
2. Process Metrics: It describes the effectiveness
and quality of the processes that produce the software
product. Examples are:
Effort required in the process
Time to produce the product
Effectiveness of defect removal during
development
Number of defects found during testing
Maturity of the process.
3. Project metrics: It describes the project
characteristics and execution. Examples are:
Number of software developers
Staffing pattern over the life cycle of the
software
www.neerajbooks.com
Cost and schedule
Productivity.
Some metrics belong to multiple categories like
quality metric may belong to all three categories. It
focuses on quality aspects of the product process and
the project. Some other metrics are also there like data
structure metrics, size-oriented metrics, function-
oriented metrics, information flow metrics, etc.
APPLICATION OF PERT AND GANTT
CHARTS
Complex projects require a series of activities, some
of which must be performed sequentially and others that
can be performed in parallel with other activities. This
collection of sequential and parallel activities can be
clustered together as a network. Critical Path Method
(CPM) was developed as a network model for the
project management. It is a deterministic method which
uses a fixed time estimate for each activity. It is easy to
understand and use but the variation in time having great
impact on the completion time of a project is not
considered.
The Program Evaluation and Review Technique
(PERT) is a network model that allows for randomness
in activity completion times. It was developed in late
1950’s for the U.S. Navy’s Polaris project that had
thousand of contractors. It has the potential to reduce
both the time and the cost required to complete a project.
Thus a PERT chart is a graphic representation of a
project’s schedule, showing the sequence of tasks, which
tasks can be performed simultaneously and the critical
path of tasks that must be completed on time in order
for the project to meet its completion deadline. The chart
can be constructed with a variety of attributes, such as
earliest and latest start dates for each task, earliest and
latest finish dates for each task, and slack time between
tasks. A PERT chart can document an entire project or
a key phase of a project. The chart allows a team to
avoid unrealistic timetables and schedule expectations,
to help identify and shorten tasks that are bottlenecks,
and to focus attention on most critical tasks.
The Network Diagram: In a project, an activity
is a task that must be performed and an event is a
milestone marking the completion of one or more
activities. Before a new activity begins every
predecessor activity of that activity should be completed.
PERT is an activity on arc network in which activities
are represented on the lines and events on the nodes.
The following is a very simple example of a PERT
diagram:
 www.neerajbooks.com
Steps in PERT planning process: PERT planning
involves the following steps:
1. Identify the specific activities and milestones.
2. Determine the proper sequence of the
activities.
3. Construct a network diagram.
4. Estimate the time required for each activity.
Neeraj
5. Determine the critical path.
6. Update the PERT chart as the project
progresses.
1. Identify Activities and Milestones: The tasks
that are required to complete the project are the
Publications
activities. Milestones are the events that mark the
beginning and end of one or more activities. It is helpful
to list the tasks that can later be expanded to include the
sequence and the duration that task took to complete.
www.neerajbooks.com
2. Determine Activity Sequence: This step can
be combined with the first step since the activity
sequence is evident for some tasks. Other tasks require
more analyses to know the order of performance.
3. Construct the Network Diagram: Using the
sequence information a network diagram can be drawn
easily that shows the sequence of the activities. Software
packages simplify this step by automatically converting
tabular activity information into a network diagram.
4. Estimate Activity Times: Weeks are
commonly used unit of time for activity completion,
but any consistent unit of time can be used a
distinguishing feature is its ability to deal with
uncertainty in activity completion times. For each
activity it includes the three estimates these are:
Optimistic time: It is generally the shortest
time in which the activity can be completed.
Most likely time: It is the completion time
having the highest probability. It is different
from expected time.
www.neerajbooks.com
Pessimistic time: It is the longest time that an
activity might require. Three standard
deviations from the mean is commonly used
for the pessimistic time.
5. Determine The Critical Path: It is determined
by adding the times for the activities in each sequence
and determining the longest path in the project. It
determines the total time that is required to complete
the project. Since it determines the completion time of
the project, the project can be accelerated by adding
the resources required to decrease the time for the
activities in the critical path. Such shortening is
sometimes referred to as project crashing.
6. Update as Project Progresses: Adjustments
in the PERT chart are to be made as the project
progresses. As the project unfolds, the estimated times
can be replaced with the actual ones.
Benefits of PERT: PERT is useful because it
provides the following information:
Expected project completion time.
Probability of completion before a specified
date.
The critical path activities that directly impact
the completion time.
The activities that have slack time and that can
lend resources to critical path activities.
Activities start and end dates.
Limitations of PERT: The following are the
limitations of PERT:
Assume clearly defined, independent and stable
activities.
Activity times follow beta distribution.
Subjective activity times.
Over emphasis on critical path.
GANTT Charts: A Gantt chart is a type of bar
chart that illustrates a project schedule. It shows the start
and finish dates of the activities and summarizes the
activities of a project. They comprise the work
breakdown structure of the project. Some Gantt charts
also show the dependency (i.e., precedence network)
relationships between activities. Gantt charts can be used
to show current schedule status using per cent-complete
shadings and a vertical “TODAY” line. Although now
regarded as a common charting technique, Gantt charts
were considered revolutionary when they were
introduced. This chart is used also in Information
Technology to represent data that has been collected. A
Gantt chart is a graphical representation of the duration
of tasks against the progression of time. A Gantt chart
is a useful tool for planning and scheduling projects.
 www.neerajbooks.com
An example of GANTT Chart is shown below:
Neeraj
The horizontal axis is a time scale, expressed either
Publications
in absolute time or in relative time referenced to the
beginning of the project. Rows of bars in the chart show
the beginning and ending dates of the individual activity
in the project. In the above diagram every predecessor
www.neerajbooks.com
task of the next activity has already been completed.
However, the bars may overlap in cases where a task
can begin before the completion of another and there
may be several tasks performed in parallel. For this
reason Gantt chart is useful for communicating the
timing of the various tasks. For a larger project tasks
can be broken down into subtasks each having their own
Gantt charts to maintain readability.
Advantages of GANTT Chart: Some of the
advantages of GANTT Chart are as follows:
Cutting project cost and reducing the time scale.
Coordinating and expediting planning.
Eliminating the idle time.
Obtaining better scheduling and control for
subcontractor activities.
Developing better troubleshooting procedures.
Cutting time for routine decisions, but allowing
more time for decision making.
Disadvantages of GANTT Chart: The
disadvantages of GANTT Chart are:
www.neerajbooks.com
Estimates must be completed before the chart
is drawn.
It does not effectively address the dependencies
between jobs (although constraints can be added
as vertical lines).
Dependencies are hard to verify.
It is difficult to show two sets of dates when
using techniques such as earliest start date and
latest start.
It is difficult to show slack and critical path
without additional notation.
Changes to the schedule require redrawing of
the chart.
Several scheduling possibilities cannot be
shown in the same chart.
Resource assignments are not easy to illustrate.
Q. 1. What do you mean by Project Planning?
Ans. The software project management process
begins with a set of activities that are collectively called
project planning. The first of these activities is
estimation. Whenever estimates are made, we look into
the future and accept some degree of uncertianty as a
matter of course. To quote Frederick Brooks [BRO75]:
[O]ur techniques of estimating are poorly
developed. More seriously, they reflect an unvoiced
 www.neerajbooks.com
assumption that is quite untrue, i.e. that all will go
well.......... [B]ecause we are uncertain of our estimates,
software managers often lack the courteous
stubbornness to make people wait for a good product.
Although estimating is as much art as it is science,
this important activity need not be conducted in a
haphazard manner. Useful techniques for time and effort
estimation do exist. And because estimation lays a
foundation for all other project planning activities, and
project planning provides the road map for sucessful
software engineering, we would be ill-advised to embark
without it.
Q. 2. What are the three ‘P’s of effective
Software Project Management?
Ans. Effective software project management
stresses on the three P’s people, problem and process.
The order is not arbitrary. The manager who forgets
that software engineering work is an intensely human
effort will never succeed in project management. A
Neeraj
manager who fails to encourage comprehensive
customer communication early in the development of a
project may have an elegant solution for the wrong
problem. Finally, the manager who gives little attention
to the process runs the risk of inserting competent
technical methods and tools into a vacuum.
Publications
1. People: The cultivation of motivated, highly
skilled software people i.e. the “people factor” is so
important that the Software Engineering Institute has
developed a People Management Capability Maturity
Model (PM-CMM) “To enhance the readiness of
www.neerajbooks.com
software organizations to undertake increasingly
complex application by helping to attract, grow,
motivate, deploy, and retain the talent needed to improve
their software development capability”.
The people management maturity model defines
the following key practice areas for software people:
recruiting, selection, performance management, training,
compensation, career development, organization and
work design and team culture development.
Organization that achieve high levels of maturity in the
people management area have a higher likelihood of
implementing effective software engineering practices.
2. The Problem: Before a project can be planned,
its objectives and scope need to be established,
alternative solutions need to be considered and technical
and management constraints need to be identified.
Without this information, it is not possible to have
reasonable estimate of the cost; an effective assessement
of risk; A realistic breakdown of project tasks; or a
manageable project schedule that provides a meaningful
indication of progress.
www.neerajbooks.com
The software developer and customer must meet
to define project objectives and scope. Objectives and
scope are understood, alternative solutions are
considered. Although very little detail is discussed, the
alternatives enable managers and practitioners to select
“best” approach, given the constraints imposed by
delivery deadlines, budgetary restrictions, personnel,
technical interfaces and other factors.
3. The Process: A software process provides the
framework from which a comprehensive plan for
software development can be prepared. A small number
of framework activities are applicable to all software
projects, regardless of their size or complexity. A number
of different task sets– tasks, milestones, deliverables,
and quality assurance points – enable the framework
activities to be adapted to the characteristics of the
software project and the requirements of the project
team. Finally, umbrella activities – such as software
quality assurance, software configuration management,
and measurement – overlay the process model. Umbrella
activities are independent of any one framework activity
and occur throughout the process.
Q. 3. Mention the Objective of Project Planning?
How is it achieved?
Ans. Project Planning Objective: The objective
of software project planning is to provide a framework
that enables the manager to make reasonable estimates
of resources, cost, and schedule. These estimates are
made within a limited time frame at the beginning of a
software project and should be updated regularly as the
project progresses. Estimates try to define “best case”
and “worst case” scenarios so that project outcomes
can be bounded.
The planning objective is achieved through a
process of information discovery that leads to reasonable
estimates.
Q. 4. What are the steps in Project Planning?
Ans. Project Planning moves around the various
aspects of the Project. Generally, Project Planning is
considered to be a process of estimating, scheduling
and assigning the projects resources in order to deliver
an end product of good quality. However it is much
more as it can assume a very strategic role, which can
determine the success of the project. A Project Plan is
one of the crucial steps in Project Planning in General.
Project Planning can include the following types:
1. Project Scope Definition and Scope Planning.
2. Project Activity Definition and Activity
Sequencing.
3. Time, Effort and Resource Estimation.
 www.neerajbooks.com
4. Risk Factors Identification.
5. Cost Estimation and Budgeting.
6. Organizational and Resource Planning.
7. Schedule Development.
8. Quality Planning.
9. Risk Management Planning.
10. Project Plan Development and Execution.
11. Performance Reporting.
12. Planning Change Management.
13. Project Rollout Planning.
Q. 5. What does Monitoring include?
Ans. Monitoring includes the following:
1. It measures the ongoing project activities that
is tell about the exact position of the software.
2. It monitors the project variables like cost, effort,
scope, etc. against the project management plan
and the performance of the project that is it tells
where one should stand after considering all the
project variables.
Neeraj
3. Proper actions should be taken to address issues
and risks properly that is it decides how one
can get back on track.
4. It influences the factors so that only approved
changes are implemented by carrying the change
Publications
control process.
Q. 6. What are the tasks of project controlling?
Ans. The tasks of project controlling are:
1. Creating and updating of infrastructure for the
supply of right information.
www.neerajbooks.com
2. Finding of a way to communicate disparities of
project parameters.
3. Determining the project key performance index
system that is the KPI’s of the project or the
development of project information technology
based on an intranet.
4. For potential project regulations proposals are
generated and a divergence analysis is done.
5. To accomplish an appropriate project structure,
project workflow, control and governance
appropriate methods should be established.
6. Creating transparency amongst the project
parameters.
Q. 7. What is Software Metrics and Indicator?
Ans. Software metrics refers to a broad range of
measurements for computer software. Measurement can
be applied to the software process to improve it on a
continuous basis. Measurement can be applied
throughout a software project to help in estimation,
quality control, productivity assessment and project
www.neerajbooks.com
control. Also, measurement can assess the quality of
technical work products and assists in tactical decision
making as a project goes ahead.
In software project management, concern is
primarily with productivity and quality metrics–
measures of “output” as a function of effort and time
applied and measures of the “fitness for use” of the
products produced. For planning and estimating
purposes the interest is historical software development
productivity on past projects. The quality of the software
that was produced of past productivity and quality data
in the present product, planning and estimating more
accurately.
Metrics and Indicators: The terms “measure”,
“measurement” and “metrics” are often used
interchangeably, bit there is subtle differences between
them. Because “measure” and “measurement” can be
used either as a noun or a verb, definitions of the terms
can become confusing. In software engineering context,
a measure provides a quantitative indication of the
extent, amount, dimensions, capacity, or size of some
attribute of a product or process. Measurement is the
act of determining a measure. The IEEE Standard
Glossary of Software Engineering Terms defines metric
as “A quantitative measure of the degree to which a
system, component, or process possesses a given
attribute.”
A software metric relates the individual measures
in some way e.g.,the average number or errors found
per review or the average number of errors found per
person-hour expended on reviews.
A software engineer collects measures and develops
metrics so that indicators will be obtained. An indicator
is a metric or combination of metrics that provide insight
into the software process, a software project, or the
product itself. An indicator provides insight that enables
the project manager or software engineers to revise the
process, the project, or the product to make them better.
Q. 8. What is the use of metrics and indicators
in the Process and Project Domain?
Ans. Metrics in the Process and Project
Domains: Measurement is common place in the
engineering world. We measure speed, pressure, weight,
temperature, voltage, the list is endless. However,
measurement is far less common in the software
engineering world. The problem is what to measure
and what trouble evaluating metrics to use.
Metrics should be collected so that process and
product indicators can be ascertained. Process indicators
 www.neerajbooks.com
enable a software engineering organization to gain
insight into the efficacy of an existing process (i.e., the
paradigm, software engineering tasks, work products,
and milestone). They tell managers what works and what
doesn’t. Process metrics are collected across all project
and over long periods of time. They provide indicators
that lead to long-term software process improvement.
Project indicators enable a software project
manager to:
(i) assess the status of an on going project;
(ii) track potential risks;
(iii) uncover problem areas before they “go critical”;
(iv) adjust work flow or tasks; and
(v) evaluate the project team’s ability to control
quality of software engineering work products.
Sometimes, the same software metrics can be used
to determine both project and then process indicators.
In fact, measures that are collected by a project team
Neeraj
and converted into metrics for use during a project can
also be transmitted to those with responsibility for
software process improvement. For this reason, many
metrics are used in both process and project domain.
Q. 9. Define Project Metrics and explain their
Publications
use in Software Projects?
Ans. Project Metrics and their use: Software
process metrics are used for strategic purposes. Software
project measures are tactical. That is, project metrics
www.neerajbooks.com
and the indicators derived from them are used by a
project manager and a software team to adapt project
work flow and technical activities.
The first application of project metrics on software
projects takes place during estimation. Metrics collected
from past projects are used as a basis from which effort
and time duration estimates are made for current
software work. As a project programs, measures of
effort and time spent are compared to original estimates
and the project schedule. The project manager uses these
data to monitor and control progress.
As technical work begins, other project metrics
become significant. Production rates in terms of review
hours, function points and delivered source lines are
measured. Errors uncovered during each software
engineering task are tracked. As the software evolves
from specification into design, technical metrics are
collected to assess design quality and to provide
indicators that will influence the approach taken to code
generation and module and integration testing.
www.neerajbooks.com
The aim of project metrics is two fold. First, these
metrics are used to minimize the development schedule
by guiding the adjustment necessary to avoid delays and
mitigate potential problems and risks. Second, projects
metrics are used to assess product quality on an on-
going basis and when necessary, modify the technical
approach to improve quality.
As quality improves, errors count goes down, the
amount of re-work required is also reduced. This reduces
overall project cost. Another model of software project
metrics suggests that every project should measure.
(i) Inputs: measures of the resources (e.g. people,
environment) required to do the work.
(ii) Outputs: measures of the deliverables or work
products created during the software engineering
process.
(iii) Results: measures that indicate the effectiveness
of the deliverables.
This model can be applied to both process and
project. In the project context, the model can be
recursively as each framework activity occurs.
Therefore, the outputs from one activity become inputs
to the next. Results metrics can be used to provide an
indication of the usefulness of work products as they
flow from one framework activity (or task) to the next.
Q. 10. Explain in brief the following:
(1) Size-Oriented Metrics
(2) Function-Oriented Metrics
(3) Extended Function Point Metrics
Ans. Ans. 1. Size-Oriented Metrics: Size-oriented
software metrics are derived by normalizing quality and/
or productivity measure with reference to the “size” of
the software.With simple records, a table of size-
oriented measures as in Figure 4, can be created. The
table lists each software development project that has
been completed and corresponding measures for that
project. Referring to the table entry for project X, 10,000
Lines of Code (LOC) were developed with 20 person-
months of efforts at a cost of 5,000. The effort and cost
recorded in the table represent all software engineering
activities (analysis, design, coding, and testing), not just
coding. Further information for project shows pages of
documentation were prepared. 94 errors were recorded
before the software was released, and 13 defects were
encountered after release to the customer within the first
year of operation. Three people worked on the
development of software for the project.
 www.neerajbooks.com

Project LOC Effort $(000) pp. doc. Errors Defects People

X 10,000 20 500 250 95 13 2
Y 15,300 31 900 700 163 29 5
Z 19,800 42 1400 1250 246 48 8
• • • • •
• • • • •
• • • • •

Figure 4 : Size-oriented metrics

To develop metrics that can be assimilated with
similar metrics from other projects, we can choose lines
of code as the normalization value.
From the data given in the table, a set of simple
size-oriented metrics can be prepared for each project.
opponents that LOC measures are programming
language dependent; that they penalize well-designed
but shorter programs; that they cannot easily
accommodate non-procedural languages and that their
use in estimation requires a level of detail that may be

Neeraj
(i) errors per KLOC (thousand lines of code) difficult to acheive (i.e.,the planner must estimate the
(ii) defects per KLOC LOC to be produced long before analysis and design
(iii) Rs. per LOC have been completed).
2. Function-oriented Metrics: Function-oriented
(iv) pages of documentation per KLOC
software metrics use a measure of the functionality
Also, other interesting metrics can be computed.
delivered by the application as a normalization value.

Publications
(i) errors/person-month
“Functionality” cannot be measured directly, derived
(i) LOC per person-month
indirectly using other direct measures. Function-oriented
(i) Rs. 1 page of documentation. metrics were first proposed by Albrecht, who suggested
Size-oriented metrics are not accepted by all as the a measure called the functional point. Function points
best way to measure the process of software are derived using an empirical relationship based on

www.neerajbooks.com
development. The controversy is about the use of Lines
Of Code (LOC) as a key measure. Proponents of the
LOC measure that LOC is an “artifact” of all software
development projects and 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 predicate on LOC already exists. The assent,
countable (direct) measures of software’s information
domain and assessments of software complexity.
Function points are computed by completing the
table shown in Figure 5. Five information domain
characteristics are determined, and counts are provided
in the appropriate table location. Information domain
values are defined in the following way :

Weighting Factor
measurement parameter Count Simple Average Complex
number of user inputs × 3 1 6
number of user outputs × 4 5 7
number of user inquiries × 3 4 6
number of files × 7 10 15
number of external interface × 5 7 10
count = total
Figure 5. Computing function point metrics.

www.neerajbooks.com
 www.neerajbooks.com
Number of user inputs: Each user input that
provides separate application–oriented data to the
software is counted. Inputs are not inquires, which are
counted separately.
Number of user outputs: Each user output that
gives application–oriented information to the user is
counted. Output is reports, screens, error messages and
so on. Data item in report are not counted separately.
Number of user inquiries: An inquiry is defined
as an online input that results in the generation of some
immediate software response as on-line output. Each
distinct inquiry is counted.
Number of files: Each logical master file that may
be one part of a large database or a separate files.
Number of external interfaces: All machine
readable interface (data files on tape or disk) that are
used to transmit information to other system are counted.
After the above data is collected, a complexity value
Neeraj
is given to each count. There is criteria for determining
whether a particular entry is simple, average or complex.
The determination of complexity is somewhat subjective
To compute Function Points (FP), the following
relationship is used:
Publications
FP = count-total × [0.65 + 0.01 ×  Fi]
where count-total is the sum of all entries in
Figure 5.
The Fi (i = 1 to 14) are “complexity adjustment
www.neerajbooks.com
values” based on answers to questions about the 14
factors. The constant values and the weighting factors
that are applied to information domain counts are
determined exempirically.
Once fuction points have been calculated, they are
used in a manner analogous to LOC to normalize
measures of software productivity, quality, and other
attributes:
 errors per FP
 defects per FP
 Rs. per FP
 page of documentation per FP
 FP per person-month.
(iii) Extended Function Point Metrics: The
function point metric was originally designed to be
applied to business information systems applications.
To allow these applications, the data dimension was
emphasized to the exclusion of the functional and
behavioural (control) dimensions. Due to this function
www.neerajbooks.com
point measure i.e.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 as solution this
situation.
A function point extension called feature points, is
a superest of the function point measure that can be
applied to systems and engineering software application.
The feature point measure allows applications for which
algorithmic complexity is high. Real time, process
control and embedded software applications with high
algorithmic complexity are thus amenable to the feature
point.
To compute the feature point, information domain
values are counted and weighted. In addition, the feature
point measure counts a new characteristic, algorithms.
An algorithm is defined “A bounded computational
problem that is included within a specific computing
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 engineering products has been developed
by Boeing. It integrate the data dimension of software
with the functional and control dimensions to give a
function–oriented measure, called the 3D Function
Point. It is amenable to applications that emphasize
function and control capabilities. Characteristics of all
three software dimensions are “counted, quantified and
transformed” into a measure that offer an indication of
the functionality delivered by the software.’’
Function points, feature points, and 3D function
points represent the same thing–“functionality’’ or
“utility” delivered by software. 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 per cent higher than the count determined
using function points alone.
The fuction 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 non-procedural
languages, and 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.
 www.neerajbooks.com
Opponents assert that it involves deceptive as
computation is based on subjective data counting
difficult after the fact and FP has no direct physical
meaning, it is just a number.
Q. 11. What is the use of PERT and CPM project
scheduling methods in a software project?
Ans. PERT/CPM—Scheduling of a software
project is same as for any multitask engineering effort.
Hence, general project scheduling tools and techniques
can be applied to software with little modification.
Program Evaluation and Review Technique
(PERT) and critical path method (CPM) are the two
project scheduling methods used in technique software
development. Both techniques use information already
developed in earlier project planning activities :
— estimates of effort
— a decomposition of product function
Neeraj
— the selection of the appropriate process model
— the selection of project type and task set
Interdependencies among tasks may be defined
using a task network. Tasks, sometimes called the project
Work Breakdown Structure (WBS), are defined for the
Publications
product as a whole or for individual functions.
Both PERT and CPM offer quantitative that allow
the software planner to:
(1) determine the critical path–the chain of tasks
that determines the duration of the project;
www.neerajbooks.com
(2) establish most likely time estimates for
individual tasks by applying statistical models; and
(3) calculate boundary times that define a time
“window” for a particular task.
Boundary time calculations are very useful in
software project scheduling. Slippage in the design of
one function, for example, can retard further
development of the functions. Important boundary times
are:
(1) The earliest time that a task can begin when
all preceding tasks are completed in the
shortest possible time;
(2) The latest time for task initiation before the
minimum project completion time is delay;
(3) The earliest finish–the sum of the earliest start
and the task duration;
(4) The latest finish–the latest start time added
to tasks duration; and
www.neerajbooks.com
(5) The total that–the amount of surplus time or
leeway allowed in scheduling tasks so that
the network critical path is maintained on
schedule. Boundary time calculations lead to
a determination of critical path and provide
the manager with a quantitative method for
evaluating progress as tasks are completed.
Both PERT and CPM have been implemented in
a wide variety of automated tools that are available for
virtually ever personal computer. Such tools are easy to
use and make the scheduling methods available to every
software project manager.
Q. 12. What is the use of GANTT Charts in
Software Project?
Ans. Gantt Charts (Timeline Charts): When
creating a software project schedule, the planner begins
with a set of tasks. If automated tools are used, the work
breakdown is input as a task network or task outline.
Effort, duration and start data are then input for each
task. In addition, tasks may be assigned to specific
individuals.
As a consequence of this input, a Gantt chart, a
timeline chart, is generated. A timeline chart can be
developed for the entire project. Alternatively, separate
charts can be developed for each project function or for
each individual working on the project.
Figure illustrates that format of Gantt chart. It
depicts a part of a software project schedule that
emphasizes the concept scoping tasks for a new project
schedule that emphasizes the concept scoping task for
a new word-processing software product. All project
tasks are listed in the left hand column. The horizontal
bars indicate the duration of each task. When multiple
bars occur at the same time on the calendar, task
concurrency is implied. The diamonds indicate
milestones.
Once the information needed for Gantt chart is
input, the majority of software project scheduling tools
produce project tables–a tabular listing of all project
tasks, their planned and actual start an end dates, and a
variety of related information. Used alongwith the
timeline chart, project tables enable the project manager
to follow progress.
 www.neerajbooks.com

Work tasks week 1 week 2 week 3 week 4 week 5

1. Identify need and benefits

Meet with customers
Identify needs and project constraints
Establish product statement
Milestone : product statement defined
2. Defined desired output/control/input (OCI)
Scope keyboard functions
Scope voice input functions
Scope modes of interaction
Scope document diagnostics
Scope other WP functions
Document OCI
FTR: Review OCI with customer
Revise OCI as required;
Milestone : OCI defined

Neeraj
3. Define the functionality/behaviour
Define keyboard functions
Define voice input functions
Describe modes of interaction
Describe spell/grammar check

Publications
Describe other WP functions
FTR : Review OCI definition with customer
Revise as required
Milestone : OCI definition complete

www.neerajbooks.com
4. Isolate software elements
Milestone : Software elements defined
5. Research availability of existing software
Research text editing components
Research voice input components
Research file management components
Research spell/grammar check components
Milestone : Reusable components identified.
6. Define technical feasibility
Evaluate voice input
Evaluate grammar checking
Milestone : Technical feasibility assessed
7. Make quick estimate of size
8. Create a scope definition
Review scope document with customer
Revise document as required
Milestone : Scope document complete

www.neerajbooks.com
 www.neerajbooks.com

Neeraj
Publications
www.neerajbooks.com

www.neerajbooks.com
 www.neerajbooks.com
Software Engineering Fundamentals
The days when computer software development
was handled as part of documentation or general on the
agenda of a project meeting have gone long back. Now-
Neeraj
a-days, software has become the most important part. It
also plays an increasing role in business management.
Software’s development should be managed very
carefully. It needs the structured application of scientific
and engineering principles in order to analyze, design,
Publications
construct, document and maintain it.
In this chapter, we will study about good quality
software and how it can be achieved, software
configuration management and also the maintenance
of the software is considered as the important criteria.
www.neerajbooks.com
Quality of software can be ensured by some quality
control activities performed throughout the develop-
ment of the software.
SOFTWARE CONFIGURATION MANAGEMENT
Software configuration management is a task of
initiating, evaluating and controlling the changes to a
software product. Its practice includes revision control
and the establishment of baselines. Thus, Software
Configuration Management (SCM) is a set of activities
that are designed to control changes identified by the
work products that are likely to change, establishing
relationships among them, defining mechanisms for
managing different versions of these work products,
controlling changes that are imposed, auditing and
reporting on the changes that are made.
The process of software development and
maintenance is controlled is called configuration
management. Configuration management is an integral
part of the software development process across all
phases of the life cycle. It functions as a controlling
www.neerajbooks.com
10
discipline that enables changes to be made in the existing
documentation and products in such a way as not to
destroy the integrity of the software.
The goals of SCM are:
Configuration Identification: It identifies
configurations, configuration items and
baselines.
Configuration Control: It implements a
controlled change process. This is usually
achieved by setting up a change control board
whose primary function is to approve or reject
all change requests that are sent against any
baseline.
Configuration Status Accounting: It records
and reporting all the necessary information on
the status of the development process.
Configuration Auditing: It ensures that
configurations contain all their intended parts
and are sound with respect to their specifying
documents, including requirements, archi-
tectural specifications and user manuals.
Build Management: It manages the process and
tools used for builds.
Process Management: It ensures adherence to
the organization’s development process.
Environment Management: It manages the
software and hardware that host the system.
Teamwork: It facilitates team interactions
related to the process.
Defect Tracking: It makes sure every defect has
traceability back to the source.
Configuration Management Activities: There are
four categories of configuration management activities.
They are:
1. The identification of the components and
changes.
 www.neerajbooks.com
2. The control of the way by which the changes
are made.
3. Auditing the changes.
4. Status accounting-recording and documenting
all the activities that have taken place.
The required documents for these activities are:
Project plan
Software requirement specification document
Software design description document
Source code listing
Test plans/procedures/test cases
User manuals.
All components of the system’s configuration are
recorded along with the relationships and dependencies
between them. It must record all the changes that is
addition, deletion or modification on any system
component and its effect upon the rest of the system’s
components must be checked. A new configuration is
recorded after a change has been made.
Neeraj
Software Configuration Management Process:
It is an important element of software quality assurance.
Its responsibility is to control the changes made in the
software. It is also responsible for the identification of
software configuration items and various versions of
the software, the auditing and the reporting of all the
Publications
changes that are made to the software, applied to the
configuration. It introduces a set of complex questions
such as:
How does an organization identify and manage
the many existing versions of a program in a
www.neerajbooks.com
manner that will enable change to be accommo-
dated efficiently?
How does an organization control the changes
before and after the software is released to the
customer?
Who has the responsibility for approving and
ranking changes?
How can be ensured that changes have been
made properly?
What mechanism is used to appraise others of
changes that are made?
These questions lead us to the definition of the
software configuration tasks: Identification, version
control, change control, configuration auditing and
reporting.
Software Version: There will be at least two
versions of the software system during software
maintenance that is the old version and the new
version(s). Version control combines procedures and
tools to manage different versions of the configuration
objects that are created during the software process.
www.neerajbooks.com
During the process of software evolution, many objects
are created for example files, electronic documents,
paper documents, source code, executable code and
bitmap graphics. It is the first stage towards being able
to manage multiple versions. A detailed record of every
version of the software is kept once the version control
tool is in place. According to Clemm, configuration
management allows a user to specify alternative
configurations of the software system through the
selection of appropriate versions. This is supported by
associating attributes with each software version and
then allowing a configuration to be specified and
constructed by describing the set of desired attributes.
This comprises the:
Name of each source code component,
including the variations and revisions,
The versions of the various compilers and
linkers used,
The name of the software staff who constructed
the component.
The date and the time at which it was
constructed.
Change Control Process: It will be appropriate if
changes to the software can be predicted. Change control
process comes into effect when the software and
associated documentation are delivered to configuration
management change request form which should be able
to record the recommendations regarding the change.
This form is handed to change control authority which
determines whether a change has to be accepted or not
and only the approved changes are made to the software.
The change request form is shown below:
CHANGE REQUEST FORM
Project ID:
Change Requester with date:
Requested change with date:
Change analyser:
Components affected:
Associated components:
Estimated change costs:
Change priority:
Change assessment:
Change Implementation:
Date submitted to CCA:
Date of CCA decision:
CCA decision:
Change implementer:
Date submitted to QA:
Date of implementation:
Date submitted to CM:
QA decision:
 www.neerajbooks.com

Here, CCA refers to Change Control Authority, QA for quality assurance and CM for change manager.
According to James Bach, we can define change control as follow: “Change control is vital. But the forces that
make it necessary also make it annoying. We worry about change because a tiny disturbance in the code can create
a big failure in the product. But it can also fix a big failure or enable wonderful new capabilities. We worry about
change because a single rogue developer could sink the project; yet brilliant ideas originate in the minds of those
rogues and a burdensome change control process could effectively discourage them from doing creative work.”
For a large project an uncontrolled change would lead to a big chaos. For such projects change control process
should be applied. The change control process is explained schematically below:

Need fo r change is recognized

C hange requ est from user

Developer evalua tes

Change re port is gen erated

Change control authority decides

Neeraj
Request is queued for action, ECO generated Change request is denied

Assign individua ls to con figuration obje cts Use r is informed

“Check out” configura tio n objects (items)

Publications
Make the change

Review the change

“Check in” the c onfiguration items that have been changed

www.neerajbooks.com
Establish a ba seline for testing

Perform qua lity assura nce and testing activitie s

“Promote” c hanges for inclusion in the next release

Rebuild appropriate version of software

Review the change to all configu ration items

Include change in ne w version

Distribute the new version

The change control process is described below:
A change request is submitted and evaluated to
access technical merit, potential side effects, overall
impact on other configuration objects and system
functions, and the projected cost of change. The results
of the evaluation are presented as a change report, which
is used by a Change Control Authority (CCA) to make
the final decision on the status and priority of the change.
An Engineering Change Order (ECO) is generated for
each approved change which describes the change to
be made, the constraints that must be respected and the
criteria for review and audit. Now the object to be
changed is checked out of the project database, the
change is made and appropriate SQA activities are

www.neerajbooks.com
 www.neerajbooks.com
applied. The object is then checked in to the database
and appropriate version control mechanism is used to
create a next version of the software. The changes to all
configuration items are being audited and the changes
are included in the new version which is then distributed
to all.
SOFTWARE MAINTENANCE
Software maintenance is a task that every
development group has to face when the software is
delivered to the customer’s site, installed and is
operational. Commonly maintenance means fixing
things that break or wear down whereas in software
nothing wears out. Hence, software maintenance
includes error correction, enhancement of capabilities,
deletion of absolute capabilities and optimization.
Because change is unavoidable hence modifications are
required to be done on the software. So any work that is
done after the software is released and is operational is
the maintenance work. Its purpose is to preserve the
Neeraj
value of software over time. The value can be enhanced
by meeting additional requirements, expanding the
customer base, being easy to use, and being efficient
and using new technologies. It takes about 70% of the
cost of the entire life cycle to keep the software
operational after release.
Publications
Categories of Maintenance: There are four broad
categories of software maintenance. They are:
Corrective Maintenance: It refers to the
modifications that are initiated by the defects
www.neerajbooks.com
in the software. A defect can be a result of design
errors, logic errors and coding errors. Design
error occurs when the changes made to the
software are incorrect, incomplete, wrongly
communicated or the change request is
misunderstood. Logic errors occur when there
are invalid tests and conclusions; incorrect
implementation of design specifications, faulty
logic flow or incomplete test data is there.
Coding errors are caused when incorrect
implementation of detailed logic design and
incorrect use of the source code logic is there.
Defects also occur due to data processing errors
and system performance errors. Thus, corrective
maintenance includes all the changes made to
remove actual faults in the software.
Adaptive Maintenance: It refers to the
modifications of the software to match the
changes in the ever-changing environment. The
term environment here refers to the totality of
all conditions and influences which act from
outside upon the software, for example, business
www.neerajbooks.com
rules, government policies, work patterns or
software and hardware operating platforms.
Modification will be required for the change
occurring to the whole or part of the
environment. Thus, this type of maintenance
includes any work this is initiated by moving
the software to the different hardware or
software platform-compiler, operating system
or new processor.
Perfective Maintenance: It means improving
processing efficiency or performance or
restructuring the software to improve
changeability. When software becomes useful
it tries to expand its requirements. Expansion
of requirements can take the form of
enhancement of existing system functionality or
improvement in computational efficiency. Thus
this type of maintenance refers to enhancements:
making the product better, faster, smaller, better
documented, cleaner structured, with more
functions or reports.
Other Types of Maintenance: There are long
term effects of corrective, adaptive and
perfective changes which will lead to increase
in the complexity of the software that reflects
deteriorating structure. Preventive maintenance
should be done to maintain or reduce it. Thus,
this type of maintenance concerns activities
aiming on increasing software maintainability
and prevent problems in the future. Since,
software does not degrade in the same way as
hardware and does not need maintenance to
retain the presently established level of
functionality. Some authors do not use this term
that is why it is put under “other types of
maintenance” category.
The requests come regularly to carry out
maintenance activities. The request may be for
corrective, adaptive or perfective maintenance. The
distribution of maintenance effort is shown below:
 www.neerajbooks.com
Problems During Maintenance: The most
important problem during maintenance is that the
programmer must understand the problem before
correcting or modifying it. Then the impact of the
intended change on the problem should be understood.
Some of the problems with maintenance are discussed
below:
Program is written by person or group of
persons that work individually.
Often the program is changed by the person who
did not understand it properly which results in
a deterioration of the program’s original
organization.
Program listings, even those that are well
organized, are not structured to support reading
for comprehension.
Due to high staff turnover in the Information
Neeraj
Technology industry many systems are
maintained by persons who are not the original
author of the software and do not have adequate
knowledge about the system. This means that
these persons may introduce changes to
Publications
programs without being aware of their effects
on the other parts of the system- the ripple
effect.
Some problems become visible when the system
is in use. Due to information gap the users are
www.neerajbooks.com
unable to explain what their requirements are
from the system to the programmers/analysts.
Systems are not designed for changes. If there
is hardly any scope for change, maintenance will
be very difficult.
All these problems translate to a higher total cost
that is 40% to 70% for a system.
Potential Solutions to Maintenance Problems:
A number of possible solutions are suggested for
maintenance problem. They include:
Budget and Effort Reallocation: It is
suggested that more time and resources should
be invested in the development specification and
design of more maintainable system rather than
allocating resources to develop unmaintainable
www.neerajbooks.com
or difficult to maintain systems. To address this
issue the use of more advanced requirement
specification approaches, design techniques and
tools is done.
Complete Replacement of the System: If the
cost of developing a new system is equal to the
cost of maintaining an existing system then one
can develop the new system from scratch; but it
is not practical to do so. The risk and cost
associated with complete replacement of the
system is very high. Corrective and preventive
maintenance takes place at small intervals. The
creation of another system has no guarantee of
functioning properly or better than the previous
one and even on installation few errors can occur
which didn’t occur in the previous one and once
such error are discovered they need to be fixed
which will cost them more.
Maintenance of Existing System: Complete
replacement of the system is not a good option.
An operational system is itself an asset to an
organization in terms of the technical knowledge
and the working culture engendered. The current
system may need to have the potential to evolve
to a higher state, providing more sophisticated
user-driven functionality, the capability of
developing cutting edge technology and of
allowing the integration of other systems in a
cost effective manner.
The Maintenance Process: Firstly, what is to be
modified is understood by the maintenance personnel.
Now they modify the program to satisfy the maintenance
objectives. After modifications it must ensure that the
changes that are done do not affect the other parts of
the system. Finally, the program must be tested. These
activities can be accomplished in four phases that is:
1. Program understanding.
2. Generating particular maintenance proposal.
3. Accounting for ripple effect.
4. Testing and maintainability.
The diagrammatic representation of the software
maintenance process is shown below:
 www.neerajbooks.com

Correct program error

Determine Add new capabilities
maintenance objectives Delete absolute features
Optimization

Phase 1

Complexity
Program understanding
Documentation

Self descriptiveness

Phase 2

Generate particular
maintenance proposal Extensibility

Neeraj Phase 3

Publications
Account for ripple
effect Stability

www.neerajbooks.com Phase 4

Testing
Testability

Pass testing
No

1. Program Understanding: The first phase consists of analyzing the program in order to understand it.
Attributes like complexity, documentation, self descriptiveness, etc. contribute to the ease of understanding a program.
Complexity of the system usually based on the control or data flow of the program is the measure of the effort
required to understand a program. Self-descriptiveness of the program refers to the measure of the clarity of the
program that is how easy the program is to read, understand and use.

www.neerajbooks.com
 www.neerajbooks.com
2. Generating Particular Maintenance Proposal:
To accomplish the implementation of the maintenance
objective this phase consists of generating particular
maintenance proposal. A clear understanding is required
for the maintenance objective and the program to be
modified. It is affected by the attribute extensibility.
Extensibility is the measure to which a program can
support the extension of functions.
3. Ripple Effect: This phase consists of accounting
all the ripple effect that occurred due to modifications.
Modifications not only affect the portion where it is
performed but also to the other portions of the program.
Hence ripple effect occurs here. One aspect of this effect
is functional or logical in nature. It also concerns the
performance of the program. The stability of the
program is the main concern affecting the ripple effect
after the program modification. Program stability refers
to the resistance to the amplification of changes in the
program.
Neeraj
4. Modified Program Testing: To ensure that the
program has the same reliability level as it had before
modification, testing is performed on the modified
program in this phase. It is the primary factor that
constitutes to the development of the cost effective
Publications
techniques that are applied during maintenance. Program
testability is defined as the measure of the effort required
to adequately test the program according to the well
defined testing criterion.
5. Maintainability: Maintainability may be
www.neerajbooks.com
defined qualitatively as: the ease with which software
can be understood, corrected, adapted and/or enhanced.
Program maintainability and program understandability
are parallel concepts: the more difficult a program is to
understand, the more difficult it is to maintain and the
more difficult it is to maintain higher will be the
maintenance risk.
SOFTWARE QUALITY ASSURANCE
Software Quality Assurance (SQA) consists of a
means of monitoring the software engineering processes
and methods that is used to ensure quality. The methods
by which this is accomplished are many and varied and
may include ensuring conformance to one or more
standards, such as ISO 9000 or a model such as CMMI.
Software Quality: Quality is defined as
conformance to the stated and implied needs of
customer. Quality also refers to the measurable
characteristics of a software product and these can be
compared based on a given set of standards. In the same
way, software quality can be defined as conformance to
www.neerajbooks.com
explicitly stated and implicitly stated functional
requirements. Here, the explicitly stated functional
requirement can be derived from the requirements stated
by the customer which are generally documented in
some form. Implicit requirements are requirements
which are not stated explicitly but are intended. Implicit
functional requirements are standards which a software
development company adheres to during the
development process. Implicit functional requirements
also include the requirements of good maintainability.
Quality software is reasonably bug-free, delivered
on time and within budget, meets requirements and is
maintainable. However, as discussed above, quality is
a subjective term. It will depend on who the customer
is and their overall influence in the scheme of things.
Each type of ‘customer’ will have their own slant on
‘quality’. The end-use might define quality as some thing
which is user-friendly and bug-free.
Good quality software satisfies both explicit and
implicit requirements. Software quality is a complex
mix of characteristics and varies from application to
application and the customer who requests for it.
Attributes of Quality: The following are some of
the attributes of quality:
1. Ability to be Audited: The ability of the
software being tested against conformance to standard.
2. Compatibility: The ability of two or more
systems or components to perform their required
functions while sharing the same hardware or software
environment.
3. Completeness: The degree to which all the
software’s required functions and design constraints are
present and fully developed in the requirements
specification, design document and code.
4. Consistency: The degree of uniformity,
standardization and freedom from contradiction among
the documents or parts of a system or component.
5. Correctness: The degree to which a system or
component is free from faults in its specification, design
and implementation. The degree to which software
documentation or other items meet specified require-
ments.
6. Feasibility: The degree to which the require-
ments, design, or plans for a system or component can
be implemented under existing constraints.
7. Modularity: The degree to which a system or
computer program is composed of discrete components
such that a change to one component has minimal impact
on other components.
 www.neerajbooks.com
8. Predictability: The degree to which the
functionality and performance of the software are
determinable for a specified set of inputs.
9. Robustness: The degree to which a system or
component can function correctly in the presence of
invalid inputs or stressful environmental conditions.
10. Structured: The degree to which the SDD
(System Design Document) and code possess a definite
pattern in their interdependent parts. This implies that
the design has proceeded in an orderly and systematic
manner (e.g. top-down, bottom-up). The modules are
cohesive and the software has minimized coupling
between modules.
11. Testability: The degree to which a system or
component facilitates the establishment of test criteria
and the performance of tests to determine whether those
criteria have been met.
12. Traceability: The degree to which a
Neeraj
relationship can be established between two or more
products of the development process. The degree to
which each element in a software development product
establishes its reason for existing (e.g., the degree to
which each element in a bubble chart references the
Publications
requirement that it satisfies). For example, the system’s
functionality must be traceable to user requirements.
13. Understandability: The degree to which the
meaning of the SRS, SDD, code are clear and
understandable to the reader.
www.neerajbooks.com
14. Verifiability: The degree to which the SRS,
SDD and code have been written to facilitate verification
and testing.
Quality Assurance: The software engineering
approach described in this book works toward a single
goal: to produce high-quality software. Yet many readers
will be challenged by the question : “What is software
quality?”
Philip Crossly [CRO79], in his landmark book
on quality, provides a wry answer to this question:
The problem of quality management is not what
people don’t know about it. The problem is what they
think they do know....
In this regard, quality has much in common with
sex. Everybody is for it. (Under certain conditions, of
course.) Everyone feels they understand it. (Even though
they wouldn’t want to explain it.) Everyone thinks
execution is only a matter of following natural
inclinations. (After all, we do get along somehow.) And,
www.neerajbooks.com
of course, most people feel that problems in these areas
are caused by other people. (If only they would take the
time to do things right.)
Some software developers continue to believe that
software quality is something you begin to worry about
after code has been generated. Nothing could be further
from the truth! software quality assurance (SQA) is an
umbrella activity that is applied throughout the software
process. SQA encompasses :
(1) a quality management approach,
(2) effective software engineering technology
(methods and tools),
(3) formal technical review that are applied
throughout the software process,
(4) a multitiered testing strategy,
(5) control of software documentation and the
changes made to it,
(6) a procedure to assure compliance with
software development standards (when applicable), and
(7) measurement and reporting mechanisms.
Quality Concepts: It has been said that no two
snowflakes are alike. Certainly when we watch snow
failing it is hard to imagine that snowflakes differ at all,
let alone that each flames possesses a unique structure.
In order to observe differences between snowflakes, we
must examine the specimens closely, perhaps using a
magnifying glass. In fact, the closer we look, the more
differences we are able to observe.
This phenomenon, variation between samples,
applies to all products of human as well as natural
creation. For example, if two “identical” circuit boards
are examined closely enough, we may observe that the
copper pathways on the boards differ slightly in
geometry, placement and thickness. In addition, the
location and diameter of the holes drilled in the boards
varies as well.
All engineered and manufactured parts exhibit
variation. The variation between samples may not be
obvious without the aid of precise equipment to measure
the geometry, electrical characteristics, or other attribute
of the parts. However, with sufficiently sensitive
instruments, we will likely come to the conclusion that
no two samples of any item are exactly alike.
Does this principle apply to software as well as
physical items? Imagine a program that, at some point
during its execution, needs to sort records in ascending
order based on some key field. The nature of the records
 www.neerajbooks.com
is not important. They may be employee records, a
customer database, map coordinates for a real-time flight
control system, or whatever.
The programmer creating the sort routine (or
selecting it from a library of reusable components) elects
to use quicksort to solve the immediate problem. Can
an observer of the final product distinguish the software
from an otherwise identical product that uses, for
example , a bubble sort? Perhaps, but we probably need
more information and possibly sensitive instrumentation
to distinguish between the two systems.
Variation control is the heart of quality control. A
manufacturer wants to minimize the variation among
the products that are produced, even when doing
something relatively simple like duplicating diskettes.
We want to minimize the variation between any pair of
allegedly identical diskettes. Surely, this cannot be a
problem–duplicating disks is a trivial manufacturing
operation, and we can guarantee that exact duplicates
Neeraj
of the software are always created.
Or can we? We need to ensure the tracks are placed
on the diskettes within a specified tolerance so that the
overwhelming majority of floppy drives can read the
diskettes. In addition, we need to ensure that the
Publications
magnetic flux for distinguishing a zero from a one is
sufficient for read/write heads to detect. The disk
duplication machines can, and do, wear and go out to
tolerance. So even a “simple” process such as
duplication may encounter problems due to variation
www.neerajbooks.com
between samples.
How might a software development organization
need to control variation? From one project to another,
we want to minimize the difference between the
predicted resources needed to complete a project and
the actual resources used, including staffing, equipment,
and calendar time. In general, we would like to make
sure our testing program covers a known percentage of
the software from one releases to another. Not only do
we want to minimize the number of defects that are
released to the field, but we’d like to ensure that the
variance in the number of hugs is also minimized from
one release to another. (Our customers will likely be
upset if the third release of a product has ten times as
many defects as the previous release). We would like to
minimize the differences in speed and accuracy of our
hot line support responses to customer problems. The
list goes on and on.
1. Quality: The American Heritage Dictionary
defines quality as “a characteristic or attribute of some-
thing.” As an attribute of an item, quality refers to
www.neerajbooks.com
measurable characteristics–things we are able to
compare to known standards such as length, colour,
electrical properties, malleability and so on. However,
software, largely an intellectual entity, is more
challenging to characterize than physical objects.
Nevertheless, measures of a program’s character-
istics do exist. These properties include cyclomatic com-
plexity, cohesion, number of function points, lines of
code, and many other discussed earlier. 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.
Quality of conformance is the degree to which the
design specifications are followed during manufactur-
ing. 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.
2. 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 manufac-
turing 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 defined and measurable
specification to which we may compare the outputs of
each process. The feedback loop is essential to minimize
the defects produced.
 www.neerajbooks.com
3. 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.
4. Cost of Quality: Cost of quality includes all costs
incurred in the pursuit of quality or in performing quality
related activities. Cost of quality studies are conducted
to provide a baseline for the current cost of quality, to
identify opportunities for reducing the cost of quality,
and to provide a normalized basis of comparison. The
basis of normalization is almost always dollars. Once
we have normalized quality costs on a dollar basis, we
have the necessary data to evaluate where the
Neeraj
opportunities lie to improve our processes. Furthermore,
we can evaluate the affect of changes in dollar-based
terms.
Quality costs may be divided into costs associated
with prevention, appraisal, and failure. Prevention costs
Publications
include :
• quality planning
• formal technical reviews
• test equipment
• training
www.neerajbooks.com
www.neerajbooks.com
Appraisal costs include activities to gain insight into
product condition the “first time through” each process.
Examples of appraisal costs include :
• in-process and interprocess inspection
• equipment calibration and maintenance
• testing
Failure costs are costs that would disappear if no
defects appeared before shipping a product to customers.
Failure costs may be sub-divided into internal failure
costs and external failure costs. Internal failure costs
are the costs incurred when we detect an error in our
product prior to shipment. Internal failure costs include:
• rework
• repair
• failure mode analysis
External failure costs are the costs associated with
defects found after the product has been shipped to the
customer. Examples of external failure costs are:
• complaint resolution
• product return and replacement
• help line support
• warranty work
As expected, the relative costs to find repair a defect
increase dramatically as we go from prevention to
detection and from internal failure to external failure.
Figure on the nest page based on data collected by
Boehm [BOE81], illustrates this phenomenon.
More recent anecdotal data is reported by Kaplan
and his colleagues [KAP95] and is based on work at
IBM’s Rochester development facility:
 www.neerajbooks.com
A total of 7053 hours was spent inspecting 200,000
lines of code with the result that 3112 potential defects
were prevented. Assuming a programmer cost of $ 40.00
per hour, the total cost of preventing 3112 defects was
$ 282,120, as roughly $ 91.00 per defect.
Compare these numbers to the cost of defect
removal once the product has been shipped to the
customer. Suppose that there had been no inspections,
but that programmers had been extra careful and only
one defect per 1000 lines of code [singnificantly better
than industry average] escaped into the shipped product.
That would mean that 200 defects would still have to
be fixed in the field. At an estimated cost of $ 25,000
per field fix, the cost would be $ 5 million, or
approximately 18 times more expensive than the total
cost of the defect prevention effort.
It is true that IBM produces software that is used
by tens of thousands of customers and that their costs
for field fixes may be higher than average. This in no
Neeraj
way negates the results noted above. Even if the average
software organization has field fix costs that are 25 per
cent of IBM’s (most have no idea what their costs are),
the cost savings associated with quality control and
assurance activities are compelling.
Publications
Quality Movement: Today, senior managers at
companies throughout the industiralized world
regognize that high product qauality translates to cost
saving and an improvied bottom line. However, this was
not always the case. The quality movement began in
www.neerajbooks.com
the 1940s with the seminal work of W. Edwards Deming
[DEM86] and had its first true test in Japan. Using
Deming’s ideas as a cornerstone, the Japanese have
developed a systematic approach to the elimination of
the root causes of product defects. Throughout the 1970s
and 1980s, their work migrated to the Western world
and is sometimes called “Total Quality Management
(TQM)”. Although, terminology differs across different
companies and authors a basis four-step progression is
normally encountered and forms the fondation of any
good TQM program.
The first step is called kaizen and refers to a system
of continuous process improvement. The goal of kaisen
is to develop a process (in this case, the software
process) that is visible, repeatable, and meaurable.
The second step, invoked only after kaizen has been
achieved, is called atarimae hinshitsu. This step
examines intangibles that affect the process and works
to optimize ehtier impact on the process. For example,
the software process may be affected by high staff
turnover, which itself is caused by constant
www.neerajbooks.com
recognizations within a company. It may be that a stable
organizational structure could do much to improve the
quality of software. Atarimae hinshits would lead
management to suggest changes in the way
reorganization occurs.
While the first two steps focus on the process, the
next step, called kansei (translated as “the five senses”)
concentrates on the user of the product (in this case,
software). In essence, by examining the way the user
applies the product, kansei leads to improvement in the
product itself, and potentially, to the process that created
it.
Finally, a step called miryokuteki hinshitsu
broadens management concern beyond the immediate
product. This is a business-oriented step that looks for
opportunity in related areas that can be indentified by
observing the use of the product in the marketplace. In
the software world, miryokuteki hinshitsu might be
viewed as an attempt to uncover new and profitable
products or applications that are an outgrowth from an
existing computer-based system.
For most companies kaizen should be of immediate
concern. Until a mature software process has been
achieved, there is little point in moving to the next steps.
Software Quality Assurance: Even the most jaded
software developers will agree that high-quality software
is an important goal. But how do we define quality? A
wag once said, “Every program does something right,
it just may not be the thing that we want it to do”.
There have been many definitions of software
quality proposed in the literature. For our puposes,
software quality is defined as :
Conformance to explicitly stated functional and
performanc requirements, explicitly documented
development standards, and implicit characteristics what
are expected of all professionally developed software.
There is little question that the above definition
could be modified or extended. If fact, a definitive
definition of software quality could be debated endlessly.
For the purposes of this book the above definition serves
to emphasize three important points:
1. Software requirements are the foundation from
which quality is measured. Lack of conformance to
requirement is lack of quality.
2. Specified standards define a set of development
criteria that guide the manner in which software is
engineered. If the criteria are not followed, lack of
quality will almost surely result.
3. There is a set of implicit requirements that often
goes unmentioned (e.g., the desire for good
 www.neerajbooks.com

maintainability). If software conforms to its explicit
requirements but fails to meet implicit requirements,
software quality is suspect.
SQA Plan: The SQA plan is the blueprint for
software quality assurance. Developed by the SQA
group and the project team, the plan serves as a template
for SQA activities for each software project.
An outline for SQA plan recommended by the IEEE
is given below. Initial sections describe the purpose and
scope of the document and indicate the software process
activities covered by quality assurance. All documents
in the SQA plan are listed and all applicable standards
are noted. The Management section of the plan describes
SQA’s place in the organizational structure; SQA tasks
and activities and their placement throughout the
software process; and the organizational roles and
responsibilities relative to product quality.
The Documentation section details work products
produced as part of the software process. These include :
I. Purpose of plan
— project documents (e.g., project plan)
— models (e.g., ERDs, class hierarchies)
— technical documents (e.g., specifications, test
plans)
— user documents (e.g., help files)
This section also defines the minimum set of work
products that are acceptable to achieve high quality.
Standards, Practices and Conventions lists all
applicable standards/practices that are applied during
the software process (e.g., document standards, coding
standards, and review guidelines). In addition, all
project, process, and product metrics that are to be
collected as part of software engineering work are listed.
The Reviews and Audits section of the plan
identifies the reviews and audits to be conducted by the
software engineering team, the SQA group, and the
customer. It provides an overview of the approach for
each review and audit.

Neeraj
II. References
III. Management
1. Organization
2. Tasks
3. Responsibilities
IV. Documentation

Publications
1. Purpose
2. Required software engineering documents
3. Other documents
V. Standards, Practices and Conventions
1. Purpose

www.neerajbooks.com
2. Conventions
VI. Reviews and Audits
1. Purpose
2. Review Requirements
(a) software requirements review
(b) design reviews
(c) software verification and validation reviews
(d) functional audit
(e) physical audit
(f) in-process audits
(g) management reviews
VII. Test
VIII. Problem Reporting and Corrective Action
IX. Tools, Techniques and Methodologies
X. Code Control
XI. Media Control
XII. Supplier Control
XIII. Records Collection Maintenance Retention
XIV. Training
XV. Risk Management
Fig. ANSI/IEEE Std. 730-1984 and 983-1986 software quality assurance plans

www.neerajbooks.com
 www.neerajbooks.com
The test seciton is about the software test plan and
procedure. It also defines test record-keeping
requirements. Problem Reporting and Corrective Action
defines procedures for reporting, tracking and resolving
errors and defects and identifies the organizational
responsibilities for these activities.
The rest of the SQA plan identifies the tools and
methods that support SQA activities and tasks;
references software configuration management
procedures for controlling change; defines a contract
management approach; establishes methods for
assembling, safeguarding and maintaining all records;
identifies training required to meet the needs of the plan
and defines methods for identifying, assessing,
monitoring and controlling risks.
The SQA plan is developed during project
planning and is reviewed by all interested parties.
Quality assurance activities performed by the software
engineering team and the SQA group are governed by
Neeraj
the plan. The plan identifies:
— evaluations to be performed
— audits and reviews to be performed
— standards that are applicable to the project
— procedures for error reporting and tracking
Publications
— documents to be produced by the SQA group
— amount of feedback provided to software
project team.
The SQA team prepares the SQA plan and
performs following duties :
www.neerajbooks.com
(1) Participates in the development of the
project’s software process description. The
software engineering team selects a process
for the work to be performed. The SQA group
reviews the process description for
compliance performed. The SQA group
reviews the process description for
compliance with organizational policy,
internal software standards, externally
imposed standards (e.g., (ISO 9001), and
other parts of the software project plan.
(2) Reviews software engineering activities to
verify compliance with the defined software
process. The SQA group identifies,
documents and tracks deviations from the
process and verifies that corrections have
been made.
(3) Audits designated software work products to
verify compliance with those defined as part
of the software process. The SQA group
review selected work products identifies,
www.neerajbooks.com
documents, and tracks deviations; verifies that
corrections have been made; and periodically
reports, the results of its work to the project
manager.
(4) Ensures that deviations in software work and
work products are documented and handled
according to a documented procedure.
Deviations may be encountered in the project
plan, process description, applicable
standards, or technical work products.
(5) Records any non-compliance and reports to
senior management. Non-compliance items
are tracked until they are resolved.
Moreover, the SQA group coordinates the control
and management of change and helps to collect and
analyze software metrics.
Software Quality Standards: Software standards
help an organization to adopt a uniform approach in
designing, developing and maintaining software. There
are a number of standards for software quality and
software quality assurance. Once an organization
decides to establish a software quality assurance process,
standards may be followed to establish and operate
different software development activities and support
activities. A number of organizations have developed
standards on quality in general and software quality in
specific.
Software Engineering Institute (SEI) has developed
what is called a Capability Maturity Model (CMM) now
called the Capability Maturity Model Integration
(CMMI) to help organizations to improve software
development processes.
It is a model of 5 levels of process maturity that
determine the effectiveness of an organization in
delivering quality software. Organizations can receive
CMMI ratings by undergoing assessments by qualified
auditors. The organizations are rated as CMM Level 1,
CMM Level 2 etc. by evaluating their organizational
process maturity.
1. SEI-CMM Level 1: Characterized by
unorganized, chaos, periodic panics, and heroic/efforts
required by individuals to successfully complete
projects. Successes depend on individuals and may not
be repeatable.
2. SEI-CMM Level 2: Software project tracking,
requirements management, realistic planning, and
configuration management processes are in place;
successful practices can be repeated.
3. SEI-CMM Level 3: Standard software
development and maintenance processes are integrated
 www.neerajbooks.com

throughout an organization; a Software Engineering
Process Group is in place to oversee software processes,
and training programs are used to ensure understanding
and compliance.
4. SEI-CMM Level 4: Metrics are used to track
productivity, processes, and products. Project
performance is predictable, and quality is consistently
high.
5. SEI-CMM Level 5: The focus is on continuous
process improvement. The impact of new processes and
technologies can be predicted and effectively
implemented when required.
The International Organization for Standardization
(ISO) developed the ISO 9001:2000 standard (which
Standards Title
ISO/IEC 90003 Software Engineering. Guidelines for the Application of ISO 9001 : 2000 to Computer
Software
replaces the previous set of three standards of 1994)
that helps the organization to establish, operate, maintain
and review a quality management system that is assessed
by outside auditors. The standard is generic in nature
and can be applied to any organization involved in
production, manufacturing service including an
organization providing software services.
It covers documentation, design, development,
production, testing, installation, servicing and other
processes. It may be noted that ISO certification does
not necessarily indicate quality products. It only indicates
that the organization follows a well documented
established process. Table below gives a list of standards
along with the corresponding titles.

Neeraj
ISO 9001 : 2000 Quality Management Systems - Requirements
ISO/IEC 14598-1 Information Technology-Evaluation of Software Products-General Guide
ISO/IEC 9126-1 Software Engineering – Product Quality - Part 1: Quality Model
ISO/IEC 12119 Information Technology-Software Packages-Quality Requirements and Testing
ISO/IEC 12207 Information Technology-Software Life Cycle Processes

Publications
ISO/IEC 14102 Guideline For the Evaluation and Selection of CASE Tools
IEC 60880 Software for Computers in the Safety Systems of Nuclear Power Stations
IEEE 730 Software Quality Assurance Plans
IEEE 730.1 Guide for Software Assurance Planning

www.neerajbooks.com
IEEE 982.1 Standard Dictionary of Measures to produce reliable software
IEEE 1061 Standard for a Software Quality Metrics Methodology
IEEE 1540 Software Life Cycle Processes – Risk Management
IEEE 1028 Software review and audits
IEEE 1012 Software verification and validation plans

The documents that should be produced during
software development to enhance software quality
should also be specified by the SQAP. It should identify
all documents that govern the development, verification,
validation, use and maintenance of the software and how
these documents are to be checked for adequacy.
Q. 1. What is Software Configuration Manage-
ment and how does it differ from software
maintenance?
Ans. Change is basic to any computer software
when it is built. Change increases the level of confusion
among software engineers working on a project.
Confusion comes when changes are not analyzed before
they are made, recorded before they are implemented,
reported to those with a need to know, or controlled in a
manner that will improve quality and reduce error.
Babich states that :
‘‘The art of coordinating software development
to minimize .... confusion is called configuration
management. Configuration management is the
art of identifying, organizing and controlling
modifications to the software being built by a
programming team. The goal is to maximize
productivity by minimizing mistakes.’’
Software Configuration Mangement (SCM) is an
umbrella activity that is applied throughtout the software
process. Because cahnge can occur at any time, SCM
aims to (1) identify change, (2) control change, (3)

www.neerajbooks.com
 www.neerajbooks.com
ensure that change is being properly implemented, and
(4) report change to others who may have an interest.
There is clear distinction between software
maintenance and software configuration management.
Maintenance is a set of software engineering activities
that occur after software has been delivered to the
customer and put into operation. Software configuration
management is a set of tracking and control activities
that begin when a software project begins and terminated
only when the software is no more operation.
Q. 2. What are the Fundamental Sources of
change in Software?
Ans. The output of the software process is
information. It can be divided into three broad categories:
(1) Computer programs (both source-level and
executable forms),
(2) Documents that describe the computer
programs and
(3) Data (contained within the program or external
to it).
Neeraj
The items that comprise all information produced
as part of the software process are collectively called a
software configuration.
As the software process progresses, the number
of Software Cofiguration Items (SCIs) grows rapidly. A
system specification spawns a software project plan and
Publications
software requirements specification. In each SCI simply
spawned other SCIs, little confusion would result.
However, change may occur at any time, for any reason.
The first Law of System Engineering states : No matter
where you are in the system life-cycle, the system will
www.neerajbooks.com
change, and the desire to change it will persist
throughout the life-cycle.
There are four fundamental sources of change:
— new business or market conditions that
demand changes in product requirements or
business rules.
— new customer requirements that demand
modification of data produced by information
systems, functionality delivered by products,
or services delivered by a computer-based
system.
— reorganization and/or business downsizing
that causes changes in project priorities or
software engineering team structure.
— budgetary or scheduling constraints may
redefine or product.
Software configuration management activities
manage change throughout the life-cycle of computer
software. SCM is a software quality assurance activity
that is applied throughout the software process.
Q. 3. Briefly explain software change control
process?
www.neerajbooks.com
Ans. The Software Change Control process is as
follows:
It will be appreciated if changes to the software
can be predicted earlier. Change control process comes
into situation when the software and associated
documentation are delivered to configuration
management change request form, which should record
the actions that should be taken regarding the change.
The change request form is shown below:
CHANGE REQUEST FORM
Project ID:
Change Requester with date:
Requested change with date:
Change analyser:
Components affected:
Associated components:
Estimated change costs:
Change priority:
Change assessment:
Change Implementation:
Date submitted to CCA:
Date of CCA decision:
CCA decision:
Change implementer:
Date submitted to QA:
Date of implementation:
Date submitted to CM:
QA decision:
Change Request Form
It may include assessment of the proposed change,
the estimated costs and how the change should be
implemented. This form is submitted to a Change
Control Authority (CCA), which decides whether or not
the change is to be accepted. If the change is approved
by CCA it is then applied to the software. The revised
software is then revalidated by the Software Quality
Assurance (SQA) team to ensure that the changes made
have not adversely affected the other parts of the
software. The change software is handed over to the
software configuration team and is incorporated in a
new version of the system.
Change control is currently used in a wide variety
of products and systems. For Information Technology
(IT) systems, it is a major aspect of the broader discipline
of change management. Typical examples from the
computer and network environments are patches to
software products, installation of new operating systems,
upgrades to network routing tables, or changes to the
electrical power systems supporting such infrastructure.
 www.neerajbooks.com
Q. 4. What is meant by Software Configuration
Item?
Ans. Software Configuration Item is any part of
development and/or deliverable system which may
include software, hardware, firmware, drawings,
inventories, project plans or documents. These items
are independent tested stored reviewed and changed. A
software configuration item can be one or more of the
following:
1. System specification
2. Source code
3. Object code
4. Drawing
5. Software design
6. Design data
7. Database scheme and file structure
8. Test plan and test cases
9. Product specific documents
Neeraj
10. Project plan
11. Standards procedures
12. Process description.
Q. 5. Comment “Version Control is a manage-
ment of multiple versions”?
Publications
Ans. Version control is maintaining the multiple
revisions of the same unit of item during the software
development process. For example, a System
Requirement Specification (SRS) is produced after
tasking into account the user requirements which change
www.neerajbooks.com
with time into account. Once a SRS is finalized,
documented and approved it is given a document
number, with a unique identification number. The name
of the items may follow a hierarchical pattern which
may consist of the following:
1. Project identifier.
2. Configuration item (or simply item, e.g., SRS,
programs data model).
3. Change number or version number.
The identification of the configuration item must
be able to provide the relationship between items
whenever such relationship exists.
The identification process should be such that is
uniquely identifies the configuration item throughout
the development life cycle, such that all changes are
traceable to the previous configuration. An evolu-tionary
graph graphically reflects the history of all such changes.
The aim of these is to facilities the return to any previous
state of configuration item in case of any unresolved
issue in the current unapproved version.
www.neerajbooks.com
The above evolutionary graph depicts the evolution
of a configuration item during the development life
cycle. The initial version of the item is given version
number Ver 1.0. Subsequent change to the item which
would be mostly fixing bugs or adding minor
functionality is given as Ver 1.1 and Ver1.2. After that,
a major modification to Ver 1.2 is given a number Ver
2.0 at the same time, a parallel version of the same item
without the major modification is maintained given a
version number 1.3:
Depending on the volume and extent of change,
the version numbers are given by the version control
manager to uniquely identify an item through the
software. Development lifecycle. It may noted that most
of the version of the items are released during the
software maintenance phase.
Software engineers use this version control
mechanism to track source code documentation and
other configuration items. In practice, many tools are
available to store and number these configuration items
automatically. As software is developed and deployed,
it is common to expect that multiple versions of the same
software are deployed or maintained for version reasons.
Many of these versions are used by developers to
privately work to update the software.
The project database maintains all copies of the
different versions of the software and other items. It is
quite possible that without each other’s knowledge, two
developers may copy the same version of the item to
their private area and start working on it. Updating to
the central project database after completing changes
will lead to overwriting of each other’s work. Most
version control systems provide a solution to this kind
of problem by locking the version for further
modification.
Commercial tools are available for version control
which performs one or more of following tasks:
1. Source code control
2. Revision control
3. Concurrent version control.
 www.neerajbooks.com
There are many commercial tools like Rational
Clear case, Microsoft Visual Source Safe an a number
of other commercial tools to help version control.
Managing change is an important part of
computing. The programmer fixes bugs while producing
a new version based on the feedback of the user. System
administrator manages versions change like porting
database, migrating to a new platform and application
environment without interrupting the day- to-day
operations. Revisions to documents are carried out while
improving application.
Q. 6. With the help of an example explain version
control and its effects?
Ans. Let us consider the following simple HTML
file in a web based application (welcome. htm)
<html>
<(head)
<Title> A simple HTML Page </title>
</head>
Neeraj
<body>
<h1> Welcome to HTML Concepts</h1>
</body>
</html>
Once the code is tested and finalized the first step
Publications
is to register the program to he project database. The
revision is numbered and this file is marked read only
to prevent any further undesirable changes. This forms
the building block of source control. Each time the file
is modified, a new version is created and a new revision
www.neerajbooks.com
number is given.
The first version of the file is numbered as version
1.0 Any further modification is possible only in the
developer’s private area by copying the file from the
project database. The process of copying the
configuration object (the baseline version) is called
checkout.
The version (revision) control process starts with
registering the initial versions of the file. This essentially
enforces a check on the changes which ensure that the
file can be changed unless it is checked out from the
project database.
When a change is required to be made, allowing an
e-mail address to be added to the above html file, the
developer will extract the lastest version of the file
welocome.html from the project database. Once it is
check out from the project database for modification,
www.neerajbooks.com
the file is locked for further modifications by any other
developer. Other developers can check out the file for
read only purpose.
Now, the following lines are added to the file
welcome.html.
<hr>
a href= mailto: webfile@abc.com> webfile</a>
<hr>
The revised version of the file welcome.html
become
<html>
<head>
<Title> A simple HTML Page </title>
<head>
<body>
<h1> Welcome to HTML Concepts</a>
<hr>
a href = mail to: webmaster@ xyz.com>
webmaster</a>
<hr>
</body>
</html >
Then the developer check in revised version of the
file to the project data with a new version (revision)
number version 1.1 i.e., the first revision with the details
of the modification done.
Suppose another modification is done by adding a
graphic to the html file welcome.html. This becomes
version 1.2. the version tree after two modifications
looks as shown below:
Suppose further modification is required for text
based browser as graphic will not be supported by text
based browser. Then the version 1.1 will be selected
from the project database. This shows the necessity of
storing all versions of the file in the project database.
Q. 7. What are the benefits of Control
Management?
Ans. The existence of a formal process of change
management helps the developer to identify the
responsibility of code for which a developer is
responsible. An idea is achieved about the changes that
affect the main product. The existence of such
mechanism provides a road map to the development
process and encourages the developers to be more
involved in their work.
Version control mechanism helps the software tester
to rack the previous version of the product. There by
 www.neerajbooks.com
giving emphasis on testing of the changes made since
the last approved changes. It helps the developer and
tester to simultaneously work on multiple versions of
the same product and still avoid any conflict overlapping
of activity.
The software change management process is used
by the managers to keep a control on the changes to the
product there by tracking and monitoring every change.
The existence of a formal process resources the
management. It provides a professional approach to
control software changes. It also provides confidence
to the customer regarding the quality of the product.
Q. 8. Define Software Maintenance? Is it true
that software maintenance accounts to 40% to
70 % to the total cost of a Software Life Cycle? If
yes, why is it so?
Ans. Software Maintenance: The term “software
maintenance” is used to describe the software
engineering activities that occur following delivery of
Neeraj
a software product to the customer. The maintenance
phase of the software life-cycle is the time period in
which a software product performs useful work.
Maintenance activities involve making enhance-
ments to software products, adapting products to new
environments, and correcting problem. Software product
Publications
enhancement may involve providing new functional
capabilities. Improving user displays and modes of
interaction, upgrading extermal documents and internal
documentation, or upgrading the performance
www.neerajbooks.com
characteristics of a system. Adaptation of software to a
new environment may involve moving the software to
a different machine, or for instance, modifying the
software to accomodate a new telecommunications
protocol or an additional disk drive. Problem correction
involves modification and revalidation of software to
correct errors. Some errors require immediate attention,
some can be corrected on a sheduled, periodic basis,
and other are known but never corrected.
It is well established that maintenance activities
consume a large portion of the total life-cycle budget.
It is not uncommon for software maintenance to account
for 70 per cent of total software life-cycle costs (with
development requiring 30 per cent). As a general rule
of thumb, the distribution of effort for software
maintnance include 60 per cent of the maintenance
budget for enhancement, and 20 per cent each for
adaptation and correction.
If maintenance consumes 70 per cent of the total
life-cycle effort devoted to a particular software product,
and if 60 per cent of maintenance goes to enhancing the
product, then 42 per cent of the total life-cycle effort
for that product is dedicated to product enhancement.
www.neerajbooks.com
Given this perspective, it is apparent that the product
delivered to the customer at the end of the development
cycle is only the initial version of the system. Some
authors have suggested that the appropriate life-cycle
model for software is developement evolution
evolution evolution.......
This perspective makes it clear that the primary
goal of software develpoment should be production of
maintainable software systems. Maintability, like all
high-level quality attributes, can be expressed in terms
of attributes that are built into the product. The primary
product attributes that contribute to software
maintainability are clarity, modularity, and good internal
documentation of the source code, as well as appropriate
supporting documents.
Software maintenance is a microcosm of the
software development cycle. Enhancemnent and
adaption of software problem may reinitiate the
development cycle in the analysis phase, the design
phase, or the implemention phase. Thus, all of the tools
and techniques used to develop software are potentially
useful for software maintenance.
Q. 9. What is software maintainability?
Ans. Software maintenance-more effort than any
other software engineering activity. Maintainability is
the ease with which a program can be corrected if an
error occur adapted if its environment changes, or
enhanced if the customer wants a change in
requirements. There is no way to measure maintability
directly; therefore, indirect measures are used. A simple
time-oriented metric is meantime-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. Programs that
are maintainable have a lower MTTC than programs
that are not maintainable.
Q. 10. What are the different types of changes
of software maintenance?
Ans. The maintencance phase focuses on change
that is associated with error correction, software’s
environment and enhancements due to changing
customer requirements. The maintenance phase
reapplies the definition and development phases, but in
the context of existing software one comes across four
types of change during the maintenance phase.
Correction: Even with the best quality assurance
activities, customer may uncover defects in the software.
Corrective maintenance corrects defects in the software.
Adaptiaticon: Many times the original
environment (e.g., CPU, operating system, business
rules, external product characteristics) of software may
change. Adaptive maintenance modifies the software
to allow changes in external environment.
 www.neerajbooks.com
Ehancement: As software is used, the customer/
user may desire more functions that will be beneficial.
Perfective maintenance extends the software beyond its
original functional requirements.
Prevention: Computer software deteriorates due
to change, and so preventive maintenance, called
software reengineering, is conducted to enable the
software to serve the needs of its end users. Basically,
preventive maintenance makes changes to computer
programs so that they can be more easily corrected,
adapted and enhanced.
Q. 11. Elaborate the statement “Software
maintenance is far more than fixing errors”?
Ans. All software work is marked by changes in its
various phases. Change is inevitable when computer-
based systems are built; therefore, we need mechanisms
for evaluating, controlling and making modifications.
Software maintenance is far more than “fixing
mistakes.” Maintenance means four activities that are
undertaken after a program is realeased for use:
Neeraj
corrective maintenance
adaptive maintenance
perfective maintenance or enahancement
preventive maintenance or reengineering.
Only about 20 per cent of all maintenance work is
spent on “fixing mistakes.” The remaining 80 per cent
Publications
is spent adapting existing systems to changes in their
external environment, making enhancements requested
by customers and reengineering some application for
future use. When maintenance is considered in the light
www.neerajbooks.com
of these activities, one can see why it absorbs so much
effort.
Q. 12. What is software quality and software
quality assurance?
Ans. The quality is defined as “a characteristic or
attribute of something.” Software quality, refers to
software attributes like complying, design etc. Some
software developers believe the software quality is
something to worry about after cod has been generated.
This is a false notion.
Software Quality Assurance (SQA) is an umbrella
activity that is applied throughout the software process.
SQA covers
(i) a quality management approach,
(ii) effective software engineering technology
(methods and tools),
(iii) formal technical reviews that are applied
throughout the software process,
(iv) a multitiered testing strategy,
(v) control of software documentation and the
changes made to it,
www.neerajbooks.com
(vi) a procedure to assure compliance with software
development standards (when applicable), and
(vi) measurement and reporting mechanisms.
Quality Assurance: Quality assurance consists of
the auditing and reporting functions of management. Its
goal is to assume management with the data necessary
to show that product quality is meeting its goals. If the
data provided through quality assurance identify
problems management should take necessary action to
resolve quality issues.
Q. 13. Define the terms quality of design and
quality of conference?
Ans. A dictionary defines quality as “a characteristic
or attribute of something.” As an attribute of an item
quality refers to measurable characteristics—things we
are able to compare to known standards such as length,
colour, electrical properties, malleability and so on.
However, software, largely an intellectual entity, is more
challenging to characterize than physical objects.
However, measures of a program’s characteristics
do exist. These properties include cyclomatic
complexity, cohesion, number of function points, lines
of code and many others. There are two kinds of quality
encountered: quality of design and quality of
conformance.
1. 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 or a
product increases, if the product is manufactured
according to specifications.
2. 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 covers
requirements, specifications and the design of the
system. Quality of conformance focuses primarily on
implementation. If the implementation follows the
design and the resulting system meets its requirements
and performance goals, conformance quality is high.
Q. 14. Mention the criteria applied to determine
quality of a software product?
Ans. There are many definitions of software quality,
but a practical one is as below:
 www.neerajbooks.com
Conformance to explicitly stated functional and
performance requirements, explicitly documented
development standards and implicit characteristics that
are expected of all professionally developed software.
This definition can also be modified or extended.
If fact, a definitive definition of software quality could
be debated forever. However, the above definition serves
to emphasize three important points:
(i) Software requirements are the foundation from
which quality is measured. Lack of conformance
to requirements is lack of quality.
(ii) Specified standards define a set of development
criteria that guide the ways in which software is
engineered. If the criteria are not followed, it
will result in lack of quality.
(iii) There is a set of implicit requirements that often
goes un-mentioned (e.g., the desire for good
maintainability). If software conforms to its
explicit requirements, but fails to meet implicit
requirements, software quality is in doubt.
Neeraj
Q. 15. What are the attributes of quality?
Ans. The following are some of the attributes of
quality:
1. Ability to be Audited: The ability of the software
being tested against conformance to standard.
Publications
2. Compatibility: The ability of two or more
systems or components to perform their required
functions while sharing the same hardware or software
environment.
3. Completeness: The degree to which all the
www.neerajbooks.com
software’s required functions and design constraints are
present and fully developed in the requirements
specification, design document and code.
4. Consistency: The degree of uniformity,
standardization and freedom from contradiction among
the documents or parts of a system or component.
5. Correctness: The degree to which a system or
component is free from faults in its specification, design
and implementation. The degree to which software
documentation or other items meet specified requirements.
www.neerajbooks.com
6. Feasibility: The degree to which the
requirements, design, or plans for a system or component
can be implemented under existing constraints.
7. Modularity: The degree to which a system or
computer program is composed of discrete components
such that a change to one component has minimal impact
on other components.
8. Predictability: The degree to which the
functionality and performance of the software are
determinable for a specified set of inputs.
9. Robustness: The degree to which a system or
component can function correctly in the presence of
invalid inputs or stressful environmental conditions.
10. Structured: The degree to which the SDD
(System Design Document) and code possess a definite
pattern in their interdependent parts. This implies that
the design has proceeded in an orderly and systematic
manner (e.g. top-down, bottom-up). The modules are
cohesive and the software has minimized coupling
between modules.
11. Testability: The degree to which a system or
component facilitates the establishment of test criteria
and the performance of tests to determine whether those
criteria have been met.
12. Traceability: The degree to which a
relationship can be established between two or more
products of the development process. The degree to
which each element in a software development product
establishes its reason for existing (e.g., the degree to
which each element in a bubble chart references the
requirement that it satisfies). For example, the system’s
functionality must be traceable to user requirements.
13. Understandability: The degree to which the
meaning of the SRS, SDD and code are clear and
understandable to the reader.
14. Verifiability: The degree to which the SRS,
SDD and code have been written to facilitate verification
and testing.