What is Software Engineering?

A discipline whose aim is the production of quality software, that is delivered on time,
within budget, and that satisfies its requirements.

Program Versus Software:

Software is more than programs. It consists of programs, documentation of any fact of
the program and the procedures used to setup and operate the software system. The
components of the software systems are shown in figure below:

Programs

Documentation
Operating
Procedures

Figure: Components of Software

Software= Programs + Documentation + Operating Procedures.
Any program is a subset of software and it becomes software only if documentation
and operating procedure’s manuals are prepared. Program is a combination of source
code and object code. Documentation consists of different types of manuals as shown
in figure below:
Formal Specification

Analysis/ Specification Context Diagram

Documentation Dataflow Diagram

Manuals

Design Flow charts

Entity-relationship diagram

Implementation Source code listings

Cross-reference listing

Testing Test data

Test results
Operating procedures consist of instructions to setup and use the software system and
instructions on how to react to system failure. List of operating procedure
manuals/documents is given in figure below:

System Overview

User Manuals Beginner’s guide tutorial

Reference guide
Operating
Procedures
Installation guide
Operational
Manuals System administration guide

Software Process: The software process is the way in which we produce software.
This differs from organization to organization. Surviving in the increasingly
competitive software business requires more than hiring smart, knowledgeable
developers and buying the latest development tools. We also need to use effective
software development processes, so that developers can systematically use the best
technical and managerial practices to successfully complete their projects. Many
software organizations are looking at software process improvement as a way to
improve the quality, productivity, predictability of their software development, and
maintenance efforts.

Process improvement Improved

Initial state begins future state

Productivity

Learning Curve Do not

Quit here!

Time
 Organizations do not manage to achieve significant and lasting improvements in the
way they conduct their projects. Here the reasons why is it difficult to improve
software process.
1. Not enough time
2. Lack of knowledge
3. Wrong motivation
4. Insufficient commitment

Software Characteristics: The software has a very special characteristics, “it does
not wear out”. Its behaviour and nature is quite different than other products of human
life. Some of the important characteristics are discussed below:
1. Software does not wear out: Software becomes reliable overtime instead of
wearing out. It becomes obsolete, if the environment for which it was
developed, changes. Hence software may be retired due to environmental
changes, new requirements, new expectations, etc.
2. Software is not manufactured: The life of a software is from concept
exploration to the retirement of the software product. It is one time
development effort and continues maintenance effort in order to keep it
operational. However, making 1000 copies is not an issue and it does not
involve any cost.
3. Reusability of components: In software, every project is a new project. We
start from the scratch and design every unit of the software product. Huge
effort is required to develop a software which further increases the cost of the
software product. However, 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.

Software Crisis: We all feel that software is flexible. A program can be developed to
do almost anything. Sometimes, this characteristic may be the best and may help us to
accommodate any kind of change. However, most of times, this “almost anything”
characteristics has made software development difficult to plan, monitor and control.
This unpredictability is the basis of what has been referred to for the past 30 years as
the “software crisis”.
Hardware versus Software Reliability: There is a well known “Bath tub curve” in
reliability studies for hardware products. The curve is given in figure below. The
shape of the curve is like “Bath tub”, and is known as Bath tub curve.
 Burn In Wear out phase

Useful life phase

Failure intensity

Time
Figure: Bath tub curve
There are three phases for the life of a hardware product. Initial phase is Burn-in
phase, where failure intensity is high. It is expected to test the product in the industry
before delivery. Due to testing and fixing faults, failure intensity will come down
initially and may stabilise after certain time. The second phase is the useful life phase
where failure intensity is approximately constant and is called useful life of a product.
After few years, again failure intensity will increase due to wearing out of
components. This phase is called wear out phase. We do not have this phase for the
software as it does not wear out. The curve for software is given in figure below:

Failure
intensity

Time
Important point is software becomes reliable overtime instead of wearing out. It
becomes obsolete, if the environment for which it was developed, changes. Hence,
software may be retired due to environmental changes, new requirements, new
expectations, etc.

Product & Process:

Product: What is delivered to the customer, is called a Product. It may include
source code, specification document, manuals, documentation etc. Basically, it is
nothing but a set of deliverables only.
Process: Process is the way in which we produce software. It is the collection
of activities that leads to (a part of) a product. An efficient process is required to
produce good quality products. If the process is weak, the end product will
undoubtedly suffer, but an obsessive over-reliance on process is also dangerous.

Role of management in software development: The management of software

development is heavily dependent on four factors: People, Product, Process and
Project. Order of dependency is shown in figure below:
People

Project Product

Process
Figure: Factors of management dependency

Software development is a people centric activity. Hence, success of the project is on

the shoulders of the people who are involved in the development.

The people: Software development requires good managers. The managers, who can
understand the psychology of people and provide good leadership quality. A good
manager cannot ensure the success of the project, but can increase the probability of
success. The areas to be given priority are: proper selection, training, compensation,
career development, work culture etc.

The product: What do we want to deliver to the customer? Obviously, a product; a

solution to his/her problems. Hence, objectives and scope of work should be defined
clearly to understand the requirements. Alternate solutions should be discussed. It may
help the managers to select a “best” approach within constraints imposed by delivery
deadlines, budgetary restrictions, personnel availability, technical interfaces etc.
Without well defined requirements it may be impossible to define reasonable
estimates of the cost, development time and schedule for the project.
The process: The process is the way in which we produce software. It provides the
framework from which a comprehensive plan for software development can be
established. If the process is weak, the end product will undoubtedly suffer.

The project: A proper planning is required to monitor the status of development and
to control the complexity. Most of the projects are coming late with cost overruns of
more than 100%. In order to manage a successful project, we must understand what
can go wrong and how to do it right. We should define concrete requirements
(although very difficult) and freeze these requirements. Changes should not be
incorporated to avoid software surprises. Software surprises are always risky and we
should minimise them. We should have a planning mechanism to give warning before
the occurrence of any surprise.
Software life cycle models:
Sometimes a product is constructed without specifications or any attempt at
design. Instead, the developer simply builds a product that is reworked as many times
as necessary to satisfy the client.
This is an adhoc approach and not well defined. Basically, it is a simple two-phase
model. The first phase is to write code and the next phase is to fix it as shown in figure
below. Fixing in this context may be error correction or addition of further
functionality.

Build
Code

Fix

Figure: Build & Fix model

Although this approach may work well on small programming exercise but this model
is totally unsatisfactory for software of any reasonable size. Code soon becomes
unfixable and un enhance able. There is no room for design or any aspect of
development process to be carried out in a structured or detailed way. The cost of the
development using this approach is actually very high as compared to the cost of a
properly specified and carefully designed product. In addition, maintenance of the
product can be extremely difficult without specification or design documents.

Water Fall Model: The most familiar model is the waterfall model, which is given in
figure below. This model has eight phases. The phases always occur in this order and
do not overlap. The developer must complete each phase before the next phase begins.
This model is named “Waterfall model”, because its diagrammatic representation
resembles a cascade of waterfall.

Problems of Waterfall Model:

1. It is difficult to define all requirements at the beginning of a project.
2. This model is not suitable for accommodating any change.
3. A working version of the system is not seen until late in the project’s life.
4. It does not scale up well to large projects.
5. Real projects are rarely sequential.
 Requirement Analysis Feasibility Study

Detailed Design
System Design

Coding Testing

Installation Maintenance

Due to this weaknesses, the application of waterfall model should be limited to

situations where the requirement and their implementations are well understood. For
example, if an organization has experience in developing accounting systems then
building a new accounting system based on existing designs could be easily managed
with the waterfall model.

The Rapid Application Development (RAD) Model: This model is an incremental

process model and was developed by IBM in 1980’s. Here, user involvement is
essential from requirement phase to delivery of the product. The continuous user
participation ensures the involvement of users expectation and perspective in
requirements elicitation, analysis and design of the system.
The process is started with building a rapid prototype and is given to user for
evaluation. The user feedback is obtained and prototype is refined. The process
continues, till the requirements are finalized. Software requirement and specification
(SRS) and design documents are prepared with the association of users. There are four
phases in this model and these are shown in figure below:

With active participation of users

Requirement User Construction Cut over

Planning Description
Requirement Panning Phase: Requirements are captured using any group elicitation
technique. Only issue is the active involvement of users for understanding the project.
User Description: Joint teams of developers and users are constituted to prepare,
understand and review the requirements. The team may use automated tools to capture
information from the other users.

Construction Phase: This phase combines the detailed design, coding and testing
phase of waterfall model. Here, we release the product to customer. It is expected to
use code generators, screen generators and other types of productivity tools.

Cutover Phase: This phase incorporates acceptance testing by the user, installation of
the system, and user training.
Prototyping Model: A disadvantage of waterfall model as discussed earlier is that the
working software is not available until late in the process, thus delaying the discovery
of serious errors. An alternative to this is to first develop a working prototype of the
software instead of developing the actual software. The working prototype is
developed as per current available requirements. Basically, it has limited functional
capabilities, low reliability, and untested performance (Usually low).
The developers use this prototype to refine the requirements and prepare the
final specification document. Because the working prototype has been evaluated by
the customer, it is reasonable to expect that the resulting specification document will
be correct. When the prototype is created, it is reviewed by the customer. Typically
this review gives feedback to the developers that helps to remove uncertainties in the
requirements of the software, and starts an iteration of refinement in order to further
clarify requirements as show in figure below:

Requirements

Refinement of
Quick Design
requirements as per
suggestions
Implement

Customer
Evaluation
Not accepted by customer
Accepted by customer
Design

Implementation &
Unit testing

Integration &
System Testing

Operation &
Maintenance

Figure: Prototype Model

The prototype may be a usable program, but is not suitable as the final software
product. The reason may be poor performance, maintainability or overall quality. The
code for the prototype is thrown away; however the experience gathered from
developing the prototype helps in developing the actual system. Therefore, the
development of a prototype might involve extra cost, but overall cost might turn out to
be lower than that of an equivalent system developed using the waterfall model.

Spiral Model: The problem with traditional software process models is that they do
not deal sufficiently with the uncertainty, which is inherent to software projects.
Important software projects have failed because project risks were neglected and
nobody was prepared when something unforeseen happened. We incorporate the
“Project Risk” factor into a life cycle model. The result is the Spiral model.
The radial dimension of the model represents the cumulative costs. Each path around
the spiral is indicative of increased costs. The angular dimension represents the
progress made in completing each cycle. Each loop of the spiral from X-axis
clockwise through 3600 represents one phase. One phase is split roughly into four
sectors of major activities:
 Planning: determination of objectives, alternative and constraints.
 Risk Analysis: Analyze alternatives and attempts to identify and resolve
the risks involved.
 Development: Product development and testing product.
 Assessment: Customer evaluation.
During the first phase, planning is performed, risks are analyzed, prototype are built,
and customer evaluate the prototype. During the second phase, a more refined
prototype is built, requirements are documented and validated, and customers are
involved in assessing the new prototype. By the time third phase begins, risks are
known, and a somewhat more traditional development approach is taken. The figure
below describes the function and structure of the spiral model.

I. Determine objectives, II. Evaluate alternatives,

alternatives, constraints identify, resolve risks

IV. Plan next phases III. Develop, verify

Next-level product
The advantage of this model is the wide range of options to accommodate the good
features of other life cycle models. It becomes equivalent to another life cycle model
in appropriate situations. It also incorporates software quality objectives into software
development. The risk analysis and validation steps eliminate errors in the early
phases of development.

Size Estimation Metric: Here we use to different size estimation metric. Like,
1. Lines of Code (LOC)
2. Function Point Metric (FP metric)

1. Lines Of Code (LOC): LOC is the simplest among all metrics available to
estimate project size. This metric is very popular, being the simplest to use.
Using this metric, the project size is estimated by counting the number of
source instructions in the developed program. Obviously, while counting the
number of source instructions, the lines used for commenting the code and the
header lines are ignored.
Determining the LOC count at the end of a project is a very simple job.
However, accurate estimation of the LOC count at the beginning of a project is
very difficult. So project managers usually divided the problem into modules,
and each module into sub modules and so on, until the sizes of the different
leaf-level modules can be approximately predicted. To be able to do this, past
experience in developing similar products proves helpful. By using the
estimation of the lowest level modules, project managers arrive at the total size
estimation. However, LOC as a measure of problem size has several short
comings:
 LOC gives a numerical value of problem size that can vary widely with
individual coding style- different programmers lay out their code in
different ways.
 A good problem size measure should consider the overall complexity of
the problem and the effort needed to solve it. i.e., it should consider the
total effort needed to specify, design, code, test etc and not just the
coding effort.
 LOC measure correlates poorly with the quality and efficiency of the
code. A larger code size does not necessary imply better quality or
higher efficiency.
 2. Function Point Metric: One of the important advantages of using the function
point metric is that it can be used to easily estimate the size of a software
product directly from the problem specification. This is in contrast to the LOC
metric, where the size can be accurately determined only after the product has
fully been developed.
The conceptual idea underlying the function point metric is that the size of a
software product is directly dependent on the number of different functions or
features it supports. A software product supporting many features would
certainly be of larger size than a product with less number of features.
Besides using the number of inputs and output data values, function point
metric computes the size of a software product (in units of function point or
FPs) using three other characteristics of the product as shown in the following
expression. The size of a product in function points (FPs) can be expressed as
the weighted sum of these five problems characteristics were proposed
empirically and validated by observations over many projects. Function point is
computed in two steps. The first step is compute the Unadjusted Function Point
(UFP).
UFP= (Number of inputs)*4 + (Number of outputs)*5 + (Number of
inquiries)*4 + (Number of files)*10 + (Number of interfaces)*10
Once the UFP is computed, the Technical Complexity Factor (TCF) is
computed next. The TCF refines the UFP measure by considering fourteen
other factors. Such as high transaction rates, throughput, and response time
requirements, etc. Each of these 14 factor is assigned a value from 0 (not
present or no influence) to 6 (strong influence). The resulting numbers are
summed, yielding the total degree of influence (DI). Now the TCF is computed
as (0.65+0.01*DI). As DI can vary from 0 to 70, the TCF can vary from 0.65 to
1.35. Finally, FP= UFP* TCF.

Basic Of Cost Estimation:

 Analysis of the software development process is not considered while
estimating the cost.
 It is difficult to estimate the software costs accurately as software is intangible
and intractable.

Cost Factors of Software Products: To achieve reliable cost estimates, several

factors that influence the cost of developing a software product are taken into
consideration. These factors are:
 Experience in Application domain: If the developer is familiar with the
programming language, operating system and the hardware used in the project,
then the cost of developing the project will be less.
  Product Complexity: The cost of the software project increases with the level
of complexity. There are three levels of product complexity, namely organic,
semidetached and embedded.
 Project Size: Size of the project is an important criteria for estimating the cost
of a software project. A large size project consumes more resources than a
smaller project; hence it is more costly.
 Available Time: Time available to develop a software project according to
user requirements is an important factor. Software project require more
resources and effort if the development time is decreased from the allocated
time, thus leading to an increase in the cost of the project.

Cost Estimation Model:

 Algorithmic Model: Estimation in these models is performed with the help of
mathematical equations, which are based on historical data or theory. In order
to estimate costs accurately, various inputs are provided to these algorithmic
models. Various algorithmic models are COCOMO, COCOMO II.
 Non Algorithmic Model: Estimation in these models depends on the prior
experience and domain knowledge of the project manager. Note that, these
models do not use mathematical equations to estimate the cost of a software
project. Example, expert judgement estimation by analogy etc.

But in this section we will discuss only the COCOMO and COCOMO II models in
details.

Constructive Cost Model:

The COCOMO model is commonly used as it is based on the study of the
already developed software projects. In this model, the size of the project is measured
in terms of thousands of delivered lines of code (KDLOC).
 Organic Project: These projects are small in size (not more than 50 KDLOC)
and thus easy to develop. In organic projects, small teams with prior experience
work together to accomplish user requirements that are less demanding.
 Semi detached project: The projects are less complex as user requirements are
less stringent in comparison with those of embedded projects. The size of a
semidetached project is not more than 300 KDLOC.
 Embedded project: These projects are complex in nature (size is more than
300 KDLOC) and organizations have less experience in developing such type
of projects. Developer also have to meet stringent user requirements.
The COCOMO is based on the hierarchy of three models, namely basic model,
intermediate model and advance model.
 Basic model: In the basic model, only the size of the project is considered
while calculating effort. To calculate effort, the following equation (known as
effort equation) is used:
E=A*sizeB where E is the effort in person month, and the size is
measured in terms of KDLOC. The value of constant A and B depend
on the type of project.
In this model, the values of constants (A and B) for three different types of
projects are Project Type A B listed below:
Organic 2.4 1.05
Semidetached 3.0 1.12
Embedded 3.6 1.20

 Intermediate model: In the intermediate model, parameters such as software

reliability and software complexity are also considered along with the size of
the project while estimating the effort. The steps to estimate the total efforts
are:
Step1: Calculate an initial estimate of development effort by considering the
size in terms of KDLOC.
Step2: Identify a set of 15 parameters derived from the attributes of the current
project. All these parameters are rated against a numeric value called
multiplying factor. Effort Adjustment Factor (EAF) is derived by multiplying
all the factors with each other.
Step3: adjust the estimate of development effort by multiplying the initial
estimate calculated in step1with EAF.

 Advance model: In the advance model, effort is calculated as a function of

program size and a set of cost drivers for each phase of software engineering.
This model incorporates all characteristic of inter mediate model and provide
the procedure for adjusting the phase-wise distribution of the development
schedule.
There are four phase in the advance COCOMO model, namely, requirements
planning and product design (RPD), detailed design (DD), code and unit test
(CUT), and integration and test (IT).
Constructive Cost Model II: The COCOMO model is one of the most widely used
methods for cost estimation. However, this model assumes that software is developed
according to the waterfall model using standard programming languages such as C
and FORTRAN.
However, with the adoption of object-oriented paradigm, various life cycle activities
have also acquired new perspective. For example, the waterfall model has been
replaced by the iterative incremental approach. This has been done to meet tighter
delivery schedules and dynamically changing requirements.
Observing these changes in software development, the COCOMO model was changed
and a more comprehensive cost estimation model, known as COCOMO II was
developed. The objectives of COCOMO II are to develop the support capabilities for
continuous model improvement and provide a quantitative analytic framework, a set
of tools, and techniques for evaluating the effects of software technology
improvements on software development life cycle costs.
Risk Management: A risk is any anticipated unfavourable event or circumstances
that can occur while a project is underway. If a risk becomes true, it can hamper the
successful and timely completion of a project. Risk management consists of three
essential activities:
 Risk Identification
 Risk Assessment
 Risk Containment

Risk Identification: The project manager needs to anticipate the risks in the project
as early as possible, so that the impact of the risks can be minimized by making
effective risk management plans. So, early risk identification is important. Risk
identification is somewhat similar to listing down your nightmares.
A project can get affected by a large variety of risks. In order to be able to
systematically identify the important risk which might affect a project, it is necessary
to categorize risks into different classes. There are three main categories of risks
which can affect a software project.
 Project Risks: Project risks concern various forms of budgetary, schedule,
personnel, resource and customer related problems. An important project risk is
schedule slippage.
 Technical Risks: Technical risks concern potential design, implementation,
interfacing, testing and maintenance problem.
 Business Risks: Business risks include risks of building an excellent product
that no one wants, losing budgetary or personnel commitments etc.

Risk Assessment: The objective of risk assessment is to rank the risks in terms of
their damage causing potential. For risk assessment, each risk should first be rated in
two ways:
 The likelihood of a risk coming true (r).
 The consequence of the problems associated with that risk (s).
Based on these two factors, the priority of each risk can be computed as, p=r x s.
Where p is the priority with which the risk must be handled, r is the probability of the
risk becoming true. If all identified risks are prioritized, then the most likely and
damaging risks can be handled first.

Risk Containment: After all the identified risks of a project are assessed, plans must
be made to contain the most damaging and the most likely risks. Different risks
require different containment procedures.
There are three main strategies used for risk containment:
  Avoid the risk: This may take several forms such as discussions with the
customer to reduce the scope of the work, and giving incentives to engineers to
avoid the risk of manpower turnover.
 Transfer the risk: This strategy involves getting the risky component
developed by a third party, or buying insurance cover etc.
 Risk reduction: This involves planning ways to contain the damage due to a
risk. For example, if there is risk that some key personnel might leave, new
recruitment may be planned.

To choose between the different strategies of handling a risk, the project manager
must consider the cost of handling the risk and the corresponding reduction in risk.
For this, we may compute the risk leverage of the different risks. Risk leverage is the
difference in risk exposure divided by the cost of reducing the risk.
Risk leverage = (Risk exposure before reduction-Risk exposure after reduction)/ Cost
of reduction.
Team Structure: Team structure addresses the issue of organization of the
individual project team. Let us examine the possible ways in which the individual
project teams are organized. In this text, we shall consider only three formal team
structures:
 Chief Programmer Team
 Democratic Team
 Mixed Team

1. Chief Programmer Team: In this team organization, a senior engineer

provides the technical leadership and is designated as the chief programmer. The
chief programmer partitions the task into small activities and assigns them to the
team members. The structure of the chief programmer team is shown in figure
below:

Project Manager

Software Engineering
Except this conventional structure, there is another structure of it which is slightly
different from the above structure. The structure is shown below:

Project Manager

Shadow programmer

Software Engineer

In this structure, we introduce a shadow programmer. He has nothing to do until the

chief programmer is ill or he may leave the company when it happens then the shadow
programmer be the chief programmer and handle total project work as a project
manager.
Advantages: Chief programmer team structure is very useful in any time bound
project.
Disadvantages: When the project is a complex one then it is very difficult to handle
in this team organization. Because, here all the decisions are taken by only one people
(chief programmer/shadow programmer), so some time it may be problematic to him
to take the proper decision.

2. Democratic team organization: The democratic team organization, as the

name implies, does not enforce any formal team hierarchy. Typically, a manager
provides the administrative leadership. At different times, different members of the
group provide technical leadership. The diagram of democratic team is shown below:

A democratic team structure is suitable for project requiring less than five or six
engineers and for research oriented projects.
Advantages: In this team structure every decision can be taken by a meeting between
the team members. So, for a complex project, this democratic team structure is very
essential.
Disadvantages: Here, every decision taken by all the members. So, for a time bound
project this type of team structure is not good.

3. Mixed team structure: The mixed team organization, as the name implies,
draws upon the ideas from both the democratic organization and the chief
programmer organization. The mixed control team structure is shown in figure
below.
 Project Manager

Senior Engg.

Software Engg.

This team organization incorporates both hierarchical reporting and democratic

setup. In the above figure democratic connections are shown by dashed lines and the
reporting structure is shown using solid arrows. The mixed control team structure is
suitable for large team sizes.
 Work breakdown structure: Work breakdown structure is used to decompose a
given task set recursively into small activities. WBS provides a notation for
representing the major tasks needed to be carried out in order to solve a problem.
The root of the tree is labelled by the problem name.
Each node of the tree is broken down into smaller activities that are made the
children of the node. Each activity is recursively decomposed into smaller sub
activities, until at the leaf level, the activities require approximately two weeks to
develop. WBS of an MIS (Management Information Systems) software is depicted
below:

MIS

Requirement Specification Design Code Test Documents

Database Database
GUI GUI

Activity network and Critical path method: In this topic we try to find out the
critical path from the diagram given below:

Design Database Code Database

(45) (105)

Integration &
Specification Test (120)

Design GUI Code GUI

(30) (45)

Write User Finish

Manual (60)
Critical path method:
 The minimum time (MT) to complete the project is the maximum of all paths
from start to finish.
 The earliest start (ES) time of a task is the maximum of all paths from the start
to the task.
 The latest start (LS) time is the difference between MT and the maximum of all
paths from this task to the finish.
 The earliest finish (EF) time of a task is the sum of earliest start time and
duration of the task, so, EF=ES+duration.
 The latest finish (LF) time of a task can be obtained by subtracting maximum
of all paths from the task to finish from MT. However, it can calculated by LF=
LS+duration.
 The slack time (ST) is LF-EF.
A critical task is one with zero slack time.
A path from the start node to the finish node containing only critical task is called a
critical path.
Here, we depict how to calculate the critical path from the figure shown ago.

Task ES EF LS LF ST
Specification 0 15 0 15
Design 15 60 15 60
Database
Design GUI 15 45 90 120
Code Database 60 165 60 165
Code GUI 45 90 120 165
Integrate & 165 285 165
Test
Write User 15 75 225
Manual

So the critical path is ,

Specification  Design Database Code Database Integrate & Test
Finish.
System Design:
Data Flow Diagram: The DFD is a simple graphical formalism that can be
used to represent a system in terms of the input data to the system, various processing
carried out on these data, and the output data generated by the system. The main
reason why the DFD technique is so popular is probably because of the fact that DFD
is a very simple formalism- it is simple to understand and use. A DFD model uses a
very limited number of primitive symbols to represent the functions performed by a
system and the data flow among these functions.

External entity Output Data store

Data Store

Data flow

Process

Function Symbol: A function is represented using a circle. This symbol is called a

process or a bubble. Bubbles are annotated with the names of the corresponding
functions.
External entity symbol: An external entity is represented by a rectangle. The external
entities are essentially those physical entities external to the software system which
interact with the system by inputting data to the system or by consuming the data
produced by the system.
Data flow symbol: A directed arc or an arrow is used as a data flow symbol. A
dataflow symbol represents the data flow occurring between two processes, or
between an external entity and a process, in the direction of the dataflow arrow.
Data store symbol: A data store represents a logical file. It is represented using two
parallel lines. A logical file can represent a data store symbol which can represent
either a data structure or a physical file in a disk. Each data store is connected to a
process by means of a data flow symbol. The direction of the data flow arrow shows
whether data is being read from or written into a data store.
Levels of DFD: We know that Data Flow Diagram has three levels:
1. Level 0 DFD or Context diagram.
2. Level 1 DFD
3. Level 2 DFD
Context Diagram: The context diagram is the most abstract data flow representation
of a system. It represents the entire system as a single bubble. This bubble is labelled
according to the main function of the system. The various external entities with which
the system interacts and the data flows occurring between the system and the external
entities are also represent. The data input to the system and the data output from the
system are represented as incoming and outgoing arrows. These data flow arrows
should be annotated with the corresponding data names.

Level 1 DFD: To develop the level 1 DFD, examine the high level functional
requirements. If there are between three to seven high level functional requirements,
then these can be directly represented as bubbles in the level 1 DFD. We can then
examine the input data to these functions and the data output by these functions, and
represent them appropriately in the diagram.
If a system has more than seven high level requirements, then some of the
related requirements have to be combined and represented in the form of bubble in the
level 1 DFD. These can be split in the lower DFD levels. If a system has less than
three high level functional requirements, then some of the high level requirements
need to be split into their sub functions so that we have roughly about five to seven
bubbles on the diagram.
RMS calculating software: A software system called RMS calculating software
reads three integer numbers from the user in the range between -1000 and +1000 and
determines the root mean square (rms) of the three input numbers and then display it.
The different levels of DFD for the software system mentioned above are given below
in the figure.

USER

rms Data item

Rms
calculato
r 0

Figure: Context diagram

Level 1 DFD:

Data-items

Display
Validate Comput results
input Valid data e rms rms 0.3
rms 0.1 0.2

Figure: Level 1 DFD

Level 2 DFD:

Squar
A e Asq
0.2.1

Mea Msq Root RMS

Squar
n 0.2.5
B e Bsq
0.2.4
0.2.1

Square
C 0.2.1 Csq

Figure: Level 2 DFD

Cohesion and Coupling: The intra-dependency between a module is cohesion and
the inter-dependency between the modules is called coupling.
So, cohesion is a measure of the functional strength of a module whereas the coupling
between two modules is a measure of the degree of interdependence or interaction
between the two modules.

“High cohesion, low coupling” is needed for a good software.

High cohesion means the dependency between a single module is high. i.e., the
interaction between the team member of the team develops the module is high. So,
the team functions very well.
Low coupling means the dependency between different modules is low, so the
modules are functionally independent. That means the problem of one module does
not affects the other modules.
Here we point out three main reasons to need of low coupling for a good software:
1. Error Isolation: Functional independence reduces error propagation.
2. Scope For Reuse: Reuse of a module becomes possible, because each module
does some well defined and precise functions.
3. Understandability: Complexity of the design is reduced, because different
modules are more or less independent of each other.

Classification of Cohesion:
1. Coincidental Cohesion: A module is said to have coincidental cohesion if it
performs a set of tasks that relate to each other very loosely, if at all. In this
case, the modules contains a random collection of functions.
2. Logical Cohesion: A module is said to be logically cohesive, if all elements of
the module perform similar operations, e.g., error handling, data input, data
output etc.
3. Temporal Cohesion: When a module contains functions that are related by the
fact that all the functions must be executed in the same time span, the module is
said to exhibit temporal cohesion.

Classification of Coupling:
1. Data Coupling: Two module are data coupled, if they communicate using an
elementary data items that is passed as a parameter between the two.
2. Stamp Coupling: Two modules are stamp coupled; if they communicate using
a composite data item such as a record in PASCAL or a structure in C.
3. Control Coupling: Control coupling exists between two modules, if data from
one module is used to direct the order of instruction execution in another. An
example of it is a flag set in one module and tested in another module.
Software Quality Assurance: A major aim of SQA is to help an organization
develop high quality software products in a repeatable manner. Traditionally, a quality
product is defined in terms of its fitness of purpose. That is, a quality product does
exactly what the users want it to do. For software products, the fitness of purpose is
usually interpreted in terms of satisfaction of the requirements laid down in the SRS
document.

McCall’s Quality Triangle:

Product Revision Product Transition

Product Operation

Product Revision:
 Maintainability: A software product is maintainable, if errors can be easily
corrected as and when they show up, new functions can be easily added to the
product and the functionabilities of the product can be easily modified etc.
 Flexibility: Flexibility is the ability of software to add/modify/remove
functionalities without damaging current system.
 Testability: Quality software requires quality testing. Source code should be
tested with the most coverage and with the most efficient testing methods.

Product Transition:
 Portability: A software product is said to be portable, if it can be easily made
to work in different operating system environments, in different machines, with
other software products etc.
 Interoperability: Interoperability is the ability of making systems and
organizations to work together.
 Reusability: A software product has good reusability, if different modules of
the product can easily be reused to develop new products.

Product Operation:
 Correctness: A software product is correct, if different requirements as
specified in the SRS document have been correctly implemented.
  Usability: A software product has good usability, if different categories of
users can easily invoke the functions of the product.
 Efficiency: Efficiency is the ability of software to support the resource
utilization.
 Reliability: Reliability of software product can also be defined as the
probability of the product working correctly over a given period of time.

ISO 9000: The ISO 9000 standard specifies the guidelines for maintaining a quality
system. The ISO 9000 standard mainly address operational aspects and organizational
aspects such as responsibility, reporting etc. i.e., ISO 9000 specifies a set of guidelines
for repeatable and high quality product development.

ISO 9001: It applies to the organizations engaged in design, development and

servicing of goods. This is the standard that is applicable to most software
development organizations.

ISO 9002: It applies to the organizations which do not design product but are only
involved in production. Example of these category industries include steel and car
manufacturing industries.

ISO 9003: It applies to the organizations that are involved only in installation and
testing of the product.

Why software industries need ISO 9000 certification?

 Confidence of customers in an organization increases when organization
qualifies for ISO certification.
 ISO 9000 requires a well documented software production process to be in
place.
 ISO 9000 makes the development process focused, efficient, and cost effective.
 ISO 9000 certification points out the weak points of an organization and
recommends remedial action.
 ISO 9000 sets the basic framework for total quality management (TQM).

How a software industries can get ISO 9000 certificate?

 All documents concerned with the development of a software product should
be properly managed, authorized, and controlled. This requires a configuration
management system to be in place.
 Proper plans should be prepared and the progress against these plans should be
monitored.
  Important documents should be independently checked and reviewed for
effectiveness and correctness.
 The product should be tested against specification.

SEI (Specific Instructional Objectives) CMM (Capability Maturity Model):

SEI/CMM helped organizations to improve the quality of the software they develop
and therefore adoption of SEI/CMM has significant business benefits. It can be used
in two ways:
 Capability evaluation: It provides a way to access the software process
capability of an organization. The result of capability evaluation indicates the
likely contract performance if the contractor is awarded a work. Therefore, the
result of software process capability assessment can be used to select a
contractor.
 Software process assessment: It is used by a organization with the objective
to improve its process capability. Thus this type of assessment is for purely
internal use.

SEI/CMM classifies software development industries into the following five maturity
levels:
1. Initial: A software development organization at this level is characterized by
adhoc activities. Very few or no processes are defined and followed. Since
software production processes are not defined, different engineers follow their
own process and as a result development efforts become chaotic.
2. Repeatable: At this level, the basic project management practices such as
tracking cost and schedule are established. The necessary process discipline is
in place to repeat earlier success on projects with similar applications.
3. Defined: At this level, the processes for both management and development
activities are defined and documented. The processes though defined, the
process and product qualities are not measured. ISO 9000 aims at achieving
this level.
4. Managed: At this level, the focus is on software metrics. Two types of metrics
are collected:
 Product metrics: At this metrics, we measure the characteristics of the
product being developed. Such as its size, reliability, time complexity,
understand ability etc.
 Process metrics: It reflects the effectiveness of the process being used,
such as productivity, average number of defects found per hour, average
defects correction etc.
 5. Optimizing: At this stage, process and product metrics are collected, process
and product measurement data are analyzed for continuous process
improvement.

ISO 9000 vs CMM:

 ISO 9000 is awarded by an international standards body. So, ISO certification
can be quoted in official document, tender quotation etc. However, SEI/CMM
assessment is purely for internal use.
 CMM was developed specifically for software industry and therefore addresses
many issues which are specific to software industry alone.
 CMM goes beyond quality assurance and prepares an organization to
ultimately achieve Total Quality Management (TQM). In fact, ISO 9001 aims
at level 3 of SEI/CMM model.
Coding: The input to the coding phase is the design document. During the coding
phase different modules identified in the design document are coded according to the
respective module specifications.
Normally, good software development organizations require their programmers to
adhere to some well-defined and standard style of coding called coding standards.
 A coding standard gives a uniform appearance to the codes written by different
engineers.
 It provides sound understanding of the code.
 It encourages good programming practices.
Coding Standards:
 Do not use a coding style that is too clever or too difficult to understand.
 Avoid obscure side effects: The side effect of a function call include
modification of parameters passed by reference, modification of global
variables, and I/O operations.
 Do not use an identifier for multiple purposes.

Code Review:
Code Walk-through: Code walk-through is an internal code analysis
technique. In this technique, after a module has been coded, it is successfully
compiled and all syntax errors are eliminated. Some members of the development
team are given the code a few days before the walk-through meeting to read and
understand the code. Each member selects some test cases and simulates execution of
the code by hand. The main objectives of the walk-through are to discover the
algorithmic and logical errors in the code. The members note down their findings to
discuss these in a walk-through meeting where the coder of the module is also present.
 The team performing the code walk-through should not be either too big or too
small. Ideally, it should consist of 3-7 members.
 Discussion should focus on discovery of errors and not on how to fix the
discovered errors.
 To avoid the feeling among the engineers that they are evaluated in the code
walk-through meeting, managers should not attend the walk-through meetings.

Code Inspection: In contrast to code walk-through, the aim of code inspection

is to discover some common types of errors caused due to oversight and improper
programming.
In other words, during code inspection the code is examined for the presence of
certain kinds of errors, in contrast to the hand simulation of the code execution done in
code walk-through. For instance, consider the classical errors of writing a procedure
that modifies a formal parameter while the calling routine calls the procedure with
constant actual parameters.
Testing: Testing a program consists of subjecting the program to a set of test inputs
(or test cases) and observing if the program behaves as expected. If the program fails
to behave as expected, then the conditions under which failure occurs are noted for
later debugging and correction.
 A failure is a manifestation of an error (defect or bug).
 A test case is the triplet [I,S,O], when I is the data input to the system, S is the
state of the system at which the data is input, and O is the expected output of
the system.
 A test suite (or test set) is the set of all test cases with which a given software
product is to be tested.

Verification Vs Validation: Verification is the process of determining whether the

output of one phase of software development conforms to that of its previous phase,
whereas validation is the process of determining whether a fully developed system
conforms to its requirements specification.
Thus while verification is concerned with phase containment of errors, the aim
of validation is that the final product be error free.
Types of Testing: Generally there are two types of testing:
1. Unit Testing: Software products are normally tested first at the
individual component level. Unit testing is the testing of different units of a system in
isolation.
2. Integration Testing: After testing all the components individually, the
components are slowly integrated and tested at each level of integration, this is known
as Integration testing.

Unit Testing: In order to test a single module we need a complete environment to

provide all that is necessary for execution of the module.
 The procedures belonging to other modules that the module under test calls.
 Nonlocal data structures that the module access.
 A procedure to call the functions of the module under test with appropriate
parameters. Stubs and drivers are designed to provide the complete
environment for a module. The roll of the stub and driver module is pictorially
shown in figure below:

Driver Module

Module Under Test

Global Data

Stub Module
A Stub procedure is a dummy procedure that has the same I/O parameters as the given
procedure but has a highly simplified behaviour. For example, a Stub procedure may
produce the expected behaviour using a simple table look-up mechanism. A Driver
module would contain the nonlocal data structures accessed by the module under test,
and would also have the code to call the different functions of the module with
appropriate parameter values.

Integration Test: The primary objectives of integration testing is to test the module
interfaces in order to ensure that there are no errors in the parameter passing, when
one module invokes another module. There are four different types of integration
testing:
1. Big-bang approach
2. Top-down approach
3. Bottom-up approach
4. Mixed approach.
Suppose, we divide a project in different modules and these modules are in a
hierarchy given below:

B C

D E F G

1. Big-bang Approach: It is the simplest integration technique approach,

where all the modules making up a system are integrated in a single step. In
simple words, all the modules of the system are simply put together and
tested.
Example:

Test A, B, C,
D, E, F, G
2. Top-Down integration testing: Top-down integration testing starts with
the main routine and one or two subordinate routines in the system. After
the top level ‘skeleton’ has been tested, the immediate subroutines of the
‘skeleton’ are combined with it and tested.

Test Test A, B, C,
Test D, E, F, G
A,B,
A
C

Disadvantages: In the absence of lower-level routine it may become difficult

to exercise the top-level routines in the desired manner since the lower-level
routines perform several low-level functions such as I/O.

3. Bottom-Up integration testing: In bottom-up testing, each subsystem is

tested separately and then the full system is tested. Lower-level subsystem
are successively combined to form higher-level subsystems.

Example:

Test
D
Test
B,D,
E
Test Test
E A,B,C,D,E
,F,G

Test
F
Test

C,F,
Test G
G

Advantages: Several disjoint subsystems can be tested simultaneously.

 Disadvantages: Complexity that occurs when the system is made up of a large
number of small subsystems.

4. Mixed Integration Testing: A mixed (also called sandwiched) integration

testing follows a combination of top-down and bottom-up testing
approaches. In top-down approach, testing can start only after the top-level
modules have been coded and unit tested. Similarly, bottom up testing can
start only after the bottom level modules are ready. In the mixed testing
approach, testing can start as and when modules become available.

In other words, testing has been done in two different ways:

1. Black-Box Testing: In Black-box testing, test cases are designed from an
examination of the input/output values only and no knowledge of design or
code is required. The following are the two main approaches to designing
black-box test cases.
 Equivalence Class Partitioning: In this approach, the domain of input
values to a program is partitioned into a set of equivalence classes. This
partitioning is done such that the behaviour of the program is similar to
every input data belonging to the same equivalence class. The main idea
behind defining the equivalence classes is that testing the code with any
other value belonging to that equivalence class.
Example:
For a software that computes the square root of an input integer
which can assume values between 0 and 5000, there are three
equivalence classes- The set of negative integers, the set of
integers in the range between 0 to 5000, and the integer larger
than 5000. Therefore, the test cases must include representative
values from each of the three equivalence classes and a possible
test set can therefore be: {-5,500,6000}.
 Boundary Value Analysis: A type of programming error frequently
occurs at the boundaries of different equivalence classes of inputs. The
reason behind such errors might purely be due to psychological factors.
Programmers often fail to see the special processing required by the
input values that lie at the boundary of different equivalence classes.
Example:
Programmer may improperly use < instead of <= or conversely <=
instead of <. For A function that computes the square root of integer values in
the range between 0 and 5000, the test cases must included the following
values: {0,-1,5000,5001}.
 2. White Box Testing: There are several white box testing strategies. Each
testing strategy is based on some heuristics. One white box testing strategy is
said to be stronger than another strategy, if all types of errors detected by the
first testing strategy (say A). In the practical design of test cases, if a stronger
testing is performed, then the weaker testing need not be carried out. But the
test suite should be enriched by using all the complementary testing strategies.

Types of error detected by

testing A

Types of error
detected by
testing B

Statement Coverage Criteria: The statement coverage strategy aims to design

test cases so that every statement in a program is executed at least once. The
principle idea governing the statement coverage strategy is that unless we
execute a statement, we have no way of determining if an error exists in that
statement. Unless a statement is executed, we cannot observe whether it causes
failure due to some illegal memory access, wrong result computation etc.
Consider the following Euclid’s GCD computation algorithm:

read x, read y
while (x!=y)
if x>y then
x=x-y
else
y=y-x
endif
endwhile
gcd=x

By choosing the test set {(x=3,y=3), (x=4,y=3), (x=3,y=4)}, we can exercise the
program such that all statements are executed at least once.
Edge Coverage Criteria: The edge coverage based testing strategy requires us to
design test case such that all edges of the control flow graph of this program covers at
least once. Therefore, in order to understand the edge coverage based testing strategy,
we need to first understand how the control flow graph of a program can be drawn.
When we try to draw the control flow graph of a program we must know to graphical
representation for the all elements of a program.

Statements: S1, S2
(Tips: For single statement and consecutive any number of statements we just
draw the diagram shown below)

if condition then Condition check

statements then
endif

if condition then Condition check

statement then else
else
statement
endif
if condition then
statement
elseif condition then
statement
else
statement
endif

while condition
statement
end while

For (i=1;i<n;i++)
statements
So, the control flow graph for the Euclid’s GCD computation algorithm is,

So, when we try to choose the test cases we does not bother about the numeric values,
we only depends on the condition. In the above GCD program, the conditions are,
While (x!=y)
From it we get, two conditions, x=y and x!=y. From x!=y, we get two more
conditions- one is x>y another is x<y. So the test set consists three conditions,
(x=y, x>y, x<y).
After that we see that when we trace the control flow graph using these test cases, all
of the edges of this control flow graph is covered.
McCabe’s Cyclomatic Complexity Metric: Cyclomatic complexity is a software
metric (measurement). It is quantitative measure of logical strength of the program. It
directly measures the number of linearly independent paths through a program’s
source code. We list three different ways to compute the cyclomatic complexity.

Rule1: (Region rule)

Cyclomatic complexity= Number of regions in the control flow graph of the
program
In the program’s cfg G, any portion enclosed by nodes and edges can be called a
region. Alternatively
Cyclomatic complexity= Total number of bounded area + 1.
In the program’s control flow graph G, any region enclosed by nodes and edges can be
called a bounded area.
Control flow graph for the Euclid’s GCD computation algorithm is,

R2

R3
R1

There is two region R1 and R2 and outside of this control flow graph there is an infinite
region R3. So, cyclomatic complexity = 3.
Alternatively, Cyclomatic Complexity = Number of the bounded areas + 1= 2 (R1 and
R2) + 1= 3.

Rule2: (Edge node Rule)

Cyclomatic Complexity = E-N+2, where E is the number of edges and N is the
number of nodes in the control flow graph of the program.
In the above control flow graph,
E=12, N=11
So, Cyclomatic Complexity = E-N+2 = 12 -11 + 2 = 3.
Rule3: ( Independent Path Rule)
Cyclomatic Complexity = Number of independent paths in the control flow
graph.
What is independent Path?
 A path from the source to destination which includes at least one new
node which is not present in the previous path.
 We must start with the smallest paths.

3 1 1
0 1
4
0

5 7

6 8

In this Control flow graph, the starting node is node 1 and the end or destination node
is node 11.
Path 1: 1-2-3-10-11
Path 2: 1-2-3-4-5-6-9-3-10-11
Path 3: 1-2-3-4-7-8-9-3-10-11
So, all the nodes from 1-11 has been covered. So, there is no way to find any other
independent path.
So, Cyclomatic Complexity = Number of independent path = 3.
System Testing: From we integrate different modules of a product to the product is
ready to use, this transformation done by system testing method. The diagram is
shown below:

Performance
Integrated Model Function Test Functioning Test
System

Performing System

Installation Acceptance
System in use Accepting
Test Test
System

Function Test: Here we check all kinds of functional requirements of the project. It is
one kind of black box testing. After completion of function test, the system is called
the functioning system.

Performance Test: In performance test we check different things of a project. Here,

we execute different types of testing such that,
 Stress test
 Regression test
 Compatibility test
 Security test
Stress Test: Here we check that how much data the project efficiently handle.

Regression Test: Here we check the project with the previously developed product
and analyze which is the better one.

Compatibility Test: Here we test all the modules are compatible with each other or
not.

Security Test: Is any unauthorized user can access the project or not, has been
checked here. After completion of performance test the system is called performing
system.

Acceptance Test: Is the clients can accept the product or not. Here we use two testing
mechanism.
  Benchmark test: In benchmark test the client give the developer a test set
(which is benchmark here) and say that if the project passed on this test set, he
buy it, otherwise not.
 Pilot test: In pilot test client does not believe on any benchmark, he just used
the product for 7-15 days and give his feedback on it.
Pilot test has two types – Alpha test and Beta test.

 Alpha Test: Here day to day testing is done by the own organization people
of the developer.
 Beta Test: Here testing done on the client site.

Installation Test: Here developer install the project on client’s site and run it.
Tips: If pilot testing is used, then there is no need of installation test.

Mutation Testing: In mutation testing, the software is first tested by using an initial
test suite built up from different white box testing strategies discussed. After the initial
testing is complete, mutation testing is taken up. The idea behind mutation testing is to
make a few arbitrary changes to a program at a time. Each time the program is
changed, it is called a mutated program and the change effected is called a mutant. A
mutated program is tested against the full test suite of the program. If there exists at
least one test case in the test suit for which a mutant gives an incorrect result, then the
mutant is said to be dead. If a mutant remains alive even after all the test cases have
been exhausted, the test data is enhanced to kill the mutant. The process of generation
and killing of mutants can be automated by predefined a set of primitive changes that
can be applied to the program.
Software Reliability: Reliability of a software product essentially denotes its
trustworthiness or dependability. Reliability of a software product can also be defined
as the probability of the product working correctly over a given period of time.
Hardware Vs Software Reliability: Hardware failures are inherently different from the
software failure. Most hardware failures are due to component wear and tear. To fix
hardware faults, one has to either replace or repair the failed part.
 Hardware Reliability: Initially the failure rate is high but decreases as the
faulty components are identified and removed. The system then enters it useful life.
After some time (called the product lifetime) the components wear out, and the failure
rate increases. This gives the plot of hardware reliability over time, and its
characteristics bath tub shape shown in figure below:

Burn in Wear out

Useful life
Failure Rate

Time

 Software Reliability: On the other hand, for software the failure rate is at its
highest during integration and testing phases. As the system is tested, more and more
errors are identified and moved resulting in a reduced failure rate. This error removal
continues at a slower pace during the useful life of the product. As the software
becomes obsolete, no more error correction occurs and the failure rate remains
unchanged. Its characteristics are shown in figure below:

Testing

Failure Rate Useful life obsolete

Time
Reliability Metrics: The reliability requirements for different categories of software
products may be different. For this reason, it is necessary that the level of reliability
required for a software product should be specified in the SRS (Software Requirement
Specification) document. In order to be able to do this, we need some metrics to
quantitatively express the reliability of the software product.
1. Rate of occurrence of failure (ROCOF): It measures the frequency of
occurrence of unexpected behaviour. The ROCOF is obtained by observing the
behaviour of a software product in operation over a specified time interval and then
calculating the total number of failures during the interval.
2. Mean Time To Failure (MTTF): MTTF is the average time between
two successive failures, observed over a large number of failures. To measure MTTF,
we can record the failure data for n failures. Let the failure occur at the time instants
t1,t2,.....,tn. Then MTTF can be calculated as,
n
∑ ((ti+1 – ti)/ n-1)
i=1

3. Mean Time To Repair(MTTR): It measures the average time it takes

to track the errors causing the failures and then to fix them.
4. Mean Time Between Failures (MTBF): We can combine the MTTF
and MTTR metric to get the MTBF metrics.
MTBF= MTTF + MTTR.

Availability: Availability of a system is a measure of how likely will the system be

available for use over a given period of time. This metric not only considers the
number of failures occurring during a time interval, but also takes into account the
repair time of a system when a failure occurs. This metric is important for systems
such as telecommunication system, and operating systems, which are supposed to be
never down and where repair and restart time are significant and loss of service during
that time is important.
Software Maintenance: Software maintenance denotes any changes made to a
software product after it has been delivered to the customer. Maintenance is inevitable
for almost any kind of product. However, most product need maintenance due to the
wear and tear caused by use. On the other hand, software products do not need
maintenance on this count, but need maintenance to correct errors, enhance failures,
port to new platform etc.

Types of software maintenance: The requirement of software maintenance arises on

account of the three main reasons:
1. Corrective: Corrective maintenance of a software product becomes
necessary to rectify the bugs observed while the system is in use.
2. Adaptive: A software product might need maintenance when the
customers need the product to run on new platforms, on new operating
systems, or when they need the product to interfaced with new hardware or
software.
3. Perfective: A software product needs maintenance to support the new
features that user want it to support, to change different functionalities of
the system according to customer demands, or to enhance the performance
of the system.
Feasibility Study: Here we check that the product is feasible or not. There are three
types of feasibility study:

 Technical Feasibility
 Operational Feasibility
 Economical Feasibility

Suppose, a hardware mention in SRS not available in my country now. So, this is a
technical feasibility problem. Then we can import it from another country, which take
more time as well as cost. That violets the economical feasibility.
In SRS, the clients request portion is designed depends on the meeting with clients. In
this meeting developer mention a method by which the problem has been solved. But
original time we see the method is not the optimal one, so we must change it. This is
operational feasibility problem.