Regulation: R2023

Academic Year: 2024-2025

DEPARTMENT OF CSE (CYBER SECURITY)

SUB CODE: 23CY6401 YEAR/SEM: III /VI

SUBJECT : SOFTWARE ENGINEERING BATCH: 2023-2027
INTERNAL ASSESSMENT EXAMINATION-2
ANSWER KEY
PART A
1. Give a definition of software engineering. K1 (2)
Software engineering is defined as a process of analyzing user requirements and then designing,
building, and testing software application which will satisfy those requirements. Software
engineering is defined as the application of a systematic, disciplined, quantifiable approach to
the development, operation and maintenance of software; that is, the application of
engineering to software.
2. Mention how the software process model is represented schematically. K2 (2)

3. List out the possible problems caused by engineers and developers during requirements K1 (2)
analysis.
Incomplete Requirements
Ambiguous Requirements
Assumption-Driven Analysis
Overlooking Stakeholders
Lack of Domain Knowledge
Ignoring Non-Functional Requirements
4. Mention ambler suggested component –level design guidelines K2 (2)
Components: Naming conventions should be established for components that are specified as
part of the architectural model and then refined and elaborated as part of the component level
model.
Interfaces. Interfaces provide important information about communication and collaboration.
Cohesion: Cohesion measures the strength of the relationship between elements within a module
Coupling: Coupling is a qualitative measure of the degree to which classes are connected to one
another.
5. List the different kinds of patterns K1 (2)
Creational patterns,Abstract factory pattern,Factory method pattern,Structural
patterns,Behavioral patterns,Command pattern and Aggregate pattern
6. Define Product metrics in Software Engineering K1 (2)
product metrics are quantitative measures used to assess the characteristics of software
products. These metrics help in evaluating various aspects such as quality, performance,
maintainability, and complexity of the [Link] metrics are software product
 Regulation: R2023
Academic Year: 2024-2025

measures at any stage of their development, from requirements to established systems.

Product metrics are related to software features only.
7. Write down the steps for recovery plan in recovery testing K1 (2)
The recovery process may involve activities such as system restarts, data restoration from
backups, reconfiguration, failover to redundant systems, or any other necessary steps to
recover the system's functionality.
8. What is the difference between Selenium IDE and Selenium Web Driver K2 (2)
Selenium IDE Selenium Web Driver
Selenium IDE is a record and playback tool It provides a programming interface for
for creating test scripts. controlling web browsers programmatically.
It is a browser extension available for WebDriver supports multiple browsers such
Chrome and Firefox as Chrome, Firefox, Safari, Edge, and more.
9. Mention the way by which automation tools support continuous integration(CI) K2 (2)
Jenkins: Jenkins is an open-source automation server that supports continuous
integration and delivery. It allows for the automated build, testing, and deployment of
software. Jenkins integrates with various tools and can execute test scripts and generate
reports as part of the CI/CD pipeline.
Bamboo: Bamboo is a CI/CD tool by Atlassian that offers seamless integration with
other Atlassian products like Jira and Bitbucket. It provides capabilities for building,
testing, and deploying software applications.
10. With a neat sketch, draw the process of performance testing K2 (2)

PART B
11.1 Describe in detail different types of cohesion and coupling with examples. What is K2 (16)
software architecture.
In software engineering, cohesion and coupling are fundamental concepts used to (2)
evaluate the quality of a system’s design. Cohesion refers to how closely related the
responsibilities of a single module are, while coupling refers to the degree of
interdependence between different modules. A good software design aims for high
cohesion and low coupling, which improves maintainability, readability, and scalability.
Types of Cohesion:
1. Coincidental Cohesion (Lowest level)
This occurs when unrelated tasks are grouped in the same module without any
meaningful relationship. For example, a single function that handles file reading, user
authentication, and printing reports. These tasks are completely unrelated, making the
module hard to understand and maintain.
2. Logical Cohesion (6)
In this type, elements performs similar kinds of activities but are selected using control
flags. For example, a function that performs different operations like reading, writing, or
deleting a file based on a parameter. Although the tasks are related logically, combining
 Regulation: R2023
Academic Year: 2024-2025

them reduces clarity and increases complexity.

3. Temporal Cohesion
Modules with temporal cohesion perform tasks that are related by timing, such as
initialization or clean-up operations. For instance, a function that initializes variables,
opens files, and sets up network connections during program start-up. These tasks occur
at the same time but are not strongly related otherwise.
4. Procedural Cohesion
Here, elements are grouped because they follow a specific sequence of execution. For
example, a function that reads data, processes it, and then prints results. While the steps
are related in order, they may not be strongly related in purpose.
5. Communicational Cohesion
In this type, elements operate on the same data set. For example, a module that reads a
customer record, updates it, and then writes it back to the database. Since all operations
revolve around the same data, cohesion is stronger.
6. Sequential Cohesion
This occurs when the output of one part of a module becomes the input for another part.
For example, a function that reads data, processes it, and passes the result to another step
within the same module. This shows a clear data flow, making it more cohesive.
Types of Coupling :
Coupling measures how strongly one module depends on another. Lower coupling is (3)
preferred because it reduces the impact of changes.
1. Content Coupling (Highest/ Worst)
This occurs when one module directly accesses or modifies the internal data of another
module. For example, if one function modifies a local variable of another function. This
creates strong dependency and should be avoided.
2. Common Coupling
Modules share global data. For example, multiple functions accessing and modifying a
global variable. This can lead to unexpected side effects, as changes in one module affect
others.
3. External Coupling
Modules depend on externally imposed formats, protocols, or devices. For example, two
modules depending on the same file format or communication protocol. Changes in the
external system affect both modules.
Software architecture:
Software architecture alludes to “the overall structure of the software and the ways in (2)
which that structure provides conceptual integrity for a system” Architecture is the
structure or organization of program components (modules), the manner in which these
components interact, and the structure of data that are used by the components.
 Structural properties. This aspect of the architectural design representation defines
the components of a system (e.g., modules, objects, filters) and the manner in which
those components are packaged and interact with one another.
 Extra-functional properties. The architectural design description should address how
the design architecture achieves requirements for performance, capacity, reliability,
security, adaptability, and other system characteristics. (3)
 Families of related systems. The architectural design should draw upon repeatable
patterns that are commonly encountered in the design of families of similar systems. In
 Regulation: R2023
Academic Year: 2024-2025

essence, the design should have the ability to reuse architectural building blocks.
 The architectural design can be represented using one or more of a number of different
models. Structural models: Represent architecture as an organized collection of program
components. Framework models: Increase the level of design abstraction by attempting
to identify repeatable architectural design frameworks that are encountered in similar
types of applications.
 Dynamic models : Address the behavioral aspects of the program architecture,
indicating how the structure or system configuration may change as a function of
external events.
 Process models : Focus on the design of the business or technical process that the
system must accommodate.
 Functional models can be used to represent the functional hierarchy of a system
 A number of different architectural description languages (ADLs) have been
developed to represent these models.

11.2 ii) Explain in detail about the interface analysis and interface design process (16)
Four different models come into play when a user interface is to be analyzed and (2)
designed. A human engineer (or the software engineer) establishes a user model, the
software engineer creates a design model, the end user develops a mental image that
is often called the user’s mental model or the system perception, and the
implementers of the system create an implementation model.
Users can be categorized as:
Novices. No syntactic knowledge1 of the system and little semantic knowledge of (4)
the application or computer usage in general. Knowledgeable, intermittent users.
Reasonable semantic knowledge of the application but relatively low recall of
syntactic information necessary to use the interface. Knowledgeable, frequent users.
Good semantic and syntactic knowledge that often leads to the “power-user
syndrome”; that is, individuals who look for shortcuts and abbreviated modes of
interaction. The user’s mental model (system perception) is the image of the system
that end users carry in their heads. The implementation model combines the outward
manifestation of the computer based system (the look and feel of the interface),
coupled with all supporting information (books, manuals, videotapes, help files) that
describes interface syntax and semantics. When the implementation model and the
user’s mental model are coincident, users generally feel comfortable with the
software and use it effectively. These models enable the interface designer to satisfy (2)
a key element of the most important principle of user interface design: “Know the
user, know the tasks.”
Process The analysis and design process for user interfaces is iterative and can be
represented using a spiral model Referring to the following figure, the user interface
analysis and design process begins at the interior of the spiral and encompasses four
distinct framework activities (1) interface analysis and modeling, (2) interface
design, (3) interface construction, and (4) interface validation.

(2)
 Regulation: R2023
Academic Year: 2024-2025

(4)
The goal of interface design is to define a set of interface objects and actions that
enable a user to perform all defined tasks in a manner that meets every usability goal
defined for the system. Interface construction normally begins with the creation of a
prototype that enables usage scenarios to be evaluated.
Interface validation focuses on (1) the ability of the interface to implement every user
task correctly, to accommodate all task variations, and to achieve all general user
requirements; (2) the degree to which the interface is easy to use and easy to learn,
and (3) the users’ acceptance of the interface as a useful tool in their work.
12.1 Analyze the importance of recovery testing in ensuring system reliability. K4 (16)
Examine different failure scenarios (such as system crash, network failure and
hardware malfunction) and explain how recovery testing validates the system’s
ability to restore data and resume operations.
Many computer-based systems must recover from faults and resume processing with
little or no downtime. In some cases, a system must be fault tolerant; that is, processing
faults must not cause overall system function to cease.
Recovery testing is a system test that forces the software to fail in a variety of ways and (2)
verifies that recovery is properly performed. If recovery is automatic (performed by the
system itself), reinitialization, check pointing 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.
A system or software should be recovery tested for failures like :
 Power supply failure (2)
 The external server is unreachable
 Wireless network signal loss (2)
 Physical conditions
The recovery testing life cycle includes the various phase, which is as follows:

Standard Operations: This is the normal functioning state of the system or application,
where all processes and components are running smoothly without any disruptions or
failures.
Disaster and Failure Occurrence: This stage involves the occurrence of a disaster or
 Regulation: R2023
Academic Year: 2024-2025

failure event that interrupts the standard operations. This can include natural disasters, (10)
hardware failures, software glitches, cyber-attacks, or any other unforeseen events that
lead to the system or application becoming unavailable or dysfunctional.
Interruption to Standard Process: When a disaster or failure occurs, it disrupts the
standard process and prevents the system or application from functioning properly. This
interruption may result in downtime, data loss, performance degradation, or other
negative impacts on the system's availability and reliability.
Recovery Process: Once the interruption to the standard process is identified, the
recovery process is initiated. This stage involves executing the predefined recovery plan
and procedures to restore the system or application to its normal functioning state.
Rebuild Process: In some cases, the recovery process may not be sufficient to fully
restore the system or application. The rebuild process comes into play when the system
requires significant repairs or reconstruction to recover from the failure or disaster.

12.2 Analyse a failing mobile banking app and suggest which tpes of testing K3 (16)
(UI,Functionality,stress,recovery,security,performance and deployment) should be
[Link] your choices.
A failing mobile banking application must be analyzed with a strong focus on (1)
reliability, security, and correctness, because such systems handle sensitive financial
data and critical user transactions. Therefore, testing should be prioritized based on risk
impact, with the most critical areas addressed first to restore trust and system stability.

The highest priority should be given to functionality testing, as the core purpose of a
banking app is to correctly perform operations like user authentication, balance inquiry,
fund transfers, and bill payments. Any defect in these functions—such as incorrect
transaction processing, duplication, or failure to update balances—can lead to serious (2)
financial errors and loss of customer trust. Ensuring that all business logic and
workflows operate correctly is essential before considering other aspects.

Alongside functionality, security testing is equally critical because mobile banking

apps are prime targets for cyberattacks. The application must protect sensitive
information such as login credentials, account details, and transaction data. Security
testing should verify strong authentication mechanisms, data encryption, secure
communication (HTTPS), protection against common vulnerabilities like SQL injection
or session hijacking, and compliance with financial security standards. A security flaw (2)
can result in financial loss and legal consequences, making this a top priority.

The next level of priority is performance testing, which ensures that the application
responds quickly and remains stable under normal usage conditions. Banking apps often
experience high traffic during peak times, and slow response or app crashes can frustrate (2)
users and interrupt transactions. Performance testing helps identify bottlenecks in
response time, database queries, and server interactions, ensuring smooth operation.

Closely related is stress testing, which evaluates how the system behaves under extreme
conditions beyond normal load. This testing identifies the breaking point of the system (2)
and checks whether it fails gracefully without data corruption or crashes. While
 Regulation: R2023
Academic Year: 2024-2025

important, it is slightly secondary to performance testing, as the system must first be

stable under expected conditions before testing extreme scenarios.

Recovery testing is also crucial because failures such as network interruptions, server
crashes, or incomplete transactions are common in real-world usage. The system must be (2)
able to recover without data loss and ensure transaction consistency. For example, if a
fund transfer is interrupted, the system should either complete it once or roll it back
safely, avoiding duplication or inconsistency.

UI (User Interface) testing comes next, focusing on usability, navigation, and user
experience. While UI issues may not directly cause financial loss, a confusing or poorly (2)
designed interface can lead to user mistakes, such as incorrect transactions. Therefore,
UI testing ensures that the app is intuitive, accessible, and user-friendly, but it is less
critical than functional correctness and security.

Finally, deployment testing ensures that the application works correctly across different
devices, operating systems, and environments. It verifies installation, updates, (1)
compatibility, and configuration in real-world conditions. Although important, it is given
lower priority because the system must first be functionally correct, secure, and stable
before being widely deployed.

In conclusion, the testing priority for a failing mobile banking app should be:
functionality and security (highest priority), followed by performance and recovery
testing, then stress testing, and finally UI and deployment testing. This approach (2)
ensures that the application is accurate, secure, reliable, and capable of handling failures
before focusing on usability and environment compatibility, thereby restoring user
confidence and system integrity.

13.1 Explain in detail the principles and goals of security testing K2 (8)
Security Testing is a type of Software Testing that uncovers vulnerabilities of the system
and determines that the data and resources of the system are protected from possible (1)
intruders. Security testing of any system is focuses on finding all possible loopholes and
weaknesses of the system which might result into the loss of information or repute of the
organization.
The goal of security testing is to:
 To identify the threats in the system.
 To measure the potential vulnerabilities of the system. (2)
 To help in detecting every possible security risks in the system.
Principle of Security Testing:

1. Confidentiality: This principle ensures that sensitive information is protected

from unauthorized access or disclosure. (2)
2. Integrity: Integrity ensures that data remains accurate, complete, and unaltered
during storage, processing, and transmission.
 Regulation: R2023
Academic Year: 2024-2025

3. Authentication: Authentication verifies the identity of users or systems

attempting to access the software or its resources.
4. Authorization: Authorization determines what actions and resources users or
systems are permitted to access.

(1)

Types of
Security
Testing:
[Link] Scanning: (2)
Vulnerability scanning is performed with the help of automated software to scan a
system to detect the known vulnerability patterns.
2. Security Scanning:
Security scanning is the identification of network and system weaknesses. Later on it
provides solutions for reducing these defects or risks.
[Link] Testing:
Penetration testing is the simulation of the attack from a malicious hacker. It includes
analysis of a particular system to examine for potential vulnerabilities from a malicious
hacker that attempts to hack the system.
13.2 Write short note on performance testing K2 (8)
Performance Testing is a type of software testing that ensures software applications to (1)
perform properly under their expected workload. It is a testing technique carried out to
determine system performance in terms of sensitivity, reactivity and stability under a
particular workload.
Performance Testing Process:

(1)

The performance testing process involves several key steps to ensure effective testing
and optimization of software application performance.
(2)
1. Identify Test Environment: Determine the test environment that closely
resembles the production environment, including hardware, software, and
network configurations.
2. Determine Performance Criteria: Define performance goals and criteria based
on the application's requirements and user expectations.
Types of Performance Testing
 Regulation: R2023
Academic Year: 2024-2025

Following are the types of performance testing:

1. Load testing: The load testing is used to check the performance of an application by
applying some load which is either less than or equal to the desired load is known as load (4)
testing.
2. Stress Testing : The stress testing is testing, which checks the behavior of an
application by applying load greater than the desired load.
3. Scalability Testing: Checking the performance of an application by increasing or
decreasing the load in particular scales (no of a user) is known as scalability testing.
Upward scalability and downward scalability testing are called scalability testing.
4. Stability Testing: Checking the performance of an application by applying the load
for a particular duration of time is known as Stability Testing.