SPORT FACILITY AND EQUIPMENT SYSTEM

NURUL NABILAH BINTI JAMIL

BACHELOR OF COMPUTER SCIENCE

(INTERNET COMPUTING) WITH HONOURS

UNIVERSITI SULTAN ZAINAL ABIDIN

2018

SPORT FACILITY AND EQUIPMENT SYSTEM

NURUL NABILAH BINTI JAMIL

Bachelor of Computer Science (Internet Computing) with Honours

Faculty of Informatics and Computing

Universiti Sultan Zainal Abidin, Terengganu, Malaysia

2018

i

DECLARATION

I hereby declare that this report is based on my original work and my own effort

except for quotations and citations with the guidance from my supervisor, which have

been fully acknowledged.

Signature:

Name : Nurul Nabilah Binti Jamil

Date : 8 August 2018

ii

CONFIRMATION

This is to confirm that the project of Sport Facility and Equipment System was

prepared by Nurul Nabilah binti Jamil, matric number: BTCL15040433. This project

research have fulfilled the condition to be recognized for the level of bachelor of

Computer Science for Internet Computing. The research conducted and the writing of

this report was under the guidance of my supervision.

Signature:

Supervisor : Encik Mohd Khalid Bin Awang

Date : 8 August 2018

iii

DEDICATION

Alhamdulillah. First and foremost, praised to Allah, the Most Gracious and

the Most Merciful for blessing me and give me the opportunity to undergo and

complete my final year project, Sport Facility and Equipment System.

I would like to express my gratitude to my supervisor, Encik Khalid Bin

Awang for his teaching, kindness, patience, guidance and motivation towards this

project.

My gratitude also goes to my family, my beloved mother, Zaiton Binti Che

Ariffin and father, Jamil Bin Omar @ Idris. Thank you for supporting me and make

me accomplish this project. I would like to give a special gratitude to all my friends,

and my roommate, whom giving me the full support and assisted in completing the

project even though they also busy doing final year project. Thank you for all your

support and concern.

Last but not least, thank you to everybody whom involved directly in

completing this project. All your contribution is very valuable. Thank you and May

Allah bless you.

iv

ABSTRACT

Sports facility and equipment booking system was proposed to help UniSZA

students and staffs to ease the process of borrowing the sports facilities. This system

does not only assist the facilities unit to achieve higher quality but it also helps to

make the system efficient and to make the booking process smooth and easy for the

management. The sports equipment and facilities that UniSZA have including

badminton courts, netball courts, football fields, basketball, volleyball, badminton

racket, ping pong racket and football and etc. By this booking systems, all of the

students can save their time and at the same time it can increase convenience to book

the facilities or equipment. The main issue that arises in the main existing system is

that the current system is not efficient. The courts and sports equipment for students

and staffs are limited. The implementation of this system is it can simplify the process

for application to saving time and more user friendly. The technique that will be used

is priority in order to avoid the overlapping booking the system.

v

ABSTRAK

Sistem pinjaman faciliti dan alatan sukan telah dicadangkan untuk membantu

pelajar UniSZA dan staff UniSZA untuk memudahkan proses peminjaman alatan

sukan. Sistem ini tidak hanya menolong unit faciliti untuk meningkat kepada kualiti

yang tinggi tetapi ia juga membantu menjadikan sistem ini lebih efisien yang UniSZA

ada termasuk gelanggang badminton, gelanggang bola jaring, padang bola sepak,

raket badminton, bola keranjang, bola baling, raket ping pong, bola sepak dan lain-

lain. Melalui sistem ini, semua pelajar boleh menjimatkan masa dan pada masa

yang sama ia boleh meningkatkan keselesaan pengguna untuk meminjam faciliti dan

alatan sukan. Isu utama yang dibangkitkan didalam sistem yang sedia ada adalah

sistem sekarang tidak efisien dan tidak sistematik. Gelanggang sukan untuk para

pelajar dan staff adalah terhad kepada beberapa pengguna sahaja. Dengan

mengaplikasikan penggunaan sistem ini ia boleh memudahkan proses pinjaman dan

penggunaan kepada aplikasi untuk menjimatkan masa dan mudah mesra kepada

pengguna. Teknik yang akan digunakan untk membangunkan sistem ini adalah

dengan menggunakan kaedah prioriti supaya dapat menghindari daripada pinjaman

yang bertindih.

vi

CONTENTS

PAGE

DECLARATION i

CONFIRMATION ii

DEDICATION iii

ABSTRACT iv

ABSTRAK v

CONTENTS vi

LIST OF TABLES vii

LIST OF FIGURES xvi

LIST OF ABBREVIATIONS xv

CHAPTER I INTRODUCTION

1.1

1.2

Introduction

Background Project

1

2

1.3 Problem statement 2

1.4 Objectives 3

1.5

1.6

Project Scopes

Limitation of Works

4

5

1.7

1.8

1.9

Expected Result

Structure Thesis

Summary

5

5

6

7

CHAPTER II LITERATURE REVIEW

2.1 Introduction 8

2.2 First Come First Serve 8

2.3 Priority Queue 10

2.4 Web based Application 12

2.5 Existing System 14

2.6 Summary 16

vii

CHAPTER III

METHODOLOGY

3.1 Introduction 17

3.2 Waterfall Methodology Model 17

3.2.1 Initial Planning Phase 18

3.2.2 Requirement Analysis Phase 19

3.2.3 Design 19

3.2.4 Development Phase 20

3.2.5 Testing Phase 20

3.2.6 Maintenance Phase 20

3.3 Software and Hardware Requirement 21

3.3.1 Hardware Requirement 21

3.3.2 Software Requirement 22

3.4 System Design 20

3.4.1 Framework Design 23

3.4.2 Process Model 24

3.4.2.1 Context Diagram 24

3.4.2.2 Data Flow Diagram Level 0 25

3.4.2.3 Data Flow Diagram Level 1 27

3.4.2.3.1 Data Flow Diagram Level 1

(Manage Item)

27

3.3.2.3.2 Data Flow Diagram Level 1

(Manage Booking)

28

3.3.2.3.3 Data Flow Diagram Level 1

(Manage Return)

29

3.3.2.4 Entity Relationship Diagram 30

3.5 Database Design Specification 31

3.6 Proof of Concept 32

3.7 Summary 34

CHAPTER IV IMPLEMENTATION DAN RESULT

4.1 Implementation and Output 35

viii

4.1.1 Interfaces 35

4.1.1.1 Login User 35

4.1.1.2 Signup User 36

4.1.1.3 User Homepage 37

4.1.1.4 Book Sports Item 38

4.1.1.5 Booking Form 39

4.1.1.6 Booking Details 40

4.1.1.7 Status Booking 41

4.1.1.8 User profile 42

4.1.1.9 User Logout 43

4.1.1.10 Admin Login 44

4.1.1.11 Admin Homepage 44

4.1.1.12 Admin List of booking 45

4.1.1.13 User’s booking list 46

4.1.1.14 Sport Item List 48

4.1.1.15 Admin Logout 50

4.2 Test Case 51

4.2.1 Success Sign Up (User) 51

4.2.2 Fail Sign Up (User) 51

4.2.3 Success Login (User) 52

4.2.4 Fail Login (User) 53

4.2.5 Success Login (Admin) 53

4.2.6 Fail Login (Admin) 54

4.2.7 Update Profile (User) 54

4.2.8 Booking Item (User) 54

4.2.9 Cancel booking (User) 55

4.2.10 Update booking (User) 55

4.2.11 Approve booking (Admin) 56

4.2.12 Reject booking (Admin) 56

4.2.13 Add Item (Admin) 56

4.2.14 Update Item (Admin) 57

4.2.15 Delete Item (Admin) 57

ix

4.3 Summary 58

CHAPTER V CONCLUSION

5.1 Introduction 59

5.2 Discussion 59

5.3 Limitation 60

5.4 Recommendation 60

5.5 Conclusion 60

REFERENCE 62

APPENDIX 63

x

LIST OF TABLES

TABLE TITLE PAGE

2.1 Existing System on Research Papers 15

3.1 List of hardware requirement 21

3.2 List of software requirement 22

3.3 Data for table signup for user 31

3.4 Data for table booking for user 31

3.5 Data for table admin 32

3.6 Data for table item 32

4.1 Test case for success user signup. 51

4.2 Test case for fail user sign up. 51

4.3 Test case for success user login. 52

4.4 Test case for fail user login. 53

4.5 Test case for success admin login. 53

4.6 Test case for fail admin login. 54

4.7 Test case for user update profile. 54

4.8 Test case for user booking item. 54

4.9 Test case for user cancel booking. 55

4.10 Test case for user update booking. 55

4.11 Test case for admin approve booking. 56

4.12 Test case for admin reject booking. 56

4.13 Test case for admin add item. 56

4.14 Test case for admin update item. 57

4.15 Test case for admin delete item. 57

xi

LIST OF FIGURES

FIGURE TITLE PAGE

2.1 Priority Analogy 10

3.1 Waterfall Model 18

3.2

3.3

3.4

3.5

3.6

System Framework for System

Context Diagram

Data Flow Diagram Level 0

Data Flow Diagram Level 1 for Manage Item Process

Data Flow Diagram Level 1 for Manage Booking Process

23

24

25

27

28

3.7 Data Flow Diagram Level 1 for Manage Return Process 29

3.8 Entity Relationship Diagram 30

4.1 Login Interface for user 35

4.2 Pop-up error message for login interface 36

4.3 Signup Interface for user 36

4.4 User Homepage 37

4.5 Booking Sports Item page 37

4.6 Booking form details for user 38

4.7 Pop-up message for successfully book an item 39

4.8 Booking details page 39

4.9 Status booking page for user 40

4.10 Status booking page rejecting booking 41

4.11 Pop-up message for confirm delete 41

4.12 Cancel booking had been deleted 42

4.13 User profile page 42

4.14 Logout page for user 43

4.15 Admin login page 44

4.16 Admin homepage 44

4.17 List of booking page 45

4.18 Pop-up message for booking approved 46

4.19 User’s booking list page 46

4.20 Pop-up message for booking rejected 47

4.21 Empty details of booking in List of booking page 47

4.22 Sport item list page 48

4.23 Pop-up message for data successfully add 49

4.24 Pop-up message for confirm update 49

xii

4.25 Pop-up message for confirm delete 49

4.26 Admin logout page 50

xiii

LIST OF ABBREVIATIONS / TERMS / SYMBOLS

CD Context Diagram

DFD Data Flow Diagram

ERD Entity Relationship Diagram

FYP Final year project

FCFS First Come First Serve

FIFO First In First Out

CPU Central Processor Unit

SDLC System Live Development Cycle

MPP Majlis Perwakilan Pelajar

MKK Majlis Kolej Kediaman

xiv

LIST OF APPENDICES

APPENDIX TITLE PAGE

A Gantt Chart 39

1

CHAPTER I

INTRODUCTION

1.1 Background

Nowadays, many systems had developed from manual system to computerize

system. Online booking system does not only assist the facilities unit to achieve

higher quality but it also helps to simplify the booking process and raise the efficiency

in management. Sports is an objective. There are many kinds of sports around us.

There are traditional and modern sports. From the past to the modern generation,

sports are likable and there are variations and innovation in sports.

This chapter presents an introduction of the project proposal, Sports Facilities

and Equipment System. Chapter 1 contains five sections. Firstly, the background of

the project described. The second section is the problem statement about this project.

In the third section is the objectives of the project. In the next section is the scopes that

will be covered through this project. The limitation of work of the project will be

discussed in section five. Last but not least, in the sixth section there will be the

milestone or the Gantt chart that indicates the planning outlined throughout the

project.

2

1.2 Background Project

Todays, people had attention towards sports. From the younger to the eldest,

they must at least have play sports in their lifetime. Sports like football and

basketball can bring us the unity if we play together. Through sports perspective,

sports complement for people like students and staff, which is filling needs

towards sports. Sports can develop the stamina and the enjoyment while playing

it. Sports facilities and equipment systems allow students and staff of University

Sultan Zainal Abidin (UniSZA) to booking the desired facilities or sports

equipment based on the first come first serve. The student or staff that had book

first only can get use of the facilities or equipment. If the other students and staff

that come after that, they will be rejected and they need to book to the next session

of time. The main data in the system is the availability of the sports facilities and

equipment. The student and the staff can book to their specific time follows their

needs.

1.3 Problem Statement

Currently, the sport’s user in Campus Besut is unable to know whether

they can use the facilities or sports equipment before they reserve it because

with the current system, if they want to use the facilities and the equipment, for

student, they must go to the sport center first to check the availabilities of the

required facilities or equipment.

3

Besides, if the students want to book badminton courts, they must go to

the sport’s center first to book and they will only know the available courts

upon their booking at that time.

Lastly, in the current Campus Besut Sports Centre, there is

unsystematic systems that provides difficulties to keep the detail of the users.

The details that are keep in papers and books might make the longer time to

search the previous or old details.

1.4 Objectives

The main objective in this project as follows:

i. To proposed the system that will help the students and the staff to book the

sports facilities and equipment easily.

ii. To design and develop a web based system for sports facilities and

equipment that fits the user requirements.

iii. To implement the system by using priority queue technique.

4

1.5 Project Scope

The scope of this project consist of two user which are users and admin including

a system scope.

i. Users:

In the user scope, there are two users which are students and staffs. Both

of the students and the staff, can book, edit or cancel the booking of sports

facilities and equipment based on the listed availabilities by date and time.

ii. Admin:

Admin can manage the users. Admin can view the details, edit facilities

and equipment availability and cancel booking of the sports facilities and

equipment.

iii. System:

System will manage the booking system. The system will prioritize the

user in booking queue process. It will automatically cancel the user’s

booking if there have a higher priority user than the normal user.

5

1.6 Limitation of Works

a. Scope

This scope of project focus on the booking and cancel booking of the

sports facilities and equipment. The system does not required the payment

because it’s only booking to the students and staffs in UniSZA campus

Besut only. If the many user try to book at the same session, the system

only receive the first come first serve user only.

b. Selection of facilities and equipment

All the users that book the facilities and equipment will be selected by

using first come first serve.

1.7 Expected Result

From this project of Sport Facility and Equipment System, there are several expected

result.

a. Web based booking system

b. Avoid overlapping booking

c. Help user which are student and staff to book easily.

6

1.8 Structure Thesis

A structure thesis of Sports Facilities and equipment System project concisely

describing the content in this project for each chapter.

1.8.1 Chapter 1: Introduction

In the first chapter, the contents are consist of project introduction, proposal

background, problem statement, objective, project scope, limitation of work

and Gantt chart.

1.8.2 Chapter 2: Literature Review

Chapter two is about literature review. In this chapter, will be discussing and

analysing the problem towards the existing systems. First come first serve

method that will be used in the system will be discussed.

1.8.3 Chapter 3: Methodology

Chapter three will be described the methodology of the research used in the

system. The detailed explanations about every phase are stated.

1.8.4 Chapter 4: Design and Project Modelling

Chapter four discuss about design and data modelling comprises of a context

diagram, data flow diagram, framework, and database design. Besides, more

details will be describe about the design of the model.

7

1.8.5 Chapter 5: Implementation and Result

Chapter five consist of the explanation about implementation of First Come

First Serve technique for this system.

1.8.6 Chapter 6: Conclusion

In chapter six, project achievement, project limitation and some improvements

will be discussed. Finally, the conclusion will be produced.

1.9 Summary

In chapter 1, the purpose of the project of the system is identified to overcome

the problem that occur in the current system. Also, the function and limit of the

project are stated. Besides, the brief about every chapter was stated in this

chapter.

8

CHAPTER II

LITERATURE REVIEW

2.1 Introduction

Literature review is made research about the critical points of current

knowledge on a specific topic. The purpose is to justify the choice of research

questions, theoretical or conceptual framework, and the method. In this chapter

consist of system review and method review. System review is about the

comparison for the existing system whereas the method review is study and

analyze about the technique and methodology that suited for the system.

2.2 First Come First Serve (FCFS)

First come, first served (FCFS) is an operating system process scheduling

algorithm and a network routing management mechanism that automatically

executes queued requests and processes by the order of their arrival. With first

come, first served, what comes first is handled first; the next request in line will be

executed once the one before it is complete.

FCFS is also known as first-in, first-out (FIFO) and first come, first choice

(FCFC). FCFS provides an efficient, simple and error-free process scheduling

9

algorithm that saves valuable CPU resources. It uses non-preemptive scheduling in

which a process is automatically queued and processing occurs according to an

incoming request or process order. FCFS derives its concept from real-life

customer service.

Let's take a look at how FCFS process scheduling works. Suppose there are

three processes in a queue: P1, P2 and P3. P1 is placed in the processing register

with a waiting time of zero seconds and 10 seconds for complete processing. The

next process, P2, must wait 10 seconds and is placed in the processing cycle until

P1 is processed. Assuming that P2 will take 15 seconds to complete, the final

process, P3, must wait 25 seconds to be processed. FCFS may not be the fastest

process scheduling algorithm, as it does not check for priorities associated with

processes. These priorities may depend on the processes' individual execution

times.

10

2.3 Priority Queue

A Priority Queue is different from a normal queue, because instead of being a

“first-in-first-out”, values come out in order by priority. It is an abstract data type that

captures the idea of a container whose elements have “priorities” attached to them. An

element of highest priority always appears at the front of the queue. If that element is

removed, the next highest priority element advances to the front.

Conceptual picture of a priority queue:

Figure 2.1: Priority Analogy.

Imagine a priority queue as a bag that holds priorities based on figure 2.3. We can

put one in and can take out the current highest priority. Priorities can be any

comparable values.

Queuing schemes, on the other hand are used when there is a relatively significant

number of resources and users can only be allocated just one of them, at any point in

time. More specifically, Orduña and García‐Zubia (2011), highlighted that by using

the queuing scheme to schedule access to resources, all requests made by users to

access a particular resource have to be placed sequentially in a queue in the order that

they arrived and then processed successively one after another on a first‐come,

first‐served basis. On the whole, users are only provided access to the first available

resource that meets their specific request (Lowe, 2013).

Priorities in Priorities out

11

A priority queue is an abstract data type which is like a regular queue or stack data

structure, but where additionally each element has a “priority” associated with it. In a

priority queue, an element with high priority is served before an element with low

priority. If two elements have the same priority, they are served according to their

order in the queue.

In essence, there are two types of priority queue: the non-preemptive priority

queue and the preemptive priority queue (Kihlwan, 2012). The non‐preemptive and

preemptive priority queues are both extreme cases with respect to the preemption

condition, as they “never” or “always” allow preemption, respectively when a request

to access a resource arrives in the queue from a user with a higher priority during the

service of the request from a lower priority user (Kihlwan, 2012).

More specifically, in the case of the preemptive priority queue, during the service

of a user’s request, the scheduling server “continuously” checks the queue for the

presence of requests to access a resource from users with higher priorities than the

current user being serviced, to determine whether or not to preempt the service of this

user. If there exists a request from a user with higher priority in the queue, the low

priority request currently being processed will be preempted (Harchol‐Balter, 2013).

In many practical situations, however, it may be counter‐productive and undesirable to

continuously review the system state, as this can incur considerable processing time,

especially when the information on the queue is decentralized and distributed over a

network (Kihlwan, 2012).

12

On the other hand, with non‐preemptive priority queues, the scheduling server

“never” reviews the system state while processing a user’s request to access a

particular resource. This implies that users with high priorities will have to wait for

some time until the service of a low priority user is completed. As highlighted by

Harchol‐Balter (2013), this can lead to severe degradation of the quality of service

experienced by high‐priority users, especially when the processing time of a

low‐priority user request is relatively slow.

While priority queues are often implemented with heaps, they are conceptually

distinct from heaps. A priority queue is an abstract concept like “a list” or “a map”;

just as a list can be implemented with a linked list or an array, a priority queue can be

implemented with a heap or a variety of other methods such as an unordered array.

2.4 Web Based Application

A web based application is a software package that can be accessed through the

web browser. The software and database reside on a central server rather than being

installed on the desktop system and is accessed over a network.

It is a client–server computer program in which the client (including the user

interface and client-side logic) runs in a web browser. Common web applications

include webmail, online retail sales, online auctions, wikis, instant messaging services

13

and many other functions. An application that is usable only with an active Internet

connection and that uses HTTP as its primary communications protocol.

Web sites most likely to be referred to as “web applications” are those which have

similar functionality to a desktop software application, or to a mobile app. HTML5

introduced explicit language support for making applications that are loaded as web

pages, but can store data locally and continue to function while offline.

Web based applications are the ultimate way to take advantage of today’s

technology to enhance productivity and efficiency. Web based application gives an

opportunity to access information from anywhere in the world at any time. It also

facilitates to save time and money and improve the interactivity with customers and

partners.

It allow the administration staff to work from any location to access information

remotely 24 hours a day, 7 days a week. With a computer connected to the Internet, a

web browser and the right user name and password can access the systems from any

location.

Web-based applications are easy to use and can be implemented without

interrupting existing work process. Whether need a content managed solution or an e-

commerce system, we can develop a customized web application that fulfills the

requirements. The web based software, enables to interact with the application and

data in a fluid and highly responsive manner.

14

2.5 Existing System

Existing system is the example of the functional online system that are related to this

system.

Author/Title/

Year

Content Advantages Disadvantages

Pei Chyi,

Tan. Sport

Facility

Booking

System

(SFBS). 2012

• Allow user to

book the sport

equipment and its

facilities.

• First come first

serve concept.

• Use GSM modem

to send/ receive

messages from

mobile phone.

Can notify the

users using

messages.

• Priority

purpose: some

of the users

booking

manually

cancelled by

admin.

• Not request the

users in

advance to

book at

different date

and time.

Nooraidawati

, Azhari.

UTeM Sport

Center: On-

Line Booking

Of Facilities

and

Equipments.

2008

• Allow user to

book its facilities

and equipment.

• More concern

about the security

of the data in the

system.

• Secured

data of

bookin

gs in

the

databas

e

• Users need to

physically the

facilities or

equipment by

meeting the

staff at the

counter.

15

Hooi Fong,

Tan.

Automatic

Sport

Facilities

management

System

(UMPASFM

S). 2012

• The system is

develop for

helping admin to

manage their

sport facilities

and equipment.

• Using

testing

method

to

validate

the

system.

• Need admin

approval after

booking before

can use it.

• Disadvantages

for who need it

as soon as

possible.

Smithurst,

Ben. A web-

Based Sports

Centre

Booking

System. 2003

The sports

member can book

squash court

online.

View/delete their

own booked

sessions.

Users

can

view

the

most

popular

activitie

s and

trackin

g

number

s who

book

and do

not

arrive

for

their

session.

Only sports

members are

allowed to use

the booking

function of the

system.

Table 2.1: Existing System on Research Papers

16

2.6 Summary

From this chapter, the main function of the project have been explained

specifically like the function of FCFS, priority queue and wed based application.

After that, the analysis from the past projects that had a similar function are made as a

reference and g guidance about how to develop this project. There are some helpful

information that can be used for the developing phases.

17

CHAPTER III

METHODOLOGY

3.1 Introduction

This chapter will be discuss about the methodology that are being used in this

project. With the methodology, the project will have the guidance to support the

system and to ensure that the project is complete and working well. There are many

methodology recommendation to develop the system like waterfall model, spiral

model and agile model in the System Development Live Cycle (SDLC). These

approaches should be chosen wisely based on the suitability of the system before the

beginning of the development phase as it will become the guidance through the

development process. The methodology of the SDLC proposed in this system is

waterfall model.

3.2 Waterfall Methodology Model

Sports Facilities and Equipment System uses waterfall model as the

methodology throughout this project. The waterfall model emphasizes that a

logical progression of steps be taken throughout the software development life

cycle (SDLC), much like the cascading steps down an incremental waterfall. By

using waterfall model as a guide, this project is designed and implemented with

18

the details added gradually until all of the requirements is satisfied to complete

this project. This methodology is used because it works well on a smaller projects

where the requirements are very well understood. In this model, every phases are

not overlap. The implementation of the waterfall model within a new project is

rather straightforward process. In this model, phases are processed and completed

one at a time and the phases also do not overlap.

Figure 3.1: Waterfall Model

3.2.1 Initial Planning Phase

In the planning phase, the idea of the Sports Facilities and Equipment System

is generated to help the users which is the student and the lecturer to be able to

booking the facilities and equipment easily by using priority queue approach. The

priority queue is capable to solve the issue of the user that are being treated

indifferently. The discussion session about the problem faced in the system are

determined and arranged with the supervisor weekly.

19

3.2.2 Requirement Analysis Phase

During this second stage, the user requirement is analysed in order to properly

generate the models and business logic that will be used in the application. All of the

information are obtained through the research papers and journal of the previous

works and the existing system. The system requirements are identified by direct

observation in the existed booking systems and several research papers. At the end of

this phase, objectives, scope and limitation of works are determined.

3.2.3 Design Phase

In the design phase, all the information which is obtained in the analysis phase

is used to design the realistic framework. All of the information in the previous phases

are gathered and transformed into the design which is follow the identified

requirement. Then, there will be Context Diagram (CD), Data Flow Diagram (DFD)

level 1 and level 2 and also the Entity Relationship Diagram (ERD), data dictionary

and interface design of the system. The design for the interface should cover some of

the basic features in Sports Facilities and Equipment System. The purpose of using

these diagram is because to improve the understanding on how the system will

function. A web based booking system is designed so that the user be able to book

the facilities and equipment.

20

3.2.4 Development Phase

In the development phase, there are the creation of the prototype that is the

main frame of the building this project. The prototype defines the overall structure of

the system. In the building prototype process, involved most of the coding and the

flow of the system. The sport facility and equipment system is a web system and will

be implemented by using Hypertext Pre-Processor (PHP) language and MYSQL

database. The editing tools that are used in the making of the system are notepad++

Lucid Chart. The XAMPP will run as a local server in order to run the system. It’s

will give an idea about how the system will operate.

3.2.5 Testing Phase

Once the development phase is over, the testing phase take place. After the

development of the prototype, the system will be tested to test the functionality and

the correct flow the system. A few test will be done to ensure that there are no bug

and error, or faults in the system. So that the problem that arise can be corrected. In

this phase, the test of the system should be following the requirement of the system. It

can helps in finding the vulnerabilities that are not discovered in the previous phase.

3.2.6 Maintenance Phase

As soon as the system is tested and deploy, it enters the maintenance phase. In

this phase where the system can be modify to enhance the functionality of the system.

Changes can be made if there are error and have to fix the system. Generally, it’s

include minor bug fixes that usually made during this phase.

21

3.3 Software and Hardware Requirement

In the section will show the list of the software and hardware requirement that

involved in the development process. This is the important aspect to develop the

system following the software and the hardware requirement for smooth execution.

The details of the hardware and the software are shown below;

3.3.1 Hardware Requirement

The hardware requirements that are used to develop Sport Facility and

Equipment System are;

No. Hardware Description

1. Laptop Lenovo G400s

2. Processor Intel® Core ™i3

3. Memory 8GB RAM

4. Operating System Windows 8

5. System Type 32-bit Operating System

6. Pen-drive To back-up the project

Table 3.1: List of hardware requirements

22

3.3.2 Software Requirement

The software requirement for this project are;

No Software Purpose

1. Notepad++ Used to run codes

2. XAMPP Server This server is used to run PHP and MYSQL

codes of the system which is contained of

Apache and PhpMyAdmin

3. MySQL (PhpMyadmin) As database for the system

4. Google Chrome A browser to open the application and run the

localhost

5. Microsoft Word 2013 Used to prepare documentation of the report

6. Microsoft Power Point 2013 Used to prepare the slide for the presentation

7. Snipping Tool Used to captured and screen shot the images

8. Smart Draw Used to developing CD, ERD and DFD

Table 3.2: List of software requirements

3.4 System Design

In the system design, the flow of the system is organized to enable the system

development will progress smoothly. The details of the framework, context diagram,

data flow diagram (DFD) and also the entity relationship diagram (ERD) will be

explain in detailed in this chapter. The way of the system functionality is drawn in the

diagram to make clear the understanding of the each process of the system and

facilitating the interaction between the system designer, programmer and also the end-

users.

23

3.4.1 Framework Design

Figure 3.2: System Framework for System

The framework are indicating on what kind of programs should be build and

how they would interrelate. In the figure 3.2, the user which are student and staff can

book, view available facility and equipment that they want to book and also they can

cancel boking. After the user booking the facilities or equipment, they can view their

own booking details. An admin be able to retrieve the user’s details of their booking.

An admin can manage user, manage the facilities and the equipment and manage

booking as well as views the report of the system that retrieved from the database.

The website of the booking system act as the interface to the user of the system which

retrieves and send the data to the system database through the web server.

24

3.4.2 Process Model

3.4.2.1 Context Diagram

Figure 3.3: Context Diagram

From the context diagram above, there are three entities involved in the Sport

Facility and Equipment Booking System which are Student, Staff and Admin. The

data flow coming from the student shows that the student provides to the system for

the process of registering, login, and book/cancel. The booking detail, and booking

confirmation, will be given to the student. The student can check the available item.

For the staff, the data flow in and out are the same as the student. The staff

will provide into the system from the process of the registering, login, and

book/cancel. While from the system, it will provide booking detail, and booking

confirmation. Staff can check he available items.

25

For the admin, the data flow coming to the system is login process. Also admin

will be manage the user, manage book/cancel and manage facility/equipment. Admin

will be provided booking report from the system.

3.4.2.2 Data Flow Diagram Level 0

Figure 3.4: Data Flow Diagram Level 0

26

From the data flow diagram level 0 above, it show six process and six data

store in the system. There are three entities which are student, staff and admin are

involved in the system. The student entity are involved in manage student process,

manage item process, manage booking process, and manage return process. The staff

entity are involved in manage staff process, and manage booking process and manage

return process. An admin are involved in manage student process, manage staff

process, manage item process, manage booking process, manage return process and

manage report process.

The data store that involved within the process are, data store D1 of student

file, data store D2 of staff file, data store D3 of item file, data store D4 of booking file,

and data store D5 of return file and D6 of report file.

In the manage student process, student provide the student detail and will be

stored in data store D1. For manage staff process, the staff provide the staff detail and

stored in D2. In the manage item process, admin was involved and the data were sent

to D3. In manage booking process the three entities are involved and the data will go

to D4. In manage return process the three entities are involved and the data will go to

D5. Lastly, only admin was involved in the manage report process and the report data

will be stored in D6.

27

3.4.2.3 Data Flow Diagram Level 1

3.4.2.3.1 Manage Item

Figure 3.5: Data Flow Diagram Level 1 for Manage Item

Based on the above data flow diagram level 1 for manage item process, admin

are in charge in the facility/equipment management. Item means facility and the

equipment. There are add item, update item and delete item process. The data that

flows in the three process are the details of the item. Then, the recorded details will

be stored in the data store D1 of item file.

28

3.4.2.3.2 Manage Booking

Figure 3.6: Data Flow Diagram Level 1 for Manage Booking

Based on the above data flow diagram level 1 for manage booking process,

three entities are involved which are student, staff and admin. There are add booking,

update booking and delete booking. The student and the staff provide their booking

detail into all the process and the data will be stored in data store D1 of booking file.

Admin will manage the booking process.

29

3.4.2.3.3 Manage Return Process

Figure 3.7: Data Flow Diagram Level 1 for Manage Return Process

In manage return process, the three entities are involved which are student,

staff and admin. When returning the equipment after borrow it, they must return to

the sport centre and the details of the return will be recorded. Admin will check the

condition of the item returned. The data will be stored in data store return file.

30

3.4.2.4 Entity Relationship Diagram (ERD)

Figure 3.8: Entity Relationship Diagram (ERD)

The figure above shows an entity relationship diagram (ERD) for sport facility

and equipment system. There are student, staff, booking, return, item and admin

entity. They are connected to each other.

‘

31

3.5 Database Design Specification

In order to develop the system, it needs database. The database are used to store

data of the system. The database name in this system is ludis (sport in latin words)

where it contains four tables which are signup, booking, admin and item. There are

the following list of the table below;

Table 3.3: Data for table signup for user

Table 3.3 above shows the database for table signup for the user. Signup

means registration. In this table, it has nine data which are idsignup, username,

fullname, password, repassword, studentstaffid, email and phoneno.

Table 3.4: Data for table booking for user

32

Table 3.4 above shows that the database for table booking for user. There are

nine data which are idbooking, username, usertype, itemname, quantity, date,

starttime, endtime and status.

Table 3.5: Data for table admin

Table 3.5 above shows the database for table admin. There are consist of three

attribute which are id, user and password.

Table 3.6: Data for table item

Table 3.6 above shows the database for table item. There are consist of three

attribute which are itemname, remark and status.

33

3.6 Proof of Concept

In sport facility and equipment system, the concept that are used are priority.

From the explanation from chapter 2, the priority concept are used to the user. The

user that involved in the system are student and staff of University Sultan Zainal

Abidin (UniSZA) in Besut Campus. The concept are applied in the booking process.

From the normal basic of the booking system which are first come first serve which

means whom are faster book can booking first.

In this case the priority have took place beside first come first serve. The priority

were given to the user whom have the highest priority over the normal user. For

example, if there are one student and one staff want to book a court at the same time

and date, the priority were given to the staff and the student whom didn’t get to book

can book at the other time.

In this sport facility and equipment system, there are three types of priority level.

Level for staff (2), level for student of MKK/MPP (1) and level for normal student (0).

There are also the status level coded in the system. There are status pending (0),

booking approve (1) and booking not approve (2) applied in user and admin in

booking section. Moreover, status available (0), approve (1) and not available (2)

applied in admin in sport item section because admin manage sport item in the sport

facility and equipment system.

34

3.7 Summary

From this chapter, the methodology was explained in detail which is using

waterfall as a model for the system. The hardware and the software requirement also

had been explain through this chapter. The framework, context diagram (CD), data

flow diagram (DFD) level 0 and level 1, and entity relationship diagram (ERD) has

been presented. The framework and context diagram will be the general function

while the details are on data flow diagram level 0 and level 1. In addition there are the

list of the database design specification that are going to be used in the system as its

plays a main function in executing the system.

35

CHAPTER IV

IMPLEMENTATION AND RESULT

4.1 Implementation

4.1.1 Interfaces

This section will describe about the interface in the system. The system

interface is the interaction between the user and the system so that the user can make

the choice on the interface and the system will process it. The system has three user

which are student, staff and admin. There are interfaces for users and for admin.

4.1.1.1 Login User

Figure 4.1: Login Interface for user

36

Figure 4.1 shows the login interface for all user. Username and password are

required. If the user enter wrong username or password, the system will display a

pop-up error message as shown in Figure 4.2 below.

Figure 4.2: Pop-up error message for login interface

If the user have not have an account, they must signup first in order to login in Figure

4.3.

4.1.1.2 Signup User

Figure 4.3: Signup Interface for user

If the user enter right username and password, they will be directed to the user

homepage as shown in Figure 4.4 below.

37

4.1.1.3 User Homepage

Figure 4.4: User Homepage

Figure 4.4 above shows that the main page of the system when the user successfully

login. At the top of the page, the username of the user are displayed. User can

directly book the facility or the equipment when click “Book Here” button. It will be

directed to the book sports item page as Figure 4.5 below.

4.1.1.4 Book Sport Item

Figure 4.5: Book Sports Item page

38

From the Figure 4.5 above, the user can choose their desired sports item such

as badminton racket1, badminton racket2, court1, court2 and etc. In this page, there

are remark and status that shows the availability of the sport item in the sport centre.

By clicking “BOOK”, it will be directed to the booking details form in Figure 4.6

below.

4.1.1.5 Booking Form

Figure 4.6: Booking form details for user

From the Figure 4.6 above, the user need to fill in the form by providing their

details such as user type, quantity, start time and end time. The name of the item

chosen was already displayed in the table. When the user completed the form, click

“Submit” button to proceed to the next process.

39

Figure 4.7: Pop-up message for successfully book an item

4.1.1.6 Booking Details

Figure 4.8: Booking details page

Figure 4.8 above shows the booking details page that shows the status of the

user’s booking. This page also display the user detail that they have fill in the

booking details form. The ‘pending’ in the status shows that the booking they have

made are pending because admin are not approve yet but the status has been goes to

admin page.

40

4.1.1.7 Status Booking

Figure 4.9: Status booking page for user

Figure 4.9 above shows the status updated from the admin for the successful

booking. Means that the booking session at that date and time are free and no other

user book the same item at the same date and the same time. For the successful

booking, the status ‘pending’ before are changed to ‘booking approved’. When the

user choose another item, but admin reject their booking, in the status will written ‘not

available’ as shown in Figure 4.10.

41

Figure 4.10: Status booking page rejecting booking

If the user want to delete their booking when the status is ‘pending’ or

‘booking approve’, the user can click “delete” button to cancel booking. A pop-up

message will be appear as shown in Figure 4.11 below to confirm delete.

Figure 4.11: Pop-up message for confirm delete

42

Figure 4.12: Cancel booking had been deleted

From the Figure 4.12 above, the user has choose to delete ‘badminton racket1’ from

booking. After the user delete, the cancelled booking are not appear in the table as

shown in the figure 4.12 above.

4.1.1.8 User Profile

Figure 4.13: User profile page

43

For Figure 4.13 above, it shows the user profile. The user can change their profile

details by clicking “update” button.

4.1.1.9 User Logout

Figure 4.14: Logout page for user

In Figure 4.14 above, shows that the logout page for the user when the user click

‘logout’.

44

4.1.1.10 Admin Login

Figure 4.15: Admin login page

Figure 4.15 show the admin login page. An admin require to enter username and

password in order to login.

4.1.1.11 Admin homepage

Figure 4.16: Admin homepage

45

After login, an admin will be directed to the homepage admin. In this page,

admin can manage booking and manage sports item.

4.1.1.12 Admin List of Booking

Figure 4.17: List of booking page

Figure 4.16 shows the list of booking page. In this page, admin will manage

booking by deciding whether admin want to approve or reject the user’s booking. If

the user’s booking redundant with the other user, admin will chose the user with the

highest value of priority. By means, if a staff have a same booking details as a

student, admin will chose a staff. So, a student that have a redundant booking will be

rejected. On the student page, it will display ‘not available’ at the status as shown in

the previous user’s figure. When admin approve the booking, it will appear a pop-up

message as shown in Figure 4.18.

46

Figure 4.18: Pop-up message for booking approved

4.1.1.13 User’s Booking List

Figure 4.19: User’s booking list page

After admin approve a booking, it will be directed to the user’s booking list page as

shown in Figure 4.19 above. In this page, it will display the user ‘booking approve’

status only. Like in the previous user that choose court1, when admin approve, the

status change to ‘booking approve’ and the details are keep in the table.

47

Figure 4.20: Pop-up message for booking rejected

Figure 4.20 shows that when admin reject user booking by clicking “reject” button, a

pop-up message will appear as shown in figure above.

Figure 4.21: Empty details of booking in List of booking page

From the Figure 4.21 above, shows that when all of the booking have been

approved by admin, where the ‘booking approved’ status are keep in Figure 4.19.

Only the ‘pending’ status are goes into this page. This page is empty because there

are not have any status ‘pending’ of booking.

48

4.1.1.14 Sports Item List

Figure 4.22: Sport item list page

Figure 4.22 above shows the list of the sport item page. In this page, admin

will manage the sports item. If the sport centre has a new item, admin will add them

into the form. An admin also can update the information about the item and delete the

item if the item are no longer in the sport centre.

49

Figure 4.23: Pop-up message for data successfully add

Figure 4.23 above shows that the pop-up message when admin has successfully

adding the data of the item into the database.

Figure 4.24: Pop-up message for confirm update

Figure 4.24 above shows that the pop-up message when the user want to update the

details of their booking.

Figure 4.25: Pop-up message for confirm delete

50

Figure 4.25 above shows that the pop-up message appear when admin want to confirm

delete the chosen sport item.

4.1.1.15 Admin logout

Figure 4.26: Admin logout page

In Figure 4.26 above, shows that the logout page for admin when the admin click

‘logout’. The admin session has ended.

51

4.2 Test Case

Test case is used as a guideline for the users to use the system. The table below shows

the main test case produced from the Sport Facility and Equipment System.

4.2.1 Success Sign Up (User)

Step Procedure Expected Result Pass/Fail

1. Signup page ;

http://localhost/ludis/signup.php

Sign up page loaded. Pass

2. Enter details;

Username: Nabilah

Full Name: Nurul Nabilah

Password: Nabilah

Re-enter Password: Nabilah

User Type: student

User Id: 040433

Email:

nurulnabilah700@gmail.com

Phone No: 019-3990881

The details will be keep

into database.

Pass

3. Click “Signup” button Signup successful.

Proceed to login page.

Pass

Table 4.1: Test case for success user sign up

4.2.2 Fail Sign Up (User)

Step Procedure Expected Result Pass/Fail

1. Signup page;

http://localhost/ludis/signup.php

Sign up page loaded. Pass

2. Enter uncomplete details;

Username: Nabilah

Pass

http://localhost/ludis/signup.phpmailto:nurulnabilah700@gmail.comhttp://localhost/ludis/signup.php

52

Full Name: Nurul Nabilah

Password: //Empty or no value

Re-enter Password: nabilah

User Type: student

User Id: 040433

Email:

nurulnabilah700@gmail.com

Phone No: 019-3990881

3. Click “Signup” button Pop-up message appear. Pass

Table 4.2: Test case for fail user sign up

4.2.3 Success Login (User)

Step Procedure Expected Result Pass/Fail

1. Go to login page;

http://localhost/ludis/login.php

Login page loaded Pass

2. Enter details that valid;

Username: nabilah

Password: nabilah

Pass

3. Click “Login” button Login successful. Redirect

to user homepage

Pass

Table 4.3: Test case for success user login

mailto:nurulnabilah700@gmail.comhttp://localhost/ludis/login.php

53

4.2.4 Fail Login (User)

Step Procedure Expected Result Pass/Fail

1. Go to login page;

http://localhost/ludis/login.php

Login page loaded Pass

2. Enter details that invalid;

Username: nabilah

Password: 12345

Pass

3. Click “Login” button Pop-up message appear.

Pass

Table 4.4: Test case for fail user login

4.2.5 Success Login (Admin)

Step Procedure Expected Result Pass/Fail

1. Go to login page;

http://localhost/ludis/adminlogin.php

Login page loaded. Pass

2. Enter valid details;

Username: admin

Password: admin

Pass

3. Click “Login” Login successful.

Redirect to admin

homepage.

Pass

Table 4.5: Test case for success admin login

http://localhost/ludis/login.phphttp://localhost/ludis/adminlogin.php

54

4.2.6 Fail Login (Admin)

Step Procedure Expected Result Pass/Fail

1. Go to login page;

http://localhost/ludis/adminlogin.php

Login page loaded. Pass

2. Enter invalid details;

Username: admin

Password: 12345

Pass

3. Click “Login” Pop-up message appear Pass

Table 4.6: Test case for fail admin login

4.2.7 Update Profile (User)

Step Procedure Expected Result Pass/Fail

1. Go to profile page Profile page loaded. Pass

2. Click “update” button, enter edited

details.

Redirected to edit profile

page.

Pass

3. Click “submit” button Update success.

Redirected back to the

profile page.

Pass

Table 4.7: Test case for user update profile

4.2.8 Booking Item (User)

Step Procedure Expected Result Pass/Fail

1. Go to booking page and choose

item by selecting the desired item.

Item selection page

loaded.

Pass

2. Click “Book” button Proceed to booking

details page.

Pass

3. Enter booking details;

User type: student

Pass

http://localhost/ludis/adminlogin.php

55

Quantity: 2

Date: 2018-08-05

Start Time: 08:00

End Time: 09:00

4. Click “submit” button Booking data successfully

add.

Status = ‘pending’

Pass

Table 4.8: Test case for user booking item

4.2.9 Cancel booking (User)

Step Procedure Expected Result Pass/Fail

1. Go to booking details page Redirect to booking

details page.

Pass

2. Click “Cancel” button Pop-up messages show

“Are you sure you want to

cancel?”

Pass

3. Click “Yes” button Cancel successful Pass

Table 4.9: Test case for user cancel booking

4.2.10 Update booking (User)

Step Procedure Expected Result Pass/Fail

1. Go to booking details page Redirect to booking

details page.

Pass

2. Click “Update” button Pop-up messages show

“Confirm update?”

Pass

3. Click “Yes” button Update successful Pass

Table 4.10: Test case for user update booking

56

4.2.11 Approve booking (Admin)

Step Procedure Expected Result Pass/Fail

1. Go to approve page Redirect to approve page. Pass

2. Click “Approve” button Status = ‘pending’ changed

to status = ‘booking

approved’

Pass

Table 4.11: Test case for admin approve booking

4.2.12 Reject booking (Admin)

Step Procedure Expected Result Pass/Fail

1. Go to approve page Redirect to approve page. Pass

2. Click “Reject” button Status = ‘pending’ changed

to status = ‘booking not

approved’

Pass

Table 4.12: Test case for admin reject booking

4.2.13 Add Item (Admin)

Step Procedure Expected Result Pass/Fail

1. Go to add item page Add item loaded Pass

2. Enter details;

Item: net1

Remark: ada

Status: 0

Pass

3. Click “Add” button Add item successful.

Redirected to add item

page.

Pass

Table 4.13: Test case for admin add item

57

4.2.14 Update Item (Admin)

Step Procedure Expected Result Pass/Fail

1. Go to add item page Add item loaded Pass

2. Edit required details item name,

remark, or status.

Pass

3. Click “Update” button Update item successful.

Redirected to add item

page.

Pass

Table 4.14: Test case for admin update item

4.2.15 Delete Item (Admin)

Step Procedure Expected Result Pass/Fail

1. Go to add item page Add item page loaded Pass

2. Click “Delete” button Pop-up message “Are you

sure you want to delete?”

appear.

Pass

3. Click “Yes” button Delete successful.

Redirected to add item

page.

Pass

Table 4.15: Test case for admin delete item

58

4.3 Summary

Through this chapter, the design of the interfaces are explained from the user page

until administrator page in detail. In order to make the system smooth and functional,

all the test cases is tested carefully to get the expected result. In addition, the purpose

of the test case is to testing the system to ensure that the Sport Facility and Equipment

System works properly and meet the requirement and also for the system to be

acceptable to all user.

59

CHAPTER V

CONCLUSION

5.1 Introduction

This chapter presented the conclusion and the future work of the proposed project.

The aimed for this chapter is to summarize the whole project. The discussion to the

Sport Facility and Equipment System are included in this chapter. Constraints which

is limitation of this project are stated. In addition, in this chapter also will discussed

about the recommendation of the project in the future.

5.2 Discussion

The objectives that was stated in the first chapter was full filled. This project was

conducted to make the booking process easier to the user which are student and staff.

The system also follows the user requirements. For the third objective which is using

priority technique, the system cannot process the auto priority. There is need for an

admin to manually choose the user with the highest priority if there are redundant

booking data. The first come first serve and priority based method can make the result

more concrete, clear and reliable. Overall, the Sport Facility and Equipment System

will generate the sports item information and the user can see the status that displayed

in their booking details.

60

5.3 Limittion

Throughout the testing of the system, even after the system was developed, there

are some constraint and limitation happen to the system. Firstly, this system was

developed for the users in UniSZA Campus Besut. So, only the student and the staff

of UniSZA can use this system. Outsiders cannot use the system. Secondly, this

system are not completely using auto priority method. The user will receive pending

in status after they add their booking and have to wait for the admin to approve or

reject their booking. An admin will analyse and compare the booking details from the

pending status if there is a redundant booking from the user. It will take some time for

admin to checking all of the booking before approve it. If there is no redundant

booking, admin can easily approve the user’s booking. If not, admin have to reject the

booking.

5.4 Recommendations

The system was implemented for the user that can provide the user to book the

item of the facility or equipment from the sport centre in UniSZA without wasting

time and energy to book manually at the counter. Besides, this system allows admin

to manage the booking session and the item. So, for the recommendation for the

future works, this system should implement the auto priority queue to the user because

there are need in the auto priority in booking. It will also can make easier for admin

to monitor the system. Admin do not have to check all booking and decide himself

whether want to approve or reject user booking. The user also can view the slot for

the session or the timetable in order to book an item and they can see the availabilities

before booking.

5.5 Conclusion

Sport Facility and Equipment System project was aimed to computerize the

current manual booking system which will help both student and staff of UniSZA.

The user needs to register and login in order to book the sport facility or equipment.

Admin can manage the booking and manage the item of the sport facility and

61

equipment. This system make the user easily book the sports item without going to

the sports centre. The booking system is important to all of the users in UniSZA.

62

REFERENCES

Harchol‐Balter, M. (2013). Performance modelling and design of computer systems:

Queueing theory in action. 1st Edition. New York: Cambridge University Press.

Kilhwan, K. (2012). T‐preemptive priority queue and its application to the analysis of

an opportunistic spectrum access in cognitive radio networks. Journal of Computers

and Operations 68 Research, 39(7), pp. 1394‐1401.

Lombardi, M. and Milano, M. (2012). Optimal methods for resource allocation and

scheduling: A Cross‐Disciplinary Survey. International Journal of Constraints, 17(1),

pp. 51‐85.

Pinedo, M.L. (2012). Scheduling: theory, algorithms and systems. 4th Edition. New

York: Springer.

HP, (2010). An Introduction to load testing for web applications. Business

whitepaper.

63

APPENDIX A

Gantt Charts

Appendix A: Gantt Charts.

TASK WEEK

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Project Briefing

Topic Discussion and

Determination

Project Title Proposal

Proposal Writing:

Introduction

Proposal Writing:

Literature Review

Proposal Progress

Presentation & Evaluation

Discussion & Correction

Proposal

Proposed Solution

Methodology

Proof of Concept

Drafting Report of the

Proposal

Report Submission