Pritpal ppt

8/7/2019 Pritpal ppt

http://slidepdf.com/reader/full/pritpal-ppt 1/39

FOOD E-BOOKING Mid-Term Project Report(Jan-May 2011)

SUBMITTED BY:

NAME :PRITPAL SINGH SAINI Reg No:10804564

Program: MCA(Hons.)

Section:A3803

UNDER THE GUIDANCE OF:

EXTERNAL FACULTY COORDINATOR INTERNAL FACULTY COORDINATOR MR. LAKHWINDER SINGH GHUMAN MR. JASWINDER SINGH

PROJECT OFFICER FACULTY ADVISOR

LOVELY INFOTECH

DEPARTMENT OF

LOVELY SCHOOL OF TECHNOLOGY AND SCIENCES(LHST)

LOVELY PROFESSIONAL UNIVERSITY,

PHAGWARA



PROJECT: FOOD E-BOOKING

ACKNOWLEDGEMENT

The satisfaction that accompanies the successful completion of the task would be incomplete without the mention of the people whose Ceaseless

cooperation made it possible, whose constant guidance and encouragement crown all efforts with success. We are grateful to our Project Guide Mr.

Lakhwinder Singh Ghuman for the inspiration and the constructive suggestions that helped us in preparation of the project Food E-Booking System.

FOOD E-BOOKING TEAM

Pritpal Singh Saini

Sunny Gupta

Sagar Singh Rana

Mohd.Hasnain




1.

OVERVIEW FOOD E-BOOKING:

Food E-Booking is used to describe the relationship between a 'Customer' and a Restaurant Owner, who is Providing services to his customers. Food-E

Booking give support, Managing Control to the Restaurant owner through the internet and as well as provoding facility to the customers to Give and

recieve orders to there home or any place where they would like to. This project will be developed with the vision of enhancing relationship among

administrator, Customers and Restaurant Owners. It is concerned with Online Booking and Managing Process for both customers and the Restaurant

owners.. The motive of this project is to Provide convinence to both the customers and the respective Restaurant owners regarding the whole Online

process..

1.1 PROBLEMS/NEED

SLOW PROCESS: Manual working of managing all the details of orders and the generating documents like Reports etc is very tedious and slow.

DATA INCONSISTENCY: It is difficult to maintain the Orders Details ,i.e the orders that have been completed and the no of oders that are yet to be

completed all will be stored centerally.

MORE WAITING: Customers have to waite for long time as the only way to give the orders was to go to the particular Restaurant and place the order,

and waite for the order to be Completed, so with this system one can easily Place Orders and receive them.

DIFFICULTY IN SEARCHING RECORDS: It is difficult for anybody to search all the records of different customers and items as well as orders placed and Total

sales and purchase record.

CHOICE TO CUSTOMERS: Customes had less choice, as they are restricted to only one Restaurant but with this system customers can search for the

availability of the items in the different Restaurant and can place Orders according to there Requirements.

DIFFICULT TO ANALYSE SALES: As all the sales and purchase records are to be kept manually, reports Orders and sales.

PHYSICAL PRESENCE: for having any kind of Orders and Managements of Restaurant owner need to be physically present at the same location i.e where

the Restaurant is Physically Present.

PROBLEM OF HANDLING NUMBER ORDERS BOTH LARGE AND SMALL: Manually one is not capable to handle the orders sequentially.

PROBLEM IN PREPARING ON-DEMAND REPORTS: Preparing On-Demand reports manually are a tedious task.




1.2 SOLUTIONS/APPROACH

These steps will be considered to solve above mentioned problems.

Online registration

Communication among Restaurant Owners and the Administrator,as well as communication between Customer and Restaurant

Searching option is available for administrator

Help and support for all users

Easy to measure performance

Reporting Facility

Administration module for assigning and creating modules

Provide online Payment system for the orders to be delivered at home

2.BUSINESS RULES AND REQUIREMENTS:

BRID MODULE IMPORTANCE DESCRIPTION

1 ONLINE REGISTRATION 1 COMPLETE DETAILS FO CUSTOMERS AND

Restaurant Owners

SIGN IN AND SIGN UP OPTIONS FOR ALL TYPE OF

USERS

2 ADMINISTRATION 1 CREATE UPDATE USER

ADD USER ROLES

ADD MENU ITEMS/UPDATE

ACCESS RIGHTS

ASSSIGN ROLES

3 ITEMS MANAGEMENT 1 CREATE USER CATEGORIES




EDIT/UPDATE CATEGORIES

ADD NEW ITEMS

EDIT/UPDATE ITEMS

4 ORDER MANAGEMENT 1 PROPER WAY TO PLACE ORDERS PROVIDE CANCELATION OF ORDERS

5 PAYMENT MANAGEMENT 1 PROVIDE PAYMENT CHANNELS LIKE ONLINE OR

THROUGH CASH

6 RESTAURAUNT

MANAGEMENT

1 PROVIDED ADMIN TO MANAGE THE LIST OF

RESTERAUNTS

7 DATABASE MANAGEMENT 1 STORE ALL THE RECORDS IN THE RELEVCENT TABLES

EASY MAINTENANCE OF THE DATABASE

8 REPORTING 1 PROVIDE ADMIN. AND RESTERAUNT OWNERS TO

GENERATE REPORTS OF ORDERS ETC

9 SEARCHING 2 PROVIDE PROVISION FOR CUSTOMERS TO SEARCH

ITEM WISE OR RESTERAUNT WISE.

10 HELP AND SUPPORT 1 AVAILABLE FOR ALL KIND OF USERS

11 OFFERS MANAGEMENT 2 PROVIDE DETAILS OF OFFERS AVAILABLE TO THE

CUSTOMERS BY THE DIFFERENT RESTERAUNTS

Legend:

BRID=Business Requirement Identifier

1=Essential(Included in this Release)[Important & Urgent]2=Beneficial(But not Essential)-Optionally Included in this Release




3. EXCLUSIONS COST :

The Cost Management and Budgeting is excluded in the current release.

If the project will be extended on large scale then the cost factor on the resources will be included.

3.1 FEASIBILITY

Sending and receiving short messages service (SMS) between Customers and Restaurant is not feasible because of less number of resources.

If this project will move to industry level then it can be extended to add this module.

4. FOUNDATIONS AND IMPACT

4.1 ASSUMPTIONS

It is assumed that system will provide a user friendly interface which is easy to understand and manage.

User need to have basic knowledge of computers and internet.

Administrator has the complete right of accessing database and profiles of mentors and mentees.

Only registered user can place order

4.2 ISSUES AND CONSTRAINTS

Security requirement of all Transaction Taking Place for the orders

Outsiders cannot access this system.

Resteraunt owners cannot access each other’s profiles.

Database is fully accessible to administrator and partially accesible to the owners.

Feedback will be available only to the customers.

Customer has to select from the list of Restaurant available before placing order




After the order is placed then the Restaurant will send the OPT time to the customer

Customer have the right to cancel or update the order according to the given parameters:

1.Ordered will, be canceled only before the half time of the OPT(Order processing Time)

In the order management, all the times will be properlly managed like1.Date and time of Customers Order

2.Date and time when the delivery is to be made

3.Date time of When the actual delivery was made

4.Order processing Time

5.Mange the time for the order if the order is updated/changed or cancelled Before the registration of the Restraunt in the database, first the

request is to be made by the owner of the Restaurant and then after the verification done by the admin,then login credentials will be provided to the

owner

4.3 RISK ASSESSMENTS

Network failure can interrupt the communication among users/Customers/ Restaurant owner.

The availability of required number of users may affect the system, during the online communication process.

There can be Unavailability of the Bank server for Payments .

5. WORK FLOW DIAGRAMS

1.DFD(DATA FLOW DIAGRAM)

The DFD’s represents the flow of the data among the different processes, entities and records. There are 0-level (context diagram) and 1-level DFD’s. The 0-

level DFD represents the overall entities participating in the system excluding the detailed functionality of the system. Whereas 1-Level DFD represents the

module wise detailed functionality of the system.




1.LEVEL 0:




2.DFD LEVEL 1(ADMINISTRATION)




3.DFD LEVEL 1(ITEMS MANAGEMENT)




4.DFD LEVEL 1(REGISTRATION MANAGEMENT)




5 DFD LEVEL 1(ORDER MANAGEMENT)




6.DFD LEVEL 1(PAYMENTS MANAGEMENT)




7 COMPLETE DFD




5.2 ENTITY-RELATIONSHIP DIAGRAMS

E-R diagrams represent the different entities and their relationships it also defines the attributes associated with each entity. Entities are represented in

rectangle ( ), attributes are represented in ovals ( ) and relationships are represented by diamonds ( ). There are two types of E-R diagrams: General E-R

diagrams And Crow-Foot Notations.

1. ER DIAGRAM ITEM MANAGEMENT:




2. ER DIAGRAM ORDER MANAGEMENT:




3.REGISTRATION MODULE:




4.ER DIAGRAM OF ADMINISTRATION:




5.OVERALL ER DIAGRAM




5.3 FLOW CHART:

Flow charts are the pictorial representations of the Flow of data of the Event Management System. In flowcharts the Start/Stop is represented by eclipse ,

Input/output is shown in Rectangle , operations are shown in parallelogram , and diamonds represents the Decision box.

1.FLOW CHART FOR ADMINISTRATION




2.ITEM MANAGEMENT:




3.ORDER MANAGEMENT




4.PAYMENTS MANAGEMENT




5. REGISTRATION MANAGEMENT




7. COMPLETE FLOW CHART




5.4 CLASS DIAGRAM:

Class diagram describes the structure of the system, showing the different classes each with their attributes, methods and properties, and the relationship

between them.




6. FUNCTIONALITY:

LEVEL 1: IT DETERMINES DIFFERENCE BETWEEN ADMINISTRATOR AND OTHER USER INCLUDING CUSTOMERS AND RESTARAUNT OWNERS. IT WILL LEAD DIFFERENT USERS TO LEVEL 2

MODULES ACCORDING TO THEIR RIGHTS.

LEVEL 2: IT INCLUDES VARIOUS MODULES WITH DIFFERENT FUNCTIONALITY AND EACH USER CAN ACCESS THESE M ODULES ACCORDING TO HIS/HER RIGHTS. THIS LEVEL INCLUDES

FOLLOWING MODULES:

1. ADMINISTRATION (AUTHENTICATION AND AUTHORIZATION)

This module belong to higher authority people will have full right to access and change staff

members, food resources and other module contents. Main responsibilities of the administrator are given

below:




1. Create/Edit Roles

2.Role Assignment

3.Access Rights

4.Create/Edit Menus/Links

5.User Management

6.Restaurant Management

2. REGISTRATION:1. Customer registration

2. And Restaurant registration

This module will include the registration of the Customer as well as Restaurant.

3. USER MANAGEMENT:

1. Customer Details2. Staff Details

3. Restaurant Details

This module will contain all details of registered customers, registered Restaurants and their Staffs and this module can be accessed by the

administrator and those staff members which are assigned to

handle this module.

4. ORDER MANAGEMENT:

This module will contain all details of Orders, Reorders, Order type and Canceled order.

5. OFFERS MANAGEMENT:

This module will contain all details of all special offers like new items, Discounts, Special

Coupons etc. And in this module we collect customer information automatically and send special offers

to the customers.




We divide the offers into two categories:-

1. Category-wise offers and

2. Item-wise offers

6. RESTAURANT MANAGEMENT:

In this module we manage all the activities of the entire restaurant like adding/deleting items in

their menu card, Rate changes of their items, or location if it is changed etc.

7. ITEM MANAGEMENT:

In this module we manage different kinds of items with the flexibility of different parameters such as

description, price, features etc.

1. Creating and editing items

2. Categorizing items

8. PAYMENT MANAGEMENT:

In this module we will manage all details regarding payments. Like payment mode are through

Check, Cash, online through Credit card, or Debit card.

9. SEARCHING:

In this module the user can search rapidly and efficiently for restaurant, food Items

10. FEEDBACK:In this module customer should be able to comment about their experience at any restaurant

and give them between one and five stars. Other users should be able to view these comments.

LEVEL 3: THIS IS THE LAST MODULE WHICH REFERS TO THE REPORTING SESSION AFTER THE EVENT IS COMPLETED I.E. IT INCLUDES THE ACTIVITIES LIKE TAKING

PRINT OUTS OF ANY REPORTS. IT IS ACCESSIBLE TO SELECTED USERS.




11. REPORTING:

It will include the preparation of reports. These reports will contain the information about the salesand manufactured item. It will include:

1. Print-out option for report.

2. Item Descriptions




7. DATABASE DIAGRAM




8.DESIGN :




9. NOTATIONS/NAMING CONVENTIONS

WE WILL BE FOLLOWING THE FOLLOWING STANDARDS:

1. We will be Using Pascal casing for Class names

public class HelloWorld

{

...

}

2. Use Pascal casing for Method names

void SayHello(string name)

{

...

}

3. Use Camel casing for variables and method parameters

int totalCount = 0;

void SayHello(string name)

{

string fullMessage = "Hello " + name;

...

}

4. Use the prefix “I” with Camel Casing for interfaces ( Example: IEntity )




5. Use Meaningful, descriptive words to name variables. Do not use abbreviations.

string address

int Salary

6. Use names like index, temp One exception in this case would be variables used for iterations in loops:

for ( int i = 0; i < count; i++ )

{

...

}

7. controls (including third party controls) that we will be using Will be named according to as shown in the table below:

Eg: For textbox for input of name will be written as: txtName




Control Prefix

Label Lbl

TextBox Txt

DataGrid Dtg

Button Btn

ImageButton Imb

Hyperlink Hlk

DropDownList Ddl

ListBox Lst

DataList Dtl

Repeater Rep

Checkbox Chk

CheckBoxList Cbl

RadioButton Rdo

RadioButtonList Rbl

Image Img

Panel Pnl

PlaceHolder Phd

Table Tbl

Validators Val

8. Indentation and Spacing.

Pritpal ppt

Documents

Transcript of Pritpal ppt