CHAPTER THREE: METHODOLOGY

3.1 Introduction

In this chapter, the method followed in the development, design, and deployment of

the Hostel Management System was explained. The system was developed as a web

application with the aim of automating some of the hostel operations—such as

registration of students, checking room availability, filing of room requests, and

manual approval of requests by the administrator. The method followed in this

chapter directed the project from requirement analysis to testing and deployment

3.2 Analysis of the Existing System

Prior to development, the manual hostel management process was observed.

Observation indicated that:

• Students needed to physically approach the hall admin's office in order to ensure

room availability.

• Applications were processed using paper forms.

• Room allocation was done on a first-come-first-served basis in most cases, which

tended to result in delays, mistakes, and lack of transparency.

• The record-keeping and maintenance requests were ineffective since there was no

electronic system that was centralized.

3.2.1 Limitations of the Existing System

The existing hostel allocation system, which relies largely on manual procedures,

presents several practical challenges that hinder efficiency and fairness in student
accommodation management. As student populations continue to grow, the

drawbacks of the current system have become more pronounced.

Firstly, the allocation process is entirely manual. Administrators are responsible for

reviewing student applications, matching them with available rooms, and recording

this information by hand or using simple tools like spreadsheets. This process is not

only time-consuming but also highly prone to human error. Mistakes such as

duplicate room assignments or incorrect data entries are common, especially during

peak periods like the start of a new academic session.

In addition, the system lacks transparency. Students are often unaware of how

allocations are made or when their requests will be processed. In some cases, the

absence of clear guidelines creates room for favoritism or perceived bias, which

undermines trust in the allocation process.

Another major limitation is the absence of real-time updates. Students cannot check

the availability of rooms or monitor the status of their requests. As a result, many end

up submitting requests for already full rooms, leading to frustration and unnecessary

delays.

The system also does not provide any form of notification or alert mechanism.

Students have to physically visit the hostel office or rely on word of mouth to find out

whether their requests have been approved or rejected. This lack of communication

slows down the entire process and leaves students feeling disconnected.

Record keeping is another area of concern. Without a centralized digital system,

important data about room history, student occupancy, and maintenance issues can

easily be lost, misplaced, or duplicated.

When issues like broken facilities or plumbing faults arise, students have no formal

channel to log complaints, and administrators have no system to track, prioritize, or

respond to them efficiently.

Finally, the current system does not scale well. As student enrollment increases, the

workload on hostel administrators becomes overwhelming. Managing hundreds or

thousands of students manually is simply not sustainable in the long term.

These limitations highlight the need for a more robust, transparent, and automated

system that can streamline hostel room allocation and management in a way that

benefits both students and administrators.

3.3 Development Strategy for the Proposed System

For the successful development of this hostel management system, the Waterfall

Model was adopted as the primary software development methodology. The Waterfall

Model is a linear and sequential approach that allows each phase of development to be

completed before the next begins, ensuring proper documentation and structured

progress (Sommerville, 2011). This model was chosen due to its clarity, ease of use,

and suitability for projects with well-defined requirements, such as this one.

Given that the scope and functionalities of the system were already well-understood

from the early stages—such as user registration, room requests, allocation approvals,

maintenancet tracking, and administrative control—the Waterfall Model was

appropriate in maintaining discipline, simplicity, and reduced project risk (Royce,

1970). Its rigid nature makes it a preferred choice for academic systems where

changes are minimal once development begins.

the project team to track deliverables across each stage and align them with

documented requirements (Peters & Pedrycz, 2000). Although it has limitations in

terms of flexibility, the model proved effective for this project as the requirements

remained stable throughout the process.

3.3.1 Phases of the Waterfall Model

The Waterfall Model consists of the following sequential phases:

1. Requirement Analysis: In this phase, the functional and non-functional

requirements of the system were gathered through observation of current hostel

allocation practices and literature review. It served as the foundation for

understanding user needs and system constraints.

2. System Design: Based on the requirements, the overall architecture, database

schema, and interface structure of the system were designed. This phase included the

creation of data flow diagrams, ER diagrams, and interface wireframes.

3. Implementation: The actual development of the hostel management system was

carried out using Django as the backend framework and Bootstrap for the frontend

design. The system components were built according to the design specifications.
4. Testing: The developed modules were tested for accuracy, performance, and

security. Both functional testing (e.g., room request and approval flow) and non-

functional testing (e.g., responsiveness and usability) were performed.

5. Deployment: After successful testing, the system was deployed locally for

demonstration and evaluation purposes.

6. Maintenance: Although not extensively addressed in this academic project, the

maintenance phase is included in the model to accommodate future updates or bug

fixes after deployment.

This structured and disciplined model helped ensure that the system met its intended

goals within the given timeline and with clear deliverables at every phase

(Sommerville, 2011; Royce, 1970).

3.4 Requirement Analysis

Requirement analysis is a critical phase in system development, as it helps to define

what the system should do and how it should behave under various conditions. This

phase involves identifying the functional and non-functional requirements of the

system, both of which are essential in ensuring that the final product meets the needs

of the users.

For the proposed hostel management system, the requirements were gathered through

a combination of user observation, discussions with stakeholders (such as students

and hall administrators), and analysis of similar systems. The goal was to ensure the

system aligns with institutional policies and addresses the common challenges

associated with room allocation, maintenance, and administrative management.

The requirements are divided into two categories:

Functional requirements specify the key features and capabilities the system must

provide. These define what the system is expected to do to meet user needs. The

proposed hostel management system includes the following functional requirements:

1. User Authentication: Students and administrators must be able to register, log

in, and log out securely.

2. Student Profile Management: Students can fill in and update their profiles (e.g.,

name, department, level).

3. Room Availability Display: The system shows currently available rooms to

students in real time.

4. Room Request Submission: Students can request specific rooms online.

5. Room Allocation Management: Admins can approve or reject room requests.

6. Notifications: Students receive in-system notifications when their room or

maintenance requests are approved or rejected.

7. Maintenance Request Module: Students can file maintenance issues, and

admins can resolve them.

8. Admin Dashboard: Admins can manage students, rooms, requests, and

maintenance logs

3.4.2 Non-Functional Requirements

The non-functional requirements define the quality attributes, constraints, and system

characteristics that ensure the efficiency, reliability, and usability of the hostel

management system. These include:

1. Performance: The system responds promptly to user requests, with room

allocation operations and data retrieval typically completing within two seconds.
2. Scalability: The application is scalable to accommodate an increasing number of

students, rooms, and hostels as the institution expands.

3. Usability: The user interface is intuitive and user-friendly, designed to

accommodate users with minimal technical expertise. Features are clearly labeled

and navigable.

4. Availability: The system maintains high availability, especially during critical

periods such as room request and allocation phases, minimizing downtime.

5. Security: All user passwords are stored using encryption techniques, and user

authentication is required to access protected features. Admin and student

privileges are separated to prevent unauthorized access.

6. Data Integrity: The system ensures that data entered into the database is

consistent, accurate, and validated. Allocation conflicts (e.g., double-booking a

room) are programmatically prevented.

7. Maintainability: The codebase and database design follow standard conventions,

making the system easy to maintain, update, and extend in the future.

8. Portability: The system is web-based and functions across different browsers

and devices, ensuring accessibility from desktops, tablets, and smartphones.

9. Responsiveness: The system supports dynamic rendering and adapts to different

screen sizes and resolutions, improving mobile usability.

10. Auditability: Actions such as room requests, approvals, and updates are logged

in the database, enabling accountability and traceability.

3.5 System Design

System design serves as the blueprint for building the proposed hostel management

system. It focuses on defining the architecture, interface layouts, data models, and
process flows that guide developers in creating a functional and user-friendly

application.

3.5.1 System Architecture

The system adopts a three-tier architecture, separating responsibilities into the

presentation layer (frontend), logic layer (backend), and data layer (database). This

modular structure enhances maintainability, scalability, and security.

• Presentation Layer (Front-end): The user interface is developed in HTML, CSS,

and JavaScript using Bootstrap that provides a responsive and usable design.

• Business Logic Layer (Back-end): The back-end was implemented using Django,

which handled data processing, room allocation logic, and user authentication.

• Database Layer: MySQL was employed to safely store data such as student

profiles, hostel information, room information, and maintenance records.

3.5.2 User Interface Design

The user interface is designed with simplicity and usability in mind. Key design

elements include:

Navigation Bar: Offers quick access to features such as room list, dashboard, profile,

and settings.

Student Dashboard: Displays the student's room requests, approved allocations, and

maintenance requests.

Admin Dashboard: Provides an overview of all students, room statuses, and pending

allocations.

Forms: Used for signup, room requests, and maintenance reporting. These forms

incorporate validation and error handling for better user experience.

The design is mobile-responsive, allowing seamless use on various devices.

The Entity Relationship (ER) model of the proposed Hostel Management System

illustrates how entities in the system interact with one another. Each relationship

represents a real-world interaction between components of the system and helps

maintain referential integrity in the database. The key relationships include:

1. User – Student (One-to-One) Every student is associated with a unique user

account. The Student entity references the User entity through a foreign key (user_id).

This relationship ensures that each student inherits authentication credentials from the

base User model, allowing unified login functionality for both students and admins.

2. Hostel – Room (One-to-Many) Each hostel can contain multiple rooms,

establishing a one-to-many relationship. The Room entity holds a foreign key

(hostel_id) referencing the Hostel entity, indicating that many rooms can belong to a

single hostel

3. Student – Allocation (One-to-Many) A student may submit multiple room

requests over time (e.g., if earlier ones are rejected), creating a one-to-many

relationship between Student and Allocation. Each allocation is tied to a specific

student via the student_id.

4. Room – Allocation (One-to-Many) Each room can have multiple allocations over

time, although only a limited number can be approved concurrently based on room

capacity. The Allocation entity references the Room entity through the room_id

foreign key.

5. Student – Maintenance-request (One-to-Many) Students can submit multiple

maintenance requests. The Maintenance-request entity links to the Student entity via

student_id, allowing the system to track which student raised a given issue.
6. User – Allocation (One-to-Many) Admins (a special type of user) approve room

allocations. The approved_by field in the Allocation entity references the User who

performed the approval, establishing an administrative trail.

7. User – Maintenance-request (One-to-Many) Similarly, admins who resolve

maintenance requests are tracked via the resolved_by field in the Maintenance-request

entity. This field references the User who handled the resolution.

8. Student – Notification (One-to-Many) A student may receive multiple

notifications regarding room approvals, rejections, or maintenance resolutions. The

Notification entity contains a foreign key to the Student entity (student_id),

establishing this one-to-many relationship.

FIGURE 3.2: ENTITY RELATIONSHIP DIAGRAM

3.5.4 Data Flow Diagram

The Data Flow Diagram (DFD) visually represents how data moves through the hostel

management system, outlining the sources, processes, and data storage involved. The

DFD is essential for understanding the structure of the system and the interactions
between users (students and administrators) and the various modules of the system. It

helps identify the logical flow of information and the dependencies among different

components. This section illustrates both the high-level (Level 0) and detailed (Level

1) views of the system. These diagrams help stakeholders gain insight into how the

system operates, from student registration to room allocation and maintenance request

handling.

Level 0 DFD (Context Diagram)

The Level 0 DFD, also known as the context diagram, provides a broad overview of

the entire system. It represents the system as a single process and shows the

interaction between external entities (students and administrators) and the system.

Level 1 DFD

The Level 1 DFD breaks down the major system process into sub-processes, showing

how data flows between modules such as authentication, room allocation,

maintenance request handling, and student notifications. It gives a more granular view

of the internal functionality of the system.

The implementation phase involved translating the system design into a working

software application. This included setting up the development environment, building

the user interfaces, writing back-end logic, connecting the database, and integrating

all modules of the hostel management system. The system was developed using

Django for the back-end, MySQL for data storage, and Bootstrap for front-end

styling.

3.6.1 Development Environment

The system was built using the following tools and technologies:

 Operating System: Windows 11

 Programming Language: Python 3.13

 Framework: Django 5.2 (Model-Template-View architecture)

 Database: MySQL

 Front-End: HTML, CSS (Bootstrap), JavaScript

 Text Editor/IDE: Visual Studio Code

 Browser for Testing: Google Chrome

compatibility with modern web technologies.

3.6.3 Challenges Faced

Several challenges arose during the development of the system, including:

 Integrating the notification system and ensuring it works with allocation updates.

 Handling database migrations when new fields were added (e.g., level,

notifications_enabled).

 Fixing template errors, such as incorrect context data or unsupported template

tags.

 Implementing secure and user-friendly features like password change and real-

time notifications.

 Ensuring mobile responsiveness and proper user experience across devices.

Despite these challenges, debugging, documentation, and help from community

forums enabled successful resolutions.

3.7 Testing

To ensure the system functioned as expected, several testing methods were employed:

 Unit Testing: To verify individual functions such as room request, allocation

approval, and rejection.

 Integration Testing: To ensure modules like student signup, room allocation,

and notifications worked together smoothly.

 User Testing: The system was manually tested with different user roles (student

and admin) to observe real-time behavior and identify edge cases.

(e.g., password mismatch, duplicate usernames).

The system passed all test cases relevant to its scope and met the initial project

objectives.

3.8 Framework of the Proposed System

The hostel management system follows a modular, web-based framework that

separates concerns across multiple layers:

 Presentation Layer: The user interface accessible via browser, built with

HTML/CSS and Bootstrap.

 Application Layer: Handles business logic — implemented using Django views

and models.

 Data Layer: Manages persistent data using MySQL, supporting student records,

room details, and allocations.

 Security Layer: Handles authentication, session management, and access

control.

This framework was chosen for its scalability, ease of maintenance, and alignment

with modern web application architecture.

3.8.1 Use Case Model

The use case model represents the functional requirements of the proposed hostel

management system by identifying key interactions between users (actors) and the

system. It provides a high-level overview of how the system will be used and what

functionalities it must support to fulfill user needs.

actor interacts with the system differently:

Students can register, log in, view available rooms, request room allocations,

view allocation status, submit maintenance requests, and manage their profile.

Admins have access to manage hostels and rooms, approve or reject room

allocation requests, resolve maintenance issues, and manage student records.

The use case diagram serves as a planning tool for developers and a communication

bridge between stakeholders and the development team. It ensures that all user

interactions are properly captured and that the system meets its intended goals.