Project Report

Software Engineering
CSE-516

Submitted to:

Dr. Mohammad Osiur Rahman

Professor
Department of Computer Science and Engineering
University of Chittagong

Project Name:

CSE CU Association

Team Members:

Members ID Name
1 21701012 Fahmida Akter
2 21701025 Saimanul Hoque
3 21701026 Oishik Albab

Submitted on August 20, 2025

Contents

1 Introduction 2
1.1 Background & Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Scope of the Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Project Planning & Management 5

2.1 Resource Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Work Breakdown Structure (WBS) . . . . . . . . . . . . . . . . . . . . . 6
2.3 Project Timeline & Scheduling . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4 Risk Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.5 Budget Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.6 Development methodology(V-shaped Model) . . . . . . . . . . . . . . . . 10

3 Requirements & Scope 11

3.1 Functional Requirements: . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2 Non-Functional Requirements: . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3 Scope of Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3.1 Deliverables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3.2 Exclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3.3 Tasks and Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3.4 Stakeholders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3.5 Estimated Cost of Project . . . . . . . . . . . . . . . . . . . . . . 13
3.3.6 Approvals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.4 Interview Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.4.1 Purpose of the Interview . . . . . . . . . . . . . . . . . . . . . . . 14
3.4.2 Interview Questions and Responses . . . . . . . . . . . . . . . . . 14
3.5 Use Case Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4 System Design & Architecture 17

4.1 High-Level Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1.2 Data Flow Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1.3 Entity Relationship Diagram . . . . . . . . . . . . . . . . . . . . . 19
4.1.4 System Deployment Diagram . . . . . . . . . . . . . . . . . . . . 20
4.2 Module-Level Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2.1 Key Modules & Interactions . . . . . . . . . . . . . . . . . . . . . 20
4.2.2 Module Interaction Flow . . . . . . . . . . . . . . . . . . . . . . . 21
4.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5 Development & Implementation 22

5.1 Technology Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.2 Development Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.2.1 Code Organization . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.2.2 Security Measures . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.2.3 API Development Practices . . . . . . . . . . . . . . . . . . . . . 22

1
 5.2.4 Database Design & Maintenance . . . . . . . . . . . . . . . . . . 22
5.3 Testing Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.4 Collaboration & Version Control . . . . . . . . . . . . . . . . . . . . . . . 23
5.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

6 Verification & Validation 24

6.1 Testing Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.1.1 Unit-Level Validation . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.1.2 Integration Checks . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.1.3 System-Level Testing . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.1.4 Performance Evaluation . . . . . . . . . . . . . . . . . . . . . . . 24
6.1.5 Security Validation . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.2 Testing Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.2.1 White-Box Testing . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.2.2 Black-Box Testing . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.3 Issue Tracking & Resolutions . . . . . . . . . . . . . . . . . . . . . . . . 25
6.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

7 Testing Process Flow Diagram 26

8 System Rollout & Support 27

8.1 Release Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
8.2 Sustainability & Ongoing Support . . . . . . . . . . . . . . . . . . . . . . 27

9 Decommissioning & Data Governance 28

9.1 Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
9.2 Data Retention Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . 28
9.3 System Shutdown Procedure . . . . . . . . . . . . . . . . . . . . . . . . . 28
9.4 Regulatory & Policy Alignment . . . . . . . . . . . . . . . . . . . . . . . 28
9.5 Forward-looking Measures . . . . . . . . . . . . . . . . . . . . . . . . . . 29

10 Conclusion & Recommendations 30

10.1 Summary of Findings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
10.2 Challenges Faced . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
10.3 Future Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

List of Figures
1 V-Model applied to CSECU Association . . . . . . . . . . . . . . . . . . 10
2 Use Case Diagram for CSECU Association . . . . . . . . . . . . . . . . . 16
3 High-Level Data Flow Diagram for CSECU Association Management System 18
4 ER Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5 System Deployment Diagram . . . . . . . . . . . . . . . . . . . . . . . . 20
6 Testing Process Flow Diagram for CCAMS . . . . . . . . . . . . . . . . . 26

List of Tables
1 Project Timeline and Key Milestones . . . . . . . . . . . . . . . . . . . . 7

2
 2 Gantt Chart Representation . . . . . . . . . . . . . . . . . . . . . . . . . 7
3 CSECU Association Project Budget Breakdown . . . . . . . . . . . . . . 9

Listings

1
1 Introduction

1.1 Background & Motivation

Every university department often runs its own association or club to organize cultural
events, seminars, workshops, and other co-curricular activities. These associations play
an important role in building unity among students, encouraging participation in de-
partmental activities, and ensuring proper management of resources. Traditionally, the
management of membership records, event registrations, and financial expenses is handled
manually, which can be time-consuming, error-prone, and difficult to update.
To overcome these challenges, there is a growing need for a computerized system
that can automate these processes. A well-structured software solution ensures accuracy,
security, and efficiency in managing association activities, while also providing an easy-to-
use interface for both members and administrators. The motivation behind developing the
CSECU Association project comes from the need to simplify and digitize the management
of departmental association activities. As students of Computer Science and Engineering,
we often participate in various cultural events and administrative tasks. Managing these
processes manually becomes increasingly complex as the number of members and events
grows.
By developing this software, we aim to:

• Provide a centralized system for membership management.

• Allow students to register for events online with pre-filled information for conve-
nience.

• Enable administrators to track expenses and manage events efficiently.

• Ensure security through role-based access control and CAPTCHA verification.

• Create a user-friendly platform that reflects the vision and activities of the associ-
ation.

1.2 Problem Statement

The CSECU departmental association is responsible for organizing cultural programs,

seminars, and other academic and extracurricular activities. At present, most of the
management tasks, such as maintaining membership records, registering participants for
events, and tracking expenses, are done manually. This traditional process suffers from
several limitations:

1. Time-consuming and inefficient record-keeping.

2. High chance of errors when managing large amounts of data manually.

3. Difficulty in updating or retrieving information quickly.

4. Lack of security, as records are often stored in physical files or spreadsheets without
proper access control.

2
 5. Poor user experience, since members need to repeatedly fill in details for event
registrations.
These challenges create delays, inconsistencies, and frustration for both students and
administrators. Therefore, there is a clear need for a digital solution that automates these
processes, ensures accuracy, and provides a secure, user-friendly interface for managing
the association’s activities.

1.3 Objectives

The main objectives of the CSECU Association project are:

• Automate membership management by maintaining a digital database of members
with secure signup and login facilities.

• Simplify event registration by providing online registration forms that automatically

pre-fill member details from the database.

• Manage association expenses efficiently by recording and tracking financial trans-

actions in a structured way.

• Provide role-based access so that administrators and general users can access only
the features relevant to their responsibilities.

• Ensure system security using CAPTCHA verification to prevent unauthorized or

automated access.

• Improve accessibility and user experience with a clean, user-friendly interface for
both students and administrators.

• Promote departmental activities by showcasing event photos and information through

an integrated image gallery and “About Us” section.

1.4 Scope of the Project

The scope of the CSECU Association project is to provide a digital platform for managing
departmental association activities efficiently. The system is designed with the following
scope:
Inclusions:
• Membership management with secure signup and login features.

• Event management, including online registration with pre-filled member informa-

tion.

• Expense management for recording and monitoring financial transactions.

• Role-based access control for administrators and general members.

• CAPTCHA integration to ensure security against automated access.

• Informational sections such as About Us, Vision and Mission, Our History, Batch
Representatives, and Contact Us.

3
 • An image gallery to showcase departmental events.

Exclusions / Future Scope:

• Online payment gateway for event fees or donations.

• Mobile application version of the system.

• Automated email/SMS notifications for event updates.

• Integration with external university systems.

This defined scope ensures that the system focuses on the essential functions required for
smooth operation of the association, while leaving room for future enhancements.

4
2 Project Planning & Management

2.1 Resource Planning

Resource planning is a crucial part of project management that ensures all necessary
human, technical, and material resources are available to complete the project efficiently.
For the CSECU Association project, resource planning was done carefully to allocate the
right tools, technologies, and responsibilities for each phase of development.

1. Human Resources:

• Project Developer(s): Responsible for coding the system, designing the UI,
and integrating modules.
• Database Designer: Responsible for designing the ER diagram, creating the
database schema, and managing data relationships.
• Tester: Responsible for conducting unit, integration, and system testing to
ensure functionality and reliability.
• Supervisor / Mentor: Provides guidance, reviews progress, and ensures the
project meets academic requirements

2. Technical Resources:

• Software:
⋄ MySQL Database for data storage and management.
⋄ HTML, CSS, and JavaScript, for developing the web-based user interface.
⋄ XAMPP/WAMP server for hosting and testing the application locally.
• Hardware:
⋄ Personal computer/laptop for development and testing.
⋄ Internet connection for research, libraries, and deployment.

3. Documentation Resources:
⋄ Reference books, lecture notes, and online tutorials to follow SDLC methodology
and best coding practices.

5
2.2 Work Breakdown Structure (WBS)

The Work Breakdown Structure (WBS) provides a hierarchical decomposition of the

CSECU Association project, ensuring a structured approach to project management.
It systematically breaks down the project scope into well-defined phases and deliverables,
making it easier to allocate resources, track progress, and manage dependencies. The
WBS chart categorizes the project into the following key phases:

• Phase 1: Requirement Gathering – Captures and defines project requirements,

including functional and non-functional specifications.

• Phase 2: System Design – Design ER diagram and database schema,UI/UX

design(homepage, login, event, about us, gallery), and security planning.

• Phase 3: Development – Develop database (tables, constraints, relationships),

Develop user interface (homepage, forms, gallery, about us),Implement member-
ship module (signup, login, CAPTCHA),Implement expense management module,
Implement admin features (role management, data update).

• Phase 4: Testing – Includes unit testing, integration testing, system validation,

and debugging.

• Phase 5: Deployment – Configure server environment (XAMPP/WAMP/O-

racle), Deploy database and web application, Verify system performance in live
environment.

6
2.3 Project Timeline & Scheduling

Key Milestones:
The following table outlines the key milestones for the project, ensuring a structured and
time-bound execution plan.

Date Range Milestone

01/05/2025 - 14/05/2025 Requirement Gathering & Analysis
15/05/2025 - 31/05/2025 UI/UX Design & Prototyping
01/06/2025 - 24/06/2025 Backend Development (Database & APIs)
25/06/2025 - 14/07/2025 Frontend Development
15/07/2025 - 31/07/2025 System Integration & Testing
01/08/2025 - 09/08/2025 Deployment & Cloud Hosting
10/08/2025 - 15/08/2025 Maintenance & Documentation

Table 1: Project Timeline and Key Milestones

Task Dependencies:
• UI/UX Design must be completed before Frontend Development begins.

• Backend Development must be finished before System Integration starts.

• Testing can only start after both Frontend and Backend development are com-
pleted.

• Deployment depends on successful Testing approval.

Gantt Chart Representation:

Task May 1 May 15 Jun 01 Jun 25 Jul 15 - Aug 01 Aug 10

- May - May - Jun - Jul 14 Jul 31 - Aug - Aug
14 31 24 09 15
Requirement Gathering
UI/UX Design
Backend Development
Frontend Development
System Integration & Testing
Deployment
Maintenance & Documentation

Table 2: Gantt Chart Representation

7
2.4 Risk Management

Risk management is a critical part of project planning that identifies potential problems
which may affect the successful completion of the project and defines strategies to mitigate
them. For the CSECU Association project, several potential risks were anticipated, along
with measures to reduce their impact.

1. Technical Risks:

• Database Design Errors: Mistakes in the ER diagram or schema could

cause data inconsistencies.
⋄ Mitigation: Careful design review, testing with sample data before full im-
plementation.
• Module Integration Issues: Errors when connecting the UI with the database.
⋄ Mitigation: Conduct integration testing after completing each module.

2. Development Risks:

• Coding Delays: Difficulty in implementing complex features like role-based

access or CAPTCHA.
⋄ Mitigation: Allocate buffer time, break tasks into smaller subtasks, and
prioritize critical modules.
• Software/Tool Limitations: Compatibility issues with server, database, or
IDE.
⋄ Mitigation: Use widely supported tools (XAMPP/WAMP, Oracle, standard
web technologies).

3. Human Resource Risks:

• Skill Gaps: Lack of experience in certain technologies (e.g., Oracle database,

PHP).
⋄ Mitigation: Use tutorials, consult mentors, and divide tasks based on indi-
vidual strengths.

4. Operational Risks:

• Deployment Issues: Server configuration errors or local environment mis-

matches.
⋄ Mitigation: Test deployment on local servers first and maintain backup
copies of all files.

5. External Risks:

• Data Loss: Accidental deletion or corruption of the database.

⋄ Mitigation: Maintain regular backups and version control.

By identifying these risks early and planning mitigation strategies, the project ensured a
smoother development process, minimized delays, and improved the overall quality and
reliability of the system.

8
2.5 Budget Planning

• Budget Breakdown

Category / Budget Item Cost Calculation Total (BDT)

Software Cost
My SQL Database Free(Open Source) 00
Development Tools Intellij IDEA, GitHub (free ver- 00
sions)
SSL Certificate For secure login & signup 6,000
Hardware Cost
Developer Laptop (2 units) 80,000 × 2 160,000
Backup Storage External HDD/SSD 10,000
Human Resource Cost
Project manager(Monthly 30,000 × 4 months 120,000
Salary)
Backend Developer 35,000 × 4 months 140,000
Frontend Developer 30,000 × 4 months 120,000
Tester / QA Engineer 25,000 × 4 months 100,000
Database Admin (part- 15,000 × 4 months 60,000
time)
Miscellaneous Costs
Office expenses & documen- Printing, manuals, & administra- 10,000
tation tive tasks
Internet & Utilities For development period 20,000
Total Estimated Budget 746,000

Table 3: CSECU Association Project Budget Breakdown

• Budget Analysis:

– Original Budget: 7,46,000

– Software: 6,000
– Hardware: 1,70,000
– Human Resources: 5,40,000
– Miscellaneous: 30,000

Analysis: Human resources take the largest share (72%), Hardware is 20%, soft-
ware only 1%, miscellaneous 6%.

9
2.6 Development methodology(V-shaped Model)

The V-Model is an extension of the waterfall model, emphasizing verification and val-
idation at each stage of development. For the CSECU Association project, which was
developed using MySQL (database), HTML, CSS , this model ensures that every
development phase has a corresponding testing phase.
This project consist of the following stages:

• Requirement Analysis ensured capturing user needs such as membership reg-

istration, event management, and expense tracking. These were validated later
during Acceptance Testing.

• System Design (overall database schema and web structure) was verified during
System Testing.

• Architectural Design (role-based UI, admin-user separation) corresponded to

Integration Testing.

• Module Design (membership form, event registration, CAPTCHA, etc.) was

linked to Unit Testing.

• Coding with HTML, CSS, PHP, and MySQL was validated through Code Veri-
fication.

Requirement Analysis Acceptance Testing

(Membership, Events, Expenses, Login) (Full System by Users/Admin)

System Design System Testing

(Database Schema, UI Structure) (All Modules Together)

Architectural Design Integration Testing

(Modules: Member, Event, Expense, Login) (Database UI, Forms)

Module Design Unit Testing

(Forms, Functions, Queries) (Signup, Login, Event, Expense)

Coding
(MySQL, PHP/Java, HTML/CSS)

Figure 1: V-Model applied to CSECU Association

10
3 Requirements & Scope

3.1 Functional Requirements:

• Membership Management: Users should be able to sign up, log in, and manage
their membership details.

• Event Management: Admin can create events; members can view and register
for events.

• Expense Management: Admin can record and track expenses related to events
and association activities.

• Role-Based Access: Different interfaces for admin and regular users, controlling
access to features.

• CAPTCHA Security: Login and registration forms should include CAPTCHA

to prevent automated spam.

• Dynamic Data Display: Homepage and event listings should dynamically fetch
data from the database

3.2 Non-Functional Requirements:

• Usability: The interface should be simple and user-friendly for students and ad-
mins.

• Performance: The system should respond quickly to user actions.

• Security: Proper authentication and data validation to prevent unauthorized ac-

cess.

• Compatibility: The system should work on modern web browsers.

3.3 Scope of Work

The scope of work defines what will be developed in the project, the deliverables provided
to the client/users, and what is explicitly excluded

3.3.1 Deliverables
The project will provide the following tangible outputs:

1. Membership Management Module:

• Signup and login forms with CAPTCHA.

• User profile management for students and admin.

2. Event Management Module:

• Admin can create, update, and delete events.

11
 • Members can view and register for events.

3. Expense Management Module:

• Admin can record event-related expenses.

• System generates expense summaries.

4. Role-Based User Interface:

• Admin interface for managing events, expenses, and members.

• User interface for viewing events, registration, and profile management.

5. Database Backend:

• MySQL database storing all user, event, and expense data.

• Queries and functions to dynamically fetch and update data.

6. Documentation:

• User manual describing system usage.

• Technical documentation including ER diagrams, V-Model design, and database
schema.

3.3.2 Exclusions
The project will not cover the following:

• Mobile application version or offline access.

• Advanced analytics, reporting dashboards, or real-time notifications.

• Integration with external payment systems for event registration.

• Support for multiple departments or scaling beyond a single university department.

12
3.3.3 Tasks and Schedule

S. No Tasks Goods Needed Services Needed Delivery Reporting

Date Head
1 Requirement Gath- - Consultation with Completed Oishik Al-
ering stakeholders bab
2 Database Develop- Server & Storage Database Design & Completed Fahmida
ment Setup Akter
3 Backend Develop- Web Server API Development Completed Saimanul
ment Hoque
4 Frontend Develop- - JavaScript,HTML Completed Fahmida
ment Akter
5 System Testing Testing Tools QA Testing Completed Oishik Al-
bab
6 Deployment Hosting Service Deployment to Pending Saimanul
Cloud Hoque
7 Maintenance & - Ongoing Support Ongoing Fahmida
Bug Fixes Akter

3.3.4 Stakeholders

S. No Name of Stakeholder Responsibility

1 Oishik Albab Technical Lead, Business Analyst, Test, QA En-
gineer
2 Fahmida Akter Database Developer, Frontend Developer,
Maintenance Engineer
3 Saimanul Hoque Backend Developer, Test and Deployment
4 Professor Dr. Osiur Rahman Academic Supervisor & Reviewer
5 Chittagong University End-User Institution

3.3.5 Estimated Cost of Project

Type Description Cost (BDT)

Internal Labor Developer salaries for 3 members (estimated for 6 months) 600,000
External Labor UI/UX Consultation & Testing (if any) 50,000
Materials Web Hosting, Database Storage, Development Tools 30,000
Services Maintenance, Cloud Services, Software Licenses 20,000
Total Project Cost 700,000

3.3.6 Approvals
• University Supervisor Approval: Pending

• Budget Approval: Pending

13
3.4 Interview Section

3.4.1 Purpose of the Interview

The interview was conducted to gather information from stakeholders and end users about
their expectations, current challenges, and desired features. The goal was to collect data
to guide the requirements analysis for developing the CSECU Association Management
System.

3.4.2 Interview Questions and Responses

S. No Questions Response
1 How do you currently manage mem- Currently, it is manual with spreadsheets, which
bership registrations and event par- is time-consuming and prone to errors.
ticipation?
2 What problems do you face with the Manual record-keeping makes tracking difficult;
current system? it is hard to maintain records and generate re-
ports.
3 How do you currently register for Mostly via manual forms or email submissions.
events or access membership details?
4 What features would you like in a Easy event creation, event registration, mem-
new system? bership management, member information, ex-
pense tracking, role-based access, and clear re-
porting.
5 How do you organize events and reg- We create events manually and collect registra-
istrations? tions via email or paper forms, which makes
tracking participation difficult.
6 Are there specific security require- Yes, admin and user access must be role-based
ments? with secure login and CAPTCHA.
7 What additional features would you A dashboard showing upcoming events, regis-
like? tration status, and personal membership info.
8 Would you like reminders or notifi- Yes, email or system notifications for registered
cations for events? students would help reduce confusion.

Summary of finding:

• Admin Needs: Efficient management of memberships, events, and expenses; role-

based access; secure login; and notifications for members.

• User Needs: Quick and clear event registration, access to personal membership
information, and a dashboard for tracking events.

• Challenges Identified: Current manual processes are slow, error-prone, and lack
centralized data storage, making it hard to track participation and generate reports.

14
3.5 Use Case Analysis

Overview

Use Case Analysis is a technique used to identify the functional requirements of a system
from the perspective of its users (actors). It helps in understanding how users interact
with the system and what actions the system must perform to meet their needs.

Actors

In the CSECU, the following primary actors are identified:

• Admin: Responsible for managing membership, event, expenses.

• Student: Registers for events, views personal membership details, and participates
in association activities.

• Instructor: Facilitates course delivery, submits grades, and initiates the certifica-
tion process for eligible students.

Primary Use Cases

1. User Registration Login:

• Users can sign up, log in, and recover passwords.

• Admin can approve or manage user accounts.

2. Event Management:

• Admin creates, updates, or deletes events.

• Users view events and register for them.

3. Expense Management:

• Admin records event-related expenses and generates reports.

4. Role-Based Access:

• Admin has full access to all modules.

• Users have limited access to view events, registration, and personal details.

5. Dashboard Notifications:

• Users can see upcoming events, registration status, and personal info.
• Admin receives notifications for event registrations or expense updates.

15
 CSECU Association

Manage Users, Event, Expense

Admin

Login, Registration

Student

Issue Certificate

Instructor Provide approvals

Figure 2: Use Case Diagram for CSECU Association

Diagram Explanation

The diagram visually represents the interactions between the system and its users. Each
actor is connected to the functionalities they can access:

• The Admin interacts with the system to manage members, event, and expense.

• The User/Member has access to login, registration into any event.

• The Instructor Can create or manage events, provide approvals, and access reports
related to student participation.

16
4 System Design & Architecture

4.1 High-Level Architecture

4.1.1 Overview

The CSECU Association Management System (CCAMS) follows a three-tier

architecture, ensuring scalability, transparency, and maintainability. The system con-
sists of the following layers:

• Presentation Layer (Frontend)

– Developed using HTML, CSS, and JavaScript for a dynamic and respon-
sive user interface.

– Provides access to students, association representatives, and administrators.

– Ensures role-based authentication and authorization.

• Application Layer (Backend & API)

– Built with Java Spring Boot, handling business logic and user requests.

– Implements authentication, event management, fund tracking, and user inter-

actions.

– Connects with the database using JDBC & ORM (Hibernate).

• Data Layer (Database)

– MySQL Database for structured data management.

– Stores user information, events, registrations, expenses, and income records.

– Optimized with indexing and relational integrity constraints.

17
4.1.2 Data Flow Diagram

Register/Login
User (Student/Member) Event Registration Process

Fund Management Process

Fund Updates Notify Members

Expense Tracking Notification Process

Expense Records Messages & Alerts

Association Database

Figure 3: High-Level Data Flow Diagram for CSECU Association Management System

18
4.1.3 Entity Relationship Diagram

Figure 4: ER Diagram

19
4.1.4 System Deployment Diagram

Client (Browser)

User Interface
(HTML, CSS, JS)

Backend (Java
Spring Boot)

Database (MySQL)

Figure 5: System Deployment Diagram

4.2 Module-Level Design

4.2.1 Key Modules & Interactions

• Authentication & User Management Module
– Handles student/member registration, login, and role-based access.
– Implements secure password storage and session handling.
• Event Management Module
– Allows administrators to create and manage events.
– Students can browse upcoming events and register.
• Registration Module
– Records student participation and registration details.
– Tracks payments and confirmations.
• Fund & Expense Management Module
– Manages association funds, income sources, and departmental ex-
penses.
– Provides summaries of financial status.
• Reporting & Analytics Module
– Generates reports on event participation, expenses, and income.
– Provides insights for transparency and accountability.
• Admin Dashboard Module

20
 – Grants admins control over users, events, and financial records.
– Implements audit trails and data backup mechanisms.

4.2.2 Module Interaction Flow

1. User logs in → Authentication Module validates credentials.

2. User registers for event → Registration Module records details.

3. Treasurer/admin updates fund usage → Fund & Expense Module stores record.

4. Notifications generated → Notification Module alerts users.

5. Admin generates reports → Reporting Module compiles insights.

4.3 Conclusion

This modular design ensures a transparent, efficient, and scalable approach to man-
aging CSECU Association activities. Each module operates independently while main-
taining seamless communication through a centralized database, enabling future scala-
bility and departmental improvements.

21
5 Development & Implementation

5.1 Technology Stack

The CSECU Association Management System (CCAMS) was implemented with

a mix of modern and reliable technologies to balance usability, transparency, and main-
tainability.
• Frontend: HTML, CSS, JavaScript (for interactive UI)
• Backend: Java Spring Boot (business logic and API services)
• Database: MySQL (relational data management)
• Version Control: Git and GitHub for collaborative development
• Deployment Environment: XAMPP (local testing and hosting)
• Testing Tools: Postman (API validation), Manual Testing for workflows

5.2 Development Guidelines

To ensure a reliable and well-structured implementation, the team followed a set of con-
ventions throughout the project lifecycle.

5.2.1 Code Organization

• Organized source code into clear packages/modules (controllers/, services/,
models/).
• Applied consistent naming conventions for files, classes, and methods.
• Ensured readability with comments and documentation in critical areas.

5.2.2 Security Measures

• Enforced secure password storage with hashing techniques.
• Used prepared statements in SQL to prevent SQL injection.
• Implemented role-based access (student, representative, admin).

5.2.3 API Development Practices

• Designed endpoints using REST principles for easy integration.
• Applied meaningful HTTP status codes for request outcomes.
• Ensured error messages were consistent and informative.

5.2.4 Database Design & Maintenance

• Normalized all relations up to 3NF to reduce redundancy.
• Applied indexes to frequently queried attributes (e.g., StudentId, EventId).
• Maintained regular backups for data reliability.

22
5.3 Testing Approach

Quality assurance was prioritized by verifying functionality at multiple levels:

• Unit Testing: Tested individual modules (e.g., login, registration).

• Integration Testing: Validated interactions between event, registration, and ex-

pense modules.

• System Testing: Verified complete workflows (fund collection, event creation,

registration).

5.4 Collaboration & Version Control

• Used GitHub repositories for maintaining project history.

• Followed a simple branching strategy (main for stable, dev for new features).

• Conducted peer reviews before merging changes into the main branch.

5.5 Summary

By following these practices, the CCAMS project was built as a secure, organized,
and transparent system. The chosen technology stack ensures that the system can be
extended and scaled in the future while preserving maintainability and ease of use.

23
6 Verification & Validation

6.1 Testing Approach

To guarantee the reliability and accuracy of the CSECU Association Management

System (CCAMS), a structured testing process was followed. The testing plan covered
multiple levels of evaluation:

6.1.1 Unit-Level Validation

• Goal: Ensure individual modules (login, event creation, fund entry) function as
expected.

• Tools Used: JUnit (for backend), manual checks for UI components.

• Scope: Authentication service, registration forms, database queries.

• Example: Test that inserting a new user returns a success response and stores
data correctly.

6.1.2 Integration Checks

• Goal: Validate smooth communication between backend, database, and frontend.

• Tools Used: Postman (API requests), Spring Boot Test utilities.

• Scope: User-event registration, expense tracking with event linkage.

• Example: Ensure registering a student for an event updates both the registration
table and the user’s profile.

6.1.3 System-Level Testing

• Goal: Verify complete workflows match user requirements.

• Tools Used: Manual end-to-end execution, browser-based testing.

• Scope: Fund collection, event management, notifications, reporting.

• Example: Validate that an event can be created, students can register, and ex-
penses can be logged against it.

6.1.4 Performance Evaluation

• Goal: Confirm the system handles multiple requests and data updates without
failures.

• Tools Used: Apache JMeter (basic load simulation).

• Scope: Concurrent event registrations and fund transactions.

• Example: Simulate 50 users registering for different events at the same time.

24
6.1.5 Security Validation
• Goal: Ensure the system prevents unauthorized access and secures sensitive data.

• Tools Used: Manual penetration attempts, parameterized queries for SQL safety.

• Scope: Authentication bypass, direct database queries, input sanitization.

• Example: Attempt to log in with invalid credentials or bypass admin panel access.

6.2 Testing Techniques

6.2.1 White-Box Testing

Applied during backend module development to examine business logic, conditional
flows, and database interactions. Code coverage analysis ensured critical functions (au-
thentication, transactions) were fully tested.

6.2.2 Black-Box Testing

Applied for end-user scenarios where testers interacted with the system without know-
ing its internal logic. This validated usability, correctness of outputs, and alignment with
functional requirements.

6.3 Issue Tracking & Resolutions

Bugs and improvements were documented using GitHub Issues, ensuring structured
resolution.

Issue Impact Status Resolution

Event Registration High Resolved Fixed missing foreign key constraint in
not saving registration table.
Duplicate user ac- Medium Resolved Enforced unique constraints on email
counts and student ID.
Expense records High Resolved Corrected join query linking expense
mismatched table with event table.
UI misaligned on Low Resolved Updated CSS with responsive grid sys-
mobile view tem.
Unauthorized Critical Resolved Strengthened role-based access and ses-
dashboard access sion validation.

6.4 Summary

By adopting a structured validation process and effective bug management, the CCAMS
achieved a stable, secure, and user-friendly system. The layered testing strategy
ensured both functional correctness and long-term maintainability.

25
7 Testing Process Flow Diagram
The diagram below shows how different testing phases are carried out in the development
cycle of the CSECU Association Management System (CCAMS).

Requirement Analysis

Unit Testing (White Box)

Integration Testing System Testing

Performance &
Security Testing

Final System Validation

Figure 6: Testing Process Flow Diagram for CCAMS

26
8 System Rollout & Support

8.1 Release Process

To ensure a smooth transition from development to active use, the CSECU Association
Management System (CCAMS) followed a structured release process:

1. Testing in staging environment: All modules (user management, event regis-

tration, fund tracking) were tested in a controlled environment before release.

2. Database backup: A full backup of existing records was created to safeguard

against potential deployment issues.

3. Environment setup: Server configurations, database connections, and access cre-

dentials were updated to match the live environment.

4. Deployment execution: The system was moved to production using XAMPP for
hosting and MySQL for database management.

5. Verification phase: Post-deployment checks ensured that login, event creation,

and fund tracking worked correctly.

6. Monitoring: Continuous monitoring of usage and performance was initiated to

quickly detect and resolve errors.

8.2 Sustainability & Ongoing Support

For long-term stability and improvement, the following measures are planned:

• Regular updates: Enhance features such as reporting, notifications, and financial

tracking.

• Security enhancements: Apply patches to prevent vulnerabilities, focusing on

authentication and database safety.

• User-driven improvements: Collect feedback from students, representatives,

and admins to refine usability.

• Scalability: Optimize queries and introduce caching mechanisms as the number

of users and events increases.

• Technical support: Provide ongoing troubleshooting and maintenance for smooth

operation.

• Documentation: Keep user manuals and administrator guides updated with new
features and workflows.

27
9 Decommissioning & Data Governance

9.1 Context

When a system reaches the end of its lifecycle, proper shutdown and data handling are
necessary to maintain security and compliance. For the CSECU Association Man-
agement System (CCAMS), this involves structured disposal of the application and
careful retention of historical records (students, events, funds, expenses).

9.2 Data Retention Guidelines

The system maintains a retention policy to balance transparency, compliance, and storage
efficiency:

• Retention Period: Member, event, and financial records will be retained for 5
years after account or event closure, as per university policy.

• Archival Method: Important data (fund logs, event outcomes) will be exported
into encrypted offline archives for audit/reference.

• Restricted Access: Archived data is accessible only to authorized administrators

and auditors.

9.3 System Shutdown Procedure

The decommissioning process of CCAMS will follow these steps:

1. Final Backup: Export all active records into a secure backup file before shutdown.

2. Data Cleansing: Apply secure deletion (e.g., overwriting, cryptographic wipe) to

remove sensitive data from servers.

3. Service Deactivation: Disable hosting services (XAMPP/Apache, MySQL con-

nections) and revoke user access credentials.

4. Hardware Disposal (if applicable): Any local servers or storage devices will be
discarded following institutional IT disposal rules.

5. Verification: Conduct a final audit to confirm compliance with academic and

security standards.

9.4 Regulatory & Policy Alignment

The process is aligned with:

• University IT Guidelines: Ensuring consistency with campus-level data han-

dling policies.

• Information Security Standards: Following principles inspired by ISO 27001

for safe information disposal.

28
 • Student Data Protection: Respecting privacy by erasing personal information
upon graduation or withdrawal.

9.5 Forward-looking Measures

To strengthen long-term governance:

• Automating data archiving and deletion schedules.

• Maintaining audit logs even after system shutdown.

• Periodically reviewing disposal policies for alignment with evolving academic regu-
lations.

29
10 Conclusion & Recommendations

10.1 Summary of Findings

The development and implementation of the CSECU Association Management System

(CCAMS) successfully addressed the administrative and transparency challenges related
to managing departmental events, funds, and member activities. The project replaced
inefficient manual processes with a structured, database-driven web application, enabling
smooth and reliable operations.
Key achievements of the project include:

• Creation of a secure, role-based access system for students, representatives, and

administrators.

• Digitalization of event registration, significantly reducing paperwork and minimiz-

ing human errors.

• Implementation of income and expense tracking modules, ensuring accountability

in fund management.

• Integration of reporting features to support data-driven decision-making within the

association.

• Establishment of a centralized database, ensuring structured storage and easy re-

trieval of records.

These outcomes align with the project objectives and contribute to enhancing orga-
nizational efficiency, transparency, and communication within the CSE department.

10.2 Challenges Faced

During the system design and implementation phases, several challenges were encoun-
tered:

• Data Normalization: Ensuring all tables were properly normalized to 3NF re-
quired extensive testing and adjustments.

• Integration Bugs: Initial issues occurred when linking the registration and ex-
pense modules with event data.

• UI Limitations: Developing a user-friendly and responsive interface within limited

resources was challenging.

• Time Constraints: Balancing academic schedules with project deadlines extended

the timeline.

Despite these challenges, corrective measures were taken, and the final system met
the key requirements set out in the design phase.

30
10.3 Future Enhancements

The following improvements have been identified for future development of CCAMS:

• Mobile Application: Develop a mobile version of the platform to allow easier

access for students and administrators.

• Enhanced Notifications: Implement automated email/SMS reminders for event

registration deadlines and fund updates.

• Data Visualization: Add dashboards with charts and graphs to display fund
usage and event participation statistics.

• Alumni Integration: Extend the system to include alumni contributions and

engagement with departmental activities.

• Scalability Improvements: Optimize performance to support larger volumes of

data as association activities expand.

These enhancements will strengthen CCAMS, improve user experience, and ensure
the system remains a sustainable and scalable solution for future departmental needs.

31