Online Hotel Management System

Submitted by:
Names Registration No
Muhammad Adnan 2019-UKT-006227
Abdul Qadeer 2019-UKT-006238

Class:
BS CS (2019-23)

Supervised by:
Dr Waqar Hussain

Department of Computer Science

Faculty of computing and engineering
 University of Kotli Azad Jammu and Kashmir
FINAL APPROVAL
It is certified that we have reviewed the project report prepared for “Online Hotel
Management System” and it is our judgment that this project is of sufficient standard
to warrant its acceptance by the University of Kotli Azad Jammu and Kashmir for
BS Computer Science as a partial fulfilment. This project is submitted by
Muhammad Adnan, registration number 2019-UKT-006227, Abdul Qadeer ,
registration number 2019-UKT-006238.
Committee

Supervisor
Dr Waqar Hussain
Lecturer
Department of Computer Science Sign:_______________________
Faculty of Computing & Engineering
University of Kotli AJK

External Examiner

Dr. Muhammad Munawar Iqbal

Assistant Professor Sign:____________________
Department of Computer Science
University of Engineering and Technology (UET), Taxila,
Punjab Pakistan

Chairman
Dr Asif Kabir
Lecturer
Department of Computer Science Sign:_______________________
Faculty of Computing & Engineering
University of Kotli AJK

Dean
Prof. Dr. Ghulam Nabi
Faculty of Computing & Engineering Sign: ______________________
University of Kotli AJK
 DECLARATION
We declare that this system, neither as a whole nor as a part has been copied
from any other source. It is further declared that we have completed our project
entirely on the basis of our personal effort made under the sincere guidance of our
teachers. No portion of the work presented in this report has been submitted in
support of any application for any other degree or qualification of this or any other
university or institute of learning. If any part of this project and write up is proved to
be copied out or there is any duplication of code, then will be responsible for the
consequences.

Muhammad Adnan: ______________

Abdul Qadeer: ______________

 ABSTRACT
Our aim is to develop “Online Hotel Management System" is a Web based
application system that to accommodate the tourist in a big challenge in the terrify of
Kotli where large number of Hotels are available but because of poor management
tourism is badly compromised. To runs the hotel management that is the primary need
of any tourist there should a computerize & and digital system to provide the
residence access at doorstep of any tourist. To manage the tourist accommodation of
tourist we will develop an online web based responsive system to management
hoteling in Kotli AJK. This system is developing to automate day to day activity of a
restaurant. Restaurant is a kind of business that serves people all over world with
ready-made food. This system can be used by employees in a hotel to handle the
owner, their orders and can help them easily find free rooms, tables, or place orders.
The services that are providing is food ordering and reservation table management by
the customer through the system online, customer information management and
waiter information management, menu information management and report. The
restaurant menu is organized by categories (appetizers, soups, salads, entrees, sides,
drinks etc) of menu items. Main objectives develop the system this is to provide
ordering and reservation service by online to the customer.

iv
 ACKNOWLEDGEMENT
All the praise and glory to Allah, who has blessed us with the courage and
knowledge to achieve our goal. We can never thank Him enough for His countless
blessings upon us. Praise to Prophet Mohammad (S.A.W), who is and will always
be a source of guidance and knowledge for humanity.
For us, a milestone of this nature would never have been possible to achieve
without the support of galaxy of some truly loving and kind people in our life. No
words can fully describe our feelings of respect and gratitude for our affectionate
parents, supporting sibling and friends, whose love, encouragement, and prayers
invariably buoyed us up. Their concern, love and support can never be paid back.
We owe a lot of sincere gratitude to our respected supervisor Dr Waqar
Hussain, whose true guidance, positive criticism, and sincere encouragement made
us to get to our destination. He became a source of inspiration for us and kept us
moving in the right direction towards our goal.

Muhammad Adnan
Abdul Qadeer

v
 PREFACE
This report presents a description of the analysis, design, implementation, and

testing of the "Online Hotel Management System" developed is to provide ordering

and reservation service by online to the customer. These chapters include the steps

involved in the study to develop; a brief description of these chapters is given below:

Chapter 1: This chapter contains the introduction of the concerned organization and

the project.

Chapter 2: This chapter contains the description of the requirements specification.

Chapter 3: This chapter is about system design.

Chapter 4: This chapter is about project management.

Chapter 5: This chapter is about implementation.

Chapter 6: This chapter is about system testing.

Chapter 7: This chapter is about Software Testing for the Measurements of Its

Correctness.

Chapter 8: This Chapter is about Conclusions, Limitations and Recommendations.

Chapter 9: This chapter is about Appendices and References.

vi
 TABLE OF CONTENTS
FINAL APPROVAL.................................................................................................................ii
DECLARATION..........................................................................................................................iii
ABSTRACT................................................................................................................................iv
ACKNOWLEDGEMENT...............................................................................................................v
PREFACE...................................................................................................................................vi
Chapter 1..................................................................................................................................1
1 INTRODUCTION......................................................................................................................1
1.1 Purpose...........................................................................................................................1
1.2 How will it work?............................................................................................................1
1.3 System Conception.........................................................................................................1
1.3.1 Who is the application for?..............................................................................................1
1.3.2 What problems will it solve?............................................................................................1
1.3.3 Where will it be used?.....................................................................................................2
1.3.4 When is it needed?..........................................................................................................2
1.4 Software Process Model.................................................................................................2
Chapter 2..................................................................................................................................3
2 SYSTEM REQUIREMENT SPECIFICATION................................................................................3
2.1 System Requirements Specification.................................................................................3
2.2 Functional Requirements................................................................................................3
2.3 Non-Functional Requirements........................................................................................4
2.3.1 Security Requirements.....................................................................................................4
2.3.2 Software Quality Attributes.............................................................................................4
2.3.3 Product Requirements.....................................................................................................4
2.3.4 Organizational Requirements..........................................................................................5
2.3.5 External Requirements....................................................................................................5
2.4 System Features..............................................................................................................5
2.4.1 User information..............................................................................................................6
2.4.2 Response Sequences........................................................................................................6
2.4.3 System Architecture........................................................................................................6
2.4.4 System Evolution.............................................................................................................6
2.5 Other Non-functional Requirements..............................................................................6
2.6 Performance Requirements............................................................................................6
2.7 Safety Requirements.......................................................................................................7
2.8 Security Requirements....................................................................................................7
vii
 2.9 Software Quality Attributes............................................................................................7
2.10 Business Rules...............................................................................................................7
Chapter 3..................................................................................................................................8
3 SYSTEM DESIGN.....................................................................................................................8
3.1 System Design.................................................................................................................8
3.1.1 Class Model......................................................................................................................8
3.2 Class Diagram..................................................................................................................8
3.3 Use Case Diagram.........................................................................................................10
3.3.1 Booking..........................................................................................................................11
3.3.2 Logout............................................................................................................................11
3.3.3 Booking..........................................................................................................................12
3.3.4 Select Services...............................................................................................................12
3.3.5 Payment.........................................................................................................................13
3.3.6 Notification....................................................................................................................13
3.4 Sequence Model...........................................................................................................14
3.4.1 Scenarios........................................................................................................................14
3.4.2 Sequence Diagrams.......................................................................................................14
3.4.3 Sequence Diagram for login...........................................................................................14
3.4.4 Sequence Diagram for Make Booking............................................................................15
3.4.5 Sequence Diagram for Log Out......................................................................................15
3.5 Activity Diagram............................................................................................................16
3.5.1 Activity Diagram for Login..............................................................................................16
3.5.2 Activity Diagram for Make Booking...............................................................................17
Chapter 4................................................................................................................................19
4 SOFTWARE PROJECT MANAGEMENT...................................................................................19
4.1 Project Management Techniques.................................................................................19
4.2 Work Breakdown Structure for TSR..............................................................................19
4.3 Gantt chart:...................................................................................................................19
4.3.1 Critical Path Method:.....................................................................................................20
4.3.2 Activity on Node diagram..............................................................................................21
4.3.3 Critical Path Method......................................................................................................21
4.3.4 Paths..............................................................................................................................21
4.3.5 Time Period:..................................................................................................................21
4.4 Total Cost:.....................................................................................................................22
4.5 Productivity..................................................................................................................22

viii
 4.6 Resources we used.......................................................................................................22
4.7 Hardware......................................................................................................................22
4.8 Software........................................................................................................................23
Chapter 5................................................................................................................................24
5 PROJECT IMPLEMENTATION................................................................................................24
5.1 Framework....................................................................................................................24
5.2 Hardware Requirements...............................................................................................24
5.3 Software Requirements................................................................................................24
Chapter 6................................................................................................................................26
6 SOFTWARE TESTING............................................................................................................26
6.1 Introduction..................................................................................................................26
6.2 Psychology of Testing..................................................................................................26
6.3 Testing Objective..........................................................................................................26
6.4 The Box Approach........................................................................................................26
6.4.1 White Box testing..........................................................................................................27
6.4.2 Black Box testing............................................................................................................27
6.5 Levels of Testing..........................................................................................................28
6.6 Unit Testing..................................................................................................................28
6.7 Integration Testing........................................................................................................28
6.8 System Testing..............................................................................................................28
6.9 Alpha Testing...............................................................................................................29
6.10 Beta Testing................................................................................................................29
6.11 Acceptance Testing.....................................................................................................29
6.12 Interface Testing.........................................................................................................29
Chapter 7................................................................................................................................30
7 SOFTWARE TESTING FOR THE MEASUREMENTS OF ITS CORRECTNESS..........30
7.1 Testing..........................................................................................................................30
7.2 Development Testing....................................................................................................30
7.3 Unit Testing...................................................................................................................31
7.4 Components Testing.....................................................................................................31
7.5 System Testing..............................................................................................................32
7.6 User Testing..................................................................................................................32
7.7 Test Cases.....................................................................................................................33
7.7.1 Test Case for Signup.......................................................................................................33
7.7.2 Test Case for Login.........................................................................................................34

ix
7.7.3 Test Case for Logout......................................................................................................35
Chapter 8................................................................................................................................35
8 CONCLUSIONS, LIMITATIONS AND RECOMMENDATIONS....................................35
8.1 Conclusion....................................................................................................................35
8.2 Future Improvements...................................................................................................35
8.3 Limitations....................................................................................................................36
Chapter 9................................................................................................................................37
9 APPENDICES AND REFERENCES............................................................................................37
9.1 Appendices...................................................................................................................37
9.2 Glossary........................................................................................................................37
9.3 References:...................................................................................................................37

x
 LIST OF FIGURES
Figure 1: Spiral Process Model..............................................................................................2
Figure 2: Class Diagram of Online Hotel Management System..........................................9
Figure 3: Use Case Diagram of Online Hotel Management System..................................10
Figure 4: Sequence Diagram for Login...............................................................................15
Figure 5: Sequence Diagram for Make Booking................................................................15
Figure 6: Sequence Diagram for logout..............................................................................16
Figure 7: Activity diagram for Login..................................................................................17
Figure 8: Activity Diagram for Make Book........................................................................18
Figure 10: Gantt chart..........................................................................................................20
Figure 11: AON Network Diagram.....................................................................................21
Figure 12: Critical Path Method..........................................................................................21
Figure 13: White Box Testing..............................................................................................27
Figure 14: Black Box Testing...............................................................................................27

LISTS OF TABLES
Table 1: Use Case Description for User Login............................................................12
Table 2: Use Case Description for User Logout..........................................................12
Table 3: Use Case Description for Booking................................................................13
Table 4: Use Case Description for Select Service.......................................................14
Table 5: Use case Description for Payment.................................................................15
Table 6: Use Case Description for Notification...........................................................16
Table 7: Work Breakdown Structure...........................................................................23
Table 8: Network Table...............................................................................................24
Table 9: Hardware Requirement for Project................................................................28
Table 10: Software Requirements................................................................................29
Table 11: Test Case for Signup....................................................................................38
Table 12: Test Case for login.......................................................................................38
Table 13: Test case for Booking.................................................................................39
Table 14: Test Case for Logout....................................................................................39
Table 15: Glossary.......................................................................................................41

xi
 Chapter 1
1 INTRODUCTION
This chapter describes the existing system and the proposed system in details.
What problems we were facing in the existing system, due to which we are going to
atomize our system, are described here? What functionality our system will provide,
is described here.

1.1 Purpose
The purpose of this project is to develop an Online Hotel Management
System that streamlines hotel operations, enhances user experience, and optimizes
the management of reservations, customer information, billing, and other crucial
aspects of hotel management.

1.2 How will it work?

The Online Hotel Management System will operate as a web-based
application accessible to both hotel staff and customers. The system will allow users
to make reservations, view room availability, manage bookings, handle billing,
generate reports, and provide a seamless communication platform between hotel
staff and guests.

1.3 System Conception

This section outlines the fundamental concepts of the application.

1.3.1 Who is the application for?

The application primarily targets hotel owners, managers, staff, and guests.
Hotel owners and managers will benefit from improved operational efficiency, while
staff will have better control over reservations and customer service. Guests will
experience a more convenient and user-friendly booking process.

1.3.2 What problems will it solve?

The application aims to address common challenges in hotel management,
including manual booking processes, inefficient record-keeping, data redundancy, and
communication gaps between hotel staff and guests. By solving these issues, the
system intends to enhance the overall hotel management experience.

1
1.3.3 Where will it be used?
The application will be used in various hotel establishments, ranging from
small bed-and-breakfasts to large luxury hotels. It is designed to accommodate
different scales of operations and tailor its features to the specific needs of each
establishment.
1.3.4 When is it needed?
Given the growing demand for online and efficient hotel management
solutions, the application is needed now more than ever. The digital transformation in
the hospitality industry requires effective, centralized systems to meet the demands of
modern guests and optimize hotel operations.
1.4 Software Process Model
For this project, we have chosen the Spiral Model for software development. The Spiral
Model allows for flexibility and accommodates changes as the project progresses, making it
suitable for complex and evolving projects like an online hotel management system . For this
project we will follow iterative waterfall process model, because of clear and
unchanging business requirements as shown in Figure 1.

Figure 1: Spiral Process Model

2
 Chapter 2
2 SYSTEM REQUIREMENT SPECIFICATION
2.1 System Requirements Specification
System requirements are more detailed descriptions of the software system’s
functions, services, and operational constraints. The system requirements document
(sometimes called a functional specification) should define exactly what is to be
implemented. It may be part of the contract between the system buyer and the
software developers.

2.2 Functional Requirements

These are statements of services the system should provide, how the system
should react to inputs, and how the system should behave in particular situations. In
some cases, the functional requirements may also explicitly state what the system
should not do. The functional requirements for a system describe what the system
should do. The System Requirements Specification (SRS) provides a comprehensive
overview of the functional and non-functional requirements that the Online Hotel
Management System must meet.
This section describes the functional requirements of the system.
1. User Management:
 Users should be able to register, log in, and manage their profiles.
 Differentiate between staff and guest roles.
2. Reservation Management:
 Allow guests to view room availability and make reservations.
 Enable staff to manage reservations, check-in, and check-out processes.
3. Billing and Invoicing:
 Calculate bills based on room rates and additional services.
 Generate invoices and receipts for guests.
4. Reporting:
 Provide various reports for management, including occupancy, revenue, and
guest feedback.

3
2.3 Non-Functional Requirements
Non-functional requirements are not directly concerned with the specific
services delivered by the system to its users. They may relate to emergent system
properties such as reliability, response time, usability and store occupancy.

Non-functional requirements, such as performance, security and availability

usually specify or constrain characteristics of a system as a whole. There are
following types of Non-functional requirements.

2.3.1 Security Requirements

A security requirement is a statement of needed security functionality that
ensures one of many different security properties of software is being satisfied.
Security requirements are derived from industry standards, applicable laws, and a
history of past vulnerabilities. No one can hack our system and control it.

2.3.2 Software Quality Attributes

 Reliability:
a. The system should be available 24/7 with minimal downtime.
b. Ensure accurate and consistent data processing.
 Usability:
a. Design an intuitive user interface for easy navigation and use.
b. Provide clear instructions and help features.
2.3.3 Product Requirements
These requirements specify or constrain the behaviour of the software.
Examples include performance requirements on how fast the system must execute and
how much memory it requires, reliability requirements that set out the acceptable
failure rate, security requirements, and usability requirements.

In our system minimal navigation through will make its performance better. It
is not an embedded system so memory is not a big issue for our system, as memory
has become very cheap now days. We are providing a user-friendly interface and our
system will be guiding the user at every step of performing some tasks. Our system
will be reliable as we are handling exceptions in our system. To deal security issues
we are using user name and password for security purposes.

4
2.3.4 Organizational Requirements
These requirements are broad system requirements derived from policies and
procedures in the customer’s and developer’s organization. Examples include
operational process requirements that define how the system will be used,
development process requirements that specify the programming language, the
development environment or process standards to be used, and environmental
requirements that specify the operating environment of the system.
For development we are using these tools:

Development Tools: Visual Studio

Programming Language: C#, SQL , CSS, Java & HTML.

2.3.5 External Requirements

External Requirements are those Requirement elements that have been
connected to the current element using a Realization connector. By creating the
connector from the element to the Requirement, you create an expectation that the
element must implement the requirement as part of the system solution.

2.4 System Features

Features are the “tools” you use within a system to complete a set of tasks or
actions. Functionality is how those features actually work to provide you with a
desired outcome. For example, a basic requirement for most boarding schools is the
ability to customise leave types. System Feature describe the system and how it will
function to help with a user’s task.

System Software include the following features.

High speed. System software must be as efficient as possible to provide an effective
platform for higher-level software in the computer system.
Hard to manipulate: It often requires the use of a programming language, which is
more difficult to use than a more intuitive user interface (UI).
Written in a low-level computer language: System software must be written in a
computer language the central processing unit (CPU) and other computer hardware
can read.
Close to the system: It connects directly to the hardware that enables the computer to
run.

5
Versatile: System software must communicate with both the specialized hardware it
runs on and the higher-level application software that is usually hardware-agnostic
and often has no direct connection to the hardware it runs on. System software also
must support other programs that depend on it as they evolve and change.

2.4.1 User information

The user must login or signup to the system for service confirmation with his
name, last name, CNIC, address, contact number, confirmation then proceed to
payment.

2.4.2 Response Sequences

The user can login or signup to the system after that the system will response
to the user for payment, confirmation of the service.

2.4.3 System Architecture

System architecture or systems architecture is the conceptual model that
defines the structure, behaviour, and more views of a system. An architecture
description is a formal description and representation of a system, organized in a way
that supports reasoning about the structures and behaviours of the system.

2.4.4 System Evolution

This section describes the fundamental assumptions on which the system is
based, and any anticipated changes due to hardware evolution, changing user needs,
and so on. This section is useful for system designers as it may help them avoid
design decisions that would constrain likely future changes to the system.

2.5 Other Non-functional Requirements

Non-functional requirements define system attributes such as security,
performance, safety. They serve as a constraints or restrictions on the design of the
system across the different backlogs.

2.6 Performance Requirements

The system must be interactive, and the delays involved must be less. So, in
every action response of the system, there are no immediate delays. Performance
requirements define how well the software system accomplishes certain functions
under specific conditions. Examples include the software's speed of response,

6
throughput, execution time and storage capacity. The service levels comprising
performance requirements are often based on supporting end-user tasks.

2.7 Safety Requirements

If there is extensive damage to a wide portion of the database due to
catastrophic failure, such as a disk crash, the recovery method restores a paste copy of
the database that was backed up to archival storage and reconstructs a more current
state by reapplying or reasoning the operations of committed transactions from the
backend-up log, up to time of failure.

2.8 Security Requirements

Security systems need database storage just like many other applications.
However, the special requirements of the security market mean that vendors must
choose their database partner carefully.

2.9 Software Quality Attributes

 Availability
 Maintainability
 Usability
 Correctness
 Reliability

2.10 Business Rules

For operating website, the user must be familiar with web-based system and for
using android app user must have android operating system and should be familiar
with it. The admin can confirm user reserved service after checking user’s full details,
user can reserve services.

7
 Chapter 3
3 SYSTEM DESIGN
3.1 System Design
Design is the first step in the development phase for any engineered product or
system. The designer’s goal is to produce a model or representation of a class that will
later be built. Beginning, once system requirement has been specified and analysed,
system design is the first of the three technical activities -design, code and test that is
required to build and verify software. This document details out the overall software
design.

During design, progressive refinement of data structure, program structure, and

procedural details are developed reviewed and documented. System design can be
viewed from either technical or project management perspective. From the technical
point of view, design is comprised of four activities – architectural design, data
structure design, interface design and procedural design.

3.1.1 Class Model

The class diagram is the main building block of object-oriented modelling. It is
used both for general conceptual modelling of the systematic of the application, and
for detailed modelling translating the models into programming code. Class diagrams
can also be used for data modelling. The classes in a class diagram represent both the
main objects, interaction in the application and classes to be programmed.
In the diagram, classes are represented with boxes which contain three parts.
• The upper part holds name of the class.
• The middle part contains the attributes of the class.
• The bottom part gives the methods or operations the class are take or
undertake.

After the identification of classes their attributes and the relationships among them
our class diagram is given above.

3.2 Class Diagram

Class diagrams provide a graphic notation for modelling classes and their
relationships thereby describing possible objects. Class diagrams are useful both
abstract modelling and for designing actual programs. They are concise, easy to
8
understand, and work well in practice. We will use class diagrams throughout this
book to represent the structure of applications. Class diagrams are useful in many
stages of system design as shown in Figure 2.
Figure 2: Class Diagram of Online Hotel Management System

9
3.3 Use Case Diagram
A system involves a set of use cases and a set of actors. Each use case
represents a slice of the functionality the system provides. The set of use cases shows
the complete functionality of the system at some level of detail. Similarly, each actor
represents one kind of object for which the system can perform behaviour. The set of
actors represents the complete set of objects that the system can serve. Objects
accumulate behaviour from all the systems with which they interact as actors. This
system involves a set of use cases like make a login, add record, and detection as
shown in Figure 3.

Figure 3: Use Case Diagram of Online Hotel Management System

10
3.3.1 Booking
This use case starts when an actor wishes to log into the System. The system
requests the actor to enter his/her details. The actor enters his/her name and password.
The system then validates the entered credentials and logs the actor into the system as
shown in Table 1.

Table 1: Use Case Description for User Login

Use Case Name Login

Summary Only Admin, can login to his respective panels to use his
relative services.
Actor Admin and Customer
Precondition The system is launched, and login pages are waiting to get login
details.
Post Condition After the successful login operation admin will be able to
navigate to his respective panels.
Description The administrator will provide email and password so he can
login in to their relative panels.
Exceptions Login validations: if admin provides wrong login information
Online hotel management will deny the access showing an error
message of invalid email or wrong password.

3.3.2 Logout
This use case starts when an actor wishes to log out of the System. The system
then performs the action of checking that which actor is wishing to logout from the
system by validating the credentials of that actor. The process is shown in Table 2.

Table 2: Use Case Description for User Logout

Use Case Name Logout

Administrator can logout to his respective panels after using their
Summary
relative services.
Actor Administrator, and customer
The system is launched, and administrator, of online hotel
Precondition
System services form his respective panels.

11
 Post Condition After the successful logout.

Administrator will click on the “Logout” button after completing

Description
their sessions
Exit: if the administrator presses the exit or Alt+F4 before
Exceptions clicking on the “logout” button, system will be closed.

3.3.3 Booking
This use case starts when an actor wishes to book a room. The process is
shown in Table 3.
Table 3: Use case description for Booking

Use Case Name Booking

Summary Customer will visit site and making booking

Actor Customer
When customer visit from his respective account they will go the
Description home page then select the Book know option and then filling
specific fields and press the booked know to make booking.

3.3.4 Select Services

This use case starts when an actor want to add special service . The system
requests the actor to enter his/her name and room number. The actor enters his/her
credentials. The system validates the entered name and room number and logs the
actor into the system and then as shown in Table 4.

Table 4: Use case description for Select Services

Use Case Name Add car

Users visit the site and and book room after that he can select
Summary
specific services.
Actor User
The system will ask for book first, to enter service page and there
Precondition
should be add Service.

12
3.3.5 Payment
This use case starts when an actor wishes to log out of the room and make
payment the process shown in table 5 below.

Table 5: Payment

Use Case Name Payment

User can make payment of room and the services he can take.
Summary

Actor User

3.3.6 Notification
This use case starts when a person places an order for the cab, the person can
view and locate the cab with the notification bar of the device as shown in Table 6.

Table 6: Use case description for notification

Use Case Name Notification

User can view notification on place order detail with his
Summary
account. System will use the IP address to remember his name.
Actor Admin and User

Precondition The system will not ask for login first to enter home page

Post Condition Message will be shown comment has been submitted

successfully.
When user will see the visiting place at the visiting place page
then he can view all visiting places then open anyone place
Description
detail by clicking on view detail button to see detail of place the
he submit a comment on it.
Wrong email or password: if the admin enters a wrong
password or email the system will ask for valid email and
Exceptions
password. Sing out: If client/lawyer presses the sign out button
without comments, the system will return back to index form.
Back to Home: if the lawyer/client presses the back to home
button without comments, system will return to home.

13
3.4 Sequence Model
The sequence model showcases the interactions between different components of
the system in various scenarios.

3.4.1 Scenarios
A scenario is a sequence of the events that occurs during one particular
execution of a system such as for a use case. The scope of a scenario can vary; it
may include all events in the system or it may include only those events impinging
on or generated by certain objects. A scenario can be the historical record of
executing an actual system or a thought experiment of executing a proposed
system. A scenario can be displayed as a list of text statements. A scenario contains
messages between objects as well as activities performed by objects. Each message
transmits information from one object to another.

3.4.2 Sequence Diagrams

A sequence diagram is a Unified Modeling Language (UML) diagram that
illustrates the sequence of messages between objects in an interaction. A sequence
diagram consists of a group of objects that are represented by lifelines, and the
messages that they exchange over time during the interaction. It is used primarily to
show the interactions between objects in the sequential order that those interactions
occur. Much like the class diagram, developers typically think sequence diagrams
were meant exclusively for them. A sequence diagram simply depicts interaction
between objects in a sequential order i.e. the order in which these interactions take
place.

3.4.3 Sequence Diagram for login

A sequence diagram is a Unified Modelling Language (UML) diagram
consists of a group of objects that are represented by lifelines, and the messages that
they exchange over time during the interaction. It is used primarily to show the
interactions between objects in the sequential order that those interactions occur. The
system validates the entered name and password and logs the actor into the system as
shown in Figure 4.

14
 Figure 4: Sequence Diagram for Login

3.4.4 Sequence Diagram for Make Booking

The Update sequence diagram shows the sequence of steps required to update
data into the system. The system requests the actor to enter results. The actor enters
data. The system validates the data and update the information as shown in Figure 5.

Figure 5: Sequence Diagram for Make Booking

3.4.5 Sequence Diagram for Log Out

The Logout sequence diagram shows the sequence of steps required to exit
from the system. The system requests that the actor enter his/her name and password.
15
The actor enters his/her name and password After that user will click on the log out
button they’ll be returned the Home Page of Online Hotel Management System as shown in
Figure 6.

Figure 6: Sequence Diagram for logout

3.5 Activity Diagram

Activity diagram is another important diagram in UML to describe dynamic
aspects of the system. Activity diagram is basically a flow chart to represent the flow
form one activity to another activity. The activity can be described as an operation of
the system. So, the control flow is drawn from one operation to another. Activity
diagrams represent workflows in a graphical way.

3.5.1 Activity Diagram for Login

An activity diagram shows the sequence of steps that make up a complete
complex process, such as an algorithm or workflow. An activity diagram shows flow
16
of control, similar to a sequence diagram, but focuses on operations rather than on
objects. Activity diagrams are most useful during the early stages of designing
algorithms and workflows as shown in Figure 7.

Figure 7: Activity diagram for Login

3.5.2 Activity Diagram for Make Booking
An activity diagram shows flow of control, similar to a sequence diagram, but
focuses on operations rather than on objects. Activity diagrams are most useful during

17
the early stages of designing algorithms and workflows. In this activity diagram user
add record into the system and system update the record as shown in Figure 8.

Figure 8: Activity Diagram for Make Book

18
 Chapter 4
4 SOFTWARE PROJECT MANAGEMENT
4.1 Project Management Techniques
Project management system helps your engineering team track every initiative. A
single system can manage every aspect of every project your engineering team is
executing. In Notion, all the project work lives side-by side deadlines and updates
saving you time bouncing between tools. Project management techniques involved
both of Gant Chart and Critical Path Methods. Both have different qualities and
importance which can be helpful in every project, these techniques are very helpful in
business purpose and many organizations. These techniques are,
 Gantt Chart
 Critical Path Method

4.2 Work Breakdown Structure for TSR

Work break down structure is that how we can work in our project. Basically
work breakdown structure helps us in our project and it is easy way too reached at our
target easily. The WBS for our project is given below in Table 7.

Table 7: Work Breakdown Structure

Level Activity
1 Idea
2 Research Work
3 SRS
4 Design Documentation
5 Progress Presentation
6 Implementation & Testing

4.3 Gantt chart:

A chart in which a series of horizontal lines shows the amount of work done or
production completed in certain periods of time in relation to the amount planned for
those periods. It is a visual description of a project's timeline. The chart shows the
start and end dates of a project's components, such as resources and planning. If you
are involved in a project, it is recommended to use a Gantt chart to help organize the

19
various tasks within the project. Online Hotel Management System Gantt chart are
shown in the Figure 9.

Figure 9: Gantt chart

4.3.1 Critical Path Method:
The critical path method (CPM) is a technique where you identify tasks that
are necessary for project completion and determine scheduling flexibilities. A critical
path in project management is the longest sequence of activities that must be finished
on time in order for the entire project to be complete. The critical path method (CPM)
is a technique that's used by project managers to create a project schedule and
estimate the total duration of a project. Critical Path Method for Online Hotel
Management System have activity, description, immediate predecessor and activity of
the project as shown in Table 8.

Table 8: Network Table

Activity Description Immediate Activity Time,

Predecessor Weeks
A Generation of Idea - 3 Weeks
B Research and related work- A 5 Weeks
study
C Making SRS B 4 Weeks
D Design Phase documentation C 5 Weeks
E Presentation of the Design B, C 2 Week
phase

20
 F Implementation and Testing E 2 weeks

4.3.2 Activity on Node diagram

We can see how we can draw activity on node, that how the activity is drawn
on node from start to the point ‘F’ as shown in Figure 10.

Figure 10: AON Network Diagram

4.3.3 Critical Path Method
The Critical path method is that who is the largest of path in the project. The
critical path method for our project is given below Figure 12.

Figure 11: Critical Path Method

4.3.4 Paths
Two paths we can obtain in critical path method is given below,
A B C D E F = 35 Weeks
A B C E F = 30 Weeks

So ABCDEF is a critical path for this project.

4.3.5 Time Period:

This project will take 30 weeks to complete on normal.
21
4.4 Total Cost:
To find the total cost and effort involved we use the COCOMO model in this
project. As our TSR project contains about (2.5) KLOC, we will use the Organic
Mode.

Effort (E) = a x
(Size)b

Where a = 2.4, b
= 1.05 So,

Effort = 2.4 x (2.5) x1.05

E = 6.3 Staff Months
Development Time = 2.5 x (E) x 0.38

TDEV = 2.5 x (6.3) x 0.38

TDEV =4.5

TDEV = 5 months

4.5 Productivity
Productivity= Size / Effort
Productivity = 2.5 / 6.3 =
0.3968 Productivity = 0.4
LOC/Staff-month

Staff = Effort / TDEV

Staff = 6.3 / 5

Staff = 1.26 Staff members on average

4.6 Resources we used

The resources that we use in our project which included both the software and
hardware is given below.

4.7 Hardware
 Android Mobile
 Internet
22
4.8 Software
 Internet
 Visual Studio
 HTML, CSS, JavaScript & bootstrap.

23
 Chapter 5
5 PROJECT IMPLEMENTATION
We use Html, CSS, SQL & Visual Studio to do all the necessary tasks and
operations that are required to achieve the proposed solution of our project. We are
using Html & JavaScript to develop application. By using this language, we are doing
interact with modules and implement other different modules.

5.1 Framework
The Visual Studio Framework is the entire stack of stuff that makes up the OS.
This is the underlying Native libraries that are not directly accessible, the layer above
that that you actually interact with and the code that developers write to run on the
system.

5.2 Hardware Requirements

The hardware requirements are the requirements of a hardware device. Most
hardware only has operating system requirements or compatibility. These
requirements include the minimum processor speed, memory, and disk space required
to install Windows. In almost all cases, you will want to make sure that your hardware
exceeds these requirements to provide adequate performance for the services and
applications running on the server. System requirements could cause a company to
save a lot of money and time, and also can cause a company to waste money and time
as shown in Table 9.

Table 9: Hardware Requirement for project

Laptop For designing and developing applications, we need a laptop having

at least 4 gigabytes of RAM, 250 gigabytes HDD.

5.3 Software Requirements

A software requirements specification (SRS) is a document that describes what
the software will do and how it will be expected to perform. It also describes the
functionality the product needs to fulfil all stakeholders (business, users) needs. The
software requirements are description of features and functionalities of the target
system. Requirements convey the expectations of users from the software product.

24
The requirements can be obvious or hidden, known or unknown, expected or
unexpected from client's point of view as shown in Table 10.

Table 10: Software Requirements

Software Software Android studio.

Language 1: JavaScript
2:HTML
3:CSS
4: Bootstrap

25
 Chapter 6
6 SOFTWARE TESTING
6.1 Introduction
Software testing is a critical element of software quality assurance and
represents the ultimate review of specification, design and coding. In fact, testing is
the one step in the Computer Science process that could be viewed as destructive
rather than constructive. As a secondary benefit, testing demonstrates that software
functions appear to be working according to the specification. Testing provides a
good indication of software reliability and some indication of software quality as a
whole. Testing cannot show the absence of defects, it can only show that software
defects are present finally we arrive at system testing and we tried our best to test
each individual module and also as an integrated module (as a whole) with sufficient
data that may an organization have, fulfilling the objective of our “Online Hotel
Management System”.

6.2 Psychology of Testing

The aim of testing is often to demonstrate that a program works by showing
that it has no errors. The basic purpose of testing phase is to detect the errors that
may be present in the program. Hence one should not start testing with the intent of
showing that a program works, but the intent should be to show that a program
doesn’t work. Testing is the process of executing a program with the intent of finding
errors.

6.3 Testing Objective

Objective of testing is to find maximum errors in the software. So, a good testing
strategy is the one with high potential of finding errors and bugs.
 Testing is a process of executing a program with the intent of finding an error.
 A successful test is one that uncovers an as yet undiscovered error.
 A good test case is one that has a high probability of finding error, if it exists.
 The tests are inadequate to detect possibly present errors.
 The software more or less confirms to the quality and reliable standards.

26
6.4 The Box Approach
Traditionally software testing methods are divided into white- and black-box
testing. These two approaches describe the point of view of test designer.

6.4.1 White Box testing

White-box testing, also known as clear box testing, and glass box testing
which tests internal workings of a program, instead of the functionality. In white-box
testing detailed internal perspective of the system, as well as programming skills, are
used to design test cases. I tested step wise every piece of code, taking care that
every statement in the code is executed at least once as shown in Figure 12.

Figure 12: White Box Testing

6.4.2 Black Box testing
Black-box testing treats the software as a "black box", examining
functionality without any knowledge of internal software workings. The tester is only
aware of what the software is supposed to do, not how it does it, tester only knows
the input and output and nothing more as shown in Figure 13.

27
 Figure 13: Black Box Testing

6.5 Levels of Testing

In order to uncover the errors, present in different phases we have the concept of
levels of testing. The basic levels of testing are as shown below
 Unit Testing
 Acceptance Testing
 System Testing
 Integration Testing

6.6 Unit Testing

Unit testing focuses verification effort on the smallest unit of software i.e. the
module. Using the detailed design and the process specifications testing is done to
uncover errors within the boundary of the module. All modules must be successful in
the unit test before the start of the integration testing begins. In this application we
test the programs up as system. Unit testing is first done on modules, independent of
one another to locate errors. This enables to detect errors.
All components of our project were tested with driven programs. Even each
function was tested individually using the test cases which are described at the end of
chapter.

28
6.7 Integration Testing
After the unit testing, we have to perform integration testing. The goal here is
to see if modules can be integrated properly, the emphasis being on testing interfaces
between modules. This testing activity can be considered as testing the design and
hence the emphasis on testing module interactions.
In this project integrating all the modules forms the main system. When
integrating all the modules we have checked whether the integration effects working
of any of the services by giving different combinations of inputs. All modules were
collected and integrated to each other and results of each test were up to the mark.

6.8 System Testing

After testing each module and getting the expected results, here the modules are
integrated to make sure that the application is well supporting its features. As a
standalone application, its results are according to requirements, as expected. The
application runs smoothly when executed.
 Application is reliable and less prone to crash.
 Application is capable enough to meet all the requirements of users.
 The application is easy to maintain.
 The application is fast and takes less memory space.
 The application is easily usable by the intended user.
 Application is easy to access when needed by user.

6.9 Alpha Testing

Alpha testing is specially used by product development organizations.
Developers observe the users and note problems. Alpha testing is testing of an
application when development is about to complete. Minor design changes can still
be made as a result of alpha testing.
During alpha testing of our project we find following minor errors and solve them
such as,
 Broken links
 Spelling mistakes

29
6.10 Beta Testing
Beta Testing is conducted at the client’s place i.e. outside the organization. In
Beta testing, developer is not present while testing as it is tested at client’s side. Here,
customer records all the errors and other issues encountered during this testing and
reports to the developer.

6.11 Acceptance Testing

Acceptance Test is performed with realistic data of the client to demonstrate
that the software is working satisfactorily. Testing here is focused on external
behaviour of the system, the internal logic of program is not emphasized.

6.12 Interface Testing

The system has been tested at interface level. The interface is tested to make
sure that the form, menus, text boxes and buttons are operational and everything is
displayed according to the requirement.

Chapter 7
7 SOFTWARE TESTING FOR THE MEASUREMENTS
OF ITS CORRECTNESS
7.1 Testing
Testing is intended to show that a program does what it is intended to do and
to discover program defects before it is put into use. When you test system, you
execute a program using artificial data. You check the results of the test run for errors,
anomalies, or information about the programs non-functional attributes.
The testing process has two distinct goals:
To demonstrate the developer and the customer that the system meets its
requirements. For custom software this means that there should be at least one test for
every requirement in the requirements document. For generic software products, it
means that there should be tests for all the system features, plus combination of these
features, that will be incorporated in the product release.

30
 To discover situation in which the behaviour of the system is incorrect,
undesirable, or does not conform to its specification. There are consequences of
system defects. Defects testing is concerned with rooting out undesirable system
behaviour such as system crashes, unwanted interactions with other systems, incorrect
computations and data corruption.

7.2 Development Testing

Development testing includes all testing activities that are carried out by the
team developing the system. The tester of the software is usually the programmer who
developed that software, although this is not always the case. Some development
processes use programmer/tester pairs (Cusamano and Selby, 1998) where each
programmer has an associated tester who develops tests and assists with the testing
process. For critical systems, a more formal process may be used, with a separate
testing group within the development team. They are responsible for developing tests
and maintaining detailed records of test results.
During development, testing may be carried out at three levels of granularity:
• Unit testing, where individual program units or object classes are tested. Unit
testing should focus on testing the functionality of objects or methods.
• Component testing, where several individual units are integrated to create
composite components. Component testing should focus on testing component
interfaces.
System testing, where some or all of the components in a system are integrated and
the system is tested as a whole. System testing should focus on testing component
interactions.
Development testing is primarily a defect testing process, where the aim of
testing is to discover bugs in the software. It is therefore usually interleaved with
debugging the process of locating problems with the code and changing the program
to fix these problems.

7.3 Unit Testing

Unit testing is the process of testing program components, such as methods or
object classes. Individual functions or methods are the simplest type of component.
Your tests should be calls to these routines with different input parameters.

31
When you are testing object classes, you should design your tests to provide
coverage of all of the features of the object. This means that you should:
• Test all operations associated with the object;
• Set and check the value of all attributes associated with the object;
• Put the object into all possible states. This means that you should simulate all
events that cause a state change.

7.4 Components Testing

Software components are often composite components that are made up of
several interacting objects. For example, in the weather station system, the
reconfiguration component includes objects that deal with each aspect of the
reconfiguration. You access the functionality of these objects through the defined
component interface. Testing composite components should therefore focus on
showing that the component interface behaves according to its specification. You can
assume that unit tests on the individual objects within the component have been
completed.

7.5 System Testing

System testing during development involves integrating components to create
a version of the system and then testing the integrated system. System testing checks
that components are compatible, interact correctly and transfer the right data at the
right time across their interfaces. It obviously overlaps with component testing but
there are two important differences:
During system testing, reusable components that have been separately
developed and off-the-shelf systems may be integrated with newly developed
components. The complete system is then tested.
Components developed by different team members or groups may be
integrated at this stage. System testing is a collective rather than an individual
process. In some companies, system testing may involve a separate testing team with
no involvement from designers and programmers.

7.6 User Testing

User or customer testing is a stage in the testing process in which users or
customers provide input and advice on system testing. This may involve formally

32
testing a system that has been commissioned from an external supplier, or could be an
informal process where users experiment with a new software product to see if they
like it and that it does what they need. User testing is essential, even when
comprehensive system and release testing have been carried out. The reason for this
is that influences from the user’s working environment have a major effect on the
reliability, performance, usability, and robustness of a system.
It is practically impossible for a system developer to replicate the system’s
working environment, as tests in the developer’s environment are inevitably artificial.
For example, a system that is intended for use in a hospital is used in a clinical
environment where other things are going on, such as patient emergencies,
conversations with relatives, etc. These all affect the use of a system, but developers
cannot include them in their testing environment.
In practice, there are three different types of user testing:
• Alpha testing, where users of the software work with the development team to
test the software at the developer’s site.
• Beta testing, where a release of the software is made available to users to
allow them to experiment and to raise problems that they discover with the
system developers.
• Acceptance testing, where customers test a system to decide whether or not it is
ready to be accepted from the system developers and deployed in the customer
environment.

7.7 Test Cases

A test case is a singular set of actions or instructions for a tester to perform
that validates a specific aspect of a product or application functionality. If the test
fails, the result might be a software defect that the organization can triage. Testing is
expensive and time consuming, so it is important that you choose effective unit test
cases. Effectiveness, in this case, means two things:

The test cases should show that, when used as expected, the component
that you are testing does what it is supposed to do. If there are defects in the
component, these should be revealed by test cases. You should therefore write two
kinds of test case. The first of these should reflect normal operation of a program and
should show that the component works. For example, if you are testing a component

33
that creates and initializes a new patient record, then your test case should show that
the record exists in a database and that its fields have been set as specified. The
other kind of test case should be based on testing experience of where common
problems arise. It should use abnormal inputs to check that these are properly
processed and do not crash the component. [Sommerville-2009]

Test cases are built around specifications and requirements, i.e., what the
application is supposed to do. Test cases are generally derived from external
descriptions of the software including specification specifications requirements and
design parameters. The test designer determines input, output and possible flow of
events.

7.7.1 Test Case for Signup

The Sign Up test case test the ask the User to sign up first and then login to
become a Registered User. This allows the User to gain access to the system features
as shown in Table 11.
Table 11: Test Case for Signup

ID 01
Name Signup
Brief Description Used to sign-up to the system
Expected Input Signup name, Email and password
Expected flow of 1. Enter Name 2. Enter Email 3.Enter Password 4.Press
events Sign-up button.
Alternate flow of 1. Invalid Information added, or Email already exist 2.
events Error message displayed to admin.
Pre-Condition None
Post-Condition signed in
Actor Admin
Status Pass

7.7.2 Test Case for Login

This login test case tests when an actor wishes to log into the System. The
system requests that the actor enter his/her name and password. The actor enters

34
his/her credentials. The system validates the entered name and password and logs the
actor into the system as shown Table 12.

Table 12: Test case for login

ID 02
Name Login
Brief Description Used to login to the system
Expected Input Login Email password
Expected flow of events 1. Enter Email 2. Enter password 3.press ”Login”
Alternate flow of events 1. Invalid login Email or password 2. Error
message displayed to admin.
Pre-Condition None
Post-Condition Logged in
Actor Admin
Status Pass

7.7.3 Test Case for Logout

The Logout test case tests the User to logout of the system after using their
relative services. User will click on the log out button after completing their sessions;
they’ll be returned the Home Page of Online Hotel Management System as shown in
Table 13.

Table 13: Test case for Logout

ID 06
Name Logout
Brief description Admin
Expected flow of events Admin logout of FDR by clicking Logout button,
System will take the user to logout page.
Pre-condition Must login
Actor Admin
Status Pass

35
 Chapter 8
8 CONCLUSIONS, LIMITATIONS AND
RECOMMENDATIONS
8.1 Conclusion
The Online Hotel Management System presented in this spiral book offers a
comprehensive and efficient solution to streamline hotel operations and enhance user
experience. By addressing key challenges in the hotel management industry, such as
manual booking processes and data redundancy, this system significantly improves
operational efficiency and guest satisfaction. The features provided, including
reservation management, billing, and reporting, make it a valuable tool for hotel
owners and managers.

8.2 Future Improvements

While the system meets the defined requirements and goals, there is always room for
enhancement and growth. Future improvements could focus on the following areas:
Integration with third-party services: Implement integration with external booking
platforms and payment gateways to expand the system's reach and usability.
 Enhanced user interface: Continuously improve the user interface to make it
more intuitive and user-friendly, ensuring a seamless experience for both hotel
staff and guests.
 Machine learning for demand forecasting: Utilize machine learning algorithms
to forecast room demand based on historical data, allowing hotels to optimize
pricing and availability.
 Mobile application development: Develop a mobile application to provide
users with an on-the-go solution, enabling them to manage reservations and
access services from their smartphones.

8.3 Limitations
While the Online Hotel Management System offers significant benefits, it is important
to acknowledge certain limitations:
 Dependence on internet connectivity: The system heavily relies on stable
internet connectivity, which may pose challenges in areas with unreliable or
limited internet access.
 Learning curve: Hotel staff may require some time to adapt to the new
system, particularly if they are accustomed to traditional manual methods.
 Security concerns: Despite robust security measures, the system may still be
susceptible to cybersecurity threats, necessitating ongoing monitoring and
updates.
36
In conclusion, the Online Hotel Management System demonstrates a substantial leap
forward in hotel management technology, optimizing processes and enhancing the
overall guest experience. By addressing limitations and incorporating future
improvements, the system has the potential to revolutionize the hospitality industry.

Chapter 9
9 APPENDICES AND REFERENCES
9.1 Appendices
These should provide detailed, specific information that is related to the
application being developed; for example, hardware and database descriptions.
Hardware requirements define the minimal and optimal configurations for the system.
Database requirements define the logical organization of the data used by the system
and the relationships between data. [Sommerville-2009].

9.2 Glossary
An alphabetical list of words relating to a specific subject, text, or dialect, with
explanations a brief dictionary. It is a list of some of the words found in the book and
what they mean. It is found at the end of a book. A glossary sometimes includes
pictures that explain some of the words as shown in Table 14.

Table 14: Glossary

37
 IEEE Institute of Electrical and Electronics Engineering

SRS Software requirements specification

SDLC Software development life cycle

GPS Global positioning system

ROM Read Only Memory

RAM Random Access Memory

GB Giga Byte

9.3 References:
[1]Sommerville-2009] Sommerville I. (2009). Computer Science. United States of
America. Boston Massachusetts. Pearson Education.

[2] Balaha M, Rumbaugh J-2005] Balaha M, Rumbaugh J. (2005). Object Oriented

Modelling and Design with UML 2.0: UML2. State of India. Noida.Dorling
Kindersley (India) Pvt. Ltd.

[3] http://en.wikipedia.org/wiki/systemsarchitectures

[4] https://www.youtube.com/watc?v=hN9xemJYwos

[5] http://www.omg.org/spec/UML/2.0/

38