Online HMS

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
i
i
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 co-operation 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 Page
No. Description 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 advance 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
vi
LIST OF FIGURES
Page
Figure Description 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
Figure Of Use Case With Reference To

7 Administrator/Rector 30
Figure Of Use Case With Reference To Room

8 Allocation 31
Procedure
9 Figure Of Activity Diagram 32
Figure Of Class Diagram (Admin Access To

10 Portal) 33
Figure Of Class Diagram (Hosteller Access To

11 Portal) 34
12 Figure Of State Diagram 35
13 Figure Of Sequence Diagram 36

vii
TABLE OF CONTENTS
Title Page i
Declaration of Originality ii
Certificate iii
Project Approval iv
Acknowledgement v
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 REQUIREMENT
22
3.2 WEB APPLICATION
REQUIREMENT...22
viii
CHAPTER 4: PROCESS DESIGN..23
4.1INPUT DESIGN..23
4.1.1 ADMINISTRATOR..
23
4.2OUTPUT DESIGN..............................................................23
4.3DATABASE DESIGN24
4.4ARCHITECTURAL DESIGN25
4.5PROCESS 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.1DATA ELEMENTS39
5.2DATABASE 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

i
x
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
Online Hostel Management
System
1.2 PROJECT PROFILE
Project Title Hostel Management System
Computerization of all the routine process of

Objective 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 Microsoft Windows 7

System
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

literature 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 More resources may be
be developed quickly and
early in required.
the life
cycle.
Results are obtained early Although cost of change is
and lesser
periodically
. but it is not very suitable for
changing
requirements.
developmen More management attention

Parallel t can be is
planned. required.
Progress can be Architectur

measured. e & design issues
may arise because not all
requiremen
ts are gathered in
the beginning of the entire
cycle.
Chang Definin
Less costly to e the g increments may
definitio o
scope/requirements. require n f the
complete system.
Testin debuggi Not suitable for smaller

g and ng during projects.
smaller iteration is
easy.
Risks are identified and Manageme complexit
resolved nt y is
iteratio
during n; And each more.
iteration is an easily
managed
milestone.
Highly resource
With every increment skilled s are
operational product is required for risk
delivered. analysis.

Issues & risks identified from Projects progress is highly
each increment can be
resolved dependent upon the risk
to the next analysis
increment. phase.
Table 2 Pros and Cons of Iterative Model
P a g e | 11
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
Data flow diagrams and actual

One week flow in
database interaction
Utilities and tools required to

Three weeks user
interface implementation.
Modular completion of the

One week database
entities with actual scenario.
Development of web interface

Three Weeks 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
Analysis of existing
Task -1 Completion level system
with database design
Task -2 Data flow diagrams and

actual flow in database
interaction
Utilities and tools required

Task -3 to
user interface
implementation.
Task -3 Implementation Design of user interface

part 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 assessment.
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. Lack of analysis for change of requirements.
b. Change 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.
P a g e | 17
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
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 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:
Applicable cost in
Physical assets & rupees
deliverabl
es
Computer machines 50000
Optical
disks 500
Developing platform 5000
Office
goods 2000
Maintenance of
systems 5000
Internet/communicatio
n 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
Cost Very
Category Driver Low Low Nominal High Very Extra
High High
Product Required 0.75 0.88 1.00 1.15 1.40 -
Attributes Software
Reliability
Database - 0.94 1.00 1.08 1.16 -
Size
Product 0.70 0.85 1.00 1.15 1.30 1.65
Complexity
Computer Execution - - 1.00 1.11 1.30 1.66
Attributes Time
Constraint
Main - - 1.00 1.06 1.21 1.56
Storage
Constraint
Computer - 0.87 1.00 1.07 1.15 -
Turnaround
Time
Table 6 cost driver of
attributes
Cost
Category Driver Very Low Nominal High Very Extra
Low High High
Personnel Analyst 1.46 1.19 1.00 0.96 0.71 -

Attributes Capability
Application
s 1.29 1.13 1.00 0.91 0.82 -
Experience
Programme
r 1.42 1.17 1.00 0.86 0.70 -
Capability
Virtual 1.21 1.10 1.00 0.90 - -
Machine
Experience
Language 1.14 1.07 1.00 0.95 - -
Experience
Project Modern 1.24 1.10 1.00 0.91 0.82 -
Programmi
Attributes n
g Practices
Use of 1.24 1.10 1.00 0.91 0.83 -
Software
Tools
Testing
tasks 1.23 1.08 1.00 1.04 1.10 -
Table 7 cost driver of advance attributes
P a g e | 21
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 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 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 MANAGEMENT Request
Hostel
Information SYSTEM Fulfill
Figure 3 Context Level

Diagram
DFD LEVEL-1
DIAGRAMS:
1.0 Send Student
Registration Details Hosteler
Form Registration Receipts
STUDENT
Registration
2.0 Send Receipts FeePaymen

Account Update
Amount
Account
Details
3.0 Set room

Room allocated Room_data
Information Room
Allocation
Message Given
4.0
STUDENT
Information
Confirmation
Confirm flag
Figure 4 DFD level-1 diagram
P a g e | 27
DFD DIAGRAM FOR PROCESS 1.0(Student Admission process):
STUDEN Registration
T 1.1
Info Updated
Registration
as new user
Inquiry
Student/hosteller data 1.2 Submitted Form

Receive Hostel file
Acknowledgment Fill Account Response
Information
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
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
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
username User Id of Rector Person

Employee Name (Name Of
name Rector)
P a g e | 39
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
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

P a g e | 40
hosteler_approximate_te
rm 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_institu
te 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
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
The users table contains the information about the

Users 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.
Fees Table contains the details about student Fees

FeePayment 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
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 field
name description Type size null
Unique id as user
Username id Nvarchar(50) 50 Not allowed
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.
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 type size Null?

descriptio
n
User name
Username as Nvarchar(50) 50 Not
primary key allowed
hosteler_id Unique Id of nvarchar 10 Yes

hostelers
hosteler_name Student Nvarchar Max Yes

name/
name
of hostelers
Date of
hosteler_dob birth Date/time NA Yes
of hosteler
hosteler_room_no Room no of Int 8 Yes

allocated
room
hosteler_date_of_joini
ng joining date Date/time NA Yes
of hostelers
hosteler_purpose purpose of Nvarchar(50) 50 Yes

standout at
hostel
hosteler_approximate
_te Term / Nvarchar(50) 50 Yes
rm duration
Nvarchar(max
father_name name of ) max Yes
father
father_mob_no Mobile no of Double 10 Yes

father
Nvarchar(max
mother_name name of ) Max Yes
mother
P a g e | 44
Contact no
mother_mob_no of Double 10 Yes
mother
Nvarchar(max
hosteler_address Address of ) N Yes
hosteler
hosteler_email Email id of Nvarchar(50) 50 yes

hosteler
hosteler_working_insti
tu At where Nvarchar(50) 50 Yes
te hosteler
works
hosteler_mob_no Mobile Double 10 yes

number of
hosteler
Nvarchar(max
guardian_name Name of ) Max Yes
guardian
Nvarchar(max
guardian_address Address of ) Max Yes
guardian
guardian_mob_no Mobile Double 10 yes

number of
guardian
hosteler_fixed_deposit Deposited Int 8 Yes

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
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 4 Yes

Nvarcha
room_id Room Unique id r 10 Not null
room_typ Nvarcha
e Type of room r 10 Yes
Room belongs to which Nvarcha
building building r 50 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 5 Yes

inventory_charg Charges of
es inventory Double 7 yes
payment_date date of payment Date 10 Yes
total_paid Total paid money Double 50 Yes

amount
Remaining amount
due_payment to Double 10 Yes
be paid
P a g e | 46
Nvarcha
Username Unique Id of user r 10 Not
(Primary key) 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
User id of the account Nvarcha
Username holder r 20 Not
allowed
Name of the Nvarcha
Name administrator r 50 yes
Age Age of administrator Double 10 Yes

Nvarcha
Address Full Address of r N Yes
administrator
Phone Phone no of admin Double 10 Yes

Date_of_joi
n Joining date of admin Date 10 Yes
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.
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
Username User id of account Nvarcha Not
holder r 20 allowed
Name Nvarcha
Employee Name r 50 Yes
Age Age Double 6 Yes
Address Nvarcha
Address of emp r n Yes
Phone Mobile number of
employee number 10 Yes
Date_of_joi Joining date of
n employee date 10 Yes
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:
field
name Field description type size Null?
username Nvarcha
Unique user id of account r 20 Not
holder allowed
Password Password of user Nvarcha 20 Not
allowed
P a g e | 48
Name Nvarcha
Student / employee name r 50 yes
Contact_no Contact number of
account Double 10 Yes
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
name Field description type size Null?
Image_id Image id for each Nvarcha Not
image r 50 allowed
Image_Nam Nvarcha
e Name of the pic/ image r 50 Yes
Image Actual location of the Nvarcha Not
image r N allowed
Table 17 Image Details Table

Validations:
Primary Key: Image_Id
Reference Key: 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 above-mentioned 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 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
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 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.
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
Online Hostel Management
System
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 HMS

Uploaded by

Copyright:

Available Formats

Online HMS

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Online HMS

Uploaded by

Copyright:

Available Formats

A project report on

In partial fulfillment for the award of the

Under the guidance of

DEPARTMENT OF INFORMATION &

I hereby declare that this submission is my own work

Place : Rajkot, Gujarat Signature :

Date : Name : Dinesh

This is to certify that the report entitled Online

It is a bonafide record of the work carried out by

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

Examiner(s) Name and Signature:

the co-operation 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

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 advance 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

Figure Of Use Case With Reference To

Figure Of Use Case With Reference To Room

9 Figure Of Activity Diagram 32

Figure Of Class Diagram (Admin Access To

Figure Of Class Diagram (Hosteller Access To

12 Figure Of State Diagram 35

13 Figure Of Sequence Diagram 36

CHAPTER 2: PROJECT MANAGEMENT...7

CHAPTER 3: SYSTEM REQUIREMENT STUDY..22

CHAPTER 5: DATA DICTIONARY..37

CHAPTER 7: SCREEN SHOTS AND USER MANUAL.53

CHAPTER 8: FUTURE PLAN64

CHAPTER 10: REFERENCES & BIBLIOGRAPHY..66

This system is designed in favor of the hostel management

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