Project Report

ANALYSIS

SUPERVISOR: Dr. PREETI MARWAHA

SUBMITTED BY
XO-313 IBRAHIM BADUSHA

XO-335 RAVI YADAV

XO-321 MOHD. FARID

2019
Department of Computer Science
ACHARYA NARENDRA DEV COLLEGE
 ACKNOWLEDGEMENT

The submission of this project gives both of us an opportunity to convey our

gratitude to all those who have helped us reach a stage where we have im-
mense confidence to launch our career in the competitive world of information
technology.
We have no second thought in admitting that it is our respected Lecturers
who have played a significant role in shaping our career and we would be
miserably failing in our duty if we don’ extend our heart filled gratitude and
sincere acknowledgement to our project guide DR. Preeti Marwaha, who has
been a source of perpetual inspiration to us, gently guiding and paving our
way towards a bright career. Both were ever willing to give us all kind of
support and encouragement. We are also very thankful to both for being an
inspired project in charge and for providing necessary help throughout our
project work.

z RAVI YADAV IBRAHIM BADUSHA MOHD. FARID

1
 ACHARYA NARENDRA DEV COLLEGE
(University of Delhi)
CERTIFICATE
It is certified that all these Final year, Computer Science students of
Acharya Narendra Dev College have completed their project “HOTEL MAN-
AGEMENT SYSTEM” successfully on time. I found them sincere hardwork-
ing. Their performance during this project development period is excellent
I wish all of them successful carriers.

RAVI YADAV IBRAHIM BADUSHA MOHD. FARID

Supervisor Principal
DR. PREETI MARWAHA DR. RAVI TUTEJA
Contents

1 PROBLEM STATEMENT 5

2 PROCESS MODEL 6
2.1 WaterFall Model . . . . . . . . . . . . . . . . . . . . . . . . . 6

3 SOFTWARE REQUIREMENT SPECIFICATION 7

3.1 PURPOSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2 SCOPE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3 Overall Description . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3.1 Product Perspection . . . . . . . . . . . . . . . . . . . 8
3.3.2 Preliminary Requirement Analysis: . . . . . . . . . . . 8
3.4 BENEFITS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.5 User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.5.1 Hardware Interface . . . . . . . . . . . . . . . . . . . . 10
3.5.2 Software Interface . . . . . . . . . . . . . . . . . . . . . 10
3.6 Functional Requirements . . . . . . . . . . . . . . . . . . . . . 10
3.6.1 FR 1 Login Requirement . . . . . . . . . . . . . . . . . 10
3.6.2 FR 2 Registration Form Requirement . . . . . . . . . . 10
3.6.3 FR3 Room Booking . . . . . . . . . . . . . . . . . . . . 11
3.6.4 FR4 Accounts and Checkouts . . . . . . . . . . . . . . 11
3.6.5 FR5 Feedback form . . . . . . . . . . . . . . . . . . . . 12
3.7 Non Functional Requirement . . . . . . . . . . . . . . . . . . . 13

4 SCHEDULING 14

5 DESIGN 15
5.1 Architectural Design . . . . . . . . . . . . . . . . . . . . . . . 15
5.1.1 Level 0 DFD . . . . . . . . . . . . . . . . . . . . . . . 15
5.1.2 Level 1 DFD . . . . . . . . . . . . . . . . . . . . . . . 16
5.1.3 Level 2 DFD . . . . . . . . . . . . . . . . . . . . . . . 17
5.2 Component Level Design . . . . . . . . . . . . . . . . . . . . . 18

3
 5.3 Pseudocode for Email queries . . . . . . . . . . . . . . . . . . 18
5.3.1 Input: . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.3.2 Pseudo Code for mailing queries: . . . . . . . . . . . . 18
5.3.3 Output . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.4 Data Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

6 CODING 20
6.1 Code Snippet 1 (write name instead of Snippet 1) . . . . . . . 20
6.2 Code Snippet 2 (write name instead of Snippet 1) . . . . . . . 21

7 TESTING 22
7.1 Testing Approaches . . . . . . . . . . . . . . . . . . . . . . . . 22
7.2 TESTING STRATEGIES . . . . . . . . . . . . . . . . . . . . 24
7.2.1 UNIT TESTING . . . . . . . . . . . . . . . . . . . . . 24
7.2.2 Independent Paths . . . . . . . . . . . . . . . . . . . . 24
7.2.3 Computing Cyclomatic Complexity . . . . . . . . . . . 24
7.3 Test Suite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Chapter 1

PROBLEM STATEMENT

This project is HOTEL MANAGEMENT SYSTEM ; the main aim of this

project is gives the customer view of the hotel. The customer needs in hotel
are, enquiry about rooms,reservation process, vacating process, canceling the
reservation.

5
Chapter 2

PROCESS MODEL

The Waterfall Model was first Process Model to be introduced. It is very

simple to understand and use. In a Waterfall model, each phase must be
completed before the next phase can begin and there is no overlapping in
the phases. Waterfall model is the earliest SDLC approach that was used for
software development.

2.1 WaterFall Model

In “The Waterfall” approach, the whole process of software development is
divided into separate phases. The outcome of one phase acts as the input
for the next phase sequentially. This means that any phase in the devel-
opment process begins only if the previous phase is complete. The water-
fall model is a sequential design process in which progress is seen as flowing
steadily downwards (like a waterfall) through the phases of Conception, Initi-
ation, Analysis, Design, Construction, Testing, Production/Implementation
and Maintenance.

Figure 2.1: Phases of WaterFall Model

6
Chapter 3

SOFTWARE REQUIREMENT
SPECIFICATION

The following subsections of the Software Requirements Specifications (SRS)

document provide an overview of the entire SRS.

3.1 PURPOSE
The Software Requirements Specification (SRS) will provide a detailed de-
scription of the requirements for the Hotel Management System (HMS). This
SRS will allow for a complete understanding of what is to be expected of the
HMS to be constructed. The clear understanding of the HMS and its’ func-
tionality will allow for the correct software to be developed for the end user
and will be used for the development of the future stages of the project. This
SRS will provide the foundation for the project. From this SRS, the HMS
can be designed, constructed, and finally tested.
This SRS will be used by our team constructing the HMS and the hotel
end users. Team will use the SRS to fully understand the expectations of
this HMS to construct the appropriate software. The hotel end users will be
able to use this SRS as a “test” to see if the team will be constructing the
system to their expectations. If it is not to their expectations the end users
can specify how it is not to their liking and the team will change the SRS to
fit the end users’ needs.

7
3.2 SCOPE
The software product to be produced is a Hotel Management System which
will automate the major hotel operations. The first subsystem is a Reserva-
tion and Booking System to keep track of reservations and room availability.
The Second subsystem is a General Management Services and Automated
Tasks System which generates reports to audit all hotel operations and allows
modification of subsystem information. The system will be able to handle
many services to take care of all customers in a quick manner. The system
should be user appropriate, easy to use, provide easy recovery of errors and
have an overall end user high subjective satisfaction.

3.3 Overall Description

3.3.1 Product Perspection
The proposed system includes the explanation to the basic structure of the
system. Here we look in detail about how different requirements of the or-
ganization are accomplished. We also explain the structure of the system
about the usage of different options available for relevant people. We also
present a detail of the Software Engineering principles which basically is the
managerial theme for the development of software itself.

3.3.2 Preliminary Requirement Analysis:

This involves the collection of requirements which the project must fulfill.
This includes the following details.

1. We will require a database system. The database is a major need as

it interprets the requirement of storing the data chunks which need to
be managed according to proposed standards. The basic need here is
speed. As user always requires an efficient and fast system and the other
requirement is intact and crash free system. This can run without even
a single second of being down! It must fulfill the following requirements:

• Make Reservations for a Room.

• Store a data base for all kinds of reservations.
• Store payment details.
• Store Room and other. information.

8
 2. The other major requirement is interface. Interface enables the user
to make interactions and usage about the system. The system must
present an easy Graphical user interface because most of the users
usually are unaware with the use of such systems and complicating
them will restrict their usage in proper way this on one hand creates
problem for the hotel management and on the other hand is a problem
for the developer. The major strongholds kept in this regard are:

• Allow receptionist to Make Reservations.

• Allow receptionist to maintain the guest lists.
• Allow the receptionist to provide the user with bill payments.
• Allow the basic information access for general public.
• Allow online reservations for rooms with payment mechanism en-
sured.

3.4 BENEFITS
The system will have many benefits over the paper data used previously in
the world or some ordinary systems available around. A few of its important
benefits are listed below:

1. It provides privacy security of the data. Not everyone is allowed to

view every aspect of the system. Only concerned people can view their
relevant data base.

2. Security is ensured with the use of passwords on the admin side. Keep-
ing every employ restricted to his own domain so that interruption is
never heard around.

3. It provides speedy access along the databases. Usage of latest algo-

rithms enables data checking in seconds so that customer gets his an-
swers in without any waste of his time.

4. The chances of any mistake over the allotment of rooms/halls/tables

are reduced with the usage of record of every reservation saved and
checked over before making any reservations.

9
3.5 User Interface
The overall system includes the Software and the relevant hardware to deal
in the software. The System mainly requires the databases which are on the
software side and the hardware is general one.

3.5.1 Hardware Interface

The hardware requirements are simple and include PCs on which the internet
facilities will be available.

3.5.2 Software Interface

The software requirements basically include the DATABASES which are of
key importance of SRS. Here DATABASES will be included to save the data
about the ROOM reservations, Record of employs.The system will include a
feedback tab as well so that the customers can play their role in making the
hotel better.

3.6 Functional Requirements

The functional requirements involve all the functionality relevant require-
ments of the system. This includes all the functionality, from GUI on one
edge to Database handling on the other.
The Overall functionalities of the system are described below:

3.6.1 FR 1 Login Requirement

Purpose: Provides member authentication Inputs: Inputs are through the
keyboard and mouse clicks. Username Password Processing: The input is
verified by checking if the member already exists in the database. Outputs:
The correct input will result in the next page i.e Book the room. If the input
is incorrect then an error message will be displayed.

3.6.2 FR 2 Registration Form Requirement

Purpose: Registration of a non-member. Inputs: Inputs are through the
keyboard and mouse clicks. Last Name, First Name, Middle Name, Address,
City, BirthDate, Age, Sex, Nationality, Status, ... Processing: The input is
validated using client side as well as server side validation. The client side

10
validation will include checks for missing information in the required fields
and other text fields like address, birthdate etc. will be checked for validity.
The server side validation will involve checking if the username entered is
already used by a member in the database. The appropriate error messages
are displayed if the input is not acceptable Outputs: New member is directed
to the main page on successful registration.

3.6.3 FR3 Room Booking

1. The System is able to allow reservations of Room from internet via
the functionality named as e-reservations. The Customers on the other
hand are allowed to make reservations on Front Desk as well.

2. The Reservations For ROOM involve the arguments like:

• Record Customers Name.

• Record Customers Requested Room Number. This function then
check the availability of Room, if the room is not available the
system will prompt to make some other choice for the room.
• The system will demand users Telephone number to ensure contact
with the user.
• For better, Front Desk can also assign the Rooms for those with
no choice of room number.

3.6.4 FR4 Accounts and Checkouts

The billing is done by the Accounts department. This department works out
with the following functionality:

1. The records for Room reservations are checked by this department to

make out the money. For Room Reservations the department takes the
name of the user as an input and the record for the ROOM RESERVA-
TIONS is checked,if the name is found, then the period for stay, type
“ROOM” or “SUITE” is checked. After checking the list, Bill is made
for the ROOM and displayed on the checkout screen of the FRONT
DESK ALONE! And the staff member available there, then prints out
the bill using print command.

2. Once the billing for the ROOM is done an archive file for each is main-
tained for each and the reservation list is emptied for the name.

11
 3. The Billings list for past and due billings can be checked from the
ACCOUNTS department. The hotel manages the billing information
inside the class with its separate database.

3.6.5 FR5 Feedback form

A Feedback tab will be available for any customer or online visitor to make
comments on the Hotel which are made available to the entire admin block.

12
3.7 Non Functional Requirement
1. The website should be speedy and it must fulfill its required operations
very fast.

2. It should maintain a proper security guide so that there are no issue of

privacy and leakage of any customer relevant private data which is not
allowed to publicize due to laws.

3. Most importantly the website must give the outputs correct. I.e. the
functions must work properly and all the related outputs should be
correct and in-time.

4. The design should be portable and capable of working in multiple op-

erating environments to ease users.

5. Error and pop-up commands should inform the user about the statistics
of some function being performed.

13
Chapter 4

SCHEDULING

Describe Gantt Chart

modify the following Gantt Chart to suit your project

Figure 4.1: Gantt Chart for Project Schedule

14
Chapter 5

DESIGN

Engineering Design is the process of devising a system, component or process

to meet the desired needs. It s a decision making process (often iterative), in
which the basic science and mathematics and engineering sciences are applied
to convert resources optimally to meet a stated objective.

5.1 Architectural Design

content

5.1.1 Level 0 DFD

Figure 5.1: Level 0 DFD

15
5.1.2 Level 1 DFD

Figure 5.2: Level 1 DFD

16
5.1.3 Level 2 DFD
if required

Figure 5.3: Level 2 DFD

17
5.2 Component Level Design
Component level design establishes the algorithmic detail required to manip-
ulate data structures, effect communication between software components via
their interfaces, and implement the processing algorithms allocated to each
component. Component level design, also called procedural design, occurs
after data, architectural, and interface designs have been established. The
intent is to translate the design model in to operational software. But the
level of abstraction of the existing design model is relatively high, and the
abstraction level of the operational program is low.
There will be multiple structure charts, based on code flow you need to
implement. Select the FR you are implementing and write it’s structure
chart(s)

Figure 5.4: structure chart for email

5.3 Pseudocode for Email queries

5.3.1 Input:
email id, password, file (optional)

5.3.2 Pseudo Code for mailing queries:

If selected mailing queries Ask for the app for mailing Ask for the user email
id Ask for the password While (user email and user id is correct) Ask to
enter the subject of the mail Also enter the text body of the query If(selected
equals attach file) Attach the particular file Else Do nothing Send the mail
End if

5.3.3 Output
: email sent status- Success or Failure

18
5.4 Data Design
Data design translates the data objects defined in the analysis model in to
data structures that reside within the software. The attributes that de-
scribe the object, the relationship between data objects and their use within
the program all influence the choice of data structures. At a higher level
of abstraction, data design may lead to the definition of architecture for a
database.

Table 5.1: Data Design for Sending Email

Name Type Width Remark
UserId Integer 7 Only integer value
Password Alphanumeric Min 8 chara At least:1 special char, 1 int value

a
a= b
a
a= (5.1)
b

19
Chapter 6

CODING

content: insert code snippets screenshots of major input and output flows

6.1 Code Snippet 1 (write name instead of

Snippet 1)
content

20
6.2 Code Snippet 2 (write name instead of
Snippet 1)
content

21
Chapter 7

TESTING

Software design is a critical element of software quality assurance and repre-

sents the ultimate review of specification, design and code generation. Once
the source code has been generated, the software must be tested to uncover
as many errors as possible before delivery to the customer. Our goal is to
design a series of test cases that have a high likelihood of finding errors. . If
testing is conducted successfully, it will uncover errors in the software. As
the secondary benefits, testing demonstrates that software functions appear
to be working according to specification, that behavioral and performance
requirements appear to have been met. The software can be tested by one
of the two ways: Knowing the specified function that a product has been
designed to perform, tests can be conducted that demonstrate each function
is fully operational while at the same time searching for errors in each func-
tion. Knowing the internal working of the product, tests can be conducted to
ensure that internal operations are performed according to specifications and
all internal components have been adequately exercised. The first approach
is called black – box testing and the second, white – box testing.

7.1 Testing Approaches

• White Box Testing White box testing is a test case design method
that uses the control structural of the procedural design to derive test
cases. It is also called glass box testing. Using this method we can
derive test cases that- Guarantee that all independent paths within a
module have been exercised at least once. Exercise all logical decisions
on their true and false sides Executes all loops at their boundaries and
within their operational bounds. Exercise internal data structures to
ensure their validity.

22
• Black Box Testing Black – box testing focuses on the functional re-
quirements of the software i.e. it enables the software engineer to derive
sets of input conditions that will fully exercise all functional require-
ments for a program. It is also called behavioral testing. Black–box
testing attempts to find errors in the following categories:- Incorrect or
missing functions Interface errors Initialization and termination errors.

23
7.2 TESTING STRATEGIES
Designing effective test cases is important but so is the strategy we use to
execute them. There are a number of testing strategies, which have the fol-
lowing generic characteristics: - Testing begins at the component level and
works “outward” toward the integration of the entire computer–based sys-
tem. Different testing techniques are approximate at different points in time.
Testing is conducted by the developer of the software and (for large projects)
an independent test group. Testing and debugging are different activities,
but debugging must be accommodated in any testing strategy. The software
engineering process may be viewed as a spiral. Initially, system engineer-
ing defines the role of software and leads to software requirement analysis
where the information domain, function, behavior, performance, constraints
and validation criteria for software are established. Moving inward along the
spiral, we come to the design and finally to coding. There are a number of
testing strategies, which are given below: -

7.2.1 UNIT TESTING

In the unit testing interfaces, local data structures, boundary conditions,
independent paths, error handling paths are tested. Test cases should be
design to uncover errors due to erroneous computations, incorrect compar-
isons, or improper control flow. For this purpose basis path and loop testing
is done. After source level code has been developed, reviewed and verified
for correspondence to component level design, unit test case design begins.
In unit test application ‘drivers’ are developed which are programs, accept
test case data, passes such data to the component to be tested and prints
relevant results. ‘Stubs’ are also developed which serve to replace modules
that are subordinate the component to be tested.

7.2.2 INTEGRATION TESTING

Integration testing is systematic technique for constructing the program
structure while at the same time conducting the tests to uncover errors as-
sociated with interfacing. The objective is to take unit tested components
and build a program structure that has been dictated by design. There are
two types of integration – Bottom up integration and Top down integration.
Regression and smoke testing are done in integration testing strategy.

24
7.2.3 VALIDATION TESTING
Next step is the validation testing where requirements established as part
of software requirements analysis are validated against the software that has
been constructed. At the culmination of integration testing, software is com-
pletely assembled as a package, interfacing errors has been uncovered and
corrected, and a final series of software tests i.e. validation testing begins.

25