Software Engineering 2019

Section II (Short Answer)

Q.2. (i) Software doesn't "wear out". Discuss, briefly. Unlike hardware, which suffers from physical environmental factors like dust, heat, and friction (following a "bathtub curve" of failure rates), software is a logical entity and does not physically degrade over time. However, software deteriorates. As a system is continuously patched, updated, or adapted to new environments (such as migrating to a new version of Next.js or a different database schema), the internal structure can become complex and messy. This continuous change introduces new bugs, causing the software to deteriorate conceptually, even though it never physically "wears out."

Q.2. (ii) What are the Drawbacks of RAD Model? The Rapid Application Development (RAD) model focuses on fast prototyping and quick delivery, but it has several notable drawbacks:

• Requires Highly Skilled Developers: It depends on a strong team capable of rapidly translating requirements into working code.
• Demands Heavy User Commitment: The customer must be continuously available for feedback; otherwise, the rapid iterations will fail.
• Not Suitable for All Projects: It only works for systems that can be easily modularized. It is a poor choice for systems with high computational complexity or heavy, complex background logic.
• Poor Architecture Risk: Rushing to build prototypes can lead to messy, unoptimized underlying code if not carefully managed.

Q.2. (iii) What is Object-oriented decomposition? Object-oriented decomposition is the process of breaking down a large, complex software system into smaller, manageable, and highly cohesive parts called "objects" or "classes." Instead of breaking a system down by functions (what it does), it breaks it down by real-world entities (what it is). Each object encapsulates both its data (attributes) and its behaviors (methods). For example, a university system might be decomposed into Student, Course, and Instructor objects, each managing its own state and interacting via messages.

Q.2. (iv) What is integration testing? Which kind of projects will require this kind of testing? Integration testing is a phase in software testing where individual software modules are combined and tested as a group to expose faults in how they interact and share data.

• Projects Requiring It: Any project utilizing a modular or layered architecture heavily relies on integration testing. For instance, in modern web development using a MERN or Next.js stack, integration testing is crucial to ensure that the React frontend correctly sends data to the Node/FastAPI backend, and that the backend properly queries the MongoDB database.

Q.2. (v) What is feasibility study? What are the contents we should contain in the feasibility? A feasibility study is a preliminary assessment conducted before heavy development begins to determine if a software project is practical, justified, and likely to succeed. The key contents of a feasibility report include:

• Executive Summary: A high-level overview of the project.
• Technical Feasibility: Assessment of available technology and technical expertise (e.g., do we have the right AI models and frameworks?).
• Economic Feasibility: Cost-benefit analysis, budget estimations, and expected ROI.
• Operational Feasibility: Will the end-users actually adopt and use the system?
• Schedule/Time Feasibility: Can the project be completed within the required deadlines?
• Conclusion/Recommendations: Final verdict on whether to proceed, pivot, or abandon the project.

Q.2. (vi) Differentiate between SRS document and design document?

• SRS (Software Requirements Specification): This document focuses entirely on the "WHAT." It details what the software must do, outlining the functional and non-functional requirements, user expectations, and system behaviors from an external perspective. It is usually written in natural language for stakeholders to understand.
• Design Document: This document focuses entirely on the "HOW." It serves as a blueprint for developers, detailing the internal architecture, database schemas, structural UML models, and algorithms. It translates the requirements from the SRS into technical specifications for coding.

Section III (Essay Type)

Q.3: What are Agile methodologies? write a note at any two agile methodologies.

Agile Methodologies Defined Agile methodologies are iterative and incremental approaches to software development. Instead of delivering a project in one massive "Big Bang" at the end of a long timeline, Agile breaks the project into small, manageable iterations (often lasting 1–4 weeks). It emphasizes continuous collaboration, high adaptability to changing requirements, and delivering functional, working software to the customer frequently.

1. Scrum Scrum is one of the most popular Agile frameworks, designed for small, highly collaborative teams.

• Sprints: Work is divided into fixed-length iterations called Sprints (usually 2 weeks).

• Key Roles:

• Product Owner: Represents the client and manages the Product Backlog (the list of all desired features).

• Scrum Master: Facilitates the process and removes blockers for the team.

• Development Team: The self-organizing group writing the code.

• Ceremonies: It includes Daily Stand-up meetings (to discuss progress and blockers), Sprint Planning, and Sprint Retrospectives to ensure continuous improvement.

2. Kanban Kanban is a highly visual Agile methodology focused on continuous workflow and reducing bottlenecks.

• Visual Board: Work items are represented as cards on a Kanban board with columns like "To Do," "In Progress," "Testing," and "Done."
• WIP Limits: It strictly enforces Work-In-Progress (WIP) limits. A team might only be allowed to have three items in the "In Progress" column at once. This forces the team to finish current tasks before pulling new ones, ensuring a smooth, continuous flow of feature delivery without overloading developers.

Q.4: Define all phases of SDLC in software development and what is the importance of SDLC in real life software project? Elaborate your answer with the help of one example.

Phases of the SDLC (Software Development Life Cycle) The SDLC is a structured framework detailing the standard phases of software engineering.

1. Requirement Gathering: Analyzing what the users need and documenting it in an SRS.
2. Design: Creating architectural blueprints, database schemas, and UI/UX layouts based on the requirements.
3. Implementation (Coding): Translating the design into actual working code using selected languages and frameworks.
4. Testing: Verifying the code against requirements to find and fix bugs (unit, integration, and system testing).
5. Deployment: Releasing the finished software to the production environment for end-users.
6. Maintenance: Providing ongoing support, patching vulnerabilities, and adding new features as user needs evolve.

Importance of SDLC in Real-Life Projects Without an SDLC, software development becomes chaotic, leading to scope creep, massive budget overruns, and ultimately, project failure. The SDLC provides strict project tracking, ensures high quality through planned testing, defines clear roles, and aligns the final product directly with the customer's actual business needs.

Real-Life Example: Building an Educational Platform Consider the real-life development of an educational platform like Scholar Quill, an LMS meant to provide study notes and past papers.

• During Requirement Gathering, you determine students need organized course notes and past paper downloads.
• In Design, you map out a modern UI with dark themes and design a MongoDB schema to handle document metadata.
• During Coding, the development team builds the backend in Next.js and integrates AI models for content aggregation.
• In Testing, the team ensures file downloads don't crash under heavy student traffic.
• Finally, during Deployment, it goes live on a cloud server, moving into Maintenance where new semester past papers are continually added. The SDLC ensures this complex process happens systematically without the platform collapsing on launch day.

Q.5: Draw a context and detailed DFD of the following case.

(Note for Exam: Use the text descriptions below to draw the standard bubble/box DFD diagrams on your paper. Use a circle for processes, rectangles for external entities, and open-ended rectangles for data stores).

1. Context Level DFD (Level 0) The Context DFD shows the entire system as a single process interacting with its external environment.

• Central Process Node (Circle): 0. Textbook Inventory System
• External Entities (Rectangles) & Data Flows (Arrows):
• Academic Departments $\rightarrow$ [TEXTBOOK MASTER LIST] $\rightarrow$ (0. System)
• (0. System) $\rightarrow$ [PURCHASE ORDER (Form 17)] $\rightarrow$ Publishing Companies
• Publishing Companies $\rightarrow$ [PACKING SLIP & Books] $\rightarrow$ Receiving Department
• Receiving Department $\rightarrow$ [Verified Slip Data] $\rightarrow$ (0. System)
• Students $\rightarrow$ [BOOK REQUEST FORM & Payment] $\rightarrow$ (0. System)
• (0. System) $\rightarrow$ [CASH REGISTER SALES RECEIPT] $\rightarrow$ Students

2. Detailed DFD (Level 1) The Level 1 DFD breaks the central system down into its core sub-processes and introduces data stores.

• Data Stores (Open Rectangles):

• D1: Course & Textbook DB

• D2: Inventory/Stock DB

• Processes (Circles) & Interactions:

• Process 1: Manage Course Data

• Input: [TEXTBOOK MASTER LIST] from Academic Departments.

• Action: Saves data to D1: Course & Textbook DB.

• Process 2: Generate Orders

• Input: Reads needed books from D1: Course & Textbook DB and compares with D2: Inventory/Stock DB.

• Output: Sends [PURCHASE ORDER (Form 17)] to Publishing Companies.

• Process 3: Verify & Update Inventory

• Input: Receiving Department verifies books against the [PACKING SLIP] and inputs verification to Process 3.

• Output: Updates stock levels in D2: Inventory/Stock DB.

• Process 4: Process Student Sales

• Input: [BOOK REQUEST FORM & Payment] from Students.

• Action: Checks D2: Inventory/Stock DB to verify the book is in stock. Reduces stock by 1.

• Output: Generates and issues [CASH REGISTER SALES RECEIPT] to the Student.

Q.6: Consider the following case study and solve the questions as below:

a) Enlist Functional, nonfunctional, user and business requirement for the above case study. (3)

• Functional Requirements: (What the system must actively do)

• The system must allow the user to select products and quantities to submit an order.

• The system must send an automated order confirmation via email.

• The system must verify requested amounts against current magazine/stock levels.

• The system must automatically generate an email to a major supplier to order out-of-stock goods.

• The system must reserve partial stock and add pending items to a list of open orders.

• Non-functional Requirements: (System qualities/performance)

• Performance: The system must check stock and process the "shipment" state immediately.

• Reliability/Availability: The web browser interface and email dispatch systems must be highly available and dependable.

• User Requirements: (What the user needs to accomplish)

• The customer requires an intuitive web-based order form to easily select desired products and amounts.

• Business Requirements: (The ultimate business goal)

• The business requires an automated order and supplier-restocking workflow to fulfill customer orders efficiently without manual stock-taking.

b) List one example for each Primary and secondary and off-stage/tertiary actor in the above mentioned case. (3)

• Primary Actor: The Customer. (They are the external entity whose direct interaction—opening the web browser and submitting the form—triggers the entire main use case of the system).
• Secondary Actor: The Major Supplier. (They are an external entity that the system interacts with to complete a specific task, which is ordering missing goods via email when stock is low).
• Off-stage/Tertiary Actor: The Inventory/Warehouse Manager. (While not explicitly clicking buttons in this specific sequence, they are the off-stage personnel who physically handle the "shipping" of goods or restock the physical "magazine" when the supplier delivers, making the system's logic possible in reality).