1

ITC 504
SOFTWARE TESTING
 Software Testing
2

Testing is the process of evaluating a system or its

component(s) with the intent to find whether it
satisfies the specified requirements or not. In simple
words, testing is executing a system in order to
identify any gaps, errors, or missing requirements in
contrary to the actual requirements.

According to ANSI/IEEE 1059 standard, Testing can be

defined as - A process of analyzing a software item to
detect the differences between existing and required
conditions (that is defects/errors/bugs) and to
evaluate the features of the software item.
 Software Testing
2
 Software Testing
2

Software Testing Strategy

 Software Testing
2

Unit testing is a fundamental level of software testing in which

individual components or units of a software application are tested in
isolation. The primary purpose of unit testing is to ensure that each
unit of code, typically a single function or method, works correctly
and produces the expected results.
◻ In software development, a "unit" refers to the smallest testable
part of a program. It can be a function, method, or a specific piece
of code that performs a well-defined task within the application.
Unit testing involves creating test cases for these individual units
to verify that they behave as intended. The key principles of unit
testing include:
◻ Isolation: Unit tests should focus on testing one unit of code in
isolation, meaning that dependencies on other units should be
minimized or replaced with test doubles (e.g., mocks or stubs).
◻ Determinism: Unit tests should be deterministic, meaning that
they produce the same results every time they are run, given the
 Software Testing
2

◻ Independence: Unit tests should be independent of each other,

so the failure of one test doesn't affect the execution of others.
◻ Automation: Unit tests are typically automated, meaning they
can be run automatically without manual intervention.
◻ Example:
◻ Let's consider a simple Python function for addition as an example
of unit testing. Here's the function:
◻ def add(a, b): return a + b
◻ Now, let's create a unit test for this function using Python's built-
in unittest framework:
 Software Testing
2

◻ import unittest
◻ # Import the function to be tested
◻ from my_module import add
◻ class TestAddition(unittest.TestCase):
◻ def test_add_positive_numbers(self):
◻ result = add(2, 3)
◻ self.assertEqual(result, 5)
◻ def test_add_negative_numbers(self):
◻ result = add(-2, -3)
◻ self.assertEqual(result, -5)
◻ def test_add_mixed_numbers(self):
◻ result = add(2, -3)
◻ self.assertEqual(result, -1)
◻ if __name__ == '__main__':
◻ unittest.main()
 Software Testing
2

◻ In this example:
◻ We import the add function from a module (in reality, it could be
part of a larger codebase).
◻ We create a test class TestAddition that inherits from
unittest.TestCase.
◻ Inside this class, we define three test methods
(test_add_positive_numbers, test_add_negative_numbers, and
test_add_mixed_numbers), each testing a different scenario for
the add function.
◻ Within each test method, we use assertion methods like
self.assertEqual to check if the function's output matches the
expected results.
◻ Unit tests like these help ensure that the add function behaves as
expected under various input conditions, and they can be run
automatically as part of your development process to catch
 Software Testing
2

Data flow across a component interface is tested

before any other testing is initiated. If data do not
enter and exit properly, all other tests are moot.
Selective testing of execution paths is an essential
task during the unit test. Test cases should be
designed to uncover errors due to erroneous
computations, incorrect comparisons, or improper
control flow
 Software Testing
2

Boundary testing is one of the most important unit

testing tasks. Software often fails at its boundaries.
That is, errors often occur when the nth element of
an n-dimensional array is processed, when the ith
repetition of a loop with i passes is invoked, when the
maximum or minimum allowable value is
encountered. Test cases that exercise data structure,
control flow, and data values just below, at, and just
above maxima and minima are very likely to uncover
errors.
 Software Testing
2

Because a component is not a stand-alone program,

driver and/or stub software must often be developed
for each unit test. The unit test environment is
illustrated below. In most applications a driver is
nothing more than a “main program” that accepts
test case data, passes such data to the component
(to be tested), and prints relevant results.
 Software Testing
2

Stubs serve to replace modules that are subordinate

(invoked by) the component to be tested. A stub or
“dummy subprogram” uses the subordinate module’s
interface, may do minimal data manipulation, prints
verification of entry, and returns control to the
module undergoing testing.
 Software Testing
2

◻ Next, components must be assembled or

integrated to form the complete software package.
◻ Integration testing addresses the issues
associated with the dual problems of verification
and program construction.
◻ Test case design techniques that focus on inputs
and outputs are more prevalent during integration,
although techniques that exercise specific program
paths may be used to ensure coverage of major
control paths
 Software Testing
2

Integration testing is a systematic technique for

constructing the software architecture while at the
same time conducting tests to uncover errors
associated with
interfacing. The objective is to take unit-tested
components and build a program structure that has
been dictated by design.
In Incremental integration: The program is
constructed and tested in small increments, where
errors are easier to isolate and correct; interfaces are
more likely to be tested completely; and a systematic
test approach may be applied.
 Software Testing
2

Top-down integration. Top-down integration testing is

an incremental approach to construction of the
software architecture. Modules are integrated by
moving
downward through the control hierarchy, beginning
with the main control module
 Software Testing
2

The main control module is used as a test driver and stubs are
substituted for all components directly subordinate to the main
control module.
2. Depending on the integration approach selected (i.e., depth or
breadth first), subordinate stubs are replaced one at a time with
actual components.
3. Tests are conducted as each component is integrated.
4. On completion of each set of tests, another stub is replaced with
the real component.
5. Regression testing (discussed later in this section) may be
conducted to ensure that new errors have not been introduced.
 Software Testing
2

Top-down strategy sounds relatively uncomplicated, but in

practice, logistical problems can arise. The most common of these
problems occurs when processing at low levels in the hierarchy is
required to adequately test upper levels.
Stubs replace low-level modules at the beginning of top-down
testing; therefore, no significant data can flow upward in the
program structure. As a tester, you are left with three choices:
(1) delay many tests until stubs are replaced with actual modules,
(2) develop stubs that perform limited functions that simulate the
actual module, or
(3) integrate the software from the bottom of the hierarchy
upward.
 Software Testing
2

Bottom-up integration. Bottom-up integration testing, as its name

implies, begins construction and testing with atomic modules (i.e.,
components at the lowest levels in the program structure).
Because components are integrated from the bottom up, the
functionality provided by components subordinate to a given level
is always available and the need for stubs is eliminated.
 Software Testing
2

A bottom-up integration strategy may be implemented with the

following steps:
1. Low-level components are combined into clusters (sometimes
called builds)
that perform a specific software subfunction.
2. A driver (a control program for testing) is written to coordinate
test case input
and output.
3. The cluster is tested.
4. Drivers are removed and clusters are combined moving upward
in the
program structure.
 Software Testing
2

Integration follows the pattern illustrated in Figure 17.6.

Components are combined to form clusters 1, 2, and 3. Each of the
clusters is tested using a driver (shown as a dashed block).
Components in clusters 1 and 2 are subordinate to Ma. Drivers D1
and D2 are removed and the clusters are interfaced directly to Ma.
Similarly, driver D3 for cluster 3 is removed prior to integration
with module Mb. Both Ma and Mb will
ultimately be integrated with component Mc, and so forth
 Software Testing
2

◻ Integration testing is a level of software testing that focuses on

verifying the interactions between different components or
modules of a software application when they are integrated or
combined. The primary goal of integration testing is to ensure
that these integrated components work together as expected and
that they do not introduce defects or issues when combined.
Integration testing can uncover problems related to data flow,
communication between modules, and overall system
functionality.
◻ Integration testing is conducted after unit testing (which tests
individual components in isolation) and before system testing
(which tests the entire system as a whole). It aims to identify
issues that may arise when various components or modules
interact with each other. The types of interactions being tested
can vary:
◻ Interface Testing: Verifying that different components can
 Software Testing
2

◻ Data Flow Testing: Ensuring that data flows correctly between

components, and that data transformations or translations work
as expected.

◻ Dependency Testing: Checking how components depend on each

other, and ensuring that dependencies are handled correctly.

◻ Integration Points: Testing where different modules are integrated,

such as at the database level or when external systems are
involved.
 Software Testing
2

Regression testing. Each time a new module is added as

part of integration testing, the software changes. New data flow
paths are established, new I/O may occur, and new control logic is
invoked. These changes may cause problems with functions that
previously worked flawlessly. In the context of an integration test
strategy, regression testing is the reexecution of some subset of
tests that have already been
conducted to ensure that changes have not propagated
unintended side effects
 Software Testing
2

After the software has been integrated (constructed),

a set of high-order tests is conducted. Validation
criteria (established during requirements analysis)
must be evaluated. Validation testing provides final
assurance that software meets all informational,
functional, behavioral, and performance
requirements.
 Software Testing
2

Most software product builders use a process called

alpha and beta testing to uncover errors that only the
end user seems able to find.
The alpha test is conducted at the developer’s site by
a representative group of end users. The software is
used in a natural setting with the developer “looking
over the
shoulder” of the users and recording errors and
usage problems. Alpha tests are conducted in a
controlled environment.
 Software Testing
2

The beta test is conducted at one or more end-user

sites. Unlike alpha testing, the developer generally is
not present. Therefore, the beta test is a “live”
application of the software in an environment that
cannot be controlled by the developer. The customer
records all problems (real or imagined) that are
encountered during beta testing and reports these to
the developer at regular intervals. As a result of
problems reported during beta tests, you make
modifications and then prepare for release of the
software product to the entire customer base.
 Software Testing
2

A variation on beta testing, called customer

acceptance testing, is sometimes performed when
custom software is delivered to a customer under
contract. The customer performs a series of specific
tests in an attempt to uncover errors before
accepting the software from the developer. In some
cases (e.g., a major corporate or governmental
system) acceptance testing can be very formal and
encompass many days or even weeks of testing.
 Software Testing
2

The last high-order testing step falls outside the

boundary of software engineering and into the
broader context of computer system engineering.
Software, once validated, must be combined with
other system elements (e.g., hardware,
people,databases). System testing verifies that all
elements mesh properly and that overall system
function/performance is achieved.
 Software Testing
2

Recovery Testing:
Recovery testing is a system test that forces the
software to fail in a variety of ways and verifies that
recovery is properly performed. If recovery is
automatic (performed
by the system itself), reinitialization, checkpointing
mechanisms, data recovery, and restart are
evaluated for correctness. If recovery requires human
intervention, the
mean-time-to-repair (MTTR) is evaluated to
determine whether it is within acceptable limits.
 Software Testing
2

Security Testing:
Any computer-based system that manages sensitive
information or causes actions that can improperly
harm (or benefit) individuals is a target for improper
or illegal
penetration. Penetration spans a broad range of
activities: hackers who attempt to penetrate systems
for sport, disgruntled employees who attempt to
penetrate for
revenge, dishonest individuals who attempt to
penetrate for illicit personal gain.
 Software Testing
2

Security testing attempts to verify that protection

mechanisms built into a system will, in fact, protect it
from improper penetration.During security testing, the
tester plays the role(s) of the individual who desires to
penetrate the system. The tester may attempt to
acquire passwords through external clerical means;
may attack the system with custom software designed
to break down any defenses that have been
constructed; may overwhelm the system, thereby
denying service to others; may purposely cause system
errors,hoping to penetrate during recovery; may
browse through insecure data, hoping to find the key to
system entry.
 Software Testing
2

Stress Testing:
Stress testing executes a system in a manner that demands resources in
abnormal quantity, frequency, or volume. For example,
(1) special tests may be designed that generate ten interrupts per second,
when one or two is the average rate,
(2) input data rates may be increased by an order of magnitude to
determine how
input functions will respond,
(3) test cases that require maximum memory or other resources are
executed,
(4) test cases that may cause thrashing in a virtual operating system are
designed,
(5) test cases that may cause excessive hunting for disk-resident data are
created. Essentially, the tester attempts to break the program.
 Software Testing
2

Performance Testing:
Performance testing is designed to test the run-time performance of
software within the context of an integrated system. Performance testing
occurs throughout all steps in the testing process. Even at the unit level,
the performance of an individual module may be assessed as tests are
conducted. However, it is not until all system elements are fully integrated
that the true performance of a system can be ascertained.
 Software Testing
2

Deployment Testing:
In many cases, software must execute on a variety of platforms and under
more
than one operating system environment. Deployment testing, sometimes
called
configuration testing, exercises the software in each environment in which
it is to
operate. In addition, deployment testing examines all installation
procedures and specialized installation software (e.g., “installers”) that
will be used by customers,and all documentation that will be used to
introduce the software to end users
 Software Testing
2

◻ When developing object-oriented software, testing strategies

need to be adapted to focus on the principles and characteristics
of object-oriented (OO) design, such as encapsulation,
inheritance, and polymorphism. Testing OO software requires
verifying the correct behavior of objects, their interactions, and
their relationships.
◻ Here are the primary test strategies for object-oriented software:
 Software Testing
2

◻ 1. Unit Testing
◻ Unit testing focuses on individual components (or "units") of the
software, typically a class or a method in the context of object-
oriented software. The goal is to verify that each unit behaves
correctly in isolation.
◻ Testing Methods: Each method within a class should be tested
independently to ensure it works as expected for different input
values and conditions.
◻ Testing Constructors/Destructors: Special attention should be
given to the creation and destruction of objects, as these can
affect object state and resource management.
◻ Testing Accessor and Mutator Methods: Test "getter" and
"setter" methods to ensure they maintain encapsulation and work
correctly.
 Software Testing
2

◻ 2. Integration Testing
◻ In object-oriented software, integration testing involves testing
how different objects interact with each other, especially when
they belong to different classes. The focus is on interactions
between methods and how they collaborate to achieve a task.
◻ Collaborator Testing: Test how objects work together,
particularly those that are closely related through inheritance or
aggregation.
◻ Interface Testing: If classes interact through defined interfaces,
the testing should ensure correct communication through these
interfaces.
 Software Testing
2

◻ 3. Class Testing
◻ Class testing involves verifying the correctness of an individual
class, particularly its internal structure and state.
◻ Inheritance and Polymorphism: Test cases should ensure that
a class correctly inherits from its parent class, overriding methods
where necessary, and that polymorphism works as expected.
◻ Abstract Classes and Interfaces: Ensure that subclasses
correctly implement methods defined in abstract classes or
interfaces.
 Software Testing
2

◻ 4. Polymorphism Testing
◻ Polymorphism allows objects to be treated as instances of their
parent class. Testing should ensure that methods behave as
expected, even when the actual object type is a subclass.
◻ Dynamic Binding: Verify that the correct methods are invoked at
runtime based on the actual object type.
◻ Method Overriding: Ensure that overridden methods behave
correctly when accessed through a parent class reference.
 Software Testing
2

◻ 5. Inheritance Testing
◻ Inheritance is a key feature of object-oriented programming
where a class can inherit properties and methods from a parent
class. Testing should ensure that inherited methods and
properties behave as expected and that derived classes function
correctly.
◻ Testing Superclass Methods: Ensure that inherited methods
function properly in derived classes.
◻ Testing Overriding Methods: Verify that the behavior of
methods that override a parent class method is appropriate and
correct.
 Software Testing
2

◻ 6. Encapsulation Testing
◻ Encapsulation refers to the practice of keeping the internal state
of an object hidden and only exposing specific methods to
manipulate it. Testing should ensure that the internal state cannot
be accessed or altered inappropriately.
◻ Testing Access Control: Ensure that private or protected data
members cannot be accessed directly from outside the class.
◻ Testing Data Integrity: Verify that setters and getters correctly
manage the internal state of the object.
 Software Testing
2

◻ 7. Exception Handling Testing

◻ Since OO software often makes heavy use of exceptions for error
handling, it’s important to test how objects behave in error-prone
situations.
◻ Testing Exception Propagation: Ensure that exceptions are
properly thrown and caught within the object’s methods.
 Software Testing
2

◻ Testing strategies for web applications involve verifying that the

application functions as expected, is secure, performs well under
load, and provides a seamless user experience across different
devices and browsers. Web apps are typically client-server-based,
with user interfaces accessed through browsers, making testing
complex due to the variety of technologies, platforms, and users
involved.
◻ Here are key testing strategies for web applications:
 Software Testing
2

◻ 1. Functional Testing
◻ Functional testing ensures that the features and functionalities of
the web application work according to the requirements. It verifies
that the system behaves as intended when a user interacts with
it.
◻ Unit Testing: Test individual components of the web application
(such as functions, methods, or individual classes) in isolation.
◻ Integration Testing: Test how different modules or components
of the web application work together (e.g., interaction between
frontend and backend).
◻ User Interface (UI) Testing: Ensure that the user interface
elements (buttons, forms, links, etc.) function properly, and that
the UI is usable and intuitive.
◻ Form Testing: Test form submissions, field validations, and error
messages when forms are filled incorrectly.
 Software Testing
2

◻ 2. Usability Testing
◻ Usability testing evaluates how user-friendly, intuitive, and easy
to navigate the web application is. It assesses the design, layout,
and ease of use.
◻ Navigation Testing: Ensure that users can easily move from one
part of the application to another without confusion.
◻ User Experience (UX) Testing: Test the overall user experience
by simulating different user journeys, identifying issues that affect
satisfaction.
◻ Accessibility Testing: Ensure the web app is accessible to users
with disabilities, complying with standards like WCAG (Web
Content Accessibility Guidelines).
 Software Testing
2

◻ 3. Cross-Browser and Cross-Device Testing

◻ Since web applications are accessed through different browsers
and devices (mobile phones, tablets, desktops), it’s important to
ensure consistent behavior across platforms.
◻ Browser Compatibility Testing: Ensure the application works
correctly on different browsers (Chrome, Firefox, Safari, Edge,
etc.) and across different versions.
◻ Device Compatibility Testing: Test the web app on various
devices (smartphones, tablets, desktops) with different screen
resolutions and operating systems (Android, iOS, Windows,
macOS).
◻ Responsive Design Testing: Verify that the web app layout
adapts properly to different screen sizes and orientations
(portrait/landscape).
 Software Testing
2

◻ 4. Performance Testing
◻ Performance testing is critical to ensure that the web app remains
responsive and provides a smooth experience, even under
different load conditions.
◻ Load Testing: Test how the web app performs under expected
user load (e.g., 1,000 users concurrently). This ensures the
system handles peak traffic without performance degradation.
◻ Stress Testing: Test the application under extreme conditions,
such as heavy user traffic or large data volumes, to identify
breaking points.
◻ Scalability Testing: Ensure the web app can scale to handle
increased loads by adding resources, such as additional servers or
database instances.
◻ Response Time Testing: Measure the time taken for web pages
to load and respond to user interactions under different network
conditions.
 Software Testing
2

◻ 5. Security Testing
◻ Security testing ensures that the web application is protected
from malicious attacks and unauthorized access. Web apps are
vulnerable to many types of threats, including data breaches and
hacking.
◻ Authentication Testing: Test the login process to ensure only
authorized users can access protected areas.
◻ Authorization Testing: Verify that users can only access the
functionalities and data they are authorized for (role-based access
control).
 Software Testing
2

◻ 6. Database Testing
◻ Database testing ensures that the web app’s interaction with the
database is accurate, efficient, and secure.
◻ Data Integrity Testing: Verify that data is correctly saved,
updated, and retrieved from the database.
◻ Data Migration Testing: Test how well the web app handles
data migration if the underlying database or schema is updated.
◻ Database Performance Testing: Ensure the database can
handle the expected load, especially under heavy read/write
operations.
◻ Data Security Testing: Verify that sensitive data (e.g., user
passwords, credit card information) is stored securely using
encryption and hashing techniques.
 Software Testing
2

◻ 7. API Testing
◻ Many web applications rely on APIs (Application Programming
Interfaces) for interacting with backend services. API testing
ensures these interactions work correctly.
◻ Functionality Testing: Test that the API endpoints return the
expected responses based on different requests (GET, POST, PUT,
DELETE).
◻ Error Handling Testing: Verify that the API returns the correct
error codes (e.g., 400 Bad Request, 404 Not Found, 500 Internal
Server Error) when something goes wrong.
◻ Performance Testing: Test how the API handles different levels
of load and whether it responds quickly under various traffic
conditions.
◻ Security Testing: Ensure that APIs are secured using tokens
(e.g., OAuth) or API keys, and that sensitive data is protected.
 Software Testing
Debugging is not testing but
often occurs as a consequence
of testing.5 Referring to
Figure 17.7, the debugging
process begins with the
execution of a test case.

Debugging occurs as a consequence of

successful testing. That is, when a test
case uncovers an error, debugging is the
process that results in the removal of the
error.
The Debugging Process:
Debugging is not testing but often occurs as
a consequence of testing. Referring to Fig,
the debugging process begins with the
execution of a test case.The debugging
process will usually have one of two
outcomes:
(1) the cause will be found and corrected or
(2) the cause will not be found. In the latter
case, the person performing debugging may
suspect a cause, design a test case to help
validate that suspicion, and work toward
 SOFTWARE MAINTENANCE
2

Much of the software we depend on today is on average 10 to 15

years old. Even when these programs were created using the best
design and coding techniques known at the time [and most were
not], they were created when program size and storage space were
principle concerns. They were then migrated to new platforms,
adjusted for changes in machine and operating system technology
and enhanced to meet new user needs—all without enough regard
to overall architecture. The result is the poorly designed structures,
poor coding, poor logic, and poor documentation of the software
systems we are now called on to keep running. Another reason for
the software maintenance problem is the mobility of software
people
 SOFTWARE SUPPORTABILITY
2

◻In order to effectively support industry-grade

software, your organization (or its designee)
must be capable of making the corrections,
adaptations, and enhancements that are
part of the maintenance activity. But in
addition, the organization must provide
other important support activities that
include ongoing operational support, end-
user support, and reengineering activities
over the complete life cycle of the software.
 SOFTWARE SUPPORTABILITY
2

◻A reasonable definition of software

supportability is the capability of supporting
a software system over its whole product
life. This implies satisfying any necessary
needs or requirements, but also the
provision of equipment, support
infrastructure, additional software, facilities,
manpower, or any other resource required to
maintain the software operational and
capable of satisfying its function
Business Process
Reengineering
2

◻ Business Process Reengineering (BPR) is a fundamental rethinking

and radical redesign of business processes to achieve significant
improvements in critical performance metrics such as cost,
quality, service, and speed. It involves the analysis, redesign, and
implementation of business processes, often leveraging modern
technology to streamline and optimize operations. BPR aims to
break down silos, eliminate inefficiencies, and align processes
with organizational goals.
◻ Key Concepts of BPR:
◻ Fundamental Rethinking: BPR questions why certain processes
exist in their current form and whether they should be completely
redesigned from scratch.
Business Process
Reengineering
2

◻ Radical Redesign: It involves making significant changes to

processes, sometimes eliminating them altogether or combining
them to make them more efficient.
◻ Dramatic Improvements: The goal is not incremental change
but major leaps in performance — like reducing costs by 50%,
improving customer service drastically, or slashing production
time.
◻ Process Orientation: BPR focuses on business processes (not
just tasks, jobs, or departments). A process is a sequence of
activities that transforms inputs into outputs to deliver value to
customers.
Business Process
Reengineering
2

◻ Example of Business Process Reengineering

◻ Case: Ford Motor Company – Accounts Payable Process In
the early 1990s, Ford was facing inefficiencies in its accounts
payable department, employing approximately 500 staff to handle
purchasing and invoice processing. The company decided to
undertake a BPR initiative to streamline the process.
◻ Original Process:
◻ The purchasing department created a purchase order (PO) for
items.
◻ When goods were received, the receiving department created a
goods received note (GRN).
◻ The accounts payable department would receive the supplier’s
invoice, match it with the PO and GRN, and then process the
payment.
◻ This was a labor-intensive process, requiring multiple checks and
Business Process
Reengineering
2

◻ Reengineered Process:
◻ Ford rethought the process from the ground up and eliminated the
need for matching invoices with purchase orders. Instead, they
created a new approach:
◻ The purchasing department issued a purchase order for the
required items.
◻ When the goods arrived, the receiving department directly
entered the information into the system.
◻ Ford would then automatically pay the supplier based on the
original purchase order and the confirmation that the goods were
received. No invoice was needed.
Business Process
Reengineering
2

◻ Outcome:
◻ Staff Reduction: The number of employees in the accounts
payable department dropped from 500 to 125.
◻ Efficiency Gains: The entire process became faster, reducing
errors and the need for manual intervention.
◻ Cost Savings: Ford significantly reduced its processing costs by
automating much of the workflow.
Business Process
Reengineering
2

◻ Benefits of BPR:
◻ Cost Reduction: BPR can lower operational costs by simplifying
processes and eliminating redundancies.
◻ Increased Efficiency: By redesigning processes, companies can
perform tasks more quickly and with fewer resources.
◻ Better Customer Service: Streamlined processes often result in
better service delivery to customers.
◻ Flexibility: Redesigned processes can often adapt more easily to
changes in market demands or technology.
 Software Re-engineering
2

◻ Software reengineering, also known as software reverse

engineering, is the process of examining, understanding, and
improving existing software systems. It is often necessary when
dealing with legacy software that is outdated, poorly documented,
or difficult to maintain. The goal of software reengineering is to
enhance the quality, maintainability, and performance of the
existing software while potentially adding new features.
◻ Key Concepts in Software Reengineering:
◻ Understanding Existing Code: In software reengineering, the
first step is to understand the existing code thoroughly. This
includes analyzing the codebase, identifying dependencies, and
comprehending the system's structure.
◻ Documentation and Reverse Engineering: In many cases, the
original documentation for legacy software may be lacking or
outdated. Reverse engineering tools and techniques are used to
extract design and architecture information from the code.
 Software Re-engineering
2

◻ Refactoring: Refactoring is a crucial part of reengineering. It

involves restructuring the code to improve its readability,
maintainability, and performance without changing its external
behavior.
◻ Migration: Sometimes, reengineering involves migrating the
software to a new platform, programming language, or
architecture. This may be necessary if the existing technology is
obsolete or no longer supported.
◻ Adding New Features: Reengineering may also involve adding
new features or functionalities to the software to align it with
current business requirements.
◻ Testing: After making changes, rigorous testing is essential to
ensure that the reengineered software functions correctly and
doesn't introduce new defects.
 Software Re-engineering
2

◻ Example: Reengineering a Legacy Accounting Software

◻ Let's consider the example of reengineering a legacy accounting
software system. The company has been using an old, monolithic
accounting software package for decades. It lacks documentation,
is difficult to maintain, and struggles to keep up with modern
accounting practices and tax regulations.
◻ Understanding Existing Code:
◻ Begin by analyzing the existing codebase and identifying modules
and components.
◻ Document the software's main functions, data structures, and
dependencies.
 Software Re-engineering
2

◻ Documentation and Reverse Engineering:

◻ Use reverse engineering tools to generate architectural diagrams
and documentation from the existing code.
◻ Create a detailed overview of the software's structure and data
flow.
◻ Refactoring:
◻ Break down the monolithic software into modular components,
making it more maintainable.
◻ Refactor code to improve readability and remove redundant or
obsolete sections.
◻ Update database schemas to accommodate new accounting
requirements.
 Software Re-engineering
2

◻ Migration:
◻ Evaluate whether the existing technology stack is still suitable.
◻ Consider migrating the software to a more modern platform,
possibly transitioning from a desktop application to a web-based
system for easier access and scalability.
◻ Adding New Features:
◻ Implement new features such as automated tax calculation, real-
time financial reporting, and integration with online banking
services.
◻ Ensure these new features align with current accounting
standards and regulations.
Restructuring-Forward
Engineering
2

◻ Restructuring-Forward Engineering is a software engineering

process that involves making significant changes to an existing
software system or codebase with the goal of improving its
structure, design, and maintainability. In this process, the existing
system is analyzed and then rebuilt or re-implemented to align it
with best practices, modern technologies, and improved design
principles. It aims to make the codebase more maintainable,
scalable, and easier to work with in the future.
◻ Key Concepts in Restructuring-Forward Engineering:
◻ Analysis: The process starts with a thorough analysis of the
existing software system to understand its current architecture,
design, and issues. This includes identifying code smells,
inefficiencies, outdated components, and other problems.
Restructuring-Forward
Engineering
2

◻ Redesign: Based on the analysis, a new and improved design is

created. This might involve breaking down monolithic structures
into smaller, modular components, improving code organization,
and adopting modern architectural patterns.
◻ Reimplementation: After redesigning the system, the next step
is to re-implement the software based on the new design. This
could involve rewriting code, replacing outdated components, and
integrating new technologies.
◻ Testing: Rigorous testing is conducted throughout the process to
ensure that the restructured software performs correctly and
retains its functionality. Testing also helps identify and fix any new
issues introduced during the restructuring.
◻ Documentation: Proper documentation is crucial to maintain
and understand the restructured codebase. It should include
updated code comments, architectural diagrams, and guidelines
for future development.
Restructuring-Forward
Engineering
2

◻ Change Management: Managing changes and ensuring that

stakeholders are informed and aligned with the restructuring
process is essential to avoid disruption to ongoing business
operations.
◻ Example: Restructuring-Forward Engineering of an E-
commerce Website
◻ Consider an e-commerce company with a successful online
shopping platform that has been in operation for several years.
Over time, the codebase has become unwieldy and challenging to
maintain. It lacks modularity, leading to difficulties in adding new
features and keeping up with changing customer demands.
Restructuring-Forward
Engineering
2

◻ Analysis:
◻ Conduct a comprehensive analysis of the existing codebase to
identify areas of concern, such as poor code organization and
outdated technologies.
◻ Recognize that the website's frontend and backend code need
restructuring to improve maintainability.
◻ Redesign:
◻ Redesign the architecture with a focus on modularity and
scalability. For instance, move from a monolithic architecture to a
microservices architecture to enable more flexible feature
development and updates.
◻ Update the user interface design to provide a more intuitive and
responsive user experience.
Restructuring-Forward
Engineering
2

◻ Reimplementation:
◻ Rewrite the backend services using modern frameworks and
technologies, such as moving from a traditional relational
database to a NoSQL database for improved scalability.
◻ Refactor the frontend code using modern JavaScript libraries and
frameworks for better performance and maintainability.
◻ Testing:
◻ Conduct thorough testing, including unit testing, integration
testing, and user acceptance testing, to ensure that the
restructured website performs without issues.
◻ Pay close attention to ensuring the existing functionality is
retained and that the user experience is enhanced.
Restructuring-Forward
Engineering
2

◻ Documentation:
◻ Update code comments and create architectural documentation
to make it easier for developers to understand and maintain the
system.
◻ Provide guidelines for future development and best practices to
keep the codebase in good shape.
◻ Change Management:
◻ Communicate the restructuring process to stakeholders, including
employees, customers, and partners, to manage expectations and
minimize disruption.
◻ Keep stakeholders informed about the benefits of the
restructuring, such as improved site performance and better user
experience.
Restructuring-Forward
Engineering
2

◻ Through Restructuring-Forward Engineering, the e-commerce

company successfully modernizes its website, making it more
maintainable and responsive to changing customer needs. This
leads to better performance, scalability, and a smoother user
experience. Additionally, it sets the company up for easier feature
development and updates in the future.
Difference Between
2

◻ Software Reengineering and Restructuring-Forward

Engineering are related concepts in the field of software
engineering, but they differ in their objectives, processes, and the
extent of changes made to existing software systems. Here are
the key differences between the two:
◻ Objective:
◻ Software Reengineering: The primary goal of software
reengineering is to improve the quality, maintainability, and
performance of existing software systems. It involves
understanding, documenting, and enhancing the software without
fundamentally changing its functionality.
◻ Restructuring-Forward Engineering: The main objective of
restructuring-forward engineering is to make substantial changes
to an existing software system to improve its structure, design,
and maintainability while potentially introducing new features. It
often involves redesigning and re-implementing significant parts
Difference Between
2

◻ Extent of Changes:
◻ Software Reengineering: Reengineering typically involves
making incremental improvements to the existing codebase. It
may include refactoring, optimizing, and fixing issues without
changing the software's core functionality.
◻ Restructuring-Forward Engineering: This process involves
more extensive changes, such as redesigning the architecture, re-
implementing components, and potentially replacing outdated
technologies. It may introduce significant modifications to the
software's functionality.
Difference Between
2

◻ Starting Point:
◻ Software Reengineering: Reengineering typically starts with an
existing software system that may have issues or inefficiencies.
The goal is to maintain and improve the existing functionality.
◻ Restructuring-Forward Engineering: This process often starts
with the recognition that the existing software requires
fundamental changes to keep it aligned with modern practices,
technologies, and business needs.
◻ Focus on Existing Functionality:
◻ Software Reengineering: The focus of reengineering is to
preserve and enhance the existing functionality of the software. It
is often done to extend the lifespan of a legacy system.
◻ Restructuring-Forward Engineering: While maintaining
existing functionality is important, the restructuring-forward
engineering process is more open to introducing new features or
Difference Between
2

◻ Technological Updates:
◻ Software Reengineering: Reengineering may involve minor
technological updates and improvements to the existing system,
such as upgrading libraries or optimizing code.
◻ Restructuring-Forward Engineering: This process often
includes significant technological updates, such as migrating to
new platforms or rewriting core components using modern
technologies.
◻ Documentation and Testing:
◻ Software Reengineering: Documentation and testing are
essential in reengineering, but the emphasis is on understanding
and improving existing code while maintaining stability.
◻ Restructuring-Forward Engineering: Documentation and
testing are equally important in restructuring-forward
engineering, but the focus is on implementing significant changes
Difference Between
2

◻ In summary, while both software reengineering and restructuring-

forward engineering involve making changes to existing software,
they differ in their objectives, scope, and the degree of
modifications made to the software. Software reengineering is
often about maintaining and enhancing existing functionality,
while restructuring-forward engineering involves more extensive
changes and modernization efforts.