GITA

AUTONOMOUS COLLEGE

MCA DEPARTMENT
MINOR-PROJECT

1
 A
Project Report
On
“ONLINE GAMING HUB”

Submitted for the partial fulfillment of requirement of the degree of

MASTER OF COMPUTER APPLICATION

Submitted by
RITESH ROSHAN MALLA RUDRA PRAKASH PANDA RUDRA MADHAB PRADHAN
ROLL NO:22MC089 ROLL NO:22MC091 ROLL NO:22MC092

REGD NO:2205287091 REGD NO: 2205287093 REGD NO:2205287094

SECTION: B SECTION: B SECTION: B

Under the Supervision of

PROF. MIKU RANJAN DEY
GITA AUTONOMOUS COLLEGE BBSR

GITA AUTONOMOUS COLLEGE

2
BHUBANESWAR

BATCH-2022-2024
 GITA AUTONOMOUS COLLEGE, BHUBANESWAR
Department of MCA
Ref No:………… Date:……………

CERTIFICATE

This is to certify that the project title entitled “ONLINE GAMING HUB” submitted by RITESH
ROSHAN MALLA ,Regd no -2205287091 ,RUDRA MADHAB PRADHAN Regd no – 2205287094 and

RUDRA PRAKASH PANDA ,Regd no – 2205287093 is an authentic work carried outby him at GITA
Autonomous college under my guidance.The matter embodied in this project work has not been
submitted earlier for the award of any degree or diploma to the best of my knowledge and belief.

Prof. (Dr.) Deepti Bala Mishra Prof. Miku Ranjan Dey

(HoD, Dept. of MCA) (Supervisor)

Examined by:

(External Supervisor)

3
 GITA AUTONOMOUS COLLEGE, BHUBANESWAR
Department of MCA

ACKNOWLEDGEMENT

We express our gratitude to prof. Miku Ranjan Dey, Project Supervisor for his guidance
And constant support.
Lastly, words run to express my gratitude to all the faculties and Hod madam of the
MCA
Department and friends for their support and co-operation, constructive criticism and
valuable suggestion during preparation of this project.
Thanking All

4
 Signature of Students.

GITA AUTONOMOUS COLLEGE, BHUBANESWAR

Department of MCA

DECLARATION

I hereby declare that the project entitled “ONLINE GAMING HUB” submitted by me and my friends
to GITA AUTONOMOUS COLLEGE in partial fulfillment of the requirement for the award of the
degree of Master of Computer Application is a recorded bonafide Project work carried out by us
under the guidance of Prof. Miku Ranjan Dey.
I further declare that the work reported in this project has not been submitted and will
not be submitted , either in part or in full, for the award of other degree or diploma in this institute
or university.

RITESH ROSHAN MALLA

Roll No:22MC089
RUDRA MADHAB PRADHAN
Roll No:22MC092
Date:……….. RUDRA PRAKASH PANDA
5
 Roll No:22MC091

ABSTRACT

The Online Gaming hub is a simple javascript based project that provides an
automated solution for gaming community to acquire more flexibility and appreciation
This is a simple interface for the user’s to experience a premium feel in the gaming
environment and inspired to more involved in gaming community.
sports and games are essential for both physical and mental of the students.
Moreover, it increases the immunity of the person. As it increases the blood flow and
makes it adaptable for exertion. The main difference between a sport and a game is,
we can play games both indoors and outdoors. But we can only play sports outdoors.
Here any one can login from anywhere in the world and know about there
interested game.we can help them achieving their goal by giving them consultancy
about the said game.we can set up them with same mindset individual with same
interest on gaming. We can arrange top level coach to train them and give them advice
on the process.they can also participate on several tournament through our
consultancy.
Additionally we can generate the progress report of your sports achievement and
help to improve your gaming skill..we also provide the opportunity of attending big
tourneys where your mindset can boost..

6
 Contents

List Of Figures vi

List of Tables vii

List of Abbreviations viii
1. Introduction
1.1 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.1 Current system . . . . . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1.2 Proposed System . . . . . .. . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Scope of Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . .. . . . . . . . . . . . . . . .. . . .

1.2.1 Technical Feasibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.2.1.1 Hardware Feasibility . .. . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . .

1.2.1.2 Software Feasibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.2.2 Financial Feasibility . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . .

1.2.2.1 Development Cost . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.2.2.2 Installation Cost .. . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . .

1.2.2.3 Operational Cost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.2.2.4 Maintainance Cost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . .. .. .. . .

1.2.3 Operational Feasibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.3 Process Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.3.1 Agile Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . .

1.3.1.1 The basic working model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.3.1.2 future Increments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2. Requirement Analysis
2.1 Method of Requirement elicitations
2.1.1 Interview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..
2.2 User Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . …

2.3 Project Requirement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . … . .

7
2.4 Requirement validation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . .. .

2.4.1 Requirement Review .. . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . .

3. Software Requirements
3.1Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . ..

3.2Document Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . .

3.3 Overall Perspective. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . .. . .

3.3.1 Product Perspective. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . .

3.3.2 Product Functionality. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . .

3.3.3 User and Characteristics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..

3.3.4 Operating Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..

3.3.5 Design and Implementation Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.3.6 User Documentations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. .

3.4 Specific Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . .

3.4.1 External Interface Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.4.1.1 Hardware Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.4.1.2 Software Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.4.2 Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...

3.5 Non Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.5.1 Performance Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.5.2 Design Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . .

3.5.3 Software Quality Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.5.3.1 Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . .. . . .

3.5.3.2 Reliability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . .. . . .

3.5.3.3 Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . .. . .

3.5.3.4 Maintainability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .

3.5.3.5 Adaptability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . .. .

3.4.3.6 Testability . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . .. . . .

4. Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . .. . . . . . . . . . . . .

4.1 System Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . .. . .

4.1.1 User Perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . .. . .

8
 4.2 Data Flow Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . .. . .

4.3 Detailed Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . .. . .

4.3.1 Use Case Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . .

4.3.2 Er Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . .. . . . . .

5. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . .. . . . . . . . . .

5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . .. . . . .

5.2 Testing Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . ..

5.3 Types Of Testing done . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . .

5.3.1 Whitebox Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . .

5.3.1.1 Advantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . .

5.3.1.2 Disadvantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .

5.3.2 Blackbox Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . .

5.3.2.1 Advantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .
5.3.2.2 Disadvantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . .

7. Software Quality Assurance . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. ..

7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.3 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

List of Figures
1.1 ER Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
1.2 Sign Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Log In . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. .. . .
1.4 Home . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. .. . .
1.5 About . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. .. . .
1.6 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. ..
1.7 Mentors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. .. .
1.8 Contact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. .. . .

List of Abbreviations

SQL Structured Query Language

HTML Hyper Text Mark-up Language
CSS Cascading Style Sheet
SMTP Simple Mail Transfer Protocol
DB Database
UI/UX User Interface/User Experince

10
 Chapter 1
Introduction.
1.1 Problem Statement:
This project is aimed at developing a website for gaming consultancy. The Online
Game Hub provides an easy interface that would let the users to the pool of gaming. It consist of
many games such as cricket , football ,volleyball, basketball etc and lots of online gaming and
Dots and a chat box to interact with other users while gaming. Multiplayer option is also
provided in , so that users can play this game in different computer systems. A registered user
can directly enter to the website by login using username and password. Here you can consult
us about any sports you are interested in. We can set you up with best mentor and same
mindset people. So that You can grow in Your life and achieve your goal..

1.1.1 Current System:

Presently, there are lots of gaming consultancy websites available. But multiplaying
options are not available for the online games.Some of these websites are less interactive to the
user.but our website is better user experience and your time and money will be worth spending.

1.1.2 Proposed System:

The proposed system is meant to give more easiness to the users that they can easily
addicted to the games. we provide multiplayer options for online games.A chat box is also
provide to interact with other players while gaming. And the interface for the users is quite
entertaining and engaging.Menus are interactive and easy accessible throughout the game.Once
the player login they can give their current location and we can help them to find the closest
gaming hub nearest them.

1.2 Scope of Project

Gaming gives relaxation and enjoyment to every user.In this busy world, gaming is the
solution to release the depression and tension.Social networking with gaming is a nice combo
for any user who was addicted to the world of gaming. The requirements specified in this
document will be used for designing all the aspects and components of the game. The document
will be updated as the requirements grow and change over the design and development process.

11
1.2.1 Technical Feasibility
We have analyzed the technical feasibility of the project based on the following factors.

1.2.1.1 Hardware Feasibility:

The minimum hardware requirements for developing Online Game Hub are given below:
• A computer system

1.2..1.2 Software Feasibility:

• XAMMP Server
• Sublime Text Editor
• Web Browser(Chrome)

1.2.2 Financial Feasibility

1.2.2.1 Development Cost:
For developing an application no particular cost is required. But devices are needed to
demonstrate its working. The only cost required is the cost of devices needed for demonstration
of the working Application.

1.2.2.2 Installation Cost

No particular installation cost is needed other than the cost of hardware devices.

1.2.2.3 Operational Cost

Execution of the application does not actually require any operational cost. The only operational
cost required is the cost of power supplies to hardware devices as well as the connectivity
charges.

1.2.2.4 Maintenance Cost

No particular maintenance cost is needed for this software

1.2.3 Operational Feasibility

The operational feasibility of the application is dependent on the following factors:
• The database must contain all the details.
• Database must be updated regularly

1.3 Process Model

1.3.1 Agile Model: Agile model is selected for the project. We are planning to implement the
system with basic facilities only. So many future enhancements are possible with this model.

12
 Agile model can satisfy this requirement efficiently. Since it follows the plan-do-check-act for
improvement, backtracking can done easily in Agile model.

1.3.1.1 The Basic Working Model :

Agile modelling is a practice based methodology for effective modelling and docu mentation
of software-based systems. This can be applied on a software development project in an effective
and light-weight manner. With an Agile Model Driven Development (AMDD) approach enables a
high level modelling at the beginning of a project to understand the scope and potential
architecture of the system, and then during development iterations it requires modelling as part
of iteration planning activities and then requires just in time (JIT) model storming approach.

MANIFESTO FOR AGILE SOFTWARE DEVELOPMENT:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan
• Requirements evolve but time scale is fixed
• Testing is integrated throughout the project life cycle

13
 Why Agile ?
• Customer satisfaction by rapid, continuous delivery of useful software.
• People and interactions are emphasized rather than process and tools.
• Continuous attention to technical excellence and good design.
• Regular adaption to changing circumstances.
• Even late changes in requirements are welcomed.
• Face-to-face conversation is the best form of communication.
• Customers, developers and testers constantly interact with each other.
• Working software is delivered frequently (weeks rather than months).

Agile solves issues like:

• Resource wastage
• Costly modifications
• Unclear requirement

1.3.2.1 Future Increments

The future enhancements of the proposed system that we have estimated are given below.
• Including more games to the system.
• Extending multiplayer options for more games.
• Improving the message system.
• Including advanced methods for notification
• There is always possibility of enhancing UI/UX(User Interface/User Experience) and
Responsive Design.

14
 Chapter 2
Requirement Analysis

2.1 Method of requirement elicitation

The techniques we have used for gathering requirements from users were:
• Interview

2.1.1 Interview
We had an discussion about the various online gaming websites regarding the various
features that has to be incorporated in to the Online Game Hub. In this interview the following
questions were asked.
• What is the need of such a website?
• What are the issues pertaining to the present gaming system?
• What are the necessary functionality required for the planned web application?
• Who are the intended users of the system?
• What are the different views and privileges given to the different class of users?
• What are the expectations from such a website?

2.2 User Requirements

On the basis of requirement survey conducted among the users, we have reached to a
conclusion that more than 5 percent of people in the world are suffered by depression and
tension due to their job complexity. Gaming gives relaxation and enjoyment to every user. In this
busy world, gaming is a solution to release the depression and tension. Social networking with
gaming is a nice combo for any user who was addicted to the world of gaming.

2.3 Project Requirements

On the basis of the requirements demanded by the user the following project
requirements are found out:
• There are mainly 6 games are included with different tastes. They are Ludo,Bingo,Dots,Puzzle
and Vanish.
• Simple and attractive interface is provided for user.

15
• Users will be able to register and login to get their account from which user can play games.
• Multiplaying option for the game Bingo is provided for more fun.
• Chat box enables the users to interact with other users while gaming.
• Message from various users are notified instantly.

2.4 Requirement validation

The goal of requirement validation is to make sure that problems are addressed and suitable
solutions are arrived at, before resources are committed to implementing the requirements. It is
concerned with examining the requirements to certify that they meet the Websites intentions.
The key activities in requirement validation are conducting requirement reviews , demonstrating
prototypes, validating the conceptual models etc. We are adopting requirement review as
mechanism for requirement validation.
2.4.1 Requirement Review
Initially we have classified the requirements, prioritized them and then negotiated the lower
priority requirements. Next step is reviewing the requirements in order to make sure that we
have collected the right requirements. The system requirements listed above are complying with
the final product.

16
 Chapter 3
Software Requirements
The software requirements specified in this chapter are applicable for the development of the
website,

3.1 Definitions
• Game Hub:-A game hub is most often one specially-designed web page at a website which
brings various games together from different perspective sources in to a single system.Interfaces
for users should be attractive in order to users to stay with the website.

3.2 Document Conventions

This document follows MCA standard format and the conventions followed for fonts,
formatting and naming are the standards followed in Computer Science and Engineering
Department of GITA Autonomous College,BBSR.

3.3 Overall Description

3.3.1 Product Perspective
Presently, there are lots of online gaming websites available. But multiplaying options are not
available for the games.There are lots of people they are stressed with people have much pleasure and
relaxation from these games.Chat system is included for users interactions.
3.3.2 Product Functionality
The service offered by the Online Game Hub is given below.
• Game Hub is provided with many traditional games such as cricket, football, tennis ETC.

• Users will be able to register and login to get their account.

• Multiplaying option for the online game is provided for more fun.
• Chat box enables the users to interact with other users while gaming.
• Message from various users are notified instantly.

3.3.3 Users and Characteristics

We are broadly defining the users who need to gain pleasure and relaxation
through gaming.
• The main stream users of the proposed system are the users who play games
for depression removing.
• Another important users of this system are those who play games just for fun.

17
 3.3.4 Operating Environment
The Online Game Hub will need the following : Windows/Unix based server that
supports HTML CSS and JAVASCRIPT:- A server is a system (software and suitable computer
hardware) that responds to requests across a computer network to provide, or help to provide, a
network service. Servers can be run on a dedicated computer, which is also often referred to as
the server, but many networked computers are capable of hosting servers. In many cases, a
computer can provide several services and have several servers running. Servers often provide
essential services across a network, either to private users inside a large organization or to
public users via the Internet. Typical computing servers are database server, file server, mail
server, print server, web server, gaming server, application server, or some other kind of server.
Numerous systems use this client / server networking model including Web sites and email
services. An alternative model, peer-to-peer networking enables all computers to act as either a
server or client as needed.

3.3.5 Design and Implementation Constraints

The issues that will limit the options available to the developers are :
• Providing multiplayer games.
• The entire process of the project should be completed by April 2015.

3.3.6 User Documentation

User manuals or online help will be provided for users to correctly login to the system and
getting it work properly. The user manual will describe the steps to be followed for the proper
working of the system .

3.4 Specific Requirements

3.4.1 External Interface
Requirements 3.4.1.1
Hardware Interfaces The hardware interface required for the user to retrieve the data from
the server in which the web portal is hosted mainly involves a server and a personal pc
connected through a network interface.
3.4.1.2 Software Interfaces
The complete user data is stored in the database and the information is accessed by the
user through a web browser enabled devices.

3.4.2 Functional Requirements

The function of the Online Game Hub is to provide an easy interface for gaming. It will
have the following phases: Manage users

18
• Users should register with their username and password to create an account
• Registered user can login to their account.
• Users will be notified with new messages from other users.
• Menus are provided gives easy way to access different games.
• User can chat with other players while gaming.

3.5 Non Functional Requirements

3.5.1 Performance Requirements
The main performance requirements that the product should satisfy are:
• Speed : Information retrieval from database should be as fast as possible.
• Load balance : The server should be able to handle reasonable number of users without any
issues.

3.5.2 Design Constraints

• GUI is only in English.
• Login and password is used for the identification of users.
• Only registered users have the ability to play games.
• This system is working for single server.

3.5.3 Software Quality Attributes

The most important quality requirements that the system should satisfy are :

3.5.3.1 Scalability
The system should have scalability property. That is this system can be modified
further without the hardcoding the JAVASCRIPT backend.

3.5.3.2 Reliability
The system should be reliable. It should perform the data management operation
efficiently.

3.5.3.3 Availability
System will be available around the clock except for the time required for back
up of data.

3.5.3.4 Maintainability
The system should be maintainable. Sometimes there may be bugs, it should be
easy to correct when it is reported.
19
 3.5.3.5 Adaptability
The system should have the ability to adapt to the new release of web browsers
and new operating systems without any modification.

3.5.3.6 Testability
The Game Hub should be properly tested under various circumstances in order
to assure its reliability.

Chapter 4
Design
4.1 System Overview
The main software platform we have used in building this system includes
HTML,CSS,MySQL,Ajax,Javascript, Bootstrap Framework. JAVASCRIPT is most popular server
side scripting language used for suitable for building high-availability heavy-duty dynamic web
sites, and capable of serving tens of thousands of requests simultaneously. MySQL is a
multithreaded, multi-user, SQL database management system that can easily integrated with
JAVASRICPT. JAVASCRIPT and MySQL together constitute backend for the Game Hub. User
interface is designed using Bootstrap which is a web development framework for building
responsive sites that can be integrated to work easily in all platforms.

4.1.1 User Perspective

Presently, there are lots of online gaming websites available. But multiplaying options are not
available for the games.Some of these websites are less interactive to the user.There are lots of
people they are stressed with their job complexity have much pleasure and relaxation from these
games.Chat system is included for users interactions. • The main stream users of the proposed
system are the users who play games for depression removing. • Another important users of this
system are those who play such games just for fun.

4.2 Data flow Diagram

DFDs are used to represent the flow of data through different modules of the system. An
integrated Data Flow Diagram is used to represent the overall system.

20
 4.3 Detailed Design
4.3.1 Use Case Diagram
A use case diagram at its simplest is a representation of a user’s interaction with the
system that shows the relationship between the user and the different use cases in which the
user is involved.

4.3.2 ER Diagram
A Sequence diagram is an interaction diagram that shows how processes operate with one
another and in what order. It is a construct of a message sequence chart. A sequence diagram
shows object interactions arranged in time sequence. It depicts the objects and classes involved
in the scenario and the sequence of messages exchanged between the objects needed to carry
out the functionality of the scenario.
The ER Diagram consists of mainly 3 entities :
• The USER entity consists of attributes like Id,Usename,Password and Online Status. Here Id is
a primary key. This relation stores signup details.
• The DEVICE entity consists of attributes like Id,OS,Browser,MacId. Here Id is the Primary
Key.Stores the details about the person who logged in.
• The MESSAGE entity consists of attributes like
MessageId,Sender,Receiver,Message,Date,Time,Is Stores the details about the message.Here
MessageId is the Primary Key. ER diagram for the proposed system is given below :

21
22
 Chapter 6
Testing
5.1 Introduction
Testing is the process of evaluating a system or its component(s) with the intent to find that
whether it satisfies the specified requirements or not. Testing is executing a system in order to
identify any gaps, errors or missing requirements in contrary to the actual desire or
requirements.

5.2 Testing Methods

There are a number of software testing methods:
1. Unit testing: Unit testing focuses verification effort on the smallest unit of the software
design, the module. This is known as module testing. Since the proposed system has modules,
the testing is individually performed on each module.
2. Integration testing : Data can be tested across an interface. One module can have adverse
effect on another sub function. When combined it may not produce the desired function.
Integration testing is a systematic technique for constructing the program structure while at the
same time conducting test to uncover errors associated within the interface.
3. Validation testing: Validation testing can be defined in many ways, but a simple definition is
that validation succeeds when the software functions in manner that is reasonably expected by
the customer. Software validation is achieved through a series of black box tests that
demonstrate conformity with requirements.
4. Output testing : After performing the validation testing, next step is output testing of the
proposed system, since no system could be useful if it does not produce the required output in
the specific format. The output generated or displayed by the system under consideration is
tested by asking the users about the format required by them.
5. Acceptance testing : User acceptance of the system is key factor for the success of any system.
The system under consideration is tested for user acceptance by constantly keeping in touch
with prospective system and user at the time of developing and making changes whenever
required.

5.3 Types of testing done

There are different methods which can be used for Software testing

5.3.1 Whitebox testing

Whitebox testing (also known as clear box testing, glass box testing, trans- parent box
testing, and structural testing) tests internal structures or workings of a program, as opposed to
the functionality exposed to the end user. In whitebox testing an internal perspective of the
system, as well as programming skills, are used to design test cases. The tester chooses inputs
23
to exercise paths through the code and determine the appropriate outputs. This is analogous to
testing nodes in a circuit, eg. InCircuit Testing (ICT). While whitebox testing can be applied at
the unit. Integration and system levels of the software testing process, it is usually done at the
unit level. It can test paths within a unit, paths between units during integration, and between
subsystems during a system level test. Though this method of test design can uncover many
errors or problems, it might not detect unimplemented parts of the specification or missing
requirements.

5.3.1.1 Advantages
• As the tester has knowledge of the source code, it becomes very easy to find
out which type of data can help in testing the application effectively
• It helps in optimizing the code.
• Extra lines of code can be removed which can bring in hidden defects.
• Due to the tester’s knowledge about the code, maximum coverage is attained
during test scenario writing.

5.3.1.2 Disadvantages
• Due to the fact that a skilled tester is needed to perform white box testing, the
costs are increased.
• Sometimes it is impossible to look into every nook and corner to find out hidden
errors that may create problems as many paths will go untested.
• It is difficult to maintain white box testing as the use of specialized tools like
code analyzers and debugging tools are required.
5.3.2 Black Box Testing
Blackbox testing treats the software as a ”black box”, examining functionality
without any knowledge of internal implementation. The tester is only aware of what
the software is supposed to do, not how it does it. Blackbox testing methods include:
equivalence partitioning, boundary value analysis, all pairs testing, state transition
tables, decision table testing, fuzz testing, model based testing, use case testing, ex ploratory
testing and specification based testing.
Specification based testing aims to test the functionality of software accord ing to the applicable
requirements. This level of testing usually requires thorough

test cases to be provided to the tester, who then can simply verify that for a given

24
input, the output value (or behaviour), either is or is not the same as the expected
value specified in the test case. Test cases are built around specifications and require ments,
i.e., what the application is supposed to do. It uses external descriptions of
the software, including specifications, requirements, and designs to derive test cases.
These tests can be functional or nonfunctional, though usually functional.
Specification based testing may be necessary to assure correct functionality,
but it is insufficient to guard against complex or highrisk situations.
One advantage of the black box technique is that no programming knowledge
is required. Whatever biases the programmers may have had, the tester likely has a
different set and may emphasise different areas of functionality. On the other hand,
blackbox testing has been said to be like a walk in a dark labyrinth without a ash
light. Because they do not examine the source code, there are situations when a
tester writes many test cases to check something that could have been tested by only
one test case, or leaves some parts of the program untested.
The technique of testing without having any knowledge of the interior work ings of the
application is Black Box testing. The tester is oblivious to the system
architecture and does not have access to the source code. Typically, when performing
a black box test, a tester will interact with the system’s user interface by providing
inputs and examining outputs without knowing how and where the inputs are worked
upon. After the completion of the implementation, we turned to Black Box testing.
We hosted a demo version of the web application for extensive testing. We seeked
the help of our classmates for the purpose of ensuring data-integrity and security.

5.3.2.1 Advantages
• Well suited and efficient for large code segments.
• Code Access not required.
• Clearly separates user’s perspective from the developer’s perspective through visibly defined
roles.
• Large numbers of moderately skilled testers can test the application with no knowledge of
implementation, programming language or operating systems.

25
 5.3.2.2 Disadvantages
• Limited Coverage since only a selected number of test scenarios are actually
performed.
• Inefficient testing, due to the fact that the tester only has limited knowledge
about an application.
• Blind Coverage, since the tester cannot target specific code segments or error
prone areas.
• The test cases are difficult to design.

Chapter 6
Software Quality Assurance
6.1 Introduction Software quality assurance (SQA) consists of a means of
monitoring the software engineering processes and methods used to ensure quality. SQA en-
compasses the entire software development process, which includes processes such as
requirements definition, software design, coding, source code control, code reviews, change
management, configuration management, testing, release management and product integration.
SQA is organized into goals, commitments, abilities, activities, measurements, and verifications.
And.

6.1.1 Purpose
The system is meant to give more easiness to the users that they can easily addicted to the
games. We provide multiplayer options for games.A chat box is also provide to interact with
other players while gaming. And the interface for the users is quite entertaining and
engaging.Menus are interactive and easy accessible throughout the game.Once the game is in
playing mode,everything a player needs will be clearly visible on the screen and easily accessible.

6.1.2 Scope
Every member in our team is responsible for the actions planned in this document such as
documenting the results throughout the development of the project, reviewing the project
progress, and testing the project quality, controlled by this plan. The following are the portions of
the software lifecycle that are covered by the SQAP: User requirements, Software requirements,
Design, Implementation and Testing. The Software Quality Assurance Plan covers the software
items. In addition, the SQAP is also covered by this quality assurance plan.

26
 Conclusion
The project has been completed successfully as specified by the
requirements. The implementation and testing has been done in a step-
by-step manner. Each module has been developed and tested
individually to obtain the required output in the desired form. On our
way working on this interesting project, we learned many things.While
working on this project, we got valuable experience on the stages
involved while developing any web application that could be useful while
working for a professional company. During the duration of this project
we learned the following things through the implementation and testing
of the project:

• JAVASCRIPT backend server scripting

• MySQL database management.
• Javascript,Jquery, CSS
• Bootstrap for UI/UX.
• Ajax for UI/UX

The future improvements can be made in certain areas of the project. There is scope for
extending the project to incorporate more features by including more games with multiplayer
option,Advanced messaging system with notification,etc. The process model selected is agile model.
So that the new options can be implemented to the same design in later point of time. The
updation of the application is an important feature of agile process model designs.

Bibliography
[1] Fundamental of Database Systems,Elmasri and Navathe
[2] Ian Sommerville., Software Engineering, 9th Ed, June 2010.
[3] www.w3schools.com//
[4] www.stackoverflow.com
[6] www.jquery.com
27
1.HOMEPAGE

2.ABOUT

28
 3.LOGIN PAGE

4.SIGN UP

29
 MENTORS

CONTACTS

30