0% found this document useful (0 votes)
3 views15 pages

DSA Project Based Assessment

The document outlines project-based learning assessment guidelines for a Data Structures & Algorithms course at Woxsen University, detailing five distinct project evaluation sets. Each set includes project titles, objectives, team roles, expected features, and evaluation rubrics, focusing on various data structures and algorithms. The projects range from inventory management systems to student academic records systems, emphasizing practical implementation and teamwork over a two-week duration.

Uploaded by

sasankkolluuru
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
3 views15 pages

DSA Project Based Assessment

The document outlines project-based learning assessment guidelines for a Data Structures & Algorithms course at Woxsen University, detailing five distinct project evaluation sets. Each set includes project titles, objectives, team roles, expected features, and evaluation rubrics, focusing on various data structures and algorithms. The projects range from inventory management systems to student academic records systems, emphasizing practical implementation and teamwork over a two-week duration.

Uploaded by

sasankkolluuru
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 15

WOXSEN UNIVERSITY HYDERABAD

PROJECT-BASED LEARNING ASSESSMENT FOR END SEMESTER,


MAY 2025

Project-Based Learning (PBL) Evaluation Sets for Data Structures & Algorithms course.

Guidelines Comment: Each set of questions is aligned with Woxsen's PBE policy and
course (DSA) CLOs.

Project-Based Learning Evaluation Set 1


Course: Data Structures & Algorithms

Code: 24TU03MJM0

Credits: 4 (L:3, T:1, P:0)

Evaluation Type: End Sem (Project-Based Assessment)

Team Structure: 4 members per team

Project Duration: 2 weeks

Project Output: Implementation (code) + Technical Report + Zoom Viva Presentation

Set 1
1(a) Project Title: "Inventory Management System Using Linked Lists and Queues"

1(b) Project Objective

To design and implement an inventory management application that allows adding,


deleting, and managing product stocks using linked lists and queues, showcasing
dynamic data structure usage.

(c) Syllabus Integration

CLO Description Mapped to Project


Component

CLO1 Select appropriate data Use of linked lists for


structures for dynamic inventory items, queues for
collections order processing
CLO2 Assess and implement Integrate merge sort for
sorting algorithms for reorder operations
inventory sorting

CLO3 Design modular programs Class hierarchy for


using data structures product, inventory, and
order management

(d) Scenario Overview


A retail store needs a system to add new products, remove sold-out items, manage
order queues, and sort inventory based on stock levels or product ID. The team will
develop a console or GUI-based application to handle these operations.

(e) Team Roles


Role Responsibility

System Architect Design a class structure for inventory and


order management

Backend Developer Implements linked list and queue


operations, sorting algorithms

Frontend Developer Creates a basic console or GUI interface


for user interaction

QA Tester & Reporting Develops test cases, documents issues,


and writes the final technical report

(f) Expected Features


• Dynamic insertion and deletion of products using linked lists

• Order processing using queue data structure

• Sorting inventory by quantity or ID using merge sort

• Search for products using binary search on sorted lists

• Exception handling for invalid operations (e.g., removing non-existent items)


(g) Written Report Structure (Group Report)

Cover Page: Title, members' names, roles

Executive Summary: 150–200 words

Project Overview: Background, problem statement

Implementation Details: Code snippets + module descriptions

Reflection: 150–200 words/member

(h) Zoom Presentation Guidelines

Duration: 12–15 minutes

1-minute introduction

System design explanation (UML)

Code walkthrough

Demo of key functionalities

Team reflection

(i) Submission Format

• Proposal Document (PDF) + DOCX

• Final Report (PDF) + DOCX

• Source Code files (.py/.java/.cpp as applicable)

• Evidence of meetings (Screenshots, recordings, logbook)

(j) Evaluation Rubric


Component Weightage Criteria

Project Proposal 10% Problem relevance,


innovation, scope

Progress Review 20% Milestone tracking,


feedback incorporation
Final Submission 30% Design, code functionality,
and correctness

Presentation/Viva 30% Technical clarity,


communication, and demo
quality

Peer/Self Review 10% Reflections, contributions,


and fairness

(k) Grading Guidelines


Excellent (90–100%): Exceptional project, design, implementation, and teamwork

Good (70–89%): Solid project with minor issues and good collaboration

Average (50–69%): Functional but with significant flaws and fair collaboration

Below Average (<50%): Incomplete, non-functional, or poor collaboration

Project-Based Learning Evaluation Set 2


Course: Data Structures & Algorithms

Code: 24TU03MJM0

Credits: 4 (L:3, T:1, P:0)

Evaluation Type: End Sem (Project-Based Assessment)

Team Structure: 4 members per team

Project Duration: 2 weeks

Project Output: Implementation (code) + Technical Report + Zoom Viva Presentation

Set 2
2(a) Project Title: "Text Search Engine Using Tries and Pattern Matching
Algorithms"

2(b) Project Objective

To build a simple text search engine that indexes a collection of documents using trie
data structure and implements pattern matching (e.g., KMP) for fast query responses.
(c) Syllabus Integration
CLO Description Mapped to Project
Component

CLO1 Select data structures for Use of tries for storing


efficient indexing dictionary and document
keywords

CLO2 Implement and compare Integrate KMP and brute-


pattern matching force search to compare
algorithms performance

CLO3 Design modular search Classes for document


application using processing, indexing, and
datastructures search interface

(d) Scenario Overview


A small digital library needs a search utility to allow users to input a keyword and quickly
retrieve document names and positions where the keyword appears. The application will
build an index from provided text files and support real-time queries.

(e) Team Roles


Role Responsibility

System Architect Designs data flow for indexing and search


operations

Algorithm Specialist Implements trie structure and pattern


matching algorithms (KMP, naive)

Backend Developer Handles file I/O, indexing, and query


handling

QA Tester & Reporting Tests search accuracy and speed, writes


the technical report
(f) Expected Features
• Build a trie-based index from a collection of text files

• Support insertion of new documents and deletion of outdated ones

• Implement KMP algorithm for efficient pattern matching

• Compare search times between KMP and brute-force approaches

• Handle edge cases such as empty queries and missing documents

(g) Written Report Structure (Group Report)


Cover Page: Title, members' names, roles

Executive Summary: 150–200 words

Project Overview: Background, problem statement

Implementation Details: Code snippets + module descriptions

Reflection: 150–200 words/member

References: Books, websites, official documentation

(h) Zoom Presentation Guidelines


Duration: 12–15 minutes

1-minute introduction

System design explanation (UML)

Code walkthrough

Demo of key functionalities

Team reflection

(i) Submission Format


• Proposal Document (PDF) + DOCX

• Final Report (PDF) + DOCX

• Source Code files (.py/.java/.cpp as applicable)


• Evidence of meetings (Screenshots, recordings, logbook)

(j) Evaluation Rubric


Component Weightage Criteria

Project Proposal 10% Problem relevance,


innovation, scope

Progress Review 20% Milestone tracking,


feedback incorporation

Final Submission 30% Design, code functionality,


and correctness

Presentation/Viva 30% Technical clarity,


communication, and demo
quality

Peer/Self Review 10% Reflections, contributions,


and fairness

Project-Based Learning Evaluation Set 3


Course: Data Structures & Algorithms

Code: 24TU03MJM0

Credits: 4 (L:3, T:1, P:0)

Evaluation Type: End Sem (Project-Based Assessment)

Team Structure: 4 members per team

Project Duration: 2 weeks

Project Output: Implementation (code) + Technical Report + Zoom Viva Presentation

Set 3
3(a) Project Title: "Route Planning System Using Graphs and Shortest Path
Algorithms"
3(b) Project Objective

To develop a route planning application that models a network of cities/locations as a


graph and computes the shortest path using Dijkstra's or BFS/DFS for unweighted
graphs.

(c) Syllabus Integration


CLO Description Mapped to Project
Component

CLO1 Select appropriate data Use adjacency list for


structure for graph sparse graph modeling
representation

CLO2 Implement and analyze Integrate Dijkstra's


shortest path algorithms algorithm and BFS for
pathfinding

CLO3 Design a modular graph- Classes for graph


based application representation,
pathfinding, and user
interaction

(d) Scenario Overview


A logistics company wants a desktop application where users can add cities (nodes) and
roads (edges), then query for the shortest route between two cities. The application
should visualize or display the path and distance.

(e) Team Roles


Role Responsibility

System Architect Designs the graph data structure and


overall software modules

Algorithm Specialist Implements Dijkstra's and BFS algorithms


for pathfinding

Frontend Developer Creates a console or basic GUI for adding


nodes/edges and querying routes

QA Tester & Reporting Validates path correctness, measures


performance, and writes the final report

(f) Expected Features


• Represent a network of cities as a weighted/unweighted graph

• Add, remove, and update nodes and edges dynamically

• Compute shortest path using Dijkstra's algorithm for weighted graph

• Implement BFS for unweighted pathfinding

• Display path and total distance in user-friendly format

(g) Written Report Structure (Group Report)


Cover Page: Title, members' names, roles

Executive Summary: 150–200 words

Project Overview: Background, problem statement

System Design: UML class diagram + explanation

Implementation Details: Code snippets + module descriptions

Reflection: 150–200 words/member

References: Books, websites, official documentation

(h) Zoom Presentation Guidelines


Duration: 12–15 minutes

1-minute introduction

System design explanation (UML)

Code walkthrough

Demo of key functionalities


Team reflection

(i) Submission Format


• Proposal Document (PDF) + DOCX

• Final Report (PDF) + DOCX

• Source Code files (.py/.java/.cpp as applicable)

• Evidence of meetings (Screenshots, recordings, logbook)

(j) Evaluation Rubric


Component Weightage Criteria

Project Proposal 10% Problem relevance,


innovation, scope

Progress Review 20% Milestone tracking,


feedback incorporation

Final Submission 30% Design, code functionality,


and correctness

Presentation/Viva 30% Technical clarity,


communication, and demo
quality

Peer/Self Review 10% Reflections, contributions,


and fairness

Project-Based Learning Evaluation Set 4


Course: Data Structures & Algorithms

Code: 24TU03MJM0

Credits: 4 (L:3, T:1, P:0)

Evaluation Type: End Sem (Project-Based Assessment)

Team Structure: 4 members per team

Project Duration: 2 weeks


Project Output: Implementation (code) + Technical Report + Zoom Viva Presentation

Set 4
(a) Project Title: Smart Parking System Using Stacks and Queues

(b) Project Objective


To simulate a smart parking lot system using stacks for vehicle parking and queues for
waiting vehicles, demonstrating linear data structure operations and algorithmic design.

(c) Syllabus Integration

CLO Description Mapped to Project Component

Implement stack and queue- Stack for parking slots, queue for vehicles in
CLO1
based operations waiting

Develop modular programs with Class-based architecture for vehicle, parking


CLO3
data abstraction slot, and queue management

Apply algorithms in real-world Use of recursion and searching within the stack
CLO4
contexts for vehicle retrieval

(d) Scenario Overview


A parking lot has limited slots (stack structure: LIFO), and vehicles arrive randomly.
When full, arriving vehicles are placed in a waiting queue. If a vehicle leaves from the
middle, others must be moved (recursion or temporary stacks). Implement a simulation
to track entries, exits, and waiting list updates.

(e) Team Roles

Role Responsibility

Designs the architecture (classes: Vehicle, ParkingLot,


System Architect
WaitingQueue)

Backend Developer Implements stack, queue, and recursive search logic

Frontend Developer Develops a CLI for simulating arrival/departure of vehicles

QA &
Writes test cases and documents vehicle logs, designs the report
Documentation

(f) Expected Features

• Add/Remove vehicles from parking lot using a stack


• Maintain a queue of waiting vehicles

• Vehicle lookup and retrieval with appropriate shifting (recursion or temporary


storage)

• Reports on parking usage and waiting time

• Handling edge cases (e.g., vehicle not found)

Project-Based Learning Evaluation Set 5


Course: Data Structures & Algorithms

Code: 24TU03MJM0

Credits: 4 (L:3, T:1, P:0)

Evaluation Type: End Sem (Project-Based Assessment)

Team Structure: 4 members per team

Project Duration: 2 weeks

Project Output: Implementation (code) + Technical Report + Zoom Viva Presentation

Set 5
(a) Project Title: File Organizer Using Trees and Hash Tables

(b) Project Objective


To build a system that simulates file organization using tree structures for folder
hierarchy and hash tables for quick file access by filename.

(c) Syllabus Integration

CLO Description Mapped to Project Component

Apply non-linear data structures like


CLO1 Use trees to simulate folder hierarchy
trees

Implement hashing techniques for Hash tables with linear and quadratic
CLO2
fast retrieval probing for file access

Integrate searching and sorting in Use binary search for finding files in sorted
CLO3
real scenarios lists per folder
(d) Scenario Overview
A simplified OS file system with directories (modeled as tree nodes) and files (with hash-
based quick lookup). Each folder can contain files and subfolders. The team builds this
with options to insert, delete, search, and organize files.

(e) Team Roles

Role Responsibility

Tree Architect Designs tree structure for folder and subfolder relationships

Hashing Developer Implements hash table with probing and rehashing for file storage

Interface Builder CLI or GUI simulation of folder navigation and file operations

Report Lead Handles report, testing evidence, and logs

(f) Expected Features

• Create/Delete folders (tree node management)

• Add/Delete/Rename files within folders

• File retrieval using hashing

• Rehashing when collision exceeds threshold

• Visualization of folder structure (tree traversal demo)

Project-Based Learning Evaluation Set 5


Course: Data Structures & Algorithms

Code: 24TU03MJM0

Credits: 4 (L:3, T:1, P:0)

Evaluation Type: End Sem (Project-Based Assessment)

Team Structure: 4 members per team

Project Duration: 2 weeks

Project Output: Implementation (code) + Technical Report + Zoom Viva Presentation

Set 6
(a) Project Title:
"Student Academic Records System Using AVL Trees and Hashing"

(b) Project Objective


To develop an application that stores and manages student academic records using AVL
trees for sorted access and hash tables for efficient direct retrieval.

(c) Syllabus Integration

CLO Description Mapped to Project Component

Use balanced trees for sorted data


CLO1 AVL tree for student ID-based ordering
management

Apply hash tables for quick key-based Hashing with open addressing to
CLO2
access retrieve student details

Design scalable systems using dynamic Modular design with rehashing, dynamic
CLO3
data structures insertions

(d) Scenario Overview


An academic office wants to maintain student records that can be searched by roll
number or name. AVL trees are used to keep records sorted by roll number, while
hashing provides constant-time access using names.

(e) Team Roles

Role Responsibility

Tree Architect Implements AVL tree operations for ordered access

Hashing Developer Builds hash table with probing and extendible hashing

Integration Lead Combines both structures in a working application

Documentation Head Maintains test logs, edge case handling, and final report

(f) Expected Features

• Insert/Delete/Search student record

• Hash-based retrieval by name

• AVL tree traversal for sorted listing

• Collision handling and rehashing


• GPA sorting and top-performer queries

You might also like