Online Hostel Management System

A project report on
WEB BASED
ONLINE HOSTEL MANAGEMENT SYSTEM
A PROJECT
Submitted by
Mr. Dineshkumar Mulchandani
In partial fulfillment for the award of the Degree of
BACHELOR OF TECHNOLOGY
IN
INFORMATION & TECHNOLOGY
Under the guidance of
Prof. Vinay Harsora
(Assistant Professor)
DEPARTMENT OF INFORMATION & TECHNOLOGY

SCHOOL OF ENGINEERING,
RK UNIVERSITY,
RAJKOT, GUJARAT-360020
Jun-2015
DECLARATION
I hereby declare that this submission is my own work and that, to the
best of my knowledge and belief, it contains no material previously
published or written by another person nor material which has been
accepted for the award of any other degree or diploma of the
university or other institute of higher learning, except where due
acknowledgment has been made in the text.
Furthermore, to the extent that I have included copyrighted material
that surpasses the bounds of fair dealing within the meaning of the
Indian Copyright Act, I certify that I have obtained a written
permission from the copyright owner(s) to include such material(s)
in my report and have included copies of such copyright clearances
to my appendix.
I declare that this is a true copy of my report, including any final
revisions, as approved by my report review committee.
Place : Rajkot, Gujarat
Signature :
Date :
Name : Dinesh Mulchandani
ii
CERTIFICATE
This is to certify that the report entitled Online Hostel
Management
System submitted by Mr. Dineshkumar
Mulchandani to the School of Engineering, RK University,

Rajkot towards partial fulfillment of the requirements for the
award of the Degree of Bachelor of Technology in Information
& Technology (B.TECH - IT).
It is a bonafide record of the work carried out by him under
my/our supervision and guidance and is to the satisfaction of
department.
Date:
Place:
Signature and Name of Guide:
Signature and Name of Head of

Dept.:
Signature and Name of Director

Seal of Institute
iii
PROJECT APPROVAL
This is to certify that project work embodied in this entitled

Online Hostel Management System was carried out by
Mr. Dineshkumar Mulchandani (11SOEIT11051) at
Department of Information & Technology, School of
Engineering, RK University is approved for award of the degree
of Bachelor of Technology in Information & Technology
(B.TECH (I.T.)) by RK University.
Date:
Place:
Examiner(s) Name and Signature:
1)
2)
3)
iv
ACKNOWLEDGEMENT
I fall short of words to pen down anything for the cooperation and encouragement extended by parents through the
completion of this project.
I am thankful to Crystal Hostel and Little Flower hostel,
Sabarmati, Ahmedabad for providing me the information & issues
regarding hostel management as in offline on paper mode.
I would like to thank the institute for the infrastructure,
administrative and qualitative support extended for the timely
completion of this project. I would like to express my deep sense of
gratitude & thankfulness to our head of department Mr. Amit
Lathigara and also my Internal Project Guide Mr. Vinay Harsora &
my External Project Guide Miss. Vina Mulani who provided his
expert guidance and inspiration during all phases of this project.
Their guidance, suggestions and expertise have been a source of
inspiration during the project tenure.
Last but not the least I would like to thanks all my faculty
members who maintained a friendly relation.
Place:
Signature:
Date:
Name:
v
LIST OF TABLES
Table No.
Description
Page No.
Basic Data Of Project Profile
03
Pros And Cons Of Iterative Model
11
Project Time Estimation
14
Representation Of Defined Schedule
15
Cost of assets
20
Cost driver of attributes
21
Cost driver of advance attributes
21
All Data Elements
41
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
vi
LIST OF FIGURES
Figure
Description
Page No.
No.
1
Iterative Model
Gantt Chart
13
Context Level Diagram
27
DFD Level-1 Diagram
27
DFD diagram for process
28
Use Case With Reference To Hosteller
29
Figure Of Use Case With Reference To Administrator/Rector
30
Figure Of Use Case With Reference To Room Allocation

Procedure
31
Figure Of Activity Diagram
32
10
Figure Of Class Diagram (Admin Access To Portal)
33
11
Figure Of Class Diagram (Hosteller Access To Portal)
34
12
Figure Of State Diagram
35
13
Figure Of Sequence Diagram
36
vii
TABLE OF CONTENTS
Title Page
Declaration of Originality
ii
Certificate
iii
Project Approval
iv
Acknowledgement
List of Tables
vi
List of Figures
vii
Table of Content
viii
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 REVIEW6
CHAPTER 2: PROJECT MANAGEMENT...7
2.1 PROJECT PLANNING AND SCHEDULING.7
2.1.1 PROJECT DEVELOPMENT MODEL..8
2.1.2 PROJECT PLAN..12
2.1.3 SCHEDULE REPRESENTATION.15
2.2 RISK MANAGEMENT .16
2.2.1 RISK IDENTIFICATION....16
2.2.2 RISK ANALYSIS & PLANNING...17
2.3 ESTIMATION.19
CHAPTER 3: SYSTEM REQUIREMENT STUDY..22
3.1 HARDWARE REQUIREMENT22
3.2 WEB APPLICATION REQUIREMENT...22
viii
CHAPTER 4: PROCESS DESIGN..23

4.1 INPUT DESIGN..23
4.1.1 ADMINISTRATOR..23
4.2 OUTPUT DESIGN..............................................................23
4.3 DATABASE DESIGN24
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 ELEMENTS39
5.2 DATABASE DESCRIPTION42
CHAPTER 6: TESTING..50
CHAPTER 7: SCREEN SHOTS AND USER MANUAL.53
CHAPTER 8: FUTURE PLAN64

CHAPTER 9: CONCLUSION.65
CHAPTER 10: REFERENCES & BIBLIOGRAPHY..66
ix
Online Hostel Management System
1. INTRODUCTION
This system is designed in favor 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 the 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 are 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 are running the hostel and web
applications are not usually used in this context. This particular project deals
with the problems on 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 computerized system that will be compatible to 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 reduce the manual work of
the persons in admin panel and the bundle of registers that were search 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 data base 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 recognized 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 focus 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 web site concept using
ASP. NET and c# based technologies.
Web based portal will give each user separated rights to deal with web
site and web interface will give managerial information to the admin regarding
to 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 hostel as

student admission, staff management, student
management, Fee Collection, check in and check out
process, Expense calculation and other routing
processes.
Organization
Little Flower Hostel, Sabarmati, ,Ahmedabad
Operating
System
Microsoft Windows 7
RDBMS
SQL SERVER
Front End Used
ASP.NET (Web Application UI)
Project Guide
Mr. Vinay Harsora
Submitted By
Mr. Dineshkumar Mulchandani
Submitted To
R.K.UNIVERSITY, RAJKOT
Table 1 Basic Data of Project Profile
Page |3
1.3 PURPOSE
Purpose behind 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 huge amount of data as management as 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 online user interface for
guest or visitors of the hostel.
Page |4
1.4 SCOPE
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 an 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 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 have certain limits to deal with speed and
immigration performance of the web site.
The main modular part was belongs 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, an interactive features can be directly visualized by the user at the

portal.
Literature reviews directly subsets the updating of the user interface and
con currently access to the database.
Project team had visited the new little flower hostel located at Sabarmati,
Ahmedabad for review the current existing system.
The current system has the offline record keeping system which is
managed by the rector of the hostel.
It ensures the more complexity in the management of the system and also
there are 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 paper work.
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.
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 required any complex roll out procedure to

deploy in large organizations. 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.
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.
Page |7
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 development of system in
particular estimated time which creates planning of different modules at
initial level.
So, according to module summery with defined waterfall liter ature tasks
the web application will take place as product as web portal.
2.1.1 PROJECT DEVELOPMENT MODEL

SDLC ITERATIVE MODEL:
In Iterative model, 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.
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).
Page |8
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."
In 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 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.
Page |9
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 in 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 | 10
The following table lists out the pros and cons of Iterative and Incremental
SDLC Model:
Pros
Cons
Some working functionality can

be developed quickly and early in
the life cycle.
More resources
required.
Results are obtained early and

periodically.
Although cost of change is lesser

but it is not very suitable for
changing requirements.
Parallel development can be

planned.
More management attention is

required.
Progress can be measured.
Architecture & design issues

may arise because not all
requirements are gathered in
the beginning of the entire cycle.
Less costly to change

scope/requirements.
the
Defining
increments
may
require definition of the
complete system.
Testing and debugging during

smaller iteration is easy.
Not suitable for smaller projects.
Risks are identified and resolved

during iteration; and each
iteration is an easily managed
milestone.
Management
more.
With
every
increment
operational product is delivered.
Highly skilled resources are

required for risk analysis.
Issues & risks identified from

each increment can be resolved
to the next increment.
Projects progress is highly

dependent upon the risk
analysis phase.
may
complexity
Table 2 Pros and Cons of Iterative Model
P a g e | 11
be
is
2.1.2 PROJECT PLAN
ANALYSIS:
I have completed the Analysis portion of my project in 25 days.
I have study different Sites Related of My Project on Internet during

Analysis Period.
After visiting the little flower hostel located at Sabarmati, Ahmedabad the
base analysis includes the offline records of the hostel and the manual
feedback forms to analyze fraction of issues into the existing system.
The drawbacks of the system also gives the more quality points to
enhance flexibility of all stockholders by upgrading the existing system.
DESIGN:
Designing of Master Page forms and other design aspects has been
completed in 30 days period I did applied lots of efforts to build design
diagrams according to the analysis on the existing system so, it takes a lot
in the case of Choosing Designing aspects such templates for Homepage
and Master Page.
Designing of database consumes a human time.
Various types of tables I have to arrange with its data types and fields.
CODING:
Duration of coding consumes a huge time taken as 30 days.
I have completed Home Module, Login Form, Master page with validation
and Ajax control and all form validation completed in 32 days.
TESTING:
I have completed the testing phase of website by applying algorithms and

using query processing in time of 10 days.
P a g e | 12
GANTT CHART:
Figure 2 Gantt chart
As shown in the Gantt chart the whole process begins from analysis of the
system that takes around 23 days in the whole scenario.
Then the design for new system takes brief analysis on the components
that can be used to implement whole product. So it takes 45 days to
design all diagrams and relevant data flow designs of the system.
Next comes to design layout and UI for the web application and it takes
only 15 days to design graphical on paper designs of the web application.
Then the main task has to be implemented by coding that is development

of the new system as it takes around 45 days to develop whole new web
application to manage hostel management.
Now finally testing phase comes to be implement so to test all

components of website it takes around 18 days to be done.
P a g e | 13
TIME REQUIRED
TASK TO BE DONE
Two weeks
Analysis on problem definition
Three weeks
Analysis of existing system with

database design
One week
Data flow diagrams and actual flow in

database interaction
Three weeks
Utilities and tools required to user

interface implementation.
One week
Modular completion of the database

entities with actual scenario.
Three Weeks
Development of web interface in

ASP.Net with back-end as SQL
SERVER.
Three weeks
Testing in virtual environment.
Table 3 Project Time Estimation
P a g e | 14
2.1.3 SCHEDULE REPRESENTATION

Estimated Duration
Task Implementation
Task -1 Initial level
Analysis on problem
definition
Task -1 Completion level
Analysis of existing system

with database design
Task -2
Data flow diagrams and

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

user interface
implementation.
Task -3 Implementation part
Design of user interface with

certain flow sequences.
Task -4
Modular completion of the

database entities with actual
scenario.
Task -4 Implementation part
Development of web
interface in ASP.Net with
back-end as SQL SERVER.
Task -5
Testing in virtual
environment.
Table 4 Representation of Defined Schedule
P a g e | 15
2.2 RISK MANAGEMENT:
To manage Risk at up to the entry level to the sub sequent level

throughout the project.
We can follow risk prediction strategies to analyze 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 identify 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 assessmen t.
2.2.1 RISK IDENTIFICATION:
Risk can be anything at all that could impact your application in a way you
werent expecting. Unexpected popularity that causes your server to catch
fire is a risk. The joke gets 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.
P a g e | 16
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
analyzing 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 organization are called internal
risks whereas the external risks come from out of the organization and are
difficult to control.
Internal risks are project risks, process risks, and product risks. External
risks are generally 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
is very difficult or impossible to identify all of them. Some of most
important risks in web application engineering project are categorized 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 as detail as below:
REQUIREMENT RISKS:
a.
b.
c.
d.
e.
f.
g.
h.
i.
Lack of analysis for change of requirements.

Change extension of requirements.
Lack of report for requirements.
Poor definition of requirements.
Ambiguity of requirements.
Change of requirements.
Inadequate of requirements.
Impossible requirements.
Invalid requirements.
P a g e | 17
ECONOMICAL RISKS:
1.
2.
3.
4.
5.
6.
7.
8.
Lack of good estimation in projects

Unrealistic schedule
The hardware does not work well
Complexity of new architecture
Large size of required architecture
Extension of requirements change
The tools does not work well
Personnel change,
Management change, technology change, and
environment change
9. Lack of reassessment of management cycle.
OPERATIONAL RISKS:
1.
2.
3.
4.
5.
6.
Inadequate budget
Change of requirements and extension of requirements
Human errors
Lack of employment of manager experience
Lack of enough skill
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 upon the amount of risk influence in web application development

project, risk strategies could be divided into three classes namely careful,
typical, and flexible.
P a g e | 18
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 in experienced web
application development organizations whose web application
development projects are officially defined and based on proven
technologies.
CONCLUSION USING RISK STRATEGIES:
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 minimized 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:
Web application cost estimation process is a set of techniques and

procedures that is 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 views 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 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.
Cost driver is anything that may or will affect the cost of the web
application. Cost driver are things such as design methodology, skill-levels,
risk assessment, personnel experience, programming language or system
complexity.
P a g e | 19
Cost of hardware assets used during project life cycle:

Physical
assets
&
Applicable cost in rupees
deliverables
Computer machines
50000
Optical disks
500
Developing platform
5000
Office goods
2000
Maintenance of systems
5000
Internet/communication
5000
devices
Paper work & stationary assets
1000
Total Estimated Amount
68500
Table 5 cost of assets
As shown in above table the cost of physical assets includes the main
hardware as well as development environment costs that are comes to
front at all over total is 68500 rupees of this project.
In an future it can also having cost of server maintenance as well as domain

launching or domain purchasing and also have web hosting charges to be
applicable on 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:
Manpower loading - 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 - amount of effort required to complete the project and is usually

measured in units as man-months (MM) or person-months (PM).
It taken physical efforts as well as on system development and testing

efforts of the project which all are mentioned below as in table.
The outputs (loading, duration and effort) are usually computed as fixed
number with or without tolerance in the classical view. Many of the data
that are inputs to the process are modified or refined during the web
application cost estimation process.
P a g e | 20
Category
Cost Driver
Very Low Low
Nominal
High
Product
Attributes
Required
Software
Reliability
Database
Size
0.75
0.88
1.00
1.15
Very
High
1.40
0.94
1.00
1.08
1.16
Product
Complexity
0.70
0.85
1.00
1.15
1.30
1.65
Execution
1.00
Time
Constraint
Main
1.00
Storage
Constraint
Computer
0.87
1.00
Turnaround
Time
Table 6 cost driver of attributes
1.11
1.30
1.66
1.06
1.21
1.56
1.07
1.15
Category
Cost Driver
Very
Low
Low
Nominal
High
Very
High
Personnel
Attributes
Analyst
Capability
1.46
1.19
1.00
0.96
0.71
Applications
Experience
1.29
1.13
1.00
0.91
0.82
Programmer
Capability
1.42
1.17
1.00
0.86
0.70
Virtual
Machine
Experience
Language
Experience
1.21
1.10
1.00
0.90
1.14
1.07
1.00
0.95
Modern
Programmin
g Practices
Use of
Software
Tools
Testing tasks
1.24
1.10
1.00
0.91
0.82
1.24
1.10
1.00
0.91
0.83
1.23
1.08
1.00
1.04
1.10
Computer
Attributes
Project
Attributes
Table 7 cost driver of advance attributes
P a g e | 21
Extra
High
-
Extra
High
3. SYSTEM REQUIREMENT STUDY

3.1 REQUIREMENTS
3.1.1 WEB APPLICATION CONFIGURATION:
Front end
: ASP.NET
Backend
: Microsoft SQL Server 2010
Operating System : Windows 7

Language
: C#
Frame work
: Visual studio 2010 framework 2.0
3.1.2 HARDWARE CONFIGURATION:

Processor
: Pentium III, 1.13GHz
RAM
: 128 Mb SD RAM
Monitor
: SVGA, smarten 56v
Keyboard
: Samsung Keyboard 105 keys
Mouse
: Logitech 3-Button
CD-ROM
: Samsung 52X
Hard Drive
: 40GB HDD
Mother Board
: Pentium 810
3.2 WEB APPLICATION REQUIREMENTS:
Web browser
Web utilities
P a g e | 22
4. SYSTEM DESIGN
4.1 INPUT DESIGN:
The system design is divided in to two portions. The Administrator
section and the User (students) section.
4.1.1 ADMINISTRATOR:
The Administrator can allot students to the hostel.
He/she can vacate the students form 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 simple format.
The goal of input data design is to make data entry base easy, logical and
free from errors as possible.
In input data design, we design the source document that capture the data
and then select the media used to enter them into the computer.
There are two major approaches for entering data in to the computer.
They are
A. Menus.
B. Dialog 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 reduce the chances
for error in data entry.
P a g e | 23
B. Dialog Box: Dialog boxes are windows and these windows are mainly
popup, which appear 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 dialog with the program.
4.2 OUTPUT DESIGN:
Designing computer output should proceed in an organized, 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 to the overall performance and the
systems working.
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. 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 database.
Designing the database is part of system design. Data elements and data
structures to be stored have been identified at 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.
P a g e | 24
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. Normalization is done to
get an internal consistency of data and to have minimum redundancy and
maximum stability.
This ensures minimizing data storage required, minimizing chances of data

inconsistencies and optimizing for updates.
4.4 ARCHITECTURAL DESIGN:
Architectural design represents the data structure and program

components that are required to build the computer based system. It
consider 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 o rder 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 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.
P a g e | 25
Symbols used in DFDs:
(1) Process: Here flow of data is transformed. E.g. Forms Distribution,

Preparing Merit list, etc.
(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 packet of data. It may be in the form of document, letter
etc.
(4) Data store: Any store data but with no reference to the physical method of
storing.
P a g e | 26
ZERO LEVEL DIAGRAM:
UNIVERSITY/
FUNDING
GOVERNMENT
AGENCY
HOSTEL
Rules & Regulation

Hostel Information
Request
MANAGEMENT
Fulfill
SYSTEM
Figure 3 Context Level Diagram

DFD LEVEL-1 DIAGRAMS:
Registration Form
STUDENT
Registration
Amount
Account Details
1.0
Send Student Details Hosteler
Registration
Receipts
2.0
Send Receipts
Account
FeePayment
Update
Office
Information
Message Given
3.0
Room
Allocation
Set room
Room allocated
Room_data
4.0
Confirmation
Information
Confirm flag
Figure 4 DFD level-1 diagram
P a g e | 27
STUDENT
DFD DIAGRAM FOR PROCESS 1.0(Student Admission process):
STUDENT
Registration
Info Updated
1.1
Registration
as new user
Inquiry
Student/hosteller data
Acknowledgment
1.2
Fill Account
Information
Submitted Form
Receive Response
Figure 5 DFD Diagram for process
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.
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.
P a g e | 28
Hostel file
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:
Figure 6 Use Case With Reference To Hosteller
P a g e | 29
USE CASE FOR ADMINISTRATOR:
Figure 7 Figure of Use Case With Reference To Administrator/Rector
P a g e | 30
USE CASE FOR USERS ROOM ALLOCATION:
Figure 8 Figure of Use Case With Reference To Room Allocation Procedure
P a g e | 31
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
P a g e | 32
4.5.4 CLASS DIAGRAM:
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 | 33
Figure 11 Figure of Class Diagram (Hosteller Access To The Portal)
P a g e | 34
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 hoe the objects state changes as a result of events that reach the object.
Figure 12 Figure of State Diagram
P a g e | 35
4.5.6 SEQUENCE DIAGRAM:
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 of Sequence Diagram
P a g e | 36
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.
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.
P a g e | 37
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 | 38
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
Attribute Name
Usage Of Attribute
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
Table: rectors
Attribute Name
Usage Of Attribute
username
User Id of Rector Person
name
Employee Name (Name Of Rector)
P a g e | 39
age
Age of an rector
address
Address of rector
phone
Phone number of employee/rector
date_of_join
Joining date of rector
Table: Feepayment
Attribute Name
Usage Of Attribute
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
username
Unique Id of user (Primary key)
Table: hostellers
Attribute Name
Usage Of Attribute
username
User Id as Primary Key
hosteler_id
Unique Id of hostelers
hosteler_name
Student name/ name of 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
P a g e | 40
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
hosteler_image_id
image id of profile image of user
Table: Admin
Attribute Name
Usage Of Attribute
username
User Id of administrator
name
Name of administrator
address
Full address of administrator
phone
phone number
date_of_join
Joining date
Table 8 All Data Elements
P a g e | 41
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
Admin Table Contains the information about students.
Room_data
Room_data Table Contains Room information
Registration
Registration details of account holder
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.
P a g e | 42
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 name field description
Type
size
null
Username
Unique id as user id Nvarchar(50)
50
Not allowed
Password
Password
Nvarchar(50)
50
Not allowed
role
Role of user
Int
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.
Primary Key & Reference Key: Username
P a g e | 43
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
description
type
size
Null?
Username
User name as Nvarchar(50)

primary key
50
Not
allowed
hosteler_id
Unique Id of
hostelers
nvarchar
10
Yes
hosteler_name
Student
name/ name
of hostelers
Nvarchar
Max
Yes
hosteler_dob
Date of birth
of hosteler
Date/time
NA
Yes
hosteler_room_no
Room no of
allocated
room
Int
Yes
hosteler_date_of_joining
joining date
of hostelers
Date/time
NA
Yes
hosteler_purpose
purpose of
standout at
hostel
Nvarchar(50)
50
Yes
hosteler_approximate_te
rm
Term /
duration
Nvarchar(50)
50
Yes
father_name
name of
father
Nvarchar(max)
max
Yes
father_mob_no
Mobile no of
father
Double
10
Yes
mother_name
name of
mother
Nvarchar(max)
Max
Yes
P a g e | 44
mother_mob_no
Contact no of
mother
Double
10
Yes
hosteler_address
Address of
hosteler
Nvarchar(max)
Yes
hosteler_email
Email id of
hosteler
Nvarchar(50)
50
yes
hosteler_working_institu
te
At where
hosteler
works
Nvarchar(50)
50
Yes
hosteler_mob_no
Mobile
number of
hosteler
Double
10
yes
guardian_name
Name of
guardian
Nvarchar(max)
Max
Yes
guardian_address
Address of
guardian
Nvarchar(max)
Max
Yes
guardian_mob_no
Mobile
number of
guardian
Double
10
yes
hosteler_fixed_deposit
Deposited
amount
Int
Yes
hosteler_image_id
Profile
Images
unique id
Nvarchar(50)
50
yes
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
Reference Key:
hosteler_id
P a g e | 45
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 name field description
type
size Null?
room_no
Room No
Char
room_id
Room Unique id
Nvarchar 10
Not null
room_type
Type of room
Nvarchar 10
Yes
building
Room belongs to which building Nvarchar 50
yes
Yes
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:
field name
field description
Type
size Null?
hostel_fees
fees of hostel
Double
10
yes
mess_charge
charges of mess
Double
Yes
inventory_charges
Charges of inventory
Double
yes
payment_date
date of payment
Date
10
Yes
total_paid
Total paid
amount
money Double
50
Yes
due_payment
Remaining amount to Double

be paid
10
Yes
P a g e | 46
Username
Unique Id of
(Primary key)
user Nvarchar 10
Not
allowed
Table 13 FeePayment Table

Validations:
this table.
Primary Key:
username
Reference Key:
NO
Admin :-
Objective: The Admin table contains the information about the Administrator
person.
Tables Referred: Admin
Table Format:
field name
field description
Username
User id of the account holder Nvarchar 20
Not
allowed
Name
Name of the administrator
Nvarchar 50
yes
Age
Age of administrator
Double
Yes
Address
Full Address of
administrator
Nvarchar N
Yes
Phone
Phone no of admin
Double
10
Yes
Date
10
Yes
Date_of_join Joining date of admin
type
size Null?
10
Table 14 Admin Table

Validations:
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.
Primary Key:
username
Reference Key:
No Reference key is there in this table.
P a g e | 47
rectors :-
Objective: The table contains the Personal information about the Employee.
Tables Referred: Employee_info
Table Format:
field name
field description
type
Username
User id of account holder
Nvarchar 20
Not allowed
Name
Employee Name
Nvarchar 50
Yes
Age
Age
Double
Yes
Address
Address of emp
Nvarchar n
Yes
Phone
Mobile number of employee number
Date_of_join Joining date of employee
date
size Null?
10
Yes
10
Yes
Table 15 Rector Table

Validations:
this table.
Primary Key:
username
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:
field name
Field description
type
size Null?
username
Unique user id of account

holder
Nvarchar 20
Not
allowed
Password
Password of user
Nvarchar 20
Not
allowed
P a g e | 48
Name
Student / employee name
Nvarchar 50
yes
Contact_no
Contact number of account

holder
Double
Yes
10
Table 16 Registration Table

Validations:
this table.
Primary Key:
Reference Key:
username
-
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 name
Field description
type
Image id for each image
Nvarchar 50
Not allowed
Image_Name Name of the pic/ image
Nvarchar 50
Yes
Image_id
Image
size Null?
Actual location of the image Nvarchar N
Not allowed
Table 17 Image Details Table

Validations:
this table.
Primary Key:
Reference Key:
Image_Id
No reference key in this table.
P a g e | 49
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:
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.
P a g e | 50
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 update d
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 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:
P a g e | 51
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 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.
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.
P a g e | 52
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 managemen t
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.
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 | 53
So now lets start with the main home page.
As shown in the screen shot the home page contains the main view to be
represented to the guest as well as online visitors.
P a g e | 54
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.
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.
P a g e | 55
Next main thing is to understand is login page.
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 | 56
1. Login with hosteller account:
Hosteller account will give platform with hosteller rights to view and
perform operations with no admin rights to user at that portal.
P a g e | 57
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 | 58
Screenshot of Payment Information:
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 | 59
2. Login with rectors account:
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.
P a g e | 60
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.
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.
P a g e | 61
3. Login with administrator account:
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 business need and evaluation of hostel management in
strategic way.
P a g e | 62
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 | 63
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 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.
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 | 64
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 features.
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 | 65
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 | 66

Online Hostel Management System

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Online Hostel Management System

Enviado por

Direitos autorais:

Formatos disponíveis

A project report on

DEPARTMENT OF INFORMATION & TECHNOLOGY

Place : Rajkot, Gujarat

Name : Dinesh Mulchandani

System submitted by Mr. Dineshkumar

Mulchandani to the School of Engineering, RK University,

Signature and Name of Guide:

Signature and Name of Head of

Signature and Name of Director

This is to certify that project work embodied in this entitled

Basic Data Of Project Profile

Pros And Cons Of Iterative Model

Project Time Estimation

Representation Of Defined Schedule

Cost driver of attributes

Cost driver of advance attributes

All Data Elements

Table Names Along With Description

Image Details Table

Context Level Diagram

DFD Level-1 Diagram

DFD diagram for process

Use Case With Reference To Hosteller

Figure Of Use Case With Reference To Administrator/Rector

Figure Of Use Case With Reference To Room Allocation

Figure Of Activity Diagram

Figure Of Class Diagram (Admin Access To Portal)

Figure Of Class Diagram (Hosteller Access To Portal)

Figure Of State Diagram

Figure Of Sequence Diagram

CHAPTER 4: PROCESS DESIGN..23

CHAPTER 8: FUTURE PLAN64

CHAPTER 10: REFERENCES & BIBLIOGRAPHY..66