Course Content

MCA/GEN/1/CC3: Software Engineering

Unit - I Software and software engineering, software
characteristics, software crisis, software engineering
paradigms, planning a software project, software cost
estimation, project scheduling, personnel planning, team
structure.
Unit - II Software requirement analysis: structured analysis,
object-oriented analysis and data modeling, software
requirement specification, validation.
Software configuration management, quality assurance,
project monitoring, risk management.

Unit - III Design and implementation of software: software design

fundamentals, structured design methodology and
object-oriented design, design verification, monitoring
and control, coding.
Software Reliability: metric and specification, fault
avoidance and tolerance, exception handling, defensive
programming.
Unit - IV Testing: testing fundamentals, white box and black box
testing, software testing strategies: unit testing,
integration testing, validation testing, system testing,
debugging.
Software maintenance: maintenance characteristics,
maintainability, maintenance tasks, maintenance side
effects. CASE tools. Agile development.
Testing in Software Engineering
As per ANSI/IEEE 1059, Testing in Software Engineering is a process of
evaluating a software product to find whether the current software product
meets the required conditions or not. The testing process involves evaluating
the features of the software product for requirements in terms of any missing
requirements, bugs or errors, security, reliability and performance.

Software Testing
Software Testing is a method to check whether the actual software product
matches expected requirements and to ensure that software product
is Defect free. It identifying the correctness of software by considering its all
attributes (Reliability, Scalability, Portability, Re-usability, Usability).
The purpose of software testing is to identify errors, gaps or missing requirements
in contrast to actual requirements.
In simple terms, Software Testing means the Verification of Application Under Test
(AUT).

Why Software Testing is Important?

Software Testing is Important because if there are any bugs or errors in the
software, it can be identified early and can be solved before delivery of the
software product. Properly tested software product ensures reliability, security
and high performance which further results in time saving, cost effectiveness
and customer satisfaction.

Testing is mandatory because it will be a dangerous situation if the software fails any of
time due to lack of testing. So, without testing software cannot be deployed to the end
user.

Need of Testing:

Testing is important because software bugs could be expensive or even

dangerous. Software bugs can potentially cause monetary and human loss, and
history is full of such examples.

 Starbucks was forced to close about 60 percent of stores in the U.S and
Canada due to software failure in its POS system. At one point, the store
served coffee for free as they were unable to process the transaction.
 Some of Amazon’s third-party retailers saw their product price is reduced
to 1p due to a software glitch. They were left with heavy losses.
 In 2015 fighter plane F-35 fell victim to a software bug, making it unable to
detect targets correctly.
 China Airlines Airbus A300 crashed due to a software bug on April 26,
1994, killing 264 innocents live
 In April of 1999, a software bug caused the failure of a $1.2 billion military
satellite launch, the costliest accident in history

What are the benefits of Software Testing?

Here are the benefits of using software testing:

 Cost-Effective: It is one of the important advantages of software testing.

Testing any IT project on time helps you to save your money for the long
 term. In case if the bugs caught in the earlier stage of software testing, it
costs less to fix.
 Security: It is the most vulnerable and sensitive benefit of software testing.
People are looking for trusted products. It helps in removing risks and
problems earlier.
 Product quality: It is an essential requirement of any software product.
Testing ensures a quality product is delivered to customers.
 Customer Satisfaction: The main aim of any product is to give
satisfaction to their customers. UI/UX Testing ensures the best user
experience.

Types of Software Testing

Here are the software testing types:

Typically Testing is classified into three categories.

 Functional Testing
 Non-Functional Testing or Performance Testing
 Maintenance (Regression and Maintenance)

Types of Software Testing in Software Engineering

1. Functional Testing:
It include-

 Unit Testing
 Integration Testing
 Smoke
 UAT ( User Acceptance Testing)
 Localization
 Globalization
 Interoperability and So on.

2. Non-Functional Testing:
It include-

 Performance
 Endurance
 Load
 Volume
 Scalability
 Usability and So on.

3. Maintenance:
It include-

Regression and Maintenance.

This is not the complete list as there are more than 150 types of testing types
and still adding. Also, all testing types are applicable to all projects but depend
on the nature & scope of the project.

Testing Levels
The levels of software testing involve the different methodologies, which can be used
while we are performing the software testing.
 1. Unit Testing
2. Integration Testing
3. System Testing
4. Acceptance Testing

1. Unit Testing
Unit testing is the first level of software testing, which is used to test if software modules
are satisfying the given requirement or not.

The first level of testing involves analyzing each unit or an individual component of
the software application. Unit testing is also the first level of functional testing.

A unit component is an individual function or regulation of the application, or we can

say that it is the smallest testable part of the software. The reason of performing the unit
testing is to test the correctness of inaccessible code. It helps developers to know
whether the individual unit of the code is working properly or not.

2. Integration Testing
The second level of software testing is the integration testing. The integration testing
process comes after unit testing. It is mainly used to test the data flow from one
module or component to other modules.

In integration testing, the test engineer tests the units or separate components or
modules of the software in a group. We only go for the integration testing when the
functional testing has been completed successfully on each application module. It is
subdivided into the Top-Down Approach, Bottom-Up Approach, and Sandwich
Approach (Combination of Top-Down and Bottom-Up).

In simple words, we can say that integration testing aims to evaluate the accuracy of
communication among all the modules.

3. System Testing (End to End Testing)

The third level of software testing is system testing, which is used to test the software's
functional and non-functional requirements.
It is end-to-end testing where the testing environment is parallel to the production
environment. In the third level of software testing, we will test the application as a
whole system.

To check the end-to-end flow of an application or the software as a user is known

as System testing.

In system testing, we will go through all the necessary modules of an application and test
if the end features or the end business works fine, and test the product as a complete
system.

4. Acceptance Testing
The last and fourth level of software testing is acceptance testing, which is used to
evaluate whether a specification or the requirements are met as per its delivery.

The software has passed through three testing levels (Unit Testing, Integration Testing,
System Testing). Some minor errors can still be identified when the end-user uses the
system in the actual scenario.

In simple words, we can say that Acceptance testing is the squeezing of all the testing
processes that are previously done.

The acceptance testing is also known as User acceptance testing (UAT) and is done by
the customer before accepting the final product.

Types of Acceptance Testing are

 Alpha,
 Beta &
 Gamma Testing.

 What are the different Approaches of Software Testing

Techniques?
In the field of software testing, some methods are used to find defects and
evaluate the quality of the product. Among them are White-Box
Testing and Black-Box Testing.
What is Black Box testing?
In Black-box testing, a tester doesn’t have any information about the internal
working of the software system. Black box testing is a high level of testing that
focuses on the behavior of the software. It involves testing from an external or
end-user perspective. Black box testing can be applied to virtually every level
of software testing: unit, integration, system, and acceptance.

The inputs received by the system and the outputs or responses it produces are tested.

The term black box symbolizes a black outer covering of the application,
preventing testers from seeing its inner workings and compelling them to
examine only the end-user experience. Due to its nature, black box testing is
sometimes called specification-based testing, closed box testing, or opaque
box testing.

What is White Box testing?

White-box testing is a testing technique which checks the internal functioning
of the system. In this method, testing is based on coverage of code
statements, branches, paths or conditions. White-Box testing is considered as
low-level testing. It is also called glass box, transparent box, clear box or code
base testing. The white-box Testing method assumes that the path of the logic
in a unit or program is known.

For the execution of this method, the tester or the person who will use this method must have
extensive knowledge of the technology used to develop the program.
The term white box signifies the application’s transparency, allowing the
tester to see through the outer box and into the inner code. White box testing
is leveraged to improve design, usability, and application security.

Principles of Software Testing

The testing of software consists of some principles that play a vital role
while testing the project.

The Principles of Testing are as follow:

1. Testing shows the presence of defects

2. Exhaustive testing is impossible
3. Early testing
4. Defect clustering
5. Pesticide paradox
6. Testing is context-dependent
7. Absence of error – a fallacy

Software testing can be divided into two steps:

1. Verification: it refers to the set of tasks that ensure that the software
correctly implements a specific function.
2. Validation: it refers to a different set of tasks that ensure that the
software that has been built is traceable to customer requirements.

Verification: “Are we building the product right?”

Validation: “Are we building the right product?”

Black Box(functional box) White Box(glass box)
Testing Testing
 It is a way of software testing in It is a way of testing the software in
which the internal structure or the which the tester has knowledge about
program or the code is hidden and the internal structure or the code or
nothing is known about it. the program of the software.

 Implementation of code is not Code implementation is necessary for

needed for black box testing. white box testing.

It is mostly done by software

 It is mostly done by software testers. developers.

 No knowledge of implementation is Knowledge of implementation is

needed. required.

 It can be referred to as outer or It is the inner or the internal software

external software testing. testing.

 It is a functional test of the software. It is a structural test of the software.

 This testing can be initiated based

on the requirement specifications This type of testing of software is
document. started after a detail design document.

 No knowledge of programming is It is mandatory to have knowledge of

required. programming.

 It is the behavior testing of the

software. It is the logic testing of the software.

 It is applicable to the higher levels It is generally applicable to the lower

of testing of software. levels of software testing.

 It is also called closed testing. It is also called as clear box testing.

 It is least time consuming. It is most time consuming.

  It is not suitable or preferred for
algorithm testing. It is suitable for algorithm testing.

Data domains along with inner or

 Can be done by trial and error ways internal boundaries can be better
and methods. tested.

 Example: Search something on Example: By input to check and

google by using keywords verify loops

 Black-box test design techniques-

 Decision table testing White-box test design techniques-
 All-pairs testing  Control flow testing
 Equivalence partitioning  Data flow testing
 Error guessing  Branch testing

 Types of Black Box Testing: Types of White Box Testing:

 Functional Testing  Path Testing
 Non-functional testing  Loop Testing
 Regression Testing  Condition testing

 It is less exhaustive as compared to It is comparatively more exhaustive

white box testing. than black box testing.

Cyclomatic Complexity in Software

Testing:
 What is McCabe’s Cyclomatic Complexity?
Cyclomatic Complexity in Software Testing is a testing metric used for
measuring the complexity of a software program. It is a quantitative measure
of independent paths in the source code of a software program. Cyclomatic
complexity can be calculated by using control flow graphs or with respect to
functions, modules, methods or classes within a software program.
Independent path is defined as a path that has at least one edge which has
not been traversed before in any other paths.
This metric was developed by Thomas J. McCabe in 1976 and it is based on a
control flow representation of the program. Control flow depicts a program as
a graph which consists of Nodes and Edges.

In the graph, ‘Nodes’ represent processing tasks while ‘edges’ represent

control flow between the nodes.

For example, if source code contains no control flow statement then its
cyclomatic complexity will be 1 and source code contains a single path in it.
Similarly, if the source code contains one if condition then cyclomatic
complexity will be 2 because there will be two paths one for true and the other
for false.

Flow graph notation for a program:

Flow Graph notation for a program defines several nodes connected through
the edges. Below are Flow diagrams for statements like if-else, While, until
and normal sequence of flow.
How to Calculate Cyclomatic Complexity
Mathematical representation:

Mathematically, it is set of independent paths through the graph diagram. The

Code complexity of the program can be defined using the formula –

There are 3 commonly used methods for calculating the cyclomatic

complexity-

 Method-01:

V (G) = E – N + 2

Where,

E – Number of edges

N – Number of Nodes

 Method-02:

V (G) = P + 1
Where,
P = Number of predicate nodes (node that contains condition)

 Method-03:

Cyclomatic Complexity OR V (G) = Total number of closed regions in the

control flow graph + 1

 Steps to be followed:
The following steps should be followed for computing Cyclomatic complexity
and test cases design.

Step 1 – Construction of graph with nodes and edges from the code
Step 2 – Identification of independent paths

Step 3 – Cyclomatic Complexity Calculation

Step 4 – Design of Test Cases

Once the basic set is formed, TEST CASES should be written to execute all
the paths.

Problem:
Calculate cyclomatic complexity for the given code-

IF A = 354

THEN IF B > C

THEN A = B

ELSE A = C

END IF

END IF

PRINT A

Solution-

We draw the following control flow graph for the given code-
Using the above control flow graph, the cyclomatic complexity may be calculated as-

Method-01:

*Cyclomatic Complexity*
= Total number of closed regions in the control flow graph + 1
=2+1
=3

Method-02:

*Cyclomatic Complexity*
=E–N+2
=8–7+2
=3

Method-03:

*Cyclomatic Complexity*
=P+1
=2+1
=3

 Tools for Cyclomatic Complexity calculation:

Many tools are available for determining the complexity of the application.
Some complexity calculation tools are used for specific technologies.
Complexity can be found by the number of decision points in a program. The
decision points are if, for, for-each, while, do, catch, case statements in a
source code.

Examples of tools are

  OCLint – Static code analyzer for C and Related Languages
 Reflector Add In – Code metrics for .NET assemblies
 GMetrics – Find metrics in Java related applications

 Cyclomatic complexity indicates several information

about the program code-

Cyclomatic Complexity Meaning

 Structured and Well Written Code

1 – 10  High Testability
 Less Cost and Effort

 Complex Code
10 – 20  Medium Testability
 Medium Cost and Effort

 Very Complex Code

20 – 40  Low Testability
 High Cost and Effort

 Highly Complex Code

> 40  Not at all Testable
 Very High Cost and Effort

Importance of Cyclomatic Complexity-

 It helps in determining the software quality.

 It is an important indicator of program code’s readability, maintainability and portability.
 It helps the developers and testers to determine independent path executions.
 It helps to focus more on the uncovered paths.
 It evaluates the risk associated with the application or program.
 It provides assurance to the developers that all the paths have been tested at least once.
 Limit code complexity.
 Determine the number of test cases required.
Advantages of Cyclomatic Complexity:
 It can be used as a quality metric, gives relative complexity of various
designs.
 It is able to compute faster than the Halstead’s metrics.
 It is used to measure the minimum effort and best areas of
concentration for testing.
 It is able to guide the testing process.
 It is easy to apply.

Disadvantages of Cyclomatic Complexity:

 It is the measure of the program’s control complexity and not the data
complexity.
 In this, nested conditional structures are harder to understand than
non-nested structures.
 In case of simple comparisons and decision structures, it may give a
misleading figure.

Mutation Testing:

 What is Mutation Testing?

Mutation Testing is a type of software testing in which certain statements of
the source code are changed/mutated to check if the test cases are able to
find errors in source code. The goal of Mutation Testing is ensuring the quality
of test cases in terms of robustness that it should fail the mutated source
code.
The changes made in the mutant program should be kept extremely small that
it does not affect the overall objective of the program. Mutation Testing is also
called Fault-based testing strategy as it involves creating a fault in the
program and it is a type of White Box Testing which is mainly used for Unit
Testing.
 How to execute Mutation Testing?

Following are the steps to execute mutation testing (mutation analysis):

Step 1: Faults are introduced into the source code of the program by creating
many versions called mutants. Each mutant should contain a single fault, and
the goal is to cause the mutant version to fail which demonstrates the
effectiveness of the test cases.

Step 2: Test cases are applied to the original program and also to the mutant
program. A Test Case should be adequate, and it is tweaked to detect faults
in a program.

Step 3: Compare the results of an original and mutant program.

Step 4: If the original program and mutant programs generate the different
output, then that the mutant is killed by the test case. Hence the test case is
good enough to detect the change between the original and the mutant
program.
Step 5: If the original program and mutant program generate the same output,
Mutant is kept alive. In such cases, more effective test cases need to be
created that kill all mutants.

 Types of Mutation Testing

In Software Engineering, Mutation testing could be fundamentally categorized
into 3 types– statement mutation, decision mutation, and value mutation.

1. Statement Mutation – developer cut and pastes a part of a code of which

the outcome may be a removal of some lines
2. Value Mutation– values of primary parameters are modified
3. Decision Mutation– control statements are to be changed

 Mutation Score
The mutation score is defined as the percentage of killed mutants with the
total number of mutants.

Mutation Score = (Killed Mutants / Total number of Mutants) * 100

Test cases are mutation adequate if the score is 100%. Experimental results
have shown that mutation testing is an effective approach for measuring the
adequacy of the test cases. But, the main drawback is that the high cost of
generating the mutants and executing each test case against that mutant
program.

 Advantages of Mutation Testing

Following are the advantages of Mutation Testing:

 It is a powerful approach to attain high coverage of the source program.

 This testing is capable comprehensively testing the mutant program.
 Mutation testing brings a good level of error detection to the software
developer.
 This method uncovers ambiguities in the source code and has the capacity
to detect all the faults in the program.
 Customers are benefited from this testing by getting a most reliable and
stable system.
Disadvantages of Mutation Testing
On the other side, the following are the disadvantages of Mutant testing:

 Mutation testing is extremely costly and time-consuming since there are

many mutant programs that need to be generated.
 Since its time consuming, it’s fair to say that this testing cannot be done
without an automation tool.
 Each mutation will have the same number of test cases than that of the
original program. So, a large number of mutant programs may need to be
tested against the original test suite.
 As this method involves source code changes, it is not at all applicable
for Black Box Testing.

 What is Volume Testing?

Volume Testing is a type of Software Testing, where the software is
subjected to a huge volume of data. It is also referred to as flood
testing. Volume testing is done to analyze the system performance by
increasing the volume of data in the database.
With the help of Volume testing, the impact on response time and system
behavior can be studied when exposed to a high volume of data.

For example, testing the music site behavior when there are millions of user
to download the song.

Benefits of Volume Testing

 By identifying load issues, a lot of money can be saved which otherwise
will be spent on application maintenance.
 It helps in a quicker start for scalability plans
 Early identification of bottlenecks
 It assures your system is now capable of real-world usage

Why to do Volume Testing

The objective of performing the volume testing is to

 Check system performance with increasing volumes of data in the

database
 To identify the problem that are likely to occur with large amount of data
 To figure out the point at which the stability of the system degrades
 Volume Testing will help to identify the capacity of the system or
application – normal and heavy volume

How to do Volume Testing

In volume testing, following things need to be tested

 Test to check if there is any data loss

 Check the system’s response time
 Check if the data is stored correctly or not
 Verify if the data is overwritten without any notification
 Check for warning and error messages, whether it comes at all for volume
problems
 Check whether high volume data affects the speed of processing
 Does system have the necessary memory resources
 Does volume test executed on the whole system
 Is there any risk if data volume is greater than specified
 Is there any guarantee that no larger date volume will occur than specified

 Stress Testing
Stress Testing is a type of software testing that verifies stability & reliability of
software application. The goal of Stress testing is measuring software on its
robustness and error handling capabilities under extremely heavy load
conditions and ensuring that software doesn’t crash under crunch situations. It
even tests beyond normal operating points and evaluates how software works
under extreme conditions.

In Software Engineering, Stress Testing is also known as Endurance

Testing. Under Stress Testing, AUT is be stressed for a short period of time
to know its withstanding capacity. A most prominent use of stress testing is
to determine the limit, at which the system or software or hardware
breaks. It also checks whether the system demonstrates effective error
management under extreme conditions.
The application under testing will be stressed when 5GB data is copied from
the website and pasted in notepad. Notepad is under stress and gives ‘Not
Responded’ error message.

Goals of Stress Testing

The goal of stress testing is to analyse the behaviour of the system after a
failure. For stress testing to be successful, a system should display an
appropriate error message while it is under extreme conditions.

To conduct Stress Testing, sometimes, massive data sets may be used which
may get lost during Stress Testing. Testers should not lose this security-
related data while doing stress testing.

The main purpose of stress testing is to make sure that the system recovers
after failure which is called as recoverability.

 Debugging:
Software programs undergo heavy testing, updating, troubleshooting, and
maintenance during the development process. Usually, the software
contains errors and bugs, which are routinely removed. Debugging is the
process of fixing a bug in the software.

It refers to identifying, analyzing and removing errors. This process begins

after the software fails to execute properly and concludes by solving the
problem and successfully testing the software. But, it is considered to be
an extremely complex and tedious task because errors need to be
resolved at all stages of debugging.
Why do we need Debugging?
The process of debugging begins as soon as the code of the software is
written. Then, it continues in successive stages as code is combined with
other units of programming to form a software product. Debugging has many
benefits such as:

 It reports an error condition immediately. This allows earlier detection

of an error and makes the process of software development stress-free
and unproblematic.
 It also provides maximum useful information of data structures and
allows easy interpretation.
 Debugging assists the developer in reducing useless and distracting
information.
 Through debugging the developer can avoid complex one-use testing
code to save time and energy in software development.

Steps involved in Debugging

The different steps involved in the process of debugging are:

1. Identify the Error: A bad identification of an error can lead to wasted

developing time. It is usual that production errors reported by users are
hard to interpret and sometimes the information we receive is misleading.
It is import to identify the actual error.
2. Find the Error Location: After identifying the error correctly, you need to
go through the code to find the exact spot where the error is located. In
this stage, you need to focus on finding the error instead of understanding
it.
3. Analyze the Error: In the third step, you need to use a bottom-up
approach from the error location and analyze the code. This helps you in
understanding the error. Analyzing a bug has two main goals, such as
checking around the error for other errors to be found, and to make sure
about the risks of entering any collateral damage in the fix.
4. Prove the Analysis: Once you are done analyzing the original bug, you
need to find a few more errors that may appear on the application. This
step is about writing automated tests for these areas with the help of a
test framework.
5. Cover Lateral Damage: In this stage, you need to create or gather all the
unit tests for the code where you are going to make changes. Now, if you
run these unit tests, they all should pass.
6. Fix & Validate: The final stage is the fix all the errors and run all the test
scripts to check if they all pass.

What is Software Maintenance?

Software Maintenance is the process of modifying a software product after
it has been delivered to the customer. The main purpose of software
maintenance is to modify and update software applications after delivery
to correct faults and to improve performance.
Software maintenance is also an important part of the Software
Development Life Cycle (SDLC). To update the software application and
do all modifications in software application so as to improve performance
is the main focus of software maintenance. Because change is inevitable,
mechanism must be developed for evaluating, controlling and making
modifications. So any work done to change the software after it is in
operation is considered to be maintenance work. The purpose is to
preserve the value of software over time. Software is a model that run on
the basis of real world. So, whenever any change requires in the software
that means the need of real world changes wherever possible.
Maintenance may span for 20 years, whereas development may be 1-2
years.
Using the right software maintenance techniques and strategies is a critical
part of keeping any software running for a long period of time and keeping
customers and users happy.

Types of Software Maintenance:

The only thing that remains constant in life is “change”. As the
specification of the computer system, reflecting changes in the
external world, so must the systems themselves. The four different
types of software maintenance are each performed for different
reasons and purposes. A given piece of software may have to undergo
one, two, or all types of maintenance throughout its lifespan.

The four types are:-

 Corrective Software Maintenance.
 Preventative Software Maintenance.
 Perfective Software Maintenance.
 Adaptive Software Maintenance.

 Corrective Maintenance
Corrective software maintenance is what one would typically associate with
the maintenance of any kind. Correct software maintenance addresses the
errors and faults within software applications that could impact various
parts of your software, including the design, logic, and code. These
corrections usually come from bug reports that were created by users or
customers – but corrective software maintenance can help to spot them
before your customers do, which can help your brand’s reputation.
Corrective maintenance aims to correct any remaining errors regardless of
where they may cause specifications, design, coding, testing, and
documentation, etc.

 Adaptive maintenance:
Adaptive software maintenance becomes important when the environment
of your software changes. This can be brought on by changes to the
operating system, hardware, software dependencies, Cloud storage, or
even changes within the operating system.

 Perfective maintenance:
Perfective software maintenance focuses on the evolution of requirements
and features that existing in your system. As users interact with your
applications, they may notice things that you did not or suggest new
features that they would like as part of the software, which could become
future projects or enhancements. Perfective software maintenance takes
over some of the work, both adding features that can enhance user
experience and removing features that are not effective and functional. This
can include features that are not used or those that do not help you to meet
your end goals.

 Preventive maintenance:
Preventative software maintenance is looking into the future so that your
software can keep working as desired for as long as possible.

This includes making necessary changes, upgrades, adaptations and

more. Preventative software maintenance may address small issues which
at the given time may lack significance but may turn into larger problems in
the future. These are called latent faults which need to be detected and
corrected to make sure that they won’t turn into effective faults. These
include optimizing code and updating documentation as needed.

Preventative software maintenance helps to reduce the risk associated with

operating software for a long time, helping it to become more stable,
understandable, and maintainable.

Changing a Software System:

The concept of software maintenance and evolution of systems was first introduced by
Lehman, who carried out several studies and proposed five laws based on these
studies. One of the key observations of the studies was that large systems are never
complete and continue to evolve. Note that during evolution, the systems become more
complex, therefore, some actions are needed to be taken to reduce the complexity. The
five laws stated by Lehman are listed in Table.

Table Lehman Laws

Law Description

Continuing change The environment in which the software operates keeps

on changing, therefore, the software must also be
changed to work in the new environment.

Increasing complexity The structure of the software becomes more complex

with continuous change in software, therefore, some
preventive steps must be taken to improve and simplify
its structure.

Large software evolution Software evolution is a self-regulating process. Software

attributes such as size, time between releases, and the
number of reported errors are almost constant for each
system release.

Organizational stability The rate with which the software is developed remains
approximately constant and is independent of the
resources devoted to the software development.

Conservation of familiarity During the life of software, added to it in each release,

may be introduced.
Factors Affecting Software Maintenance:
Many factors directly or indirectly lead to high maintenance costs. A software
maintenance framework is created to determine the affects of these factors on
maintenance. This framework comprises user requirements, organizational and
operational environment, maintenance process, maintenance personnel, and the
software product (see Table). These elements interact with each other based on three
kinds of relationships, which are listed below.
Table Components of Software Maintenance Framework

Component Features
 Request for additional functionality, error
User requirements correction, capability, and improvement in
maintainability.
 Request for non-programming related
support.

 Change in business policies.

Organizational environment  Competition in market.

 Hardware platform.
Operational environment  Software specifications.

 Capturing requirements.
Maintenance process  Variation in programming and working
practices.
 Paradigm shift.
 Error detection and correction.

 Quality of documentation.
Software product  Complexity of programs.
 Program structure.

 Staff turnover.
Software maintenance team  Domain expertise.

1. Relationship of software product and environment: In this relationship, the

software product changes according to the organizational and operational environment.
However, it is necessary to accept only those changes which are useful for the software
product.
2. Relationship of the software product and user: In this relationship, the software
product is modified according to the new requirements of users. Hence, it is important to
modify the software that is useful and acceptable to users after modification.
3. Relationship of software product and software maintenance team: In this
‘relationship, the software maintenance team members act as mediators to keep track of
the software product. In other words, the software maintenance team analyzes the
modifications in other elements of software maintenance framework to determine their
effect on the software product. These elements include user requirements, organizational
and operational environments, and the software maintenance process. All these
elements affect the modifications in software and are responsible for maintaining
software quality.
Generally, users have little knowledge of the software maintenance process due to which
they can be unsupportive to the software maintenance team. Also, users may have some
misconceptions such as software maintenance is like hardware maintenance, changing
software is easy, and changes cost too much and are time consuming.
If user requirements need major changes in the software, a lot of time may be consumed
in implementing them. Similarly, users may opt for changes that are not according to the
software standards or policies of a company. This situation creates a conflict between
users and the software maintenance team.
To implement user requirements in software, the following characteristics should be
considered.
1. Feasible: User requirements are feasible if the requested change is workable in the
software system.
2. Desirable: Before implementing new changes, it is important to consider whether the
user modification request is necessary.
3. Prioritized: In some cases, the user requirements may be both feasible and
desirable. However, these requirements may not be of high priority at that time. In such
a situation, the user requirements can be implemented later.

*The rest part of the chapter cover

through the book.*