Online Hostel Management System For Schools

LIST OF TABLES
Table Description Page

No. No.
1 Basic Data Of Project Profile 03
2 Pros And Cons Of Iterative Model 11
3 Project Time Estimation 14
4 Representation Of Defined Schedule 15
5 Cost of assets 20
6 Cost driver of attributes 21
7 Cost driver of advanced attributes 21
8 All Data Elements 41
9 Table Names Along With Description 42
10 Users Table 43
11 Hostellers Table 45
12 Room Table 46
13 FeePayment Table 47
14 Admin Table 47
15 Rector Table 48
16 Registration Table 49
17 Image Details Table 49
LIST OF FIGURES
Figure Description Page
No. No.
1 Iterative Model 9
2 Gantt Chart 13
3 Context Level Diagram 27
4 DFD Level-1 Diagram 27
5 DFD diagram for process 28
6 Use Case With Reference To Hosteller 29
7 Figure Of Use Case With Reference To 30

Administrator/Rector
8 Figure Of Use Case With Reference To Room 31

Allocation Procedure
9 Figure Of Activity Diagram 32
10 Figure Of Class Diagram (Admin Access To 33

Portal)
11 Figure Of Class Diagram (Hosteller Access To 34
Portal)
12 Figure Of State Diagram 35
13 Figure Of Sequence Diagram 36
TABLE OF CONTENTS
Title Page i
2
Online Hostel Management System
List of Tables ii
List of Figures iii
Table of Content iv
CHAPTER 1:
INTRODUCTION.1
1.1 PROJECT SUMMARY2
1.2 PROJECT PROFILE.3
1.3 PURPOSE.4
1.4
SCOPE...5
1.5 TECHNOLOGY AND LITERATURE REVIEW
6
CHAPTER 2: PROJECT
MANAGEMENT...7
2.1 RISK MANAGEMENT
.16
2.1.1 RISK
IDENTIFICATION....16
2.1.2 RISK ANALYSIS &
PLANNING...17
2.2
ESTIMATION.19
CHAPTER 3: SYSTEM REQUIREMENT

STUDY..22
3.1 HARDWARE REQUIREMENT

22
3.2 WEB APPLICATION
REQUIREMENT...22 CHAPTER 4:
Page|3
PROCESS DESIGN..23 4.1
INPUT DESIGN..23
4.1.1 ADMINISTRATOR..
23
4.2 OUTPUT
DESIGN..............................................................23
4.3 DATABASE DESIGN
24 4.4 ARCHITECTURAL
DESIGN25 4.5 PROCESS
DESIGN....25
4.5.1 DATA FLOW DIAGRAMS (DFD).
25
4.5.2 USE CASE DIAGRAMS.....
.28
4.5.3 ACTIVITY DIAGRAMS.
32 4.5.4 CLASS DIAGRAMS
...33 4.5.5 STATE
DIAGRAMS ...35
4.5.6 SEQUENCE
DIAGRAMS...36
CHAPTER 5: DATA
DICTIONARY..37
5.1 DATA ELEMENTS

39
5.2 DATABASE DESCRIPTION
42
CHAPTER 6:
TESTING..50
CHAPTER 7: SCREEN SHOTS AND USER

MANUAL.53
CHAPTER 8: FUTURE PLAN

64
4
CHAPTER 9:
CONCLUSION.65
CHAPTER 10: REFERENCES &

BIBLIOGRAPHY..66
Page|5
1. INTRODUCTION
This system is designed in favour of the hostel management

which helps them to save the records of the students about their
rooms and other things.
It helps them from the manual work from which it is very

difficult to find the record of the students and the mess bills of
the students and the information of about those ones who had
left the hostel.
All the hostels at present are managed manually by the

hostel office. The Registration form verification to the different
data processing is done manually.
Thus there are a lot of repetitions which can be easily

avoided. And hence there is a lot of strain on the person who is
running the hostel and web applications are not usually used in
this context. This particular project deals with the problems of
managing a hostel and avoids the problems which occur when
carried manually Identification of the drawbacks of the existing
system leads to the designing of a computerised system that will
be compatible with the existing system with the system which is
more user-friendly.
We can improve the efficiency of the system, thus

overcome the drawbacks of the existing system. We design this
system of the hostel management especially for the college
hostel, through this they cannot require so efficient person to
handle and calculate the things.
This system automatically calculates all the bills and issued the
notifications for those students who are against some rules.
Page|1
1.1 PROJECT SUMMARY
This web application product the hostel management to

improve their services for all the students of the hostel. This also
reduces the manual work of the persons in admin panel and the
bundle of registers that were searched when to find the
information of a previous student, because through this system
you can store the data of those students who had left the hostel.
Through this, you can check the personal profile of all the
current students within few minutes the database of the system
will help you to check a particular one.
The system will help you to check the mess bills of every
student and the students hostel dues. The students of the hostel
will be recognised from the ID number allocated at the room rental
time. In the last, this system will improve the management work in
the hostel.
This project is mainly focused on the solution regarding the

hostel management online process to accommodate the issues
that are done in manual existing offline systems.
So, this project is designed on the base of core website concept

using ASP. NET and c# based technologies.
The web-based portal will give each user separated rights

to deal with website and web interface will give managerial
information to the admin regarding be further changes in the
facilities of the system.
Page|2
1.2 PROJECT PROFILE
Project Title Hostel Management System
Objective Computerization of all the routine process of

the hostel as student admission, staff
management, student management, Fee
Collection, check in and check out process,
Expense calculation and other routeing
processes.
Operating Microsoft Windows 7,8,10

System
RDBMS SQL SERVER
Front End Used ASP.NET (Web Application UI)
Page|3
1.3 PURPOSE
The purpose of this project is to provide accommodate

consistent managerial user interface to the each user of the
hostel & stack holders.
To give online access to the each separated user.
To provide end to end facilities with transparency in the

system.
To manage the huge amount of data as management as an

online concept.
To give certain rights to the rectors based profile to generate

view detailed information of students.
To generate monthly or yearly based reports of the fee

payment section.
To accommodate issues & feedback from the hostel users.
To provide day to day updated room details on the online user

interface for guest or visitors of the hostel.
Page|4
1.4 the SCOPE
The scope of this online system is in every hostel modular business

or hostel systems to manage data & system as dynamically by web
access.
The administrative persons can generate monthly reports by

admin login to manage hostel scenario and future possibilities as
access would be easy.
In Future, we can also enhance business possibilities in the current

market area.
It can manage hostel inventories online as in web based.
It can enlarge flexibilities in the existing system with web-based

user interactive interface.
In the future, this system can be extended up to accept the online

fee payments as with source of net banking and also can do
analysis on the hosteller mess reviews and payment records of a
mess.
It can also serve the feedback system to each visitor or guest for
rating and review of features of the hostel.
Page|5
1.5 TECHNOLOGY AND LITERATURE REVIEW
The web-based user interface has certain limits to deal with speed
and immigration performance of the website.
The main modular part belonged to the ASP.NET technologies and

SQL SERVER database design & utilities.
Here, ASP.NET supports multi-user login with multiple profiles access

and interactive featured controls to gain flexibility in the interface
creation and management of controls.
So, interactive
can be directly visualised by the user at the portal.
Literature reviews directly subsets the updating of the user interface

and concurrently accesses to the database.
It ensures the more complexity in the management of the system

and also there are a number of manual forms to be filled for each
individual hosteller.
It also cant support the feedback review system on the go. So,
feedback has to be maintained manually using the paperwork.
Page|6
2. PROJECT MANAGEMENT
2.1 PROJECT PLANNING AND SCHEDULING
WEB APPLICATION:
A Web Application or web app is any web application that runs

in a web browser. It is created in a browser-supported
programming language (such as the combination of JavaScript,
HTML and CSS) and relies on a web browser to render the
application.
The web application is built around ASP.NET. ASP.NET is a

platform including design-time objects and controls and a
run-time execution context for developing and running
applications on a Web server.
ASP.NET Web applications run on a Web server configured with

Microsoft Internet Information Services (IIS). However, you do
not need to work directly with IIS. You can program IIS facilities
using ASP.NET classes, and Visual Studio handles file
management tasks such as creating IIS applications when
needed and providing ways for you to deploy your Web
applications to IIS.
Web Applications are best when the team is mostly using

developer studio and there is a high code content.
THE ADVANTAGE OF WEB

APPLICATION:
Web Application project is its much easier to exclude files from

the project view.
Web Applications do not require any complex roll out

procedure to deploy in large organisations. A compatible web
browser is all that is needed.
Browser applications typically require little or no disk space on

the client.
They require no upgrade procedure since all new features are

implemented on the server and automatically delivered to the
users.
Page|7
Web applications integrate easily into other server-side web

procedures, such as email and searching.
They also provide cross-platform compatibility in most cases

(i.e., Windows, Mac, Linux, etc.) because they operate within a
web browser window.
In the Project planning, the core concept of current existing

hostel system will be derived with issues on them, then this
planning scenario will take place to the direct implementation
of project analysis and design phase.
It will take more time to evaluate manual step by step order of

the process to the development of the online system.
So here we will use waterfall model as our standard model of

the development which directly leads to manage the
development of the system in particular estimated time which
creates planning of different modules at the initial level.
So, according to module summary with defined waterfall

literature tasks the web application will take place as a product
as a web portal.
2.1.1 PROJECT DEVELOPMENT MODEL
SDLC ITERATIVE MODEL:
In the Iterative model, the iterative process starts with

a simple implementation of a small set of the web
application requirements and iteratively enhances the
evolving versions until the complete system is
implemented and ready to be deployed.
An iterative life cycle model does not attempt to start

with a full specification of requirements. Instead,
development begins by specifying and implementing
just part of the web application, which is then
reviewed in order to identify further requirements. This
process is then repeated, producing a new version of
the web application at the end of each iteration of the
model.
Page|8
ITERATIVE MODEL DESIGN:
Iterative process starts with a simple implementation

of a subset of the web application requirements and
iteratively enhances the evolving versions until the full
system is implemented. At each iteration, design
modifications are made and new functional
capabilities are added. The basic idea behind this
method is to develop a system through repeated
cycles (iterative) and in smaller portions at a time
(incremental).
Following is the pictorial representation of Iterative

and Incremental model:
Figure 1 Iterative Model
Iterative and Incremental development is a

combination of both iterative design or iterative
method and incremental build model for development.
"During web application development, more than one
iteration of the web application development cycle
may be in progress at the same time." and "This
process may be described as an "evolutionary
acquisition" or
"incremental build" approach."
Page|9
In the incremental model, the whole requirement is

divided into various builds. During each iteration, the
development module goes through the requirements,
design, implementation and testing phases. Each
subsequent release of the module adds function to the
previous release. The process continues till the
complete system is ready as per the requirement.
The key to successful use of an iterative web

application development lifecycle is a rigorous
validation of requirements, and verification & testing
of each version of the web application against those
requirements within each cycle of the model. As the
web application evolves through successive cycles,
tests have to be repeated and extended to verify each
version of the web application.
P a g e | 10
ITERATIVE MODEL APPLICATION:
Like other SDLC models, Iterative and incremental

development has some specific applications in the web
application industry. This model is most often used in the
following scenarios:
Requirements of the complete system are clearly defined and

understood.
Major requirements must be defined; however, some

functionalities or requested enhancements may evolve with
time.
There is a time to the market constraint.
A new technology is being used and is being learnt by the

development team while working on the project.
Resources with needed skill set are not available and are
planned to be used on contract basis for specific iterations.
There are some high-risk features and goals which may

change in the future.
ITERATIVE MODEL PROS AND CONS:
The advantage of this model is that there is a working model

of the system at a very early stage of development which
makes it easier to find functional or design flaws. Finding
issues at an early stage of development enables to take
corrective measures on a limited budget.
The disadvantage with this SDLC model is that it is applicable

only to large and bulky web application development projects.
This is because it is hard to break a small web application
system into further small serviceable increments/modules.
In an iterative model, some working functionality can be

developed quickly and early in the life cycle. But the
disadvantage is more resources may be required.
P a g e | 11
The following table lists out the pros and cons of Iterative and
Incremental SDLC Model:
Pros Cons
Some working functionality More resources may

can be developed quickly be required.
and early in the life cycle.
Results are obtained early Although the cost of

and periodically. change is lesser but it is
not very suitable for
changing requirements.
Parallel development More management
can be planned. attention is required.
Progress can be measured. Architecture & design

issues may arise because
not all requirements are
gathered at the beginning
of the entire cycle.
Less costly to Defining increments may
change the require definition of the
scope/requirements. complete system.
Testing and debugging Not suitable for smaller

during smaller iteration is projects.
easy.
Risks are identified and Management complexity
resolved during iteration, is more.
and each iteration is an
easily managed milestone.
P a g e | 12
With every increment, the Highly skilled resources are

operational product is required for risk analysis.
delivered.
Issues & risks identified Projects progress is highly
from each increment can be dependent upon the risk
resolved to the next analysis phase.
increment.
Table 2 Pros and Cons of Iterative Model
2.1.3 SCHEDULE REPRESENTATION
Estimated Task
Duration Implementation
Task -1 Initial level Analysis on problem

definition
Task -2 Data flow diagrams

and actual flow in
database
interaction
Task -3 Utilities and tools

required to user
interface
implementation.
Task -3 Implementation The design of user

part interface with certain
flow sequences.
Task -4 Modular completion of

the database entities
with actual scenario.
P a g e | 13
Task -4 Implementation Development of web

part interface in ASP.Net
with backend as SQL
SERVER.
Task -5 Testing in a virtual

environment.
Table 4 Representation of Defined Schedule
2.2 RISK MANAGEMENT:
To manage Risk at up to the entry level to the subsequent

level throughout the project.
We can follow risk prediction strategies to analyse risk levels

at each development phase of the project.
The set of task to be done again consist various risk at the

time completion period of time.
Risk prediction strategies can be evaluated at the time of

project design phase where we can apply several techniques
to away the risk parameters as much as can possible.
Since there could be various risks associated with the web

application development projects, the key to identifying and
manage those risks is to know about the concepts of web
application risk management. Many concepts about web
application risk management could be identified but the most
important are risk index, risk analysis, and risk assessment.
2.2.1 RISK IDENTIFICATION:

Risk can be anything at all that could impact your application
in a way you werent expecting. The unexpected popularity
that causes your server to catch fire is a risk. The joke gets
P a g e | 14
made often that too much traffic is a great problem to have,

but thats complete bullshit. Whether your server becomes
unavailable due to hardware failure, coding errors or the
inability to scale, the end result is that youre down, and the
people trying to access your application may never return.
Sometimes the actualization of the risk wont result in

downtime, but could still be seriously damaging to the success
of the project.
A coding failure in a project that results in contest entries not

being recorded correctly could result in lawsuits.
A critical third-party API being unavailable could result in core

feature of your application (login, etc) not functioning, which
could result in lost customers or bad press.
A failure in your caching layer could result in massive strain

put on your database, which could cause latency or downtime.
A brittle deployment process could result in the inability to

deploy code, or deployments being pushed out that are
incomplete or broken.
An overly complex application or system architecture could

mean that when something goes wrong, its incredibly difficult
to diagnose.
2.2.2 RISK ANALYSIS AND PLANNING:

The key purpose of classifying risk is to get a collective
viewpoint on a group of factors. These are the types of factors
which will help project managers to identify the group that
contributes the maximum risk.
A best and most scientific way of approaching risks is to

classify them based on risk attributes. Risk classification is
considered as an economical way of analysing risks and their
causes by grouping similar risks together into classes.
Web application risks could be classified as internal or

external. Those risks that come from risk factors within the
organisation are called internal risks whereas the external
P a g e | 15
risks come from out of the organisation and are difficult to

control.
Internal risks are project risks, process risks, and product risks.
External risks are generally a business with the vendor,
technical risks, customers satisfaction, political stability and
so on.
In general, there are many risks in the web application

engineering which are very difficult or impossible to identify all
of them. Some of the most important risks in web application
engineering project are categorised as web application
requirement risks, web application cost risks, web application
scheduling risk, web application quality risks, and web
application business risks.
These risks are explained in three types in detail as below:

REQUIREMENT RISKS:
a. Lack of analysis for a change of requirements.

b. Change the extension of requirements.
c. Lack of report for requirements.
d. Poor definition of requirements.
e. Ambiguity of requirements.
f. Change of requirements.
g. Inadequate of requirements.
h. Impossible requirements.
i. Invalid requirements.
ECONOMICAL RISKS:
1. Lack of good estimation in projects

2. Unrealistic schedule
3. The hardware does not work well
4. Complexity of new architecture
5. Large size of required architecture
6. Extension of requirements change
7. The tools does not work well
8. Personnel change, Management change, technology change,
and environment change
9. Lack of reassessment of management cycle.
OPERATIONAL RISKS:
1. Inadequate budget
2. Change of requirements and extension of requirements
P a g e | 16
3. Human errors
4. Lack of employment of manager experience
5. Lack of enough skill
6. Lack of good estimation in projects
QUALITY RISKS:
1. Inadequate documentation
2. Lack of project standard
3. Lack of design documentation
4. Inadequate budget
5. Human errors
6. Unrealistic schedule
7. Extension of requirements change
8. Poor definition of requirements
9. Lack of enough skill
10. Lack of testing and good estimation in projects
11. Inadequate knowledge about techniques, programming
language, tools, and so on
STRATEGIES FOR RISK MANAGEMENT:

During the web application development process, various
strategies for risk management could be identified and
defined according to the amount of risk influence.
Based on the amount of risk influence in a web application

development project, risk strategies could be divided into
three classes namely careful, typical, and flexible.
Generally, careful risk management strategy is projected for

new and inexperienced organizations whose web application
development projects are connected with new and unproven
technology; typical risk management strategy is well-defined
as a support for mature organizations with experience in web
application development projects and used technologies, but
whose projects carry a decent number of risks; and flexible
risk management strategy is involved inexperienced web
application development organizations whose web application
development projects are officially defined and based on
proven technologies.
CONCLUSION USING RISK
STRATEGIES:
P a g e | 17
In this way, web application risk management, risks

classification, and strategies for risk management are clearly
described in this paper. If risk management process is in place
for each and every web application development process then
future problems could be minimised or completely eradicated.
Hence, understanding various factors under risk management

process and focusing on risk management strategies
explained above could help in building risk-free products in
future.
2.3 ESTIMATION:
The web application cost estimation process is a set of
techniques and procedures that are used to derive the web
application cost estimate. There is usually a set of inputs to
the process and then the process uses these inputs to
generate or calculate a set of outputs.
Most of the web application cost estimation models view the

estimation process as being a function that is computed from
a set of cost drivers. And in most cost estimation techniques,
the primary cost driver or the most important cost driver is
believed to be the web application requirements.
In a classical view of the web application estimation process,

the web application requirements are the primary input to the
process and also form the basis for the cost estimation. The
cost estimate will then be adjusted accordingly to a number of
other cost drivers to arrive at the final estimate.
A cost driver is anything that may or will affect the cost of the
web application. A cost driver is things such as design
methodology, skill-levels, risk assessment, personal
experience, programming language or system complexity.
In the future it can also have cost of server maintenance as

well as domain launching or domain purchasing and also have
web hosting charges to be applicable to this project.
In a classical view of the estimation process, it will generate

three outputs - efforts, duration and loading. The following is a
brief description of the outputs:
P a g e | 18
Manpower loading - the number of personnel (which also

includes management personnel) that are allocated to the
project as a function of time.
Project duration - time that is needed to complete the project.

Which taken around 170 days to complete overall significant
deliverables of the whole project.
Effort - the amount of effort required to complete the project

and is usually measured in units as man-months (MM) or
person-months (PM).
3. SYSTEM REQUIREMENT STUDY
3.1 REQUIREMENTS
3.1.1 WEB APPLICATION CONFIGURATION:
Front end : ASP.NET
Backend : Microsoft SQL Server 2015
Operating System : Windows 7,8,10
Language : C#
Framework : Visual studio 2015
3.1.2 HARDWARE CONFIGURATION:
: Pentium III, 1.13GHz

Processor
RAM : 1 Gb RAM
Monitor : SVGA, smarten 56v
: Keyboard 105 keys

Keyboard
Mouse : Logitech 3-Button
P a g e | 19
CD-ROM : Samsung 52X

Hard Drive : 540GB HDD
Mother Board : CORE I5

3.2 WEB APPLICATION REQUIREMENTS:
Web browser
Web utilities
4. SYSTEM DESIGN
4.1 INPUT DESIGN:

The system design is divided into two portions. The
Administrator section and the User (students) section.
4.1.1 ADMINISTRATOR:
The Administrator can allow students to the hostel.
He/she can vacate the students from the hostel.
He/she can control the status of the fee payment.
He/she can edit the details of the students.
He/she can change their rooms, edit and delete the student
records.
A process of converting user originated inputs to a computer-

based format. Input design is an important part of
development process since inaccurate input data are the most
common cause of errors in data processing. Erroneous entries
can be controlled by input design.
It consists of developing specifications and procedures for

entering data into a system and must be in a simple format.
The goal of input data design is to make data entry base easy,
logical and free from errors as possible.
P a g e | 20
In input data design, we design the source document that

captures the data and then selects the media used to enter
them into the computer.
There are two major approaches for entering data into the
computer.
They are
A. Menus.
B. Dialogue Boxes.
A. Menus: A menu is a selection list that simplifies computer

data access or entry. Instead of remembering what to enter,
the user chooses from a list of options. A menu limits a user
choice of response but reduces the chances of error in data
entry.
B. Dialogue Box: Dialogue boxes are windows and these

windows are mainly popup, which appears in response to
certain conditions that occur when a program is run. It allows
the display of bitmaps and pictures. It can have various
controls like buttons, text boxes, list boxes and combo boxes.
Using these controls we can make a dialogue with the
program.
4.2 OUTPUT DESIGN:

Designing computer output should proceed in an organised,
well throughout manner; the right output element is designed
so that people will find the system whether or executed. When
we design an output we must identify the specific output that
is needed to meet the system. The usefulness of the new
system is evaluated on the basis of their output.
Once the output requirements are determined, the system

designer can decide what to include in the system and how to
structure it so that they require output can be produced. For
the proposed web application, it is necessary that the output
reports be compatible in format with the existing reports. The
output must be concerned with the overall performance and
the systems working.
P a g e | 21
It consists of developing specifications and procedures for

data preparation, those steps necessary to put the inputs and
the desired output, i.e. maximum user-friendly. Proper
messages and appropriate directions can control errors
committed by users. The output design is the key to the
success of any system. Output is the key between the user
and the sensor.
Output design consists of displaying specifications and

procedures as data presentation. The user never left with the
confusion as to what is happening without appropriate error
and acknowledges message being received.
4.3 DATABASE DESIGN:

The data in the system has to be stored and retrieved from
the database. Designing the database is part of system
design. Data elements and data structures to be stored have
been identified at the analysis stage.
They are structured and put together to design the data

storage and retrieval system. A database is a collection of
interrelated data stored with minimum redundancy to serve
many users quickly and efficiently.
The general objective is to make database access easy, quick,

inexpensive and flexible for the user. Relationships are
established between the data items and unnecessary data
items are removed. Normalisation is done to get an internal
consistency of data and to have minimum redundancy and
maximum stability.
This ensures minimising data storage required, minimising

chances of data inconsistencies and optimising for updates.
4.4 ARCHITECTURAL DESIGN:
P a g e | 22
The architectural design represents the data structure and

program components that are required to build the computer
based system. It considers the structures and properties Of
the components that constitute the system and relationship
that exist between all architectural components of the system.
4.5 PROCESS DESIGN:

Process design plays an important role in project
development. In order to understand the working procedure,
process design is necessary. Data Flow Diagram is the tool
used for process design. Data Flow Diagram is the logical
representation of the data flow of the project.
The DFD is drawn using various symbols. It has a source and a

destination. The process is represented using circles and
source and destination are represented using squares. The
data flow is represented using arrows. One reader can easily
get the idea about the project through Data Flow Diagram.
Overall Diagrams:
4.5.1 DATA FLOW DIAGRAM(s) [D. F. D.]:
The data flow diagrams are a pictorial or graphical
representation of the outline of the system study.
The data flow diagram covers all the processes and data
storage area, which takes place during any transaction in the
system. The data flow diagrams are functionally divided into
context level, Zero level, and First level and Second level data
flow diagrams.
Symbols used in DFDs:
(1)Process: Here flow of data is transformed. E.g. Forms

Distribution, Preparing Merit list, etc.
P a g e | 23
(2)External Entity: A source or destination of data, which is

external to the system. E.g. Student, Committee etc.
(3)A data flow: It is a packet of data. It may be in the form of a

document, letter etc.
DFD DIAGRAM FOR PROCESS 1.0(Student Admission process):
Registration
STUDENT 1.1
Info Updated Registration
as new user
Inqu
iry
Student/hosteller data 1.2 Submitted Form

Hostel file
Acknowledgment Fill Account

Receive
P a g e | 24
As shown in figure above the process of submitting online

form takes basically 3 steps to be done before inserting or
updating data of new or old students.
The registration process done by student/hosteller at the

online portal by using own login credentials and then account
section provides rights to add information to the portal.
DFD LEVEL
-1 DIAGRAMS:
Registration Form
STUDENT 1.0
Send Student Details
Hosteler
Registration Registration Receipts
Amount 2.0 Send Receipts

FeePayment
Account Det
ails Update
Account
Information
3.0 Set room

Message Given Room_data
Room
Allocation Room allocated
4.0 Information
P a g e | 25 STUDENT
Confirmation
Confirm flag
So, at the last portal will generate acknowledgment status on

the go so it is very flexible at the both the ends.
4.5.2 USE CASE DIAGRAM:
Use case diagram is a diagram that shows the interaction

between user and system to capture the users goals.
It is a graphic depiction of the interactions among the

elements of a system. A use case is a methodology used in
system analysis to identify, clarify, and organize system
requirements.
In Below mentioned use case diagram shows the main

features that are accessible by the hosteller or user by using
Use cases as for each separated use with system.
USE CASE FOR HOSTELLER:
P a g e | 26
Figure 6 Use Case With Reference To Hosteller

USE CASE FOR ADMINISTRATOR:
P a g e | 27
Figure 7 Figure of Use Case With Reference To

Administrator/Rector
P a g e | 28
USE CASE FOR USERS ROOM ALLOCATION:
Figure 8 Figure of Use Case With Reference To Room Allocation

Procedure
P a g e | 29
4.5.3 ACTIVITY DIAGRAM:
In an activity diagram the diagram shows the actual process of

working activities that are done by system and as well as
administrator and hosteller entities.
Figure 9 Figure of Activity Diagram
4.5.4 CLASS DIAGRAM:
P a g e | 30
Class diagram is a collection of static elements such as classes

and their relationships connected as a graph to each other.
Figure 3 Figure Of Class Diagram (Admin Access To Portal)
P a g e | 31
Figure 11 Figure of Class Diagram (Hosteller Access To The

Portal)
P a g e | 32
4.5.5 STATE DIAGRAM:
State diagram are a familiar technique to describe the

behavior of a system. They describe all of the possible states
that a particular object can get into and how the objects state
changes as a result of events that reach the object.
Figure 12 Figure of State Diagram
4.5.6 SEQUENCE DIAGRAM:
P a g e | 33
Sequence diagram shows an interaction arranged in a time

sequence. It is an alternate way to understand the overall flow
of the control of the system program.
Figure
13 Figure foSequence Diagram
P a g e | 34
5. DATA DICTIONARY
The data dictionary of any system is an integral component of

structure analysis, since data flow diagrams by themselves do
not fully describe the subject under investigation about the
system.
A data dictionary is a catalog a repository of the elements

in the system. These elements center on data and the way
they are structured to meet user requirements and
organization needs.
This step of creating a data dictionary is simultaneous with the

process of making data flow diagram(s). Here all the data
fields in their respective tables are allotted so as to access
these data in the system. The data tables are created in a
back-end tool like Microsoft Access, Oracle, FoxPro, etc.
Here in the HOSTEL MANAGEMENT SYSTEM we are using

tables created in SQL SERVER, as it is the back-end tool used
in the system.
The data dictionary consists of different major elements like

Data Elements, Data Store [Tables Used], Data Flow, Processes
and other External entities used in the system. The data
dictionary stores details and description of these elements.
It is developed during data flow analysis and assists the

analysts involved in determining the system requirements.
Analysts use data dictionary for the following important
reasons: o To manage the details in large system.
o To communicate a common meaning for all system
elements. o To document the features of the system.
o To facilitate analysis of the details in order to evaluate the
characteristics and determine where system changes
should be made.
o To locate errors and omissions in the system.
The data dictionary contains different types of descriptions for

the data flowing through the system.
P a g e | 35
Data Elements is the most fundamental level which is also

considered as the building block for all other data in the
system. It refers to all the different data used like fields, data
item, etc. to make the system fully functional irrespective to
the table used in the system. Here all the different type of
fields used to make table are written sequentially without
referring to the tables. This process helps in the process of
Normalization of tables.
Next to Data Elements comes the Data storage which provides
the information of where and how each data element is stored
in which table and it also give information of any constraints if
there.
This step also gives knowledge of different data types used for
different field and their size. All the normalized tables are
showed in data storage.
Data Flow stage shows the flow of data in the system. This
step is can be already seen in the data flow diagrams above in
this document.
So, it refers to all the data flow paths were transactions are
done in the computerized system.
The data flow step also includes different processes used in

the system and it is followed by External Entities used in the
system.
P a g e | 36
5.1 DATA ELEMENTS

The different data elements used in the system irrespective of
the tables used in the system are as below:
Table: users
Attribute Name Usage Of Attribute
username User Name
password Password
role Profile Type
emailid E-mail address of the user
Table: room_data
room_id Room Id as unique ID
Room_no Room Number
room_type Room Type

building The Room follows to which
Building
No_of_beds No. Of bed occupied
Facilities Allocated Package Of Defined

Facilities
P a g e | 37
Table: rectors
username User Id of Rector Person
Employee Name (Name Of

name
Rector)
age Age of an rector
address Address of rector

Phone number of
phone
employee/rector
date_of_join Joining date of rector
Table: Feepayment
hostel_fees fees of hostel
mess_charge charges of mess
inventory_charges Charges of inventory
payment_date date of payment
total_paid Total paid money amount
due_payment Remaining amount to be paid

Unique Id of user (Primary
username
key)
Table: hostellers
username User Id as Primary Key
P a g e | 38
hosteler_id Unique Id of hostelers

Student name/ name of
hosteler_name
hostelers
hosteler_dob Date of birth of hosteler
hosteler_room_no Room no of allocated room
hosteler_date_of_joining joining date of hostelers
hosteler_purpose purpose of standout at hostel
hosteler_approximate_term Term / duration
father_name name of father
father_mob_no Mobile no of father
mother_name name of mother
mother_mob_no Mobile no of mother
hosteler_address Address of hosteler
hosteler_email Email of hosteler
hosteler_working_institute Working institute of hosteler
hosteler_mob_no mobile number of hosteler
guardian_name name of guardians
guardian_address address of guardian
guardian_mob_no Mobile number of guardian
hosteler_fixed_deposit deposit amount paid by user

image id of profile image of
hosteler_image_id
user
Table: Admin
username User Id of administrator
P a g e | 39
name Name of administrator
address Full address of administrator
phone phone number
date_of_join Joining date

Table 8 All Data Elements
5.2 DATABASE DESCRIPTION [TABLE USED]:

Different tables used in the system along with their description
are described below in detail.
Table Name Description
Users The users table contains the information about the

different users and their passwords.
Hostellers The hostellers Table Contains the Information

about Students every details like parents contact
information, guardian information, and students
own information.
Rectors Rectors Table contains the details of all Employee.
FeePayment Fees Table contains the details about student Fees

for the hostel.
Admin Table Contains the information about
Admin
students.
Room_data Room_data Table Contains Room information
Registration Registration details of account holder
P a g e | 40
Image_Details Image details of profile image & location of image
Table 9 Table Names Along With Description
The above tables are described briefly and can be understand

clearly from next page. Each table is described along with
different fields used, their data types, their size and constraints.
Users: -
Objective: The users table contains the information about the
different users and their passwords, which are used to access the
system as there is more than one owner in the factory and they
can access data privately. The table stores the data as username
and password and thus provides security to the system. This
table also contains the administrator user and its password, so all
the rights are provided to the administrator and some rights are
not provided by the system to some local users.
Tables Referred: users
Table Format:
field field
Type size null
name description
Unique id as user
Username Nvarchar(50) 50 Not allowed
id
Password Password Nvarchar(50) 50 Not allowed
role Role of user Int 2 Not allowed
Emailed e-mail ID of user Nvarchar(50) 50 Not allowed

Table 10 Users Table
Validations:
The table does not allow to the user to enter blank record as
All fields are not null and it will show an error message if the any
of the field i.e. userid or password.
Provides an error message on getting incorrect username
or password with error message and does not allow entering in
the system without correct username or password.
P a g e | 41
Primary Key & Reference Key:

Username
P a g e | 42
Hostellers: -
Objective: The Status table contains the information about the
Student & his/her guardians and parents details.
Tables Referred: Hostellers
Table Format:
Field name field type size Null?

descriptio
n
Username User name Nvarchar(50) 50
Not
as primary
allowed
key
hosteler_id Unique Id nvarchar 10 Yes
of hostelers
hosteler_name Student Nvarchar Max Yes
name/
name
of hostelers
hosteler_dob Date of Date/time NA Yes
birth of
hosteler
hosteler_room_no Room no of Int 8 Yes
allocated
room
hosteler_date_of_joini joining date Date/time NA Yes
ng of hostelers
hosteler_purpose purpose Nvarchar(50) 50 Yes

of
standout
at hostel
hosteler_approximate Term / Nvarchar(50) 50 Yes

_te rm duration
father_name name of Nvarchar(max max Yes

father )
father_mob_no Mobile no Double 10 Yes

of father
P a g e | 43
mother_name name of Nvarchar(max Max Yes

mother )
mother_mob_no Contact no Double 10 Yes

of mother
hosteler_address Address of Nvarchar(max N Yes

hosteler )
hosteler_email Email id of Nvarchar(50) 50 yes

hosteler
hosteler_working_inst At where Nvarchar(50) 50 Yes

itu te hosteler
works
hosteler_mob_no Mobile Double 10 yes
number of
hosteler
guardian_name Name of Nvarchar(max Max Yes
guardian )
guardian_address Address of Nvarchar(max Max Yes

guardian )
guardian_mob_no Mobile Double 10 yes

number of
guardian
hosteler_fixed_deposi Deposited Int 8 Yes
t amount
hosteler_image_id Profile Nvarchar(50) 50 yes

Images
unique id
Table 11 Hostellers Table
Validations:
The table does not allow to the user to enter blank field those are
required as those fields are not null and it will show an error
message if the any of the field which is required is kept null by
the user while doing any transaction using this table.
Primary Key: username
P a g e | 44
Reference Key: hosteler_id
Room_data: -
Objective: The Room_data table contains the information about
the Room whether the there related detail.
Tables Referred: Room_data
Table Format:
Field siz
field description type Null?
name e
room_no Room No Char 4 Yes
Nvarch Not
room_id Room Unique id 10
ar null
room_typ Nvarch
Type of room 10 Yes
e ar
buildi Room belongs to which Nvarch
50 yes
ng building ar
Table 12 Room Table
Primary Key: room_id
Feepayment :-
Objective: The Fees table contains the information about the
Student Fees description.
Tables Referred: Fees
Table Format:
siz
field name field description Type Null?
e
hostel_fees fees of hostel Double 10 yes
mess_charge charges of mess Double 5 Yes
inventory_charg Charges of
Double 7 yes
es inventory
payment_date date of payment Date 10 Yes
total_paid Total paid money Double 50 Yes

amount
P a g e | 45
due_payment Remaining amount Double 10 Yes

to be paid
Username Unique Id of us Nvarch 10 Not

(Primary key) er ar allowed
Table 13 FeePayment Table
Validations:
Reference Key: NO
Admin :-
Objective: The Admin table contains the information about the
Administrator person.
Tables Referred: Admin
Table Format:
field siz
name e
Username User id of the account Nvarcha 20 Not
holder r allowed
Name of the Nvarcha

Name 50 yes
administrator r
Age Age of administrator Double 10 Yes
Address Full Address of Nvarcha N Yes

administrator r
Phone Phone no of admin Double 10 Yes
Date_of_jo
Joining date of admin Date 10 Yes
in
Table 14 Admin Table
Validations:
P a g e | 46
The table does not allow to the user to enter blank field because
all the fields are not null and it will show an error message if the
any of the field which is required is kept null by the user while
doing any transaction using this table.
Reference Key: No Reference key is there in this table.
rectors :-
Objective: The table contains the Personal information about the
Employee.
Tables Referred:
Employee_info Table Format:
field siz
name e
Username User id of account Nvarcha Not
20
holder r allowed
Name Nvarcha
Employee Name 50 Yes
r
Age Age Double 6 Yes
Address Nvarcha
Address of emp n Yes
r
Phone Mobile number of
number 10 Yes
employee
Date_of_jo Joining date of
date 10 Yes
in employee
Table 15 Rector Table
Validations:
Reference Key: No Reference key is there in this Table.
Registration: -
Objective: The registration table contains the information about
the basic details of account holder to register.
Tables Referred:
registration Table Format:
P a g e | 47
field siz
Field description type Null?
name e
username Unique user id of account Nvarcha 20 Not
holder r allowed
Password Password of user Nvarcha 20 Not
r allowed
Name Student / employee Nvarcha
50 yes
name r
Contact_no Contact number of Double 10 Yes
account holder
Table 16 Registration Table
Validations:
Reference Key: -
Image_Details :-
Objective: The image details table contains the information
about the image profile photo for the Account holder.
Tables Referred:
Image_Details Table
Format:
Field siz
Field description type Null?
name e
Image_id Image id for each Nvarcha Not
50
image r allowed
Image_Na Nvarcha
Name of the pic/ image 50 Yes
me r
Image Actual location of the Nvarcha Not
N
image r allowed
Table 17 Image Details Table
P a g e | 48
Validations:
Primary Key: Image_Id
Reference Key: No reference key in this table.
6. TESTING
Lets have first web testing checklist :

1. Functionality Testing
2. Usability testing
3. Interface testing
4. Compatibility testing
5. Performance testing
6. Security testing
1) Functionality Testing:
This is the test for all the links in web pages,
database connection, forms used in the web
pages for submitting or getting information from
user, Cookie testing.
We have checked links as listed below: o We had

tested the outgoing links from all the pages from
specific domain under test.
o We had tested all internal links. o We had
tested links which are jumping on the same
pages. o We had tested to check if there are any
orphan pages. o Lastly in link checking, we had
checked for broken links in all abovementioned
links.
Forms are the integral part of any web site. Forms

are used to get information from users and to
keep interaction with them. So we had checked
many things on these forms as below:
P a g e | 49
o We had checked all the validations on each

field. o We had checked for the default values of
fields. o We had tested for wrong inputs to the
fields in the forms.
o Options to create forms if any, form delete,
view or modify the forms.
Cookies are small files stored on user machine.

These are basically used to maintain the session
mainly login sessions.
So, we had tested the application by enabling or

disabling the cookies in our browser options.
We have checked if the cookies are encrypted

before writing to user machine. If we are testing
the session cookies (i.e. cookies expire after the
sessions ends). We had checked for login
sessions and user stats after session end. And
also checked effect on application security by
deleting the cookies.
Database testing: o Data consistency is very

important in web application. So, we did have
checked for data integrity and errors while we
edit, delete, modify the forms or do any DB
related functionality.
o In that case, we had checked that if all the
database queries are executing correctly, data is
retrieved correctly and also updated correctly.
2) Usability Testing:
Test for navigation: o In an navigation test we got
that how the user surfs the web pages, different
controls like buttons, boxes or how user using the
links on the pages to surf different pages.
Usability testing includes:

o Web site should be easy to use. Instructions
should be provided clearly. Check if the
provided instructions are correct means
P a g e | 50
whether they satisfy purpose. o Main menu

should be provided on each page. It should be
consistent.
Content checking: o Content should be logical

and easy to understand. Check for spelling errors.
Use of dark colors annoys users and should not
be used in site theme. You can follow some
standards that are used for web page and
content building. These are common accepted
standards like as I mentioned above about
annoying colors, fonts, frames etc. o Content
should be meaningful. All the anchor text links
should be working properly. Images should be
placed properly with proper sizes.
o These are some basic standards that should be
followed in web development. Your task is to
validate all for UI testing.
Other user information for user help: o Like

search option, sitemap, help files etc. Sitemap
should be present with all the links in web sites
with proper tree view of navigation. Check for all
links on the sitemap.
3) Compatibility Testing:
Compatibility of our web site is very important
testing aspect. So, we had checked many
compatibility aspects as listed as below: o
Browser compatibility o Operating system
compatibility
o Mobile browsing o Printing
options o Browser
compatibility:
In all over web-testing phase we have experienced
that it is most influencing part on web site testing.
Some applications are very dependent on

browsers. Different browsers have different
configurations and settings that web page should
be compatible with. So, our web site coding
should be cross browser platform compatible.
Where it uses java scripts or AJAX calls for UI
P a g e | 51
functionality, performing security checks or

validations then give more stress on browser
compatibility testing of our web application.
So, we had tested this web application on

different browsers like Internet explorer, Firefox,
Netscape navigator, AOL, Safari, Opera browsers
with different versions and got that all results
were satisfactory results.
OS compatibility: o Some functionality in our web

application is may not be compatible with all
operating systems. All new technologies used in
web development like graphics designs, interface
calls like different APIs may not be available in
all Operating Systems.
o So, we had tested
application on different
operating systems like
Windows, UNIX, MAC,
Linux, and Solaris with
different OS flavors.
Mobile browsing: o While testing web pages on

mobile browsers, there were no any compatibility
issues exists on mobile.
4) Security Testing:
We have checked security of web application in
many cases which are listed as below:
We had tested by pasting internal URL directly

into browser address bar without login. Internal
pages should not open.
In this case, we have checked that If user are

logged in using username and password and
browsing internal pages then try changing url
options directly. Then Access should denied for
this user to view others stats.
P a g e | 52
We had tried some invalid inputs in input fields

like login username, password, and input text
boxes. & also checked for the system reaction on
all invalid inputs.
7. SCREEN SHOTS AND USER MANUAL
As per according to the hostels existing system

there are lots of conflicts and problems occurs in
the maintenance of hostel from top management
possibilities to the bottom phase of storing data
records.
So, this web application is designed in such a way

that whole system can be almost online and no
paper work needed to be done.
In this Web Application, The system is divided in

three kind of access modules which are listed as
below.
1. Hosteller profile login with hosteller portal.
2. Rector profile login with rector portal.
3. Administrator profile login with administrator
portal
This whole three profile logins contains the

different-different pages to provide individual
portal system which have each profile type having
different-different kind of rights to the user.
Each profile login gives certain rights to the user to

perform operations.
For example: Hosteller can view their own data

and own records only at the hosteller login. And if
rector gets logged in with his/her credentials
he/she will access whole data of hosteller and can
view, insert, update, delete specific data.
P a g e | 53
So here each & every features have been provided

based on the profile type of the user. And here the
system also serves the advance features like
group bookings of rooms or payment online
payment facilities at the hosteller login.
So, now we will see most of main pages of our

web-application with screenshots as below to
understand working and interactive usage of our
online portal.
P a g e | 54
So now lets start with
the main home page.
P a g e | 55
As shown in the screen shot the home page

contains the main view to be represented to the
guest as well as online visitors.
Now if user clicks to the gallery in menu bar
he/she will redirect to the gallery to view
amazing moments that are captured in hostel
life. As indicates that we serves the best hostel
facilities.
P a g e | 56
As shown in Screenshot, the red icons are the

photo album access to the direct view of images of
photo albums in the gallery page.
Next main thing is to understand is login page.
P a g e | 57
As shown in screenshot the login page is

commonly one for each user login whether he/she
is hosteller, rector or administrator. But it will
redirect user to its own portal as profile type and
gives whole access to the allocated rights to that
user.
P a g e | 58
1.Login with hosteller account:
P a g e | 59
Hosteller account will give platform with hosteller

rights to view and perform operations with no
admin rights to user at that portal.
The specific menu is provided to the user portal
to access data of own and for payment of fee as
well as to perform other operations like feedback
or complaint of any service issues.
Here we see the screen shots of parents

information and payment data that how it will
arrive in website.
Screenshot of parents information:
P a g e | 60
Screenshot of Payment Information:
P a g e | 61
It shows the data of fee with new records as well

as reaming fee to be paid or how much fee has
been paid And It also gives feature to generate fee
receipt in pdf file format.
When user will click on generate pdf of this data

it will make pdf and gives to user to print or
download file.
P a g e | 62
2.Login with rectors account:
P a g e | 63
As shown in screen shot above the rector will login

with his/her allocated user id and password and it
will redirects to the Rector Portal of the website.
Which at rectors home page he/she can view,

insert, delete, and update the data of all rooms of
each and every wing of hostel.
At this account type he/she can also

view/insert/update and delete data of every
hosteller who all are registered in hostel.
Screenshot of multi hosteller details page to

perform huge data process operations.
P a g e | 64
As shown in screenshot the multi-dimensional as

well as fully functional Grid View gives all data of
hostellers in separated columns with one button
exists to enlarge data to view full data or to
minimize data to gain required main view of data.
When rector person will click at payment

information in main menu or form sitemap. It will
redirects to payment information page.
3.Login with administrator account:
P a g e | 65
As shown in screenshot above the admin portal

redirects admin to administrator home page,
where admin can add/update no of rooms with no
of beds in specific room.
Administrator person have all rights to gain and

update information of stockholders as per
P a g e | 66
business need and evaluation of hostel

management in strategic way.
He/she can access all parents pages of the web-
application which can give major access & rights
to the admin.
He/she can change/update fee as per business

rules by just clicking over the fee information page
in admin portal.
And we had seen that contact us and about us

page that are virtually mounted in each page of
web application whether user is guest or specific
hosteller they can contact to office at any time
by just clicking over the about us in the main
menu of page or just clicking over the
communication info from the main menu of
web application.
P a g e | 67
8. FUTURE PLAN
In Future, The online hostel management system

can extend its features by :
o Adding scope to the online email confirmation

features
o
o .
o Mobile SMS Notifications.
o Virtual hostel concept.
o Semicircular notifications.
o Admin portal at two stage scenarios.
o Key aspects of hostel mobility.
o Online registration at any time.
o Bank account payment facilities.
o Guardian level portal as independent pro

login.
o Parents can view activity of their child on

portal.
o HMS Attendance
review by their parents.
o Cleaning and monitoring tab can be added to

this web application.
P a g e | 68
o Hosteller can provide online feedback about

issues in the existing environment.
o Conceptual and
Sorted report
generation.
o Admin panel can be extended to fulfill

requirements of rector like CCTV cam security
towards the hostel building area.
o To support Notification or security alerts.
P a g e | 69
9. CONCLUSION
After, Identification of the drawbacks of the existing

system It leads us to the designing of computerized
system that will be compatible to the existing system
with the new online system Which is more user friendly
and with more
.
I had improved the efficiency of the whole management

system, thus overcome the drawbacks of the existing
offline system by applying online record keeping
system with the support of this designated web
application.
It has been a matter of immense pleasure, honor and

challenge to have this opportunity to take up this
project and complete it successfully.
P a g e | 70
10. REFERENCES & BIBLIOGRAPHY
Crystal hostels, Rajkot
Little Flower hostels , Ahmedabad
Eklavya hostels, madhapar
Automated tech support documents
Asp. [Online] : o http://www.asp.net.
asp.net-tutorials. [Online] :
o http:// www.asp.net-tutorials.com
Code project.[Online]:
o http://www.codeproject.com/KB/aspnet/
Css-tricks. [Online]: o http://css-tricks.com
msdn.microsoft.[Online]:
o http://msdn.microsoft.com/en-
us/aa336522.aspx
w3schools.[Online]:
o http://www.w3schools.com/aspnet/
P a g e | 71

Online Hostel Management System For Schools

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Online Hostel Management System For Schools

Caricato da

Copyright:

Formati disponibili

LIST OF TABLES

Table Description Page

1 Basic Data Of Project Profile 03

2 Pros And Cons Of Iterative Model 11

3 Project Time Estimation 14

4 Representation Of Defined Schedule 15

6 Cost driver of attributes 21

7 Cost driver of advanced attributes 21

8 All Data Elements 41

9 Table Names Along With Description 42

17 Image Details Table 49

3 Context Level Diagram 27

4 DFD Level-1 Diagram 27

5 DFD diagram for process 28

6 Use Case With Reference To Hosteller 29

7 Figure Of Use Case With Reference To 30

8 Figure Of Use Case With Reference To Room 31

9 Figure Of Activity Diagram 32

10 Figure Of Class Diagram (Admin Access To 33

13 Figure Of Sequence Diagram 36

CHAPTER 3: SYSTEM REQUIREMENT

3.1 HARDWARE REQUIREMENT

5.1 DATA ELEMENTS

CHAPTER 7: SCREEN SHOTS AND USER

CHAPTER 8: FUTURE PLAN

CHAPTER 10: REFERENCES &

This system is designed in favour of the hostel management

It helps them from the manual work from which it is very

All the hostels at present are managed manually by the

Thus there are a lot of repetitions which can be easily

We can improve the efficiency of the system, thus

1.1 PROJECT SUMMARY

This web application product the hostel management to

This project is mainly focused on the solution regarding the

So, this project is designed on the base of core website concept

The web-based portal will give each user separated rights

1.2 PROJECT PROFILE

Project Title Hostel Management System

Objective Computerization of all the routine process of

Operating Microsoft Windows 7,8,10

RDBMS SQL SERVER

Front End Used ASP.NET (Web Application UI)

The purpose of this project is to provide accommodate

To give online access to the each separated user.

To provide end to end facilities with transparency in the

To manage the huge amount of data as management as an

To give certain rights to the rectors based profile to generate

To generate monthly or yearly based reports of the fee

To accommodate issues & feedback from the hostel users.

To provide day to day updated room details on the online user

1.4 the SCOPE

The scope of this online system is in every hostel modular business

The administrative persons can generate monthly reports by

In Future, we can also enhance business possibilities in the current

It can manage hostel inventories online as in web based.

It can enlarge flexibilities in the existing system with web-based

In the future, this system can be extended up to accept the online

1.5 TECHNOLOGY AND LITERATURE REVIEW

The main modular part belonged to the ASP.NET technologies and

Here, ASP.NET supports multi-user login with multiple profiles access

can be directly visualised by the user at the portal.

Literature reviews directly subsets the updating of the user interface

It ensures the more complexity in the management of the system

A Web Application or web app is any web application that runs