SOFTWARE ENGINEERING

PAST PAPERS
SPRING 2023 (A)

S.
IT
SHORT ANSWERS
Question no 1:

ED
Define "software process model” by taking relevant example?
Answer:
A "software process model" is a structured approach used to organize and manage the activities
H
involved in software development. It defines the phases or stages of software development and
the relationships between them to ensure a systematic and efficient development process

Example: Waterfall Model

R

1. Requirement Analysis: Gather requirements.

/M

2. System Design: Create design specifications.

3. Implementation: Develop code.
4. Integration and Testing: Combine and test.
5. Deployment: Install the system.
6. Maintenance: Provide support and updates.
YT

Question no 2
Differentiate 'state' and "state transition" in the context of "state transition diagram"?
Answer:

In a state transition diagram:

● State: Represents a specific condition or situation of an object at a given time.

○ Example: "Idle" or "Processing".
 ● State Transition: Represents the movement or change from one state to another based
on an event.
○ Example: Transition from "Idle" to "Processing" when a user starts a task.

Question no 3:
Differentiate 'project' and "Non Project" by taking relevant examples?
Answer:

S.
Project vs. Non-Project:

● Project: A temporary endeavor undertaken to create a unique product, service, or result

IT
with a defined beginning and end.
○ Example: Developing a new mobile app with specific features and a set timeline.
● Non-Project: Ongoing operations or tasks that are continuous and repetitive without a

ED
defined end date.
○ Example: Regular maintenance of existing software systems or daily customer
support services.

Question no 4:
H
Name five diagrams of UML and explain one of them with details?
Answer

Five UML Diagrams:

R

1. Use Case Diagram

/M

2. Class Diagram
3. Sequence Diagram
4. Activity Diagram
5. State Diagram

Detailed Explanation:
YT

Class Diagram:

● Purpose: Shows the static structure of a system, including classes, attributes, methods,
and relationships between classes.
● Components:
○ Classes: Represented as rectangles divided into three sections: class name,
attributes, and methods.
○ Attributes: Characteristics or properties of a class (e.g., name: String).
 ○ Methods: Functions or operations that a class can perform (e.g.,
calculateTotal() : float).
○ Relationships:
■ Associations: Lines connecting classes to show relationships (e.g.,
Customer associated with Order).
■ Inheritance: Arrows showing a subclass relationship (e.g., Employee
inherits from Person).
■ Aggregation/Composition: Represent part-whole relationships (e.g.,
Library contains Book).

S.
Example: For an online bookstore system, a class diagram might include classes like Book,
Author, and Customer, with relationships showing that Author writes Book and Customer

IT
purchases Book.

ED
Question no 5:
Differentiate "software testing" and "software debugging" by taking relevant example
Answer:

Software Testing vs. Software Debugging:

H
● Software Testing: The process of evaluating a software application to ensure it meets
specified requirements and functions correctly. It aims to identify defects before
deployment.
○ Example: Testing an e-commerce website by checking if the "Add to Cart" button
R

works as expected and correctly updates the shopping cart.

● Software Debugging: The process of finding, analyzing, and fixing defects or bugs in the
/M

software after they have been identified during testing or use.

○ Example: If the "Add to Cart" button is not updating the cart correctly, debugging
would involve investigating the code, finding the error, and correcting it to resolve
the issue.
YT

LONG ANSWERS
Question no 1:
Explain "Spiral Model" by taking relevant example? What are the advantages and disadvantages
of "Prototyping Model"?
Answer:
 S.
IT
Spiral Model:
ED
Definition: The Spiral Model is a software development process that combines iterative
development with systematic aspects of the waterfall model. It emphasizes risk assessment
H
and iterative refinement.

Example: Developing a new software application using the Spiral Model involves the following
R

phases:

1. Planning: Define objectives, constraints, and alternatives.

/M

○ Example: Planning features and requirements for a new project management

tool.
2. Risk Analysis: Identify and evaluate risks associated with the project.
○ Example: Assessing potential risks such as technology limitations or integration
issues.
YT

3. Engineering: Develop and test the next increment of the software.

○ Example: Implementing and testing the basic functionality of the project
management tool.
4. Evaluation: Review progress, gather feedback, and plan the next iteration.
○ Example: Reviewing user feedback on the initial release and planning additional
features or improvements.

The process repeats in cycles (or spirals), with each iteration refining and expanding the
software.
Advantages and Disadvantages of the Prototyping Model:

Advantages:

1. User Feedback: Early and frequent user feedback improves the final product.
2. Requirements Clarification: Helps in refining requirements through iterative
development.
3. Flexibility: Allows changes and adjustments based on user feedback.

Disadvantages:

S.
1. Incomplete Solutions: Prototypes might not cover all aspects of the final system.
2. Potential for Scope Creep: Frequent changes can lead to scope creep and project

IT
delays.
3. Cost Overrun: Iterative changes can lead to increased costs and extended timelines.

ED
Question no 2:
How "Component Level Design" is made? Explain it with an example?
Answer:

Component Level Design

H
Definition: Component Level Design details the individual components or modules of a system,
including their internal structures, interfaces, and interactions.
R

Steps to Create Component Level Design:

/M

1. Identify Components:
○ Break the system into modules based on functionality.
○ Example: For a library management system, components might be "User
Management," "Catalog Management," "Loan Processing," and "Notification
System."
YT

2. Define Component Interfaces:

○ Specify how each component will interact with others, including methods and
data exchanges.
○ Example: "Loan Processing" might interact with "Catalog Management" to check
book availability.
3. Specify Internal Structure:
○ Detail the data structures, algorithms, and processes within each component.
○ Example: "User Management" will handle user data and authentication
processes.
4. Define Interactions:
 ○ Describe how components will communicate and exchange data.
○ Example: "Loan Processing" requests book status updates from "Catalog
Management."
5. Design Data Storage:
○ Specify how data will be stored and managed.
○ Example: "Catalog Management" uses a database for book information.
6. Consider Non-Functional Requirements:
○ Address performance, security, and scalability needs.
○ Example: Ensure the "Notification System" can handle high volumes of messages
efficiently.

S.
Example:

IT
Library Management System:

1. Components: "User Management," "Catalog Management," "Loan Processing,"

ED
"Notification System."
2. Interfaces: Methods like registerUser() for "User Management."
3. Internal Structure: "Catalog Management" uses data structures for book details.
4. Interactions: "Loan Processing" updates "Catalog Management" on book status.
5. Data Storage: "Catalog Management" stores data in a database.
H
6. Non-Functional Requirements: "Notification System" ensures real-time message
delivery.

This design ensures each component is well-defined, interacts correctly, and supports the
R

overall system’s needs.

/M

Question no 3:
Why "Design Patterns" are used? Explain its advantages in details?
Answer:

Design Patterns are reusable solutions to common software design problems. They provide a
YT

standard terminology and are proven solutions to recurring design challenges, helping to ensure
best practices in software development.

Reasons for Using Design Patterns:

1. Promote Reusability:
○ Design patterns offer tested and proven solutions that can be reused across
different projects.
 ○ Example: The Singleton pattern ensures a class has only one instance and
provides a global point of access to it, which can be reused in multiple parts of
an application.
2. Improve Code Maintainability:
○ Patterns help create code that is easier to understand, modify, and extend. They
offer a clear structure and design, making it easier for developers to work with
the codebase.
○ Example: The Observer pattern allows an object (subject) to notify a list of
dependent objects (observers) of state changes, facilitating easier updates and
maintenance.

S.
3. Enhance Communication:
○ Design patterns provide a common vocabulary for developers. This shared
language helps teams discuss and document design decisions more effectively.

IT
○ Example: Patterns like Factory Method or Adapter provide a shared
understanding of design approaches, making it easier to communicate design
choices and intentions.

ED
4. Support Best Practices:
○ They encapsulate best practices in software design, guiding developers towards
more robust and flexible architectures.
○ Example: The Strategy pattern enables a family of algorithms to be defined,
encapsulated, and made interchangeable, promoting a clean separation of
H
concerns and adherence to the open/closed principle.
5. Facilitate Design Flexibility:
○ Patterns encourage decoupling of components, making it easier to modify and
R

extend the system without affecting other parts of the codebase.

○ Example: The Decorator pattern allows behavior to be added to individual objects,
either statically or dynamically, without affecting the behavior of other objects
/M

from the same class.

6. Reduce Development Time:
○ By using well-established patterns, developers can avoid reinventing the wheel
and reduce the time needed to come up with solutions for common problems.
○ Example: Using the Template Method pattern, developers can define the skeleton
YT

of an algorithm, deferring some steps to subclasses, which speeds up the

development of algorithms with variable parts.

Detailed Advantages:

1. Code Reusability:
○ Design patterns encapsulate solutions to common problems, enabling
developers to reuse code and avoid duplication. This leads to more efficient
development and less redundancy.
2. Improved Maintainability:
 ○ Patterns provide a structured approach to code organization, making it easier to
understand, modify, and maintain. Well-designed patterns can simplify complex
codebases and make them more manageable.
3. Standardization:
○ Using design patterns standardizes solutions and design practices across
different projects and teams. This standardization can lead to higher quality and
consistency in software design.
4. Flexibility and Scalability:
○ Patterns promote loose coupling and high cohesion, which allows for flexible and
scalable designs. Changes to one part of the system can be made with minimal

S.
impact on other parts, facilitating easier updates and extensions.
5. Documentation and Communication:
○ Design patterns provide a common terminology and documentation that can

IT
improve communication among developers, making it easier to describe and
discuss design decisions and architecture.

ED
In summary, design patterns provide reusable, maintainable, and flexible solutions that enhance
the quality of software design and development, leading to more robust and efficient software
systems.

SPRING 2023 (B)

H
Q.1. Write short note on the following:
R

Question 1:
Define "software process model"? Shortly explain its three characteristics?
/M

Answer:

A software process model is a structured framework used to plan, execute, and manage
software development.

Three characteristics:
YT

1. Phases: Defines stages like planning, development, and testing.

2. Order: Specifies the sequence of activities.
3. Control: Provides guidelines for monitoring and improving the process.

Question 2:
Explain 'modality' and 'cardinality' with respect to "entity relationship diagram" by taking relevant
examples?
Answer:

In an Entity Relationship Diagram (ERD):

 1. Modality refers to the minimum number of times an entity must participate in a
relationship. It can be optional (0) or mandatory (1).
○ Example: In a "student-course" relationship, if a student must enroll in at least
one course, the modality is 1 (mandatory).
2. Cardinality defines the maximum number of relationships an entity can have.
○ Example: In a "teacher-class" relationship, if a teacher can teach many classes,
but each class is taught by one teacher, the cardinality would be 1
(one-to-many).

S.
Question 3:
What are the stages of team formation with respect to Project Manage? Short explanation?
Answer:

IT
The stages of team formation, based on Tuckman's model, are:

1. Forming: Team members meet, roles are unclear, and there’s dependence on the leader

ED
for guidance.
2. Storming: Conflicts arise as members start to express their ideas and personalities.
3. Norming: Team resolves conflicts, establishes norms, and begins working cohesively.
4. Performing: Team operates efficiently towards goals, with well-defined roles and strong
collaboration.
H
5. Adjourning: The project ends, and the team disbands, reflecting on successes and
areas for improvement.
R

Question 4:
Define "software configuration management"? Shortly explain its phases?
/M

Answer:

Software Configuration Management (SCM) is the process of tracking and controlling

changes in software to ensure integrity and traceability throughout the development lifecycle.

Phases:
YT

1. Configuration Identification: Defining and identifying software items to be controlled

(code, documents, etc.).
2. Configuration Control: Managing changes to software items via change requests and
approvals.
3. Configuration Status Accounting: Recording and reporting on the state of
configuration items.
4. Configuration Auditing: Verifying that the software conforms to the established
baselines and requirements.
Question 5:
Define and explain "design patterns"?
Answer:

Design patterns are reusable solutions to common problems in software design. They are
templates or best practices that developers can follow to solve recurring issues in a flexible and
efficient way.

Design patterns are categorized into three types:

S.
1. Creational Patterns: Deal with object creation, ensuring objects are created in a
manner suited to the situation (e.g., Singleton, Factory).
2. Structural Patterns: Focus on the composition of objects or classes to form larger
structures (e.g., Adapter, Composite).

IT
3. Behavioral Patterns: Concerned with communication and interaction between objects
(e.g., Observer, Strategy).

ED
They help improve code maintainability, scalability, and readability.

Q.2. Answer the following questions. (3x10=30)

Question 1:
Explain four characteristics of a 'software' in detail by taking examples?
Answer:
H
Four key characteristics of software are:
R

1. Intangibility:

Software is intangible, meaning it does not have a physical presence like hardware. It exists in
/M

the form of code and instructions that are executed on hardware. This characteristic makes
software inherently different from physical systems like machines or devices.

● Example: Consider Microsoft Office. While you can purchase and install it, you can’t
physically hold it. The software consists of programs like Word and Excel, which are
used to perform tasks, but the software itself is just data and algorithms, existing only in
YT

digital form. If it malfunctions, you cannot fix it by physical means; you must modify the
code.

Impact: This intangibility also makes software easy to distribute (e.g., through downloads or
cloud platforms), but it also creates challenges like piracy and the difficulty of assessing quality
through physical inspection.

2. Complexity:
Software is highly complex due to the number of components, interactions, and the variety of
functions it must perform. This complexity arises from its functionality, user requirements, and
the intricacies of interacting with hardware and networks.

● Example: Think of an operating system like Windows or macOS. It manages hardware

resources, facilitates communication between software and hardware, and supports
multiple applications running simultaneously. It must handle thousands of processes at
once, manage security, provide a user interface, and remain stable and efficient. The
codebase for such systems can consist of millions of lines of code, with countless
interdependencies.

S.
Impact: This complexity makes software prone to bugs and defects. Ensuring all parts of a
complex system work together without failures requires meticulous design, testing, and
maintenance.

IT
3. Maintenance:

ED
Unlike hardware, software is not "manufactured" once and then used indefinitely. It requires
ongoing maintenance for several reasons:

● Fixing bugs that were not detected during development.

● Updating software to adapt to new hardware, operating systems, or user requirements.
● Improving performance or adding new features.
H
● Example: A banking software application, for instance, requires regular updates due to
evolving security standards, changes in regulations, and improvements in the services
offered (e.g., adding support for mobile payments). Banks must ensure the software is
R

updated continuously to maintain security and functionality.

Impact: Maintenance can consume a significant portion of the total cost of software, often
/M

exceeding the original development costs. As new updates and patches are rolled out, older
parts of the system may need to be restructured, leading to "software aging," where it becomes
increasingly difficult to maintain over time.

4. Conformity:
YT

Software must conform to the changing needs and requirements of its users and the
environment it operates in. However, software doesn’t naturally adapt itself; it must be changed
(through updates or new versions) to conform to new rules, business practices, legal
requirements, or user needs. Software is also expected to work within the constraints of
hardware, operating systems, and networks.

● Example: Tax software must conform to new tax laws every year. The moment a
government changes its tax structure or rates, software vendors must release an update
to reflect these changes. Similarly, compliance with privacy laws like GDPR has forced
many software systems to update how they handle user data.
Impact: As software systems are required to continuously conform to new regulations, hardware
changes, and user expectations, development teams must keep updating them, making
adaptability an ongoing concern in software engineering.

Question 2:
Explain the use case relationships in detail by taking examples?
Answer:

In Use Case Diagrams, relationships between use cases define how they interact or depend on

S.
each other. These relationships help clarify the flow of functionality within a system and how
different use cases collaborate to achieve system goals. The main types of use case
relationships are "include", "extend", and generalization. Let’s explore these in detail with

IT
examples:

1. Include Relationship:

ED
The include relationship represents mandatory behavior that is shared among multiple use
cases. It occurs when one use case always uses another use case as part of its process. The
primary use case depends on the included use case to function properly.

● Example: Consider an Online Shopping System. The use case "Place Order" may
H
include the use case "Make Payment", because every time an order is placed, payment
needs to be processed. Similarly, it might also include the use case "Validate Customer
Information" to ensure the customer’s details are correct before proceeding with the
order.
R

In this scenario:
○ "Place Order" (primary use case) includes "Make Payment" and "Validate
/M

Customer Information" because these actions must happen as part of the order
process.
● Diagram Notation: In UML, the included use case is connected to the primary use case
with a dashed arrow labeled «include».
Key Characteristics:
○ The included use case is mandatory; it always happens when the primary use
YT

case is triggered.
○ Reusability: Common functionality (like "Make Payment") can be reused by
multiple use cases (e.g., "Place Order" or "Renew Subscription").

2. Extend Relationship:

The extend relationship indicates optional or conditional behavior that occurs under specific
circumstances. The extended use case adds functionality to the base use case but is not
essential for its completion. It can be thought of as a way to "extend" the behavior of a use case
when certain conditions are met.
 ● Example: In an ATM System, the use case "Withdraw Cash" might have an extension
called "Print Receipt". The base use case (withdrawing cash) is fully functional on its
own, but the customer might optionally choose to print a receipt after the withdrawal.
In this scenario:
○ "Withdraw Cash" (base use case) can be extended by "Print Receipt" if the
user selects this option.
○ Another extension might be "Notify Bank of Withdrawal", which only happens
when a specific condition is met (e.g., withdrawals above a certain amount trigger
a notification).
● Diagram Notation: The extended use case is connected to the base use case with a

S.
dashed arrow labeled «extend».
Key Characteristics:
○ The extended use case is optional and may only occur under certain conditions.

IT
○ It allows for additional behavior without modifying the base use case, keeping the
design flexible.
○ Extend is used to handle scenarios like error handling, optional services, or

ED
additional processes that aren’t always necessary.

3. Generalization Relationship:

The generalization relationship represents a parent-child or inheritance relationship between

use cases, similar to the concept of inheritance in object-oriented programming. A general
H
(parent) use case is specialized by one or more specific (child) use cases, which inherit its
behavior but can also add new actions or modify existing ones.

● Example: In an Online Banking System, a general use case "Manage Account" might
R

be specialized into more specific use cases like "Manage Savings Account" and
"Manage Checking Account". Both child use cases inherit common behaviors from the
/M

"Manage Account" use case but can also have their own unique behaviors.
In this scenario:
○ "Manage Account" (general use case) contains behaviors like checking account
balance or updating account information.
○ "Manage Savings Account" and "Manage Checking Account" can perform
additional actions specific to their account types (e.g., handling interest for
YT

savings or processing checks for checking accounts).

● Diagram Notation: The child use case is connected to the parent use case with a solid
line and a triangle pointing to the parent (indicating inheritance).
Key Characteristics:
○ The child use case inherits the behavior of the parent use case and may also
override or extend it.
○ This relationship supports specialization and modularity, allowing for cleaner,
more manageable diagrams by avoiding duplication of common behaviors.

Examples of Relationships in a System:

Let’s imagine a Library Management System to illustrate all these relationships:

● Base Use Case: Borrow Book

○ Include: The use case "Check Member Eligibility" is always included in
"Borrow Book" because before any book is borrowed, the system must verify if
the member is allowed to borrow (e.g., no outstanding fines or overdue books).
● Extended Use Case: Extend Borrowing Period
○ Extend: The use case "Notify Member of Borrowing Deadline" extends
"Borrow Book" in certain conditions, such as when the book is almost due, and
the system automatically notifies the member. This is optional and conditional

S.
based on the due date.
● Generalization: Manage User Accounts
○ Generalization: A general use case "Manage User Accounts" could have

IT
specialized use cases like "Manage Student Accounts" and "Manage Faculty
Accounts". Both specialized use cases inherit the general behavior of managing
user accounts (e.g., updating contact details) but also add their own actions,

ED
such as managing student loans for "Manage Student Accounts" and managing
research grants for "Manage Faculty Accounts".

Summary:

● Include: Defines a mandatory relationship where a base use case must always
H
incorporate the behavior of another use case.
● Extend: Defines an optional relationship where additional functionality is triggered under
certain conditions.
● Generalization: Defines an inheritance relationship where one use case is generalized
R

by others that share similar characteristics but specialize in different behaviors.

/M

These relationships allow for the modularity, reusability, and flexibility of use cases in large,
complex systems. By properly organizing the relationships, developers can maintain clarity in
system behavior and ensure that common or conditional actions are represented efficiently.

Question 3:
YT

Explain the relationship of "Software testing" with "Software Quality Assurance" by taking
Examples?
Answer:

Software Testing and Software Quality Assurance (QA) are two critical components in
ensuring the quality of software products, but they serve different purposes and focus on
different aspects of quality. Here’s a detailed exploration of their relationship, with examples to
illustrate the connection:

1. Definitions
 ● Software Testing: This is the process of evaluating software to identify any gaps, errors,
or missing requirements in comparison to the actual requirements. It involves executing
software to ensure it behaves as expected. Testing can be manual or automated and
includes various types like unit testing, integration testing, system testing, and
acceptance testing.
● Software Quality Assurance (QA): QA encompasses the entire process of software
development, focusing on preventing defects through systematic processes,
methodologies, and standards. QA is more about the overall process and includes
activities that help ensure quality at all stages of the software development life cycle
(SDLC). QA aims to enhance the development process and ensure that quality

S.
standards are met.

2. Relationship Between Software Testing and Software Quality Assurance

IT
While software testing and software quality assurance are distinct activities, they are
interconnected and mutually supportive in achieving high-quality software. Here's how they

ED
relate:

A. Focus and Objectives

● QA Focuses on Process: QA is concerned with establishing processes that facilitate

the development of quality software. This includes defining standards, methodologies,
H
and best practices. For example, implementing coding standards (like adhering to a style
guide) and conducting regular code reviews as part of the QA process helps prevent
defects early on.
● Testing Focuses on Product: Testing focuses on the product itself to identify defects or
R

issues before release. For example, a team might conduct user acceptance testing
(UAT) to ensure the software meets the requirements and works as intended from the
/M

end-user perspective.

B. Feedback Loop

● QA Informs Testing: The insights gained from QA activities can enhance testing
strategies. For example, if a QA review identifies common issues in previous projects,
YT

the testing team can create specific test cases targeting those areas to prevent
recurrence in future releases.
● Testing Provides Input to QA: Testing outcomes provide essential feedback to the QA
process. If tests consistently fail in certain areas, this might indicate a need to improve
development processes or refine QA standards. For example, if multiple test cases fail
due to lack of error handling, QA might revise the coding standards to include specific
guidelines for error handling in the code.

C. Process Improvement
 ● Continuous Improvement: QA emphasizes continuous improvement of processes to
enhance software quality. For instance, using metrics from previous testing cycles, the
QA team may decide to implement more robust testing frameworks or tools that lead to
better test coverage.
● Testing Metrics Influence QA Strategies: Metrics gathered during testing (such as
defect density, test case execution rate, etc.) can inform QA strategies. If metrics
indicate that defects are predominantly found in a specific module, QA can focus on
improving the development practices for that module.

3. Examples

S.
To better illustrate the relationship between software testing and software quality assurance,
let’s consider a hypothetical scenario in an e-commerce application development.

IT
Example 1: Establishing Coding Standards

● QA Activity: The QA team defines a coding standard that all developers must follow.

ED
This includes guidelines on naming conventions, commenting code, and structure. They
also establish a code review process where team members must review each other’s
code before it’s merged into the main branch.
● Testing Impact: When it comes time to test the application, the testers find it easier to
understand the code and write test cases because of the consistent coding standards.
H
For example, if the naming conventions are clear, it’s easier for testers to identify what
each function does, leading to more effective test case creation.

Example 2: Automated Testing Implementation

R

● QA Activity: After a review of previous projects, the QA team identifies that manual
testing is time-consuming and error-prone. They recommend implementing automated
/M

testing frameworks to improve efficiency and consistency.

● Testing Execution: The testing team adopts automated testing for regression tests.
After the development of a new feature, automated tests are run to ensure that the
existing functionalities still work. The results help identify defects quickly, allowing for
rapid fixes.
YT

4. Conclusion

In summary, software testing and software quality assurance are integral parts of a successful
software development process. While testing is focused on evaluating the software product, QA
encompasses the entire process to prevent defects and improve quality. Their relationship is
symbiotic: QA establishes the framework and standards for development and testing, while
testing provides essential feedback and data that inform and refine QA practices. By working
together, they ensure that software meets user expectations and quality standards, ultimately
leading to a more reliable and successful software product.
YT
/M
R
H
ED
IT
S.