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.

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 Figure

Description

Page No.

No. 1

Iterative Model

9

2

Gantt Chart

13

3

Context Level Diagram

27

4

DFD Level-1 Diagram

27

5

DFD diagram for process

28

6

Use Case With Reference To Hosteller

29

7

Figure Of Use Case With Reference To Administrator/Rector

30

8

Figure Of Use Case With Reference To Room Allocation Procedure

31

9

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

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 SUMMARY……………………………………2 1.2 PROJECT PROFILE……………………………………….3 1.3 PURPOSE………………………………………………….4 1.4 SCOPE……………………………………………………...5 1.5 TECHNOLOGY AND LITERATURE REVIEW…………6 CHAPTER 2: PROJECT MANAGEMENT……………………...7 2.1 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.1 INPUT DESIGN…………………………………………..23 4.1.1 ADMINISTRATOR…………………..…………23 4.2 OUTPUT DESIGN..............................................................23 4.3 DATABASE DESIGN……………………………………24 4.4 ARCHITECTURAL DESIGN……………………………25 4.5 PROCESS DESIGN……………………………………....25 4.5.1 DATA FLOW DIAGRAMS (DFD)….………… 25 4.5.2 USE CASE DIAGRAMS.....…………………….28 4.5.3 ACTIVITY DIAGRAMS………………………. 32 4.5.4 CLASS DIAGRAMS …………………………...33 4.5.5 STATE DIAGRAMS …………………………...35 4.5.6 SEQUENCE DIAGRAMS……………………...36 CHAPTER 5: DATA DICTIONARY……………………………..37 5.1 DATA ELEMENTS………………………………………39 5.2 DATABASE DESCRIPTION……………………………42 CHAPTER 6: TESTING…………………………………………..50 CHAPTER 7: SCREEN SHOTS AND USER MANUAL……….53

CHAPTER 8: FUTURE PLAN……………………………………64 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 student’s 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 can’t 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 it’s 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.



Project’s 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 weren’t 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 that’s complete bullshit. Whether your server becomes unavailable due to hardware failure, coding errors or the inability to scale, the end result is that you’re down, and the people trying to access your application may never return.



Sometimes the actualization of the risk won’t 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, it’s 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 (student’s) 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 system’s 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 user’s 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 USER’S 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 Student’s every details like parents contact information, guardian information, and student’s 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

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 parent’s 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

8

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)

N

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

8

Yes

hosteler_image_id

Profile Image’s 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

4

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

5

Yes

inventory_charges

Charges of inventory

Double

7

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

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

6

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

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: 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: 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: 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: Reference Key:

Image_Id No reference key in this table.

P a g e | 49


6. TESTING 

Let’s 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 API’s 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 hostel’s 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 let’s 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 rector’s 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 rector’s 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

Recommend Documents