SRI RAMAKRISHNA MISSION VIDYALAYA

COLLEGE OF ARTS AND SCIENCE

COMPETITIVE EXAMINATION CELL
ORGANISES
10 DAYS ONLINE COURSE ON
UGC NET/SET/JRF
COMPUTER SCIENCE &
APPLICATIONS
Software Engineering
UGC NET – JUNE 2025
Presented by
K. Ananthalakshmi MSc., NET., (PhD).
School of Computer Science and Engineering
VIT Chennai
Golden Rules To Clear UGC NET
Discipline
Consistency
Patience
Manifestation
Believe yourself and Be You
What are the topics we going to cover today ?
 Introduction to Software Engineering

 Software Development Life Cycle (SDLC)

 Software Requirement Engineering

 Software Design and Modeling

 Software Testing

 Software Maintenance and Configuration Management

 Software Quality Assurance

 Introduction to Software Engineering
• Software engineering is a branch of engineering focused on the systematic development,
operation, and maintenance of software products using well-defined scientific principles,
methods, and procedures.

• It combines the concepts of "software"—which includes not just program code but also
associated libraries and documentation—with "engineering," which emphasizes the use of
structured, disciplined, and quantifiable approaches to problem-solving

• Definition: Software engineering applies engineering principles to the entire software

development lifecycle, from gathering requirements to designing, building, testing, and
maintaining software systems.

• Goal: The main goal is to produce efficient, reliable, and high-quality software that meets
user needs and can be maintained and updated over time
Phases of the Software Development Life Cycle
1. Planning

• This foundational phase defines the project's scope, objectives, and feasibility.

• Teams gather input from stakeholders, analyze business needs, estimate costs, allocate
resources, and set timelines.

• The outcome is a clear project plan that aligns all participants on goals and expectations.

2. Requirements Analysis

• In this phase, detailed requirements are gathered and documented.

• Teams work with stakeholders to understand what the software must do, including functional
and non-functional requirements.

• The result is a requirements specification that guides the rest of the project.
 Phases of the Software Development Life Cycle
Design
• The system's architecture and design are created based on the requirements.

• This includes defining the software structure, technology stack, user interface, data
models, and security protocols.
• The design phase produces blueprints (such as diagrams and prototypes) for
developers to follow.

Implementation (Coding/Development)
• Developers write the actual code based on the design specifications.

• This phase transforms the planned features and architecture into a working product.

• Coding standards and best practices are followed to ensure quality and
maintainability
 Phases of the Software Development Life Cycle
Testing
• The software is rigorously tested to identify and fix bugs or defects.

• Various testing methods (unit, integration, system, user acceptance) are used
to ensure the software meets requirements and works as intended.
• Testing ensures reliability, security, and performance before release.

Deployment
• The tested software is released to users, either as a full launch or in stages
(such as beta releases).
• Deployment may include installation, configuration, and user training.

• The goal is to make the software available in the production environment with
minimal disruption
Phases of the Software Development Life Cycle

Maintenance
• After deployment, the software requires ongoing support.
• Maintenance includes fixing issues, updating features, and adapting to
changing user needs or environments.
• Regular updates and performance monitoring ensure the software
remains functional and secure over time
 Software Models
Waterfall Model

The Waterfall model is a linear and sequential approach to software development and project management. Each
phase of the project must be completed before the next begins, and there is no overlap between phases. The
model's name comes from the way progress is seen as flowing steadily downwards (like a waterfall) through
several distinct phases
 Prototype Model
A prototype is an early, working model or simulation of a product ,whether physical or digital,
created to visualize and test concepts before full-scale development. In software development, a
prototype is an incomplete version of the software that demonstrates how the final product will
look, work, and feel. It is used to gather user feedback, validate requirements, and refine design
ideas before committing significant resources to building the complete system.
Incremental Model
• The incremental model is a software development methodology where
the system is built and delivered in small, manageable parts called
increments. Instead of developing the entire system at once, the
project is divided into stand-alone modules or increments, each of
which is developed, tested, and integrated sequentially.
• For instance, a mobile banking app might first launch with basic
account management features. Subsequent increments could add
transaction history, bill payments, and investment tools, allowing users
to benefit from essential functions while additional features are
gradually introduced.
 Iterative Model
 The iterative model is a software development approach where the overall project is broken
down into smaller cycles called iterations.
 Each iteration involves planning, designing, developing, and testing a small part of the system.
 Rather than attempting to deliver the full product at once, the iterative model starts with a
basic version and gradually adds features and improvements through repeated cycles until the
final system is complete.
• Flexibility: Changes in requirements can be easily accommodated in future iterations
• Early Delivery: A working version of the software is available early in the process, providing
value and enabling early feedback
• Risk Reduction: Problems can be identified and addressed early, minimizing the impact on
the final product.
• Customer Involvement: Stakeholders can review and influence the product at the end of each
iteration
 Evolutionary model
• The evolutionary model in software engineering is a development approach that
combines both iterative and incremental methods.

• Instead of delivering the entire software system at once, the evolutionary model
builds the product step by step, allowing features to be developed, improved,
and refined over multiple iterations.
Spiral Model
The spiral model is a risk-driven software development process that combines
elements of both the iterative (such as prototyping) and sequential (like Waterfall)
models. It is especially suited for large, complex, and high-risk projects where
requirements may evolve or are not fully understood at the outset.
Phases of the Spiral Model
Each spiral (cycle) is divided into four main quadrants or phases:

• Planning: Define objectives, alternatives, and constraints for the current phase.

• Risk Analysis: Identify, assess, and plan mitigation strategies for potential risks.

• Engineering: Develop, test, and integrate the next version or prototype of the
product.

• Evaluation: Review progress with stakeholders, gather feedback, and plan the
next iteration.

This process repeats, with each spiral building on the previous one, until the final
product is ready for deployment
Agile Model
The Agile model is an iterative and incremental approach to software
development and project management. Agile emphasizes flexibility, collaboration,
continuous feedback, and rapid delivery of functional software. Instead of
building the entire product in one go, Agile breaks the project into small,
manageable units called iterations or sprints, each typically lasting 2–4 weeks.
Agile is guided by core principles, including
• Customer satisfaction through early and continuous delivery of valuable
software.

• Embracing changing requirements even late in development.

• Frequent delivery of working software in short cycles.

• Close collaboration between business stakeholders and the development team.

• Empowered, self-organizing teams that determine the best way to accomplish

goals.

• Continuous reflection and adaptation to improve processes and outcomes

Scrum Model
• Scrum is an agile project management framework widely used for developing
complex products, especially in software development, but also applicable in various
industries.

• Scrum helps teams work collaboratively, adaptively, and efficiently by breaking

work into small, time-boxed iterations called sprints, typically lasting 1–4 weeks

• Transparency: All aspects of the process must be visible to those responsible for
the outcome.

• Inspection: Regular assessment of progress to detect undesirable variances.

• Adaptation: Adjusting processes promptly in response to inspection findings

 Feature-Driven Development
• Feature-Driven Development (FDD) is an agile software development methodology that
structures work around building and delivering features small, client-valued pieces of
functionality.

• FDD is iterative, incremental, and customer-centric, aiming to deliver tangible software

results frequently and efficiently.
The quick design of a software that is visible to end users
leads to _____.
(A) iterative model
(B) prototype model
(C) spiral model
(D) waterfall model
The quick design of a software that is visible to end users
leads to _____.
(A) iterative model
(B) prototype model
(C) spiral model
(D) waterfall model
Which process model is also called as classic life cycle
model?
(A) Waterfall model
(B) RAD model
(C) Prototyping model
(D) Incremental model
Which process model is also called as classic life cycle
model?
(A) Waterfall model
(B) RAD model
(C) Prototyping model
(D) Incremental model
For a software project, the spiral model was employed.
When will the spiral stop?
(A) When the software product is retired
(B) When the software product is released after Beta testing
(C) When the risk analysis is completed
(D) After completing five loops
For a software project, the spiral model was employed.
When will the spiral stop?
(A) When the software product is retired
(B) When the software product is released after Beta testing
(C) When the risk analysis is completed
(D) After completing five loops
The ________ model is preferred for software
development when the requirements are not clear.
(A) Rapid Application Development
(B) Rational Unified Process
(C) Evolutionary Model
(D) Waterfall Model
The ________ model is preferred for software
development when the requirements are not clear.
(A) Rapid Application Development
(B) Rational Unified Process
(C) Evolutionary Model
(D) Waterfall Model
The prototyping model of software development is:
(A) a reasonable approach when requirements are well-
defined
(B) a useful approach when a customer cannot define
requirements clearly.
(C) the best approach to use for projects with large
development teams
(D) a risky model that rarely produces a meaningful product.
The prototyping model of software development is:
(A) a reasonable approach when requirements are well-
defined
(B) a useful approach when a customer cannot define
requirements clearly.
(C) the best approach to use for projects with large
development teams
(D) a risky model that rarely produces a meaningful product.
Which of the following represents the life-cycle of software
development?
A. Analysis -> Design -> Coding -> testing -> operation and
maintenance
B. Analysis -> Design -> Coding -> operation and maintenance ->
testing
C. Design -> Analysis -> Coding -> testing -> operation and
maintenance
D. Design -> Analysis -> Coding -> operation and maintenance ->
testing
Which of the following represents the life-cycle of software
development?
A. Analysis -> Design -> Coding -> testing -> operation and
maintenance
B. Analysis -> Design -> Coding -> operation and maintenance
-> testing
C. Design -> Analysis -> Coding -> testing -> operation and
maintenance
D. Design -> Analysis -> Coding -> operation and maintenance
-> testing
The incremental model of software development
is________.
1. A reasonable approach when requirements are well
defined
2. A good approach when a working core product is
required quickly
3. The best approach to use for projects with large
development teams.
4. A revolutionary model that is not used for commercial
products.
The incremental model of software development
is________.
1. A reasonable approach when requirements are well defined
2. A good approach when a working core product is
required quickly
3. The best approach to use for projects with large
development teams.
4. A revolutionary model that is not used for commercial
products.
Software Requirements Engineering (SRE)

• Software Requirements Engineering (SRE) is a critical phase in the

software development life cycle (SDLC) that focuses on gathering,
analyzing, documenting, validating, and managing software
requirements.
• It ensures that the software system meets the needs and expectations
of the users and stakeholders.
 Key Activities in Software Requirements Engineering
Activity Description Common Techniques

Gathering requirements from Interviews, Surveys, Observation,

Requirements Elicitation
stakeholders. Brainstorming, Prototyping

Analyzing gathered requirements for Modeling, Conflict resolution, Feasibility

Requirements Analysis
clarity, consistency, and feasibility. analysis

Documenting requirements in a
Requirements Specification Use cases, SRS templates, UML diagrams
structured format (e.g., SRS).

Ensuring requirements are correct Reviews, Walkthroughs, Prototypes, Test

Requirements Validation
and agreed upon by stakeholders. cases

Handling changes and maintaining Version control, Traceability matrices,

Requirements Management
requirements over time. Change tracking
 Types of Requirements
Type Description Examples

Describe what the system User login, Transfer funds, Generate

Functional
should do. reports

Describe how the system Security, Performance, Usability,

Non-Functional
performs its functions. Availability

Domain Industry-specific or regulatory Compliance with RBI norms,

Requirements requirements. Healthcare standards
 Functional Requirements
• Functional Requirements in Software Engineering are also called Functional
Specification. In this requirement, the end user specifically demands as basic
facilities that the system should offer.

• It can be a calculation, data manipulation, business process, user interaction, or

any other specific functionality which defines what function a system is likely to
perform.

• These are represented or stated in the form of input to be given to the system, the
operation performed and the output expected.

• For example, in a hospital management system, a doctor should be able to retrieve

the information of his patients.

• All scenarios must be enumerated. There are many ways of expressing functional
requirements e.g., natural language, a structured or formatted language with no
rigorous syntax and formal specification language with proper syntax.
 Non-Functional Requirements
• Non-functional Requirements in Software Engineering are also called
non-behavioral requirements.
• These are basically the quality constraints that the system must satisfy
according to the project contract.
• It is not related to the system functionality, rather define how the
system should perform.
• The priority or extent to which these factors are implemented varies
from one project to other.
 Non-Functional Requirements
Issues:

• Portability

• Security

• Maintainability

• Reliability

• Scalability

• Performance

• Reusability

• Flexibility
 Domain requirements
• Domain requirements are the requirements which are characteristic of a
particular category or domain of projects.

• Domain requirements can be functional or non-functional.

• Domain requirements engineering is a continuous process of proactively

defining the requirements for all foreseeable applications to be developed in
the software product line.

• For example, in an academic software that maintains records of a school or

college, the functionality of being able to access the list of faculty and list of
students of each grade is a domain requirement. These requirements are
therefore identified from that domain model and are not user specific.
Importance of Requirements Engineering

Benefit Explanation

Ensures that the final software meets

Builds the right product
stakeholder needs

Correct requirements early reduce costly

Reduces rework and errors
changes later

Clear requirements allow better cost, time,

Improves planning and estimation
and resource estimates

Requirements guide system architecture and

Forms the basis for design & testing
help create test cases
Which of the following is not a Non functional
requirement?
A. Portability
B. Security
C. Scalability
D. User interaction
Which of the following is not a Non functional
requirement?
A. Portability
B. Security
C. Scalability
D. User interaction
The process to gather the software requirements from
client, analyze and document is known as
A. Software Engineering Process
B. User Engineering Process
C. Requirement Elicitation Process
D. Requirement Engineering Process
The process to gather the software requirements from
client, analyze and document is known as
A. Software Engineering Process
B. User Engineering Process
C. Requirement Elicitation Process
D. Requirement Engineering Process
If every requirement can be checked by a cost-effective
process, then SRS is called
A. Verifiable
B. Trackable
C. Modifiable
D. Complete
If every requirement can be checked by a cost-effective
process, then SRS is called
A. Verifiable
B. Trackable
C. Modifiable
D. Complete
Software Design and Modeling
• Software design is a fundamental phase in Software
Engineering that focuses on creating a blueprint for building a
software system. It is the step that follows requirements analysis
and precedes coding (implementation) in the Software
Development Life Cycle
• Software design is the process of transforming user
requirements into a structured solution that can be implemented
using a programming language.
• It involves identifying the software’s components, their
responsibilities, interfaces, and how they interact.
Level of Software Design
Interface Design

• Interface design is the specification of the interaction between a system and its
environment. This phase proceeds at a high level of abstraction with respect to the
inner workings of the system i.e., during interface design, the internal of the systems
are completely ignored, and the system is treated as a black box.

• Attention is focused on the dialogue between the target system and the users,
devices, and other systems with which it interacts.

• The design problem statement produced during the problem analysis step should
identify the people, other systems, and devices which are collectively called agents.
Interface Design

Interface design should include the following details:

• Precise description of events in the environment, or messages from agents to which

the system must respond.

• Precise description of the events or messages that the system must produce.

• Specification of the data, and the formats of the data coming into and going out of
the system.

• Specification of the ordering and timing relationships between incoming events or

messages, and outgoing events or outputs.
Architectural Design

• Architectural design is the specification of the major

components of a system, their responsibilities, properties,
interfaces, and the relationships and interactions between
them.
• In architectural design, the overall structure of the system is
chosen, but the internal details of major components are
ignored.
Architectural design includes
• Gross decomposition of the systems into major components.

• Allocation of functional responsibilities to components.

• Component Interfaces.

• Component scaling and performance properties, resource consumption

properties, reliability properties, and so forth.

• Communication and interaction between components.

• The architectural design adds important details ignored during the interface
design. Design of the internals of the major components is ignored until the last
phase of the design.
 Detailed Design
Detailed design is the specification of the internal elements of all major system components,
their properties, relationships, processing, and often their algorithms and the data structures.

The detailed design may include:

• Decomposition of major system components into program units.

• Allocation of functional responsibilities to units.

• User interfaces.

• Unit states and state changes.

• Data and control interaction between units.

• Data packaging and implementation, including issues of scope and visibility of program
elements.

• Algorithms and data structures.

Cohesion
• Cohesion refers to how closely related and focused the responsibilities of a
single module or component are in software design. In simple terms, it
measures the degree to which the elements inside a module belong
together.

• High cohesion means a module performs a single well-defined task.

• Low cohesion means a module performs multiple, unrelated tasks, making it

harder to maintain and reuse.

• Goal: Achieve high cohesion for better maintainability, readability, and

reusability.
Types of Cohesion (from worst to best):
1. Coincidental Cohesion
Randomly grouped tasks.
Example: A utility module doing file logging, math operations, and UI updates.
2. Logical Cohesion
Tasks grouped logically but selected using control flags.
Example: A function that handles input from keyboard, mouse, and scanner based on a switch.
3. Temporal Cohesion
Tasks that are executed together in time.
Example: Initialization routines that set up various things at program startup.
4. Procedural Cohesion
Tasks are related by the sequence of execution.
Example: A function that opens a file, reads from it, and then closes it.
Cohesion

5.Communicational Cohesion
Tasks operate on the same data set.
Example: Functions that validate and then process the same input data.
6.Sequential Cohesion
Output of one part becomes input of the next.
Example: A function that reads data, processes it, and writes it to a file.
7.Functional Cohesion (Best)
Every element contributes to a single well-defined task.
Example: A module that only sorts data.
 Coupling
Coupling refers to the degree of direct interdependence between software
modules or components. It measures how closely connected two modules are
connected.

1.Content coupling (highest/tightest)

• One module directly uses or modifies the internal data or code of another module.

• Example: accessing another module’s local variables or data structures.

• Very bad for maintainability.

2. Common coupling

• Multiple modules share the same global data.

• Changes in global data affect all modules that use it.

• Difficult to track side effects.

 Coupling
3.Control Coupling
•One module controls the flow of another by passing control flags or decisions.
•Example: Passing a flag that tells the called module what action to take.

4.Stamp (Data-Structured) Coupling

•Modules share composite data structures (like objects or structs), but the
called module only uses part of it.
•Can cause unnecessary dependencies on unused data.

5. Data Coupling (Lowest/Best)

•Modules communicate by passing only the necessary data (parameters).
•Minimal and clear interfaces.
•Preferred for modular design.
Which of the following statement(s) is/are true with respect to software
architecture?

S1 Coupling is a measure of how well the things grouped together in a module

belong together logically.

S2 Cohesion is a measure of the degree of interaction between software modules.

S3: If coupling is low and cohesion is high then it is easier to change one module
without affecting others.

(1) Only S1 and S2

(2) Only S3

(3) All of S1, S2 and S3

(4) Only S1
Which of the following statement(s) is/are true with respect to software
architecture?

S1 Coupling is a measure of how well the things grouped together in a module

belong together logically.

S2 Cohesion is a measure of the degree of interaction between software modules.

S3: If coupling is low and cohesion is high then it is easier to change one module
without affecting others.

(1) Only S1 and S2

(2) Only S3

(3) All of S1, S2 and S3

(4) Only S1
Arrange the following types of Cohesion from best to worst type.

(A) Logical Cohesion

(B) Sequential Cohesion

(C) Communication Cohesion

(D) Temporal Cohesion

(E) Procedural Cohesion

Choose the correct answer from the options given below:

A) B-C-E-D-A

B) B-A-E-D-C

C) A-B-D-C-E

D) E-B-A-C-D
Arrange the following types of Cohesion from best to worst type.

A. Logical Cohesion

B. Sequential Cohesion

C. Communication Cohesion

D. Temporal Cohesion

E. Procedural Cohesion

Choose the correct answer from the options given below:

A) B-C-E-D-A

B) B-A-E-D-C

C) A-B-D-C-E

D) E-B-A-C-D
The lower degree of cohesion is kind of
A. Logical Cohesion
B. Coincidental Cohesion
C. Procedural Cohesion
D. Communication Cohesion
The lower degree of cohesion is kind of
A. Logical Cohesion
B. Coincidental Cohesion
C. Procedural Cohesion
D. Communication Cohesion
 A. Product Complexity Software Requirements Definition

B. Structured System Analysis Software Design

C. Coupling and Cohesion Validation Technique

D. Symbolic Execution. Software Cost Estimation

Select correct option :

(A) (A)-(II), (B)-(III), (C)-(IV), (D)-(1)
(B) (A)-(III), (B)-(1), (C)-(IV), (D)-(II)
(C) (A)-(IV), (B)-(1), (C)-(II), (D)-(111)
(D) (A)-(III), (B)-(IV), (C)-(1), (D)-(II)
The software ________________ of a program or a computing system is the
structure or structures of the system, which comprise software components, the
externally visible properties of those components, and the relationships among
them.

(A) Design

(B) Architecture

(C) Process

(D) Requirement
The software ________________ of a program or a computing system is the
structure or structures of the system, which comprise software components, the
externally visible properties of those components, and the relationships among
them.

(A) Design

(B) Architecture

(C) Process

(D) Requirement
 Software Testing
Software testing is the process of evaluating a software application or
system to identify bugs, errors, or gaps and ensure it meets the specified
requirements. It helps verify that the software works as intended and
improves quality.
• Validation: ensures that the whole software meets customer requirements.
Are we building the right product?
• Verification: ensures that part of software correctly implements a specific
function. Are we building the product right?
• Testing: Demonstrating the existence of defects or providing confidence
that they do not appear to be present.
• Debugging: discovering the cause of a defect and fixing errors.
Unit Testing
Unit Testing is the process of testing individual components or units of a
software application in isolation to ensure that each unit functions
correctly.
A “unit” typically means the smallest testable part of the application,
such as a function, method, or class.
Purpose:
• Verify that each unit of the software performs as expected.
• Catch bugs early in the development process.
• Simplify debugging by isolating the part of the code causing issues.
• Provide a foundation for later testing stages like integration testing.
Integration Testing

Integration Testing is the phase in software testing where

individual modules or components are combined and tested
as a group to identify issues in the interactions between
them.
It ensures that different modules work together correctly.
• Verify data communication between modules.
• Detect interface defects.
• Ensure combined modules meet requirements.
Integration Approach
Description Key Components Used Pros Cons
Testing Type Direction

Big Bang Combine all modules and Hard to debug, defects

All at once None Simple to implement
Integration test simultaneously hard to isolate

Top-Down Start testing from top Stubs (simulate lower Early testing of high- Needs stubs, lower
Top → Bottom
Integration module downwards modules) level modules modules tested late

Bottom-Up Start testing from lower Drivers (simulate higher No need for stubs, lower High-level modules tested
Bottom → Top
Integration modules upwards modules) modules tested early late, drivers needed

Combine top-down and Faster testing, parallel Complex to plan and

Sandwich (Hybrid) Both directions Stubs and Drivers
bottom-up simultaneously approach manage
 System Testing
System Testing is the testing of a complete and fully integrated software
product. The purpose is to evaluate the system’s compliance with the
specified requirements.
• It is a black-box testing technique, focused on validating the software
as a whole.
• Verify that the software works correctly in its entirety.
• Validate functional and non-functional requirements.
• Detect discrepancies between actual and expected behavior.
 When Who Performs
Testing Type Description Purpose Example
Performed It

Tests individual
Ensure each After Testing login,
Functional features/functions
function works development of QA/Testers search, or checkout
Testing based on
as intended specific features functionality
requirements

Tests existing Ensure new code After bug fixes, Re-testing user
Regression
functionalities after doesn't break enhancements, QA/Testers registration after
Testing
code changes existing features or updates code update

Confirm the
A basic set of tests to Before detailed
Smoke application is Developers / Launch app, verify
check the stability of testing (after
Testing stable enough Testers login screen loads
a build new build)
for deeper tests

Validates the entire Verify system

After system End-users / Client checks
Acceptance system against readiness for
testing is Clients / QA invoice generation
Testing business/user delivery or go-
complete Team before release
requirements live
Alpha and Beta Testing
• Alpha Testing is a type of software testing performed at the
developer’s site by the internal teams (developers, testers, and
sometimes select users) before the product is released to external
users or customers.
• Beta Testing is a type of software testing performed by real users in a
real environment after Alpha Testing but before the final release of
the product.
Aspect Alpha Testing Beta Testing

Testing done internally by developers or QA Testing done externally by real users after
Definition
before release alpha testing

Identify bugs before releasing the product to Get feedback from real users and find issues in
Purpose
actual users real-world usage
Real-world environment (users’ devices,
Environment Lab or in-house environment
systems)
Testers Internal team (developers, testers) External users, clients, or public volunteers

Stage Early testing phase Final testing phase before official release

Access Private – not available to public Public or limited public release

Usability, compatibility, real-world
Focus Functional issues, crash reports, internal bugs
performance
Duration Shorter, controlled timeline Longer, varies based on user feedback

General user experience, suggestions, and

Feedback Type Detailed bug reports, internal metrics
undiscovered bugs

Company’s QA team tests a new CRM system Users test a new app version before it’s
Example
internally released on Play Store
Black Box Testing
• Black Box Testing is a software testing method where the tester evaluates the
functionality of an application without knowing the internal code or logic. It
focuses solely on the inputs and outputs of the software system.

• The tester is unaware of internal workings (like code, logic, or structure).

• Focuses on what the system does, not how it does it.

• Tests are based on requirements and specifications.

• Often used for functional testing.

 Black Box Testing
Technique Description

Divides input data into partitions where all values should be treated the same by
Equivalence Partitioning the system. One test case is selected from each partition to reduce the total
number of test cases.

Focuses on testing at the boundaries between partitions, as errors are more likely
Boundary Value Analysis
to occur at the edges of input ranges.

Represents complex business logic by mapping different input combinations and

Decision Table Testing
their corresponding outputs in a table format.

Tests the behavior of the system for different input conditions that trigger changes
State Transition Testing in state. It ensures that transitions occur correctly and invalid transitions are
handled properly.
 White-box testing
White-box testing is a software testing method where the tester has complete
knowledge of the internal structure, code, and logic of the program. It is also known as
Clear-box testing, Glass-box testing, or Structural testing.

In this approach, the tester examines the code and creates test cases that check the flow
of logic, conditions, loops, and decision points in the software. This helps ensure that
all parts of the code work as expected.
• Logical errors
• Incorrect conditions
• Unreachable code
• Performance issues
 Statement Coverage

• Statement Coverage ensures that every line or statement in

the source code is executed at least once during testing.
Purpose:
• To check that all individual instructions have been tested to
identify any lines of code that were never executed.
• Helps find dead code (unreachable code).
• Ensures basic code completeness.
Statement Coverage

if a > b:

print("A is greater")

print("End of comparison")

• Test Case: If a = 5 and b = 3, both lines are executed → 100% Statement

Coverage.

• But if a = 2 and b = 3, the if condition is false → Line 2 is skipped → Partial

Statement Coverage.
Branch Coverage
Branch coverage (also called decision coverage) measures whether each possible
branch from a decision point (like if, else, or case statements) has been executed
at least once.

• It ensures that all possible outcomes of each decision are tested, not just that
every line is executed.

• Detects logical errors.

• More thorough than statement coverage.

• Ensures all decision logic is tested.

Branch Coverage
def compare(a, b):

if a > b:

print("A is greater")

else:

print("B is greater")

To achieve 100% Branch Coverage, you need:

• One test case where a > b (true branch)

• One test case where a <= b (false branch)

• Even if all statements are executed, missing one branch path means branch
coverage is incomplete.
Path Coverage
Path Coverage ensures that all possible execution paths through the code are
executed at least once.

• Purpose:
To test every unique sequence of decisions and statements from start to
finish.

• Most comprehensive of the three.

• Uncovers issues in complex logical flows, especially when conditions are

nested or combined.
Path Coverage
if a > 0:

if b > 0:

print("Both positive")

else:

print("Only A positive")

else:

print("A is not positive")

To achieve 100% Path Coverage, you need to test all paths:

• a > 0 and b > 0

• a > 0 and b <= 0

• a <= 0

• Each combination forms a unique execution path. The more decision points, the more paths exist — so
path coverage can grow exponentially.
White-box testing

Technique Goal Thoroughness Focus

Individual
Statement Coverage Execute all code lines Basic
statements

Test all decision

Branch Coverage outcomes Medium Logic/conditions
(true/false)

Cover all unique Combined control

Path Coverage High
execution paths flow
Which of the following is a technique used for component
wrapping?
1. Black-box wrapping
2. Clear-box wrapping
3. Gray-box wrapping
4. White-box wrapping
Which of the following is a technique used for component
wrapping?
1. Black-box wrapping
2. Clear-box wrapping
3. Gray-box wrapping
4. White-box wrapping
To execute all loops at their boundaries and within their
operational bounds is an example of
(A)Black Box Testing
(B) Alpha Testing
(C)White Box Testing
(D)Recovery Testing
To execute all loops at their boundaries and within their
operational bounds is an example of
(A)Black Box Testing
(B) Alpha Testing
(C)White Box Testing
(D)Recovery Testing
Black Box Software testing method focuses on the
A. Boundary condition of the software
B. Control structure of the software
C. Functional requirement of the software
D. Independent paths of the software
Black Box Software testing method focuses on the
A. Boundary condition of the software
B. Control structure of the software
C. Functional requirement of the software
D. Independent paths of the software
Statement I: Software testing must be recognized as a significant effort, and its
planning must begin at the earliest possible time.
Statement II: The cost of software testing is an important contribution in
determining overall software development cost.
In the light of the above statements, choose the correct answer from the options given
below:
1. Both Statement I and Statement II are true
2. Both Statement I and Statement II are false
3. Statement I is true but Statement II is false
4. Statement I is false but Statement II is true
Statement I: Software testing must be recognized as a significant
effort, and its planning must begin at the earliest possible time.
Statement II: The cost of software testing is an important
contribution in determining overall software development cost.
In the light of the above statements, choose the correct answer from
the options given below:
1. Both Statement I and Statement II are true
2. Both Statement I and Statement II are false
3. Statement I is true but Statement II is false
4. Statement I is false but Statement II is true
Which of the following testing methods uses fault
simulation techniques?
(A) unit testing
(B) beta testing
(C) stress testing
(D) Mutation testing
Which of the following testing methods uses fault simulation
techniques?
(A) unit testing
(B) beta testing
(C) stress testing
(D) Mutation testing
• Mutation testing is a software testing technique where small changes (called
mutations) are made to a program's code to check if the existing test cases can
detect the errors.
Software maintenance

• Software maintenance is the process of modifying and

updating software after its initial delivery to correct faults,
improve performance, adapt to changing environments, or
enhance its features and usability.
• This phase is crucial in the software development lifecycle
to ensure the software remains reliable, secure, and meets
evolving user and business needs
Corrective maintenance
Corrective maintenance in software refers to the process of identifying,
diagnosing, and fixing faults or errors in a software application after they have
been discovered.

The primary goal is to restore the software to its proper working condition so it
can perform its intended functions without disruption.

• It is reactive, meaning it is performed in response to problems such as bugs,

crashes, security vulnerabilities, or performance issues that occur during
software operation.

• The process typically involves detecting the issue, analyzing and diagnosing the
root cause, implementing a fix (such as a patch or code update), testing the
solution, and documenting the changes for future reference
Corrective maintenance
• Corrective maintenance can be either planned (scheduled
based on known issues or historical data) or unplanned
(responding immediately to unexpected failures)
• Examples include releasing a patch for a security
vulnerability, fixing a bug that causes a system crash, or
resolving performance slowdowns reported by users.
• Corrective maintenance is essential for maintaining software
reliability and minimizing downtime by quickly addressing
problems as they arise.
Adaptive maintenance
Adaptive maintenance is the process of modifying software after its initial release to ensure it
remains functional and relevant in a changing technical or business environment.

This type of maintenance addresses changes in the software's external environment—such as

updates to operating systems, hardware, business rules, regulatory requirements, or third-
party services—that could otherwise render the software obsolete or nonfunctional.
• Updating software to remain compatible with a new version of an operating system.

• Modifying a web application to work with updated browsers.

• Adjusting software to comply with new laws or regulations, such as data privacy standards.

• Updating integrations when third-party APIs or cloud services change.

• Adaptive maintenance is proactive and essential for keeping software usable and secure as
its environment evolves
 Perfective maintenance
Perfective maintenance is a type of software maintenance focused on improving and
enhancing a software product based on user feedback, evolving business needs, or
technological advancements.

Unlike corrective maintenance, which fixes errors, perfective maintenance aims to

refine functionality, boost performance, and make the system more user-friendly
without necessarily addressing faults.

• Adding new features or enhancing existing ones to meet changing user requirements.

• Improving software performance or efficiency.

• Refactoring code for better readability and maintainability.

• Updating user interfaces for improved usability.

• Optimizing databases or algorithms for faster operation.

 Preventive maintenance
Preventive maintenance in software is a proactive approach that involves making
systematic changes and improvements to software to prevent potential future
problems, reduce the risk of failures, and extend the software’s useful life.

• The primary goal is to identify and address possible issues before they become
significant, costly problems that could impact performance or functionality.

• Typical preventive maintenance tasks include:

• Refactoring or optimizing code to make it more efficient and easier to maintain.

• Updating documentation to reflect the current state of the system.

• Cleaning up redundant or obsolete code.

• Improving software processes to prevent future errors or vulnerabilities.

Configuration management
• Configuration management in software engineering is the
discipline of systematically tracking, controlling, and
managing changes to software products throughout their
lifecycle to ensure consistency, integrity, and traceability.
• It encompasses practices and tools that help teams
coordinate development, avoid conflicts, and maintain a
stable and reliable software system.
Software configuration management (SCM):
Configuration identification: Defining and identifying all items (such as source code,
documentation, and test cases) that need to be managed as part of the software
project.

• Version control: Tracking and managing changes to configuration items, enabling

teams to revert to previous versions if necessary and supporting parallel
development.

• Configuration control: Implementing processes to approve or reject changes, often

through a change control board, to ensure only authorized modifications are made.

• Configuration status accounting: Recording and reporting the status and history
of configuration items and changes throughout the project.

• Configuration auditing: Verifying that configuration items are complete, correct,

and compliant with requirements and standards
 Software configuration management
Benefits of configuration management include:

• Improved collaboration and coordination among team members.

• Reduced risk of errors, conflicts, and code overwrites

• Enhanced traceability, accountability, and compliance with standards or regulations.

• Easier rollback and recovery in case of issues.

• SCM is essential in modern software development, especially in environments with

frequent changes, multiple contributors, and complex systems.

• Tools like Git, SVN, and automated configuration management systems help implement
these practices efficiently.
Software Reengineering
Software Reengineering is the process of analyzing and modifying existing
software to improve its functionality, structure, performance, or maintainability
without changing its core purpose.

• It involves revisiting old or outdated software and improving it to meet

current technology standards or user needs.

• Goals of Software Reengineering:

• Improve software quality and efficiency.

• Enhance maintainability and readability.

• Reduce costs of maintenance and future development.

• Adapt the software to new platforms or technologies.

Software Reverse Engineering
Software Reverse Engineering is the process of analyzing an existing software
system to understand its design, architecture, components, and functionality
without access to its original source code, documentation, or design.

• The goal is to gain knowledge about the system in order to:

• Recover lost documentation

• Understand how it works

• Detect security flaws

• Reuse components

• Support reengineering or migration

Key Points
• Reengineering = Improve and transform
existing systems you own.
• Reverse Engineering = Understand and
analyze existing systems, often without
source code.
Aspect Software Reengineering Software Reverse Engineering

Modifying and improving existing software to enhance Analyzing existing software to understand its design
Definition
performance, maintainability, etc. and functionality.

To upgrade, restructure, or modernize old software To extract knowledge, recover documentation, or

Purpose
systems. understand unknown systems.

Typically begins with source code and existing Starts with executable files or binaries (no access to
Starting Point
documentation. source code).

Involves forward engineering after understanding and Focuses on reverse analysis to extract design, logic,
Process Focus
improving the design. and documentation.

Code restructuring, data restructuring, forward Disassembling, decompiling, static/dynamic analysis,

Key Activities
engineering, documentation update. abstraction.

Refactoring tools, modernization frameworks, IDEs, UML Disassemblers (IDA Pro), decompilers (JD-GUI),
Tools Used
tools. debuggers (x64dbg), Ghidra.
Enhanced version of the software (cleaner, modernized, Recovered design documents, flowcharts, or even
Output
documented). source-like code.
Legal Fully legal (as it’s done on owned or maintained May have legal restrictions, especially when done on
Implications software). third-party software.

Use Case Migrating an old COBOL land registry system to Java on Analyzing a third-party system to understand file
Example cloud. format or fix undocumented bugs.

Complexity Medium to high (based on size and architecture). High (due to lack of source code and documentation).
Software products need perfective maintenance for which
of the following reasons?
A) To rectify bugs observed while the system is in use.
B) When the customers need the product to run on new
platforms
C) To support the new features that users want it to support
D) To overcome wear and tear caused by the repeated use of
the software
Software products need perfective maintenance for which
of the following reasons?
A) To rectify bugs observed while the system is in use.
B) When the customers need the product to run on new
platforms
C) To support the new features that users want it to
support
D) To overcome wear and tear caused by the repeated use of
the software
Modifying the software by restructuring is called
A. Corrective maintenance
B. Preventive maintenance
C. Adaptive maintenance
D. Perfective maintenance
Modifying the software by restructuring is called
A. Corrective maintenance
B. Preventive maintenance
C. Adaptive maintenance
D. Perfective maintenance
Software products need adaptive maintenance for which
of the following reasons?
1. To rectify bugs observed while the system is in use
2. When the customers need the product to run on new
platforms
3. To support the new features that users want it to support
4. To overcome wear and tear caused by the repeated use of
the software
Software products need adaptive maintenance for which
of the following reasons?
1. To rectify bugs observed while the system is in use
2. When the customers need the product to run on new
platforms
3. To support the new features that users want it to support
4. To overcome wear and tear caused by the repeated use of
the software
Which of the following statements is/are true?

P: Software Reengineering is preferable for software products having high failure

rates, having poor design and/or having poor code structure

Q: Software Reverse Engineering is the process of analyzing software with the

objective of recovering its design and requirement specification.

A) P only

B) Neither P nor Q

C) Q only

D) Both P and Q
Which of the following statements is/are true?

P: Software Reengineering is preferable for software products having high failure

rates, having poor design and/or having poor code structure

Q: Software Reverse Engineering is the process of analyzing software with the

objective of recovering its design and requirement specification.

A) P only

B) Neither P nor Q

C) Q only

D) Both P and Q
Software Quality Assurance (SQA)
Software Quality Assurance is a systematic process of monitoring
and improving the quality of software during the development
lifecycle to ensure it meets defined standards, user requirements, and
is reliable and defect-free.
• Ensure high-quality software is delivered to users.
• Prevent defects instead of just detecting them.
• Ensure compliance with standards like ISO, CMMI, IEEE.
• Promote continuous improvement in the development process.
 Software Quality Assurance
Component Description

Quality Planning Defining quality goals, metrics, standards, and strategies.

Ensuring processes are followed during development

Process Monitoring
(e.g., coding standards).
Conducting formal reviews, walkthroughs, and
Audits and Reviews
inspections of processes/products.
Verifying and validating the software through unit,
Testing
integration, system testing.

Defect Management Logging, tracking, analyzing, and resolving defects.

Measuring software attributes (e.g., defect density, test

Metrics Collection
coverage).

Configuration Management Ensuring changes are controlled and traceable.

Software Quality Assurance
Benefits of SQA:
• Improves customer satisfaction.
• Reduces maintenance cost by catching errors early.
• Ensures software is safe, reliable, and efficient.
• Builds a culture of quality awareness in the team.
CYCLOMATIC COMPLEXITY

• CYCLOMATIC COMPLEXITY is a software metric used to measure the

complexity of a program. It is a quantitative measure of independent paths in the
source code of the program.

• Independent path is defined as a path that has at least one edge which has not been
traversed before in any other paths.

• Cyclomatic complexity can be calculated with respect to functions, modules,

methods or classes within a program.

• 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.
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 –

• V(G) = E - N + 2
Where,
E = Number of edges
N = Number of Nodes

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

• V(G) = Total No. of Region

The Cyclomatic complexity metric provides the designer
with information regarding the number of _____________
1. Cycles in the program
2. Errors in the program
3. Independent logic paths in the program.
4. Statements in the program.
The Cyclomatic complexity metric provides the designer
with information regarding the number of _____________
1. Cycles in the program
2. Errors in the program
3. Independent logic paths in the program.
4. Statements in the program.
How many Node
are there ?
A. 9
B. 10
C. 11
D. 12
 1.Concept
2.Key Notes
3.Revision
4.Mock test
5.Repeat
Thank
You