ABSTRACT

The Online Food Ordering System described in this document has been
designed to fill a specific niche in the market by providing small restaurants
with the ability to offer their customers an online ordering option without
having to invest large amounts of time and money in having custom software
designed specifically for them. The system, which is highly customizable,
allows the restaurant employees to easily manage the site content, most
importantly the menu, themselves through a very intuitive graphical interface.
The website, which is the only component seen by the restaurant customers, is
then built dynamically based on the current state of the system, so any changes
made are reflected in real time. Visitors to the site, once registered, are then able
to easily navigate this menu, add food items to their order, and specify delivery
options with only a few clicks, greatly simplifying the ordering process. Back in
the restaurant, placed orders are promptly retrieved and displayed in an easily
readable format for efficient processing.
The purpose of this document is to provide in-depth descriptions of design and
implementation details of the system, as well as descriptions of all available
functionality and plans for evolution. In addition, user manuals and trouble-
shooting tips have been included for all three components to give the reader a
clear idea of intended typical use cases for the system.
Chapter 1 Introduction
The Online Food Ordering System has been developed to override the
problems prevailing in the practicing manual system. This software is supported
to eliminate and, in some cases, reduce the hardships faced by this existing
system. Moreover, this system is designed for the particular need of the
company to carry out operations in a smooth and effective manner. The
application is reduced as much as possible to avoid errors while entering the
data. It also provides error message while entering invalid data. No formal
knowledge is needed for the user to use this system. Thus, by this all it proves it
is user-friendly. Online Food Ordering System, as described above, can lead to
error free, secure, reliable and fast management system. It can assist the user to
concentrate on their other activities rather to concentrate on the record keeping.
Thus, it will help organization in better utilization of resources.
Every organization, whether big or small, has challenges to overcome and
managing the information of Category, Food Item, Order, Payment, Confirm
Order. Every Online Food Ordering System has different Food Item needs;
therefore, we design exclusive employee management systems that are adapted
to your managerial requirements. This is designed to assist in strategic planning
and will help you ensure that your organization is equipped with the right level
of information and details for your future goals. Also, for those busy executives
who are always on the go, our systems come with remote access features, which
will allow you to manage your workforce anytime, at all times. These systems
will ultimately allow you to better manage resources.

1.1 Purpose
The purpose of Online Food Ordering System is to automate the existing
manual system by the help of computerized equipment’s and full-fledged
computer software, fulfilling their requirements, so that their valuable
data/information can be stored for a longer period with easy accessing and
manipulation of the same. The required software and hardware are easily
available and easy to work with.
Online Food Ordering System, as described above, can lead to error free,
secure, reliable and fast management system. It can assist the user to
concentrate on their other activities rather to concentrate on the record keeping.
Thus it will help organization in better utilization of resources. The organization
can maintain computerized records without redundant entries. That means that
one need not be distracted by information that is not relevant, while being able
to reach the information.
The aim is to automate its existing manual system by the help of computerized
equipment’s and full-fledged computer software, fulfilling their requirements,
so that their valuable data/information can be stored for a longer period with
easy accessing and manipulation of the same. Basically the project describes
how to manage for good performance and better services for the clients.

1.2 Background
The background of the Project on Online Food Ordering System is to manage
the details of Food Item, Category, Customer, Order, Confirm Order. It manages
all the information about Food Item, Payment, Confirm Order, Food Item. The
project is totally built at administrative end and thus only the administrator is
guaranteed the access. The purpose of the project is to build an application
program to reduce the manual work for managing the Food Item, Category,
Payment, Customer. It tracks all the details about the Customer, Order, Confirm
Order.
Functionalities provided by Online Food Ordering System are as follows:
 Provides the searching facilities based on various factors. Such as Food
Item, Customer, Order, Confirm Order
 Online Food Ordering System also manage the Payment details online for
Order details, Confirm Order details, Food Item.
 It tracks all the information of Category, Payment, Order etc
 Manage the information of Category
 Shows the information and description of the Food Item, Customer
 To increase efficiency of managing the Food Item, Category
 It deals with monitoring the information and transactions of Order.
 Manage the information of Food Item
 Editing, adding and updating of Records is improved which results in
proper resource management of Food Item data.
 Manage the information of Order
 Integration of all records of Confirm Order.
1.3 Scope
It may help collecting perfect management in detail. In a very short time, the
collection will be obvious, simple and sensible. It will help a person to know the
management of passed year perfectly and vividly. It also helps in current all
works relative to Online Food Ordering System. It will be also reduced the cost
of collecting the management & collection procedure will go on smoothly.
Our project aims at Business process automation, i.e. we have tried to
computerize various processes of Online Food Ordering System.
 In computer system the person has to fill the various forms and number of
copies of the forms can be easily generated at a time.
 In computer system, it is not necessary to create the manifest but we can
directly print it, which saves our time.
 To assist the staff in capturing the effort spent in their respective working
areas.
 To utilize resources in an efficient manner by increasing their
productivity through automation.
 The system generates types of information that can be used for various
purposes.
 It satisfy the user requirement.
 Be easy to understand by the user and operator.
 Be easy to operate.
 Have a good user interface.
 Be expandable.
 Delivered on schedule within the budget.

1.4 Definitions, Acronyms and Abbreviations

Definitions
An online food ordering system can be defined as software that allows
restaurant businesses to accept and manage orders placed over the internet.
Online ordering systems generally consists of 2 main components. First is a
website or mobile app for hungry customers to view the restaurant's dishes and
place an online order. Second is an admin management interface for the
restaurants to receive and manage the customer's orders.

Acronyms
The customer ordering website or app will generally have several key
requirements to function adequately. These requirements are:
 Accessible across all devices from tablets to PCs.
 Easily search the restaurant's menu and see what is available
 Configure their order type such as delivery or pickup
 Choose when they would like to receive the order
 Make online payments via credit card, bank transfer, etc.
 Stay up to date on the status of the orders they have placed
 View all their past orders and quickly re-order their favorite items

Abbreviations
OFOS- Online Food Ordering System
SRS- Software Requirement Specification
GUI- Graphical User Interface

1.5 References
 https://docs.python.org/3/reference/
 https://www.sqlite.org/index.html
 https://www.tutorialspoint.com/django/index.html
 https://www.w3schools.com/python/python_classes.asp/
 https://www.w3schools.com/html/
 https://www.w3schools.com/tags/tag_object.asp
 https://www.w3schools.com/w3css/default.asp
 https://www.python.org/about/gettingstarted/
 https://www.tutorialspoint.com/python/index.html
Chapter 2 Requirements &
Constrains
2.1 Functional Requirements
As can be seen in the system model diagramed above, each of the three system
components essentially provides a layer of isolation between the end user and
the database. The motivation behind this isolation is twofold. Firstly, allowing
the end user to interact with the system through a rich interface provide a much
more enjoyable user experience, particularly for the non-technical users which
will account for the majority of the system’s users. In addition, this isolation
layer also protects the integrity of the database by preventing users from taking
any action outside those which the system is designed to handle. Because of this
design pattern, it is essential to enumerate exactly which functions a user will be
presented and these functions are outlined below, grouped by component.
2.1.1 Modules of Online Food Ordering System
 Food Item Management Module: Used for managing the Food Item
details.
 Confirm Order Module : Used for managing the details of Confirm Order
 Payment Module : Used for managing the details of Payment
 Category Management Module: Used for managing the information and
details of the Category.
 Customer Module : Used for managing the Customer details
 Order Module : Used for managing the Order information
 Login Module: Used for managing the login details
 Users Module : Used for managing the users of the system

2.1.2 Input Data and Validation of Project

  All the fields such as Food Item, Customer, Confirm Order are validated
and does not take invalid values
 Each form for Food Item, Category, Payment can not accept blank value
fields
 Avoiding errors in data
 Controlling amount of input
 Integration of all the modules/forms in the system.
 Preparation of the test cases.
 Preparation of the possible test data with all the validation checks.
 Actual testing done manually.
 Recording of all the reproduced errors.
 Modifications done for the errors found during testing.
 Prepared the test result scripts after rectification of the errors.
 Functionality of the entire module/forms.
 Validations for user input.
 Checking of the Coding standards to be maintained during coding.
 Testing the module with all the possible test data.
 Testing of the functionality involving all type of calculations etc.
 Commenting standard in the source files.

2.1.3 Output Project & Design

In a very competitive world that we are, a good and attractive GUI is needed to
make customers and administrators enjoy the services of a system, which would
serve as a system to increase productivity in supermarket business below are
previews of the output designs.

2.1.4 Features of the System

 Product and Component based
 Creating & Changing Issues at ease
  Query Issue List to any depth
 Reporting & Charting in more comprehensive way
 User Accounts to control the access and maintain security
 Simple Status & Resolutions
 Multi-level Priorities & Severities.
 Targets & Milestones for guiding the programmers
 Attachments & Additional Comments for more information
 Robust database back-end
 Various level of reports available with a lot of filter criteria’s
 It contain better storage capacity.
 Accuracy in work.
 Easy & fast retrieval of information.
 Well designed reports.
 Decrease the load of the person involve in existing manual system.
 Access of any information individually.
 Work becomes very speedy.
 Easy to update information
2.1.5 Software Requirement Specification
The Software Requirements Specification is produced at the culmination of the
analysis task. The function and performance allocated to software as part of
system engineering are refined by establishing a complete information
description, a detailed functional and behavioral description, an indication of
performance requirements and design constraints, appropriate validation
criteria, and other data pertinent to requirements.
The proposed system has the following requirements:
 System needs store information about new entry of Food Item.
 System needs to help the internal staff to keep information of Category
and find them as per various queries.
 System need to maintain quantity record.
 System need to keep the record of Customer.
 System need to update and delete the record.
 System also needs a search area.
 It also needs a security system to prevent data.
2.1.6 Admin Interface Specifications
Each of the system components will have their own unique interface. These are
described below.
The Web Ordering System
Users of the web ordering system, namely restaurant customers, must be
provided the following functionality:
 Create an account.
 Manage their account.
 Log in to the system.
 Navigate the restaurant’s menu.
 Select an item from the menu.
 Customize options for a selected item.
 Add an item to their current order.
 Review their current order.
 Remove an item/remove all items from their current order.
 Provide delivery and payment details.
 Place an order.
 Receive confirmation in the form of an order number.
As the goal of the system is to make the process of placing an order as simple as
possible for the customer, the functionality provided through the web ordering
system is restricted to that which most pertinent to accomplish the desired task.
All of the functions outlined above, with the exceptions of account creation and
management, will be used every time a customer places an order. By not
including extraneous functions, I am moving towards my goal of simplifying
the ordering process.
Menu Management System
The menu management system will be available only to restaurant employees
and will, as the name suggests, allow them to manage the menu that is displayed
to users of the web ordering system. The functions afforded by the menu
management system provide user with the ability to, using a graphical interface:
 Add a new/update/delete vendor to/from the menu.
 Add a new/update/delete food category to/from the menu.
 Add a new/update/delete food item to/from the menu.
 Add a new/update/delete option for a given food item.
 Update price for a given food item.
 Update default options for a given food item.
  Update additional information (description, photo, etc.) for a given food
item.
It is anticipated that the functionality provided by this component will be one of
the first things noted by the restaurant user, as they will have to go through it to
configure their menu, etc. before beginning to actually take orders. Once
everything is initially configured, however, this component will likely be the
least used, as menu updates generally do not occur with great frequency.
Order Retrieval System
Of the three components, the order retrieval system is functionally the simplest.
Like the menu management system, it is designed to be used only by restaurant
employees, and provides the following functions:
 Retrieve new orders from the database.
 Display the orders in an easily readable, graphical way.
 Mark an order as having been processed and remove it from the list of
active orders.

2.1.7 User Interface Specifications

Each of the system components will have their own unique interface. These are
described below.

Web Ordering System

Users of the web ordering system will interact with the application through a
series of simple forms. Each category of food has its own form associated with
it which presents a drop down menu for choosing which specific item from the
category should be added to the order, and a series of check boxes and radio
buttons for selecting which options are to be included. Adding an item to the
order is accomplished by a single button click. Users select which category of
food they would like to order, and therefore which form should be displayed, by
navigating a menu bar, an approach which should be familiar to most users.
Entering delivery and payment deals is done in a similar manner. The user is
presented with a form and must complete the required fields, which include
both drop down and text boxes, before checking out and receiving a
confirmation number. One thing worth noting here is that whenever possible
drop down boxes and buttons were used over freeform input in order to both
simplify the ordering process and reduce the possibility of and SQL injection
attempt.
Menu Management System
User interaction with the menu management system is similar to that with the
web ordering system. Users navigate a tree structure to find the vendor,
category, or specific food item that they would like to modify and after making
their selection they are presented with a form which displays all of the current
fields and values associated with that item, all of which can be modified or
removed. The form also presents buttons which allow the addition of new fields
and values. Unlike the web ordering system, however, most of the input here
will be freeform, specifically in the form of text boxes, since there is no finite
set of fields which could be added. This does not raise a major concern though,
as input sanitation will be performed, and the user, who is assumed to be a
restaurant employee, is less likely to be malicious than a web user.

Order Retrieval System

User interaction with the order retrieval will be very simple. The application
will automatically fetch new orders from the database at regular intervals and
display the order numbers, along with delivery time, in a panel on the left hand
side of the application. To view the details of an order, the user must simply
click on that order number, which will populate the right-hand panel with the
details, displayed in an easy to read and navigate tree structure. This structure
can intuitively be expanded and collapsed to display only the desired
information. Finally, once and order is processed, the user clicks a single button,
labeled “Processed”, to remove it from the list of active orders.

2.2 Non-functional Requirements

Because the design patterns of the Online Ordering System are pretty much the
standard for a web application, the non-functional requirements of the system
are very straightforward. Although written using Google Web Toolkit, the
application is cross-compiled to HTML and JavaScript, along with a PHP
backend, all of which are supported by any reasonably well maintained web
server, although I would recommend Apache2, and particularly the free XAMPP
distribution.
All of the application data is stored in a PostgreSQL database, and therefore a
PostgreSQL server must also be installed on the host computer. As with
Apache2, this software is freely available and can be installed and run under
most operating systems.
The server hardware can be any computer capable of running both the web and
database servers and handling the expected traffic. For a restaurant that is not
expecting to see much web traffic, or possibly doing only a limited test run, an
average personal computer may be appropriate. Once the site starts generating
more hits, though, it will likely be necessary to upgrade to a dedicated host to
ensure proper performance. The exact cutoffs will need to be determined
through a more thorough stress testing of the system.
2.2.1 System Evolution
As mentioned in the system model, at the heart of the entire ordering system is
the database. In fact, the system could be completely operational using nothing
but the database and an appropriate shell utility, assuming that all users are well-
versed in SQL and enjoy using it to order food. While this would be a bit
extreme, it does illustrate the point that the one part of the system which will
stay relatively constant is the database. On the other hand, it is very probable
that the other components will continue to evolve with time. For example, with
the booming popularity of mobile applications, I would really like to make the
web interface available as a phone application as well. Also it may make sense
to at some point migrate the menu management and order retrieval systems to
web, or even mobile, applications as well, as some users may prefer to use them
as such.
I am also certain that if this system goes into actual use, many requests will
arise for additional features which I had not previously considered, but would
be useful to have. For this reason, I feel as though the application can be
constantly evolving, which I consider a very good thing.
Identification of need:
The old manual system was suffering from a series of drawbacks. Since whole
of the system was to be maintained with hands the process of keeping,
maintaining and retrieving the information was very tedious and lengthy. The
records were never used to be in a systematic order. There used to be lots of
difficulties in associating any particular transaction with a particular context. If
any information was to be found it was required to go through the different
registers, documents there would never exist anything like report generation.
There would always be unnecessary consumption of time while entering records
and retrieving records. One more problem was that it was very difficult to find
errors while entering the records. Once the records were entered it was very
difficult to update these records.
The reason behind it is that there is lot of information to be maintained and
have to be kept in mind while running the business .For this reason we have
provided features Present system is partially automated (computerized),
actually existing system is quite laborious as one has to enter same
information at three different places.

Following points should be well considered:

 Documents and reports that must be provided by the new system: there
can also be few reports, which can help management in decision-making
and cost controlling, but since these reports do not get required attention,
such kind of reports and information were also identified and given
required attention.
 Details of the information needed for each document and report.
 The required frequency and distribution for each document.
 Probable sources of information for each document and report.
With the implementation of computerized system, the task of keeping records in
an organized manner will be solved. The greatest of all is the retrieval of
information, which will be at the click of the mouse. So the proposed system
helps in saving the time in different operations and making information flow
easy giving valuable reports.

2.2.2 Feasibility Study

After doing the project Online Food Ordering System, study and analyzing all
the existing or required functionalities of the system, the next task is to do the
feasibility study for the project. All projects are feasible - given unlimited
resources and infinite time.
Feasibility study includes consideration of all the possible ways to provide a
solution to the given problem. The proposed solution should satisfy all the user
requirements and should be flexible enough so that future changes can be easily
done based on the future upcoming requirements.
A. Economical Feasibility
 This is a very important aspect to be considered while developing a
project. We decided the technology based on minimum possible cost
factor.
 All hardware and software cost has to be borne by the
organization.
 Overall we have estimated that the benefits the organization is
going to receive from the proposed system will surely overcome
the initial costs and the later on running cost for system.

B. Technical Feasibility
This included the study of function, performance and constraints that may
affect the ability to achieve an acceptable system. For this feasibility
study, we studied complete functionality to be provided in the system, as
described in the System Requirement Specification (SRS), and checked if
everything was possible using different type of frontend and backend
plaformst.

C. Operational Feasibility
No doubt the proposed system is fully GUI based that is very user
friendly and all inputs to be taken all self-explanatory even to a layman.
Besides, a proper training has been conducted to let know the essence of
the system to the users so that they feel comfortable with new system. As
far our study is concerned the clients are comfortable and happy as the
system has cut down their loads and doing.

Chapter 3 System Design

In this phase, a logical system is built which fulfils the given requirements.
Design phase of software development deals with transforming the client’s
requirements into a logically working system. Normally, design is performed in
the following in the following two steps:
1. Primary Design Phase:
In this phase, the system is designed at block level. The blocks are
created on the basis of analysis done in the problem identification
 phase. Different blocks are created for different functions emphasis is
put on minimising the information flow between blocks. Thus, all
activities which require more interaction are kept in one block.

2. Secondary Design Phase:

In the secondary phase the detailed design of every block is performed.

The general tasks involved in the design process are the following:
1. Design various blocks for overall system processes.
2. Design smaller, compact and workable modules in each block.
3. Design various database structures.
4. Specify details of programs to achieve desired functionality.
5. Design the form of inputs, and outputs of the system.
6. Perform documentation of the design.
7. System reviews.
3.1 User Interface Design
User Interface Design is concerned with the dialogue between a user and the
computer. It is concerned with everything from starting the system or logging
into the system to the eventually presentation of desired inputs and outputs.
The overall flow of screens and messages is called a dialogue.
The following steps are various guidelines for User Interface Design:
1. The system user should always be aware of what to do next.
2. The screen should be formatted so that various types of information,
instructions and messages always appear in the same general display
area.
3. Message, instructions or information should be displayed long
enough to allow the system user to read them.
4. Use display attributes sparingly.
5. Default values for fields and answers to be entered by the user should
be specified.
6. A user should not be allowed to proceed without correcting an error.
 7. The system user should never get an operating system message or
fatal error.
Preliminary Product Description:
The first step in the system development life cycle is the preliminary
investigation to determine the feasibility of the system. The purpose of the
preliminary investigation is to evaluate project requests. It is not a design study
nor does it include the collection of details to describe the business system in all
respect. Rather, it is the collecting of information that helps committee members
to evaluate the merits of the project request and make an informed judgment
about the feasibility of the proposed project.
Analysts working on the preliminary investigation should accomplish the
following objectives:
 Clarify and understand the project request
 Determine the size of the project.
 Assess costs and benefits of alternative approaches.
 Determine the technical and operational feasibility of alternative
approaches.
 Report the findings to management, with recommendations outlining the
acceptance or rejection of the proposal.

Benefit to Organization
The organization will obviously be able to gain benefits such as savings in
operating cost, reduction in paperwork, better utilization of human resources
and more presentable image increasing goodwill.
The Initial Cost
The initial cost of setting up the system will include the cost of hardware
software (OS, add-on software, utilities) & labour (setup & maintenance). The
same has to bear by the organization.
Running Cost
Besides, the initial cost the long term cost will include the running cost for the
system including the AMC, stationary charges, cost for human resources, cost
for update/renewal of various related software.
Need for Training
The users along with the administrator need to be trained at the time of
implementation of the system for smooth running of the system. The client will
provide the training site.
We talked to the management people who were managing a the financial issues
of the center, the staff who were keeping the records in lots of registers and the
reporting manager regarding their existing system, their requirements and their
expectations from the new proposed system. Then, we did the system study of
the entire system based on their requirements and the additional features they
wanted to incorporate in this system.
Reliable, accurate and secure data was also considered to be a complex task
without this proposed system. Because there was no such record for keeping
track of all the activities, which was done by the Online Food Ordering System
on the daily basis.
The new system proposed and then developed by me will ease the task of the
organization in consideration. It will be helpful in generating the required
reports by the staff, which will help them to track their progress and services.
Thus, it will ease the task of Management to a great extent as all the major
activities to be performed, are computerized through this system.
Project Category
Relational Database Management System (RDBMS) : This is an RDBMS based
project which is currently using MySQL for all the transaction statements.
MySQL is an open source RDBMS System.
Brief Introduction about RDBSM :
A relational database management system (RDBMS) is a database management
system (DBMS) that is based on the relational model as invented by E. F. Codd,
of IBM's San Jose Research Laboratory. Many popular databases currently in
use are based on the relational database model.
RDBMSs have become a predominant choice for the storage of information in
new databases used for financial records, manufacturing and logistical
information, personnel data, and much more since the 1980s. Relational
databases have often replaced legacy hierarchical databases and network
databases because they are easier to understand and use. However, relational
databases have been challenged by object databases, which were introduced in
an attempt to address the object-relational impedance mismatch in relational
database, and XML databases.

3.2 Implementation Methodology

Model View Controller or MVC as it is popularly called, is a software design
pattern for developing web applications. A Model View Controller pattern is
made up of the following three parts:
 Model - The lowest level of the pattern which is responsible for
maintaining data.
 View - This is responsible for displaying all or a portion of the data to
the user.
 Controller - Software Code that controls the interactions between
the Model and View.

MVC is popular as it isolates the application logic from the user interface
layer and supports separation of concerns. Here the Controller receives all
requests for the application and then works with the Model to prepare any
data needed by the View. The View then uses the data prepared by the
Controller to generate a final presentable response. The MVC abstraction can
be graphically represented as follows.
MVC (Model View Controller Flow) Diagram
DATA FLOW DIAGRAMS

Project Planning:
Software project plan can be viewed as the following:
1) Within the organization: How the project is to be implemented?
What are various constraints (time, cost, staff)? What is market
strategy?

2) With respect to the customer: Weekly or timely meetings with the

customer with presentation on status reports. Customers feedback is
also taken and further modification and developments are done.
Project milestones and deliverables are also presented to the
customer.
For a successful software project, the following steps can be followed:

 Select a project

o Identifying project’s aims and objectives

o Understanding requirements and specification

o Methods of analysis, design and implementation

o Testing techniques

o Documentation
 Project milestones and deliverables
o Budget allocation
o Exceeding limits within control
 Project Estimates
o Cost
o Time
o Size of code
o Duration
 Resource Allocation
o Hardware
o Software
o Previous relevant project information
o Digital Library
 Risk Management
o Risk avoidance
o Risk detection

Project Scheduling:
An elementary Gantt chart or Timeline chart for the development plan is given
below. The plan explains the tasks versus the time (in weeks) they will take to
complete.

January February March

 Requiremen
t Gathering
Analysis

Design

Coding

Testing

Implement

W1 W2 W3 W4 W1 W2 W3 W4 W1 W2 W3 W4

N.B. “W” are weeks of the months, for i =1, 2, 3, 4

Cost estimation of the project:

Software cost comprises a small percentage of overall computer-based system
cost. There are a number of factors, which are considered, that can affect the
ultimate cost of the software such as - human, technical, Hardware and Software
availability etc.
The main point that was considered during the cost estimation of project was its
sizing. In spite of complete software sizing, function point and approximate
lines of code were also used to "size" each element of the Software and their
costing.
The cost estimation done by me for Project also depend upon the baseline
metrics collected from past projects and these were used in conjunction with
estimation variables to develop cost and effort projections.
We have basically estimated this project mainly on two bases –
1. Effort Estimation - This refers to the total man-hours required for the
development of the project. It even includes the time required for doing
documentation and user manual.
2. Hardware Required Estimation - This includes the cost of the PCs
and the hardware cost required for development of this project.
Tools/Platform, Hardware and Software Requirement specifications:
Software Requirements

Name of component Specification

Operating System Windows 8.1, Windows 10, Windows
11, Linux
Language Java 8 Runtime Environment
Database MySQL Server
Browser Any of Mozilla, Opera, Chrome etc
Web Server Tomcat 7
Software Development Kit Java JDK 1.7 or Above
Scripting Language Enable JSP (Java Server Pages)
Database JDBC Driver MySQL Jconnector
Hardware Requirements

Name of component Specification

Processor Intel i3 or more
RAM 2 GB or more
Hard disk 20 GB
Monitor 15” color monitor
Keyboard 122 keys

Project Profile
There has been continuous effort to develop tools, which can ease the process of
software development. But, with the evolving trend of different programming
paradigms today’s software developers are really challenged to deal with the
changing technology. Among other issues, software re-engineering is being
regarded as an important process in the software development industry. One of
the major tasks here is to understand software systems that are already
developed and to transform them to a different software environment.
Generally, this requires a lot of manual effort in going through a program that
might have been developed by another programmer. This project makes a novel
attempt to address the issued of program analysis and generation of diagrams,
which can depict the structure of a program in a better way. Today, UML is
being considered as an industrial standard for software engineering design
process. It essential provides several diagramming tools that can express
different aspects/ characteristics of program such as
Use cases: Elicit requirement from users in meaningful chunks. Construction
planning is built around delivering some use cases n each interaction basis for
system testing.
Class diagrams: shows static structure of concepts, types and class. Concepts
how users think about the world; type shows interfaces of software components;
classes shows implementation of software components.
Interaction diagrams: shows how several objects collaborate in single use
case.
Package diagram: show group of classes and dependencies among them.
State diagram: show how single object behaves across many use cases.
Activity diagram: shows behavior with control structure. Can show many
objects over many uses, many object in single use case, or implementations
methods encourage parallel behavior, etc.
The end-product of this project is a comprehensive tool that can parse any
vb.net program and extract most of the object oriented features inherent in the
program such as polymorphism, inheritance, encapsulation and abstraction.
UML:
UML stands for Unified Modeling Language is the successor to the wave of
Object Oriented Analysis and Design (OOA&D) methods that appeared in the
late 80’s. It most directly unifies the methods of Booch, Rumbaugh (OMT) and
Jacobson. The UML is called a modeling language, not a method. Most methods
consist at least in principle, of both a modeling language and a process. The
Modeling language is that notation that methods used to express design.
Notations and meta-models:
The notation is the graphical stuff; it is the syntax of the modeling language. For
instance, class diagram notation defines how items are concepts such as class,
association, and multiplicity is represented. These are:
Class Diagram: The class diagram technique has become truly central within
object- oriented methods. Virtually every method has included some variation
on this technique. Class diagram is also subject to the greatest range of
modeling concept. Although the basic elements are needed by everyone,
advanced concepts are used less often. A class diagram describes the types of
objects in the system and the various kinds of static relationship that exist
among them. There are two principal kinds of static relationship:
 Association
 Subtype
Class diagram also show the attributes and operations of a class and the
constraints that apply to the way objects are connected.
Association: Association represent between instances of class. From the
conceptual perspective, association represents conceptual relations between
classes. Each association has two roles. Each role is a direction on the
association. A role also has multiplicity, which is a indication of how many
object may participate in the given relationship.
Generalization: A typical example of generalization evolves the personal and
corporate customer of a business. They have differences but also many
similarity. The similarities can be placed in generalization with personal
customer and corporate customer sub type.
Aggregation: aggregation is the part of relationship. It is like saying a car has
engine and wheels as its parts. This sounds good, but difficult thing is
considering, what is the difference is aggregation and association.
Interaction: interaction diagrams are models that describes how groups of
objects collaboration in some behavior.
Typically, an interaction diagram captures the behavior a single use cases. The
diagram shows a number of example objects and the messages that are passed
between these objects in use cases. These are following approaches with simple
use case that exhibits the following behavior.
Objects can send a message to another. Each message is checks with given stock
item. There are two diagrams: Sequence and Collaboration diagram.
Package Diagram: One of the oldest questions in software methods is: how do
you break down a large system into smaller systems? It becomes difficult to
understand and the changes we make to them.
Structured methods used functional decomposition in which the overall system
was mapped as a function broken down into sub function, which is further
broken down into sub function and so forth. The separation of process data is
gone, functional decomposition is gone, but the old question is still remains.
One idea is to group the classes together into higher-level unit. This idea,
applied very loosely, appears in many objects. In UML, this grouping
mechanism is package. The term package diagram for a diagram that shows
packages of classes and the dependencies among them. A dependency exists
between two elements if changes to the definition of one element may cause to
other. With classes, dependencies exist for various reasons: one class sends a
message to another; one class has another as part of its data; one class mentions
another as a parameter to an operation. A dependency between two packages
exists; and any dependencies exist between any two classes in the package.

State diagram: State diagram are a familiar technique to describe the behavior
of a system. They describe all the possible states a particular object can get into
and how the objects state changes as a result of events that reach the objects. In
most OO technique, state diagrams are drawn for a single class to show the
lifetime behavior of a singe object. There are many form of state diagram, each
with slightly different semantics. The most popular one used in OO technique is
based on David Harel’s state chart.

PERT CHART (Program Evaluation Review Technique)

PERT chart is organized for events, activities or tasks. It is a scheduling device
that shows graphically the order of the tasks to be performed. It enables the
calculation of the critical path. The time and cost associated along a path is
calculated and the path requires the greatest amount of elapsed time in critical
path.

GANTT CHART
It is also known as Bar chart is used exclusively for scheduling purpose. It is a
project controlling technique. It is used for scheduling. Budgeting and
resourcing planning. A Gantt is a bar chart with each bar representing activity.
The bars are drawn against a time line. The length of time planned for the
activity. The Gantt chart in the figure shows the Gray parts is slack time that is
the latest by which a task has been finished.
Use Case Model of the Project:
The use case model for any system consists of “use cases”. Use cases represent
different ways in which the system can be used by the user. A simple way to
find all the use case of a system is to ask the questions “What the user can do
using the system?” The use cases partition the system behavior into transactions
such that each transaction performs some useful action from the users’ point of
view.
The purpose of the use case to define a piece of coherent behavior without
reveling the internal structure of the system. An use case typically represents a
sequence of interaction between the user and the system. These interactions
consists of one main line sequence is represent the normal interaction between
the user and the system. The use case model is an important analysis and design
artifact (task).Use cases can be represented by drawing a use case diagram and
writing an accompany text elaborating the drawing.
In the use case diagram each use case is represented by an ellipse with the name
of use case written inside the ellipse. All the ellipses of the system are enclosed
with in a rectangle which represents the system boundary. The name of the
system being moduled appears inside the rectangle. The different users of the
system are represented by using stick person icon. The stick person icon is
normally referred to as an Actor. The line connecting the actor and the use cases
is called the communication relationship. When a stick person icon represents
an external system it is annotated by the stereo type<<external system>>.
Dataflow Diagram:
Data flow diagram is the starting point of the design phase that functionally
decomposes the requirements specification. A DFD consists of a series of
bubbles joined by lines. The bubbles represent data transformation and the lines
represent data flows in the system. A DFD describes what data flow rather than
how they are processed, so it does not hardware, software and data structure.
A data-flow diagram (DFD) is a graphical representation of the "flow" of data
through an information system. DFDs can also be used for the visualization of
data processing (structured design). A data flow diagram (DFD) is a significant
modeling technique for analyzing and constructing information processes. DFD
literally means an illustration that explains the course or movement of
information in a process. DFD illustrates this flow of information in a process
based on the inputs and outputs. A DFD can be referred to as a Process Model.
The data flow diagram is a graphical description of a system’s data and how to
Process transform the data is known as Data Flow Diagram (DFD).
Unlike details flow chart, DFDs don’t supply detail descriptions of modules that
graphically describe a system’s data and how the data interact with the system.
Data flow diagram number of symbols and the following symbols are of by
DeMarco.

There are seven rules for construct a data flow diagram.

  Arrows should not cross each other.
 Squares, circles and files must wears names.
 Decomposed data flows must be balanced.
 No two data flows, squares or circles can be the same names.
 Draw all data flows around the outside of the diagram.
 Choose meaningful names for data flows, processes & data stores.
 Control information such as record units, password and validation
requirements are not penitent to a data flow diagram.
 Additionally, a DFD can be utilized to visualize data processing or a
structured design.

This basic DFD can be then disintegrated to a lower level diagram

demonstrating smaller steps exhibiting details of the system that is being
modeled.
On a DFD, data items flow from an external data source or an internal data store
to an internal data store or an external data sink, via an internal process. It is
common practice to draw a context-level data flow diagram first, which shows
the interaction between the system and external agents, which act as data
sources and data sinks. On the context diagram (also known as the Level 0
DFD’), the system's interactions with the outside world are modeled purely in
terms of data flows across the system boundary. The context diagram shows the
entire system as a single process, and gives no clues as to its internal
organization.
This context-level DFD is next "exploded", to produce a Level 1 DFD that
shows some of the detail of the system being modeled. The Level 1 DFD shows
how the system is divided into sub-systems (processes), each of which deals
with one or more of the data flows to or from an external agent, and which
together provide all of the functionality of the system as a whole. The level 1
DFD is further spread and split into more descriptive and detailed description
about the project as level 2 DFD. The level 2 DFD can be a number of data
flows which will finally show the entire description of the software project.
ER Diagram:
E-R Model is a popular high level conceptual data model. This model and its
variations are frequently used for the conceptual design of database application
and many database design tools employ its concept.
A database that confirms to an E-R diagram can be represented by a collecton of
tables in the relational system. The mapping of E-R diagram to the entities are:
 Attributes
 Relations
 Many-to-many
 Many-to-one
 One-to-many
 One-to-one
 Weak entities
 Sub-type and super-type

The entities and their relationships between them are shown using the following
conventions.
 An entity is shown in rectangle.
 A diamond represent the relationship among number of entities.
 The attributes shown as ovals are connected to the entities or relationship by
lines.
 Diamond, oval and relationships are labeled.
 Model is an abstraction process that hides super details while highlighting
details relation to application at end.
 A data model is a mechanism that provides this abstraction for database
application.
 Data modeling is used for representing entities and their relationship in the
database.
 Entities are the basic units used in modeling database entities can have
concrete existence or constitute ideas or concepts.
 Entity type or entity set is a group of similar objects concern to an
organization for which it maintain data,
 Properties are characteristics of an entity also called as attributes.
 A key is a single attribute or combination of 2 or more attributes of an entity
set is used to identify one or more instances of the set.
 In relational model we represent the entity by a relation and use tuples to
represent an instance of the entity.
 Relationship is used in data modeling to represent in association between an
entity set.
 An association between two attributes indicates that the values of the
associated attributes are independent.
Chapter 4 System Testing
4.1 System Testing
Testing is vital for the success of any software. No system design is ever
perfect. Testing is also carried in two phases. First phase is during the software
engineering that is during the module creation. Second phase is after the
completion of software. This is system testing which verifies that the whole set
of programs hanged together.
White Box Testing:
In this technique, the close examination of the logical parts through the software
are tested by cases that exercise species sets of conditions or loops. All logical
parts of the software checked once. Errors that can be corrected using this
technique are typographical errors, logical expressions which should be
executed once may be getting executed more than once and error resulting by
using wrong controls and loops. When the box testing tests all the independent
part within a module a logical decisions on their true and the false side are
exercised , all loops and bounds within their operational bounds were exercised
and internal data structure to ensure their validity were exercised once.
Black Box Testing:
This method enables the software engineer to device sets of input techniques
that fully exercise all functional requirements for a program. Black box testing
tests the input, the output and the external data. It checks whether the input data
is correct and whether we are getting the desired output.
Alpha Testing:
Acceptance testing is also sometimes called alpha testing. Be spoke systems are
developed for a single customer. The alpha testing proceeds until the system
developer and the customer agree that the provided system is an acceptable
implementation of the system requirements.
Beta Testing:
On the other hand, when a system into be marked as a software product, another
process called beta testing is often conducted. During beta testing, a system is
delivered among a number of potential users who agree to use it. The
customers then report problems to the developers. This provides the product
for real use and detects errors which may not have been anticipated by the
system developers.
Unit Testing:
Each module is considered independently. It focuses on each unit of software as
implemented in the source code. It is white box testing.
Integration Testing:
Integration testing aims at constructing the program structure while at the same
constructing tests to uncover errors associated with interfacing the modules.
Modules are integrated by using the top down approach.
Validation Testing:
Validation testing was performed to ensure that all the functional and
performance requirements are met.
4.2 Implementation and Software Specification Testing
It is executing programs to check logical changes made in it with intention of
finding errors. A system is tested for online response, volume of transaction,
recovery from failure etc. System testing is done to ensure that the system
satisfies all the user requirements.
Detailed Design of Implementation
This phase of the systems development life cycle refines hardware and software
specifications, establishes programming plans, trains users and implements
extensive testing procedures, to evaluate design and operating specifications
and/or provide the basis for further modification.
Technical Design
This activity builds upon specifications produced during new system design,
adding detailed technical specifications and documentation.
Test Specifications and Planning
This activity prepares detailed test specifications for individual modules and
programs, job streams, subsystems, and for the system as a whole.
Programming and Testing
This activity encompasses actual development, writing, and testing of program
units or modules.
User Training
This activity encompasses writing user procedure manuals, preparation of user
training materials, conducting training programs, and testing procedures.
Acceptance Test
A final procedural review to demonstrate a system and secure user approval
before a system becomes operational.
Installation Phase
In this phase the new computerized system is installed, the conversion to new
procedures is fully implemented, and the potential of the new system is
explored.
System Installation
The process of starting the actual use of a system and training user personnel in
its operation.
Review Phase
This phase evaluates the successes and failures during a systems development
project, and to measure the results of a new Computerized Transystems in terms
of benefits and savings projected at the start of the project.
Development Recap
A review of a project immediately after completion to find successes and
potential problems in future work.
Post-Implementation Review
A review, conducted after a new system has been in operation for some time, to
evaluate actual system performance against original expectations and
projections for cost-benefit improvements. Also identifies maintenance projects
to enhance or improve the system.
THE STEPS IN THE SOFTWARE TESTING
 The steps involved during Unit testing are as follows:
 Preparation of the test cases.
 Preparation of the possible test data with all the validation checks.
 Complete code review of the module.
 Actual testing done manually.
 Modifications done for the errors found during testing.
 Prepared the test result scripts.
The unit testing done included the testing of the following items:
  Functionality of the entire module/forms.
 Validations for user input.
 Checking of the Coding standards to be maintained during coding.
 Testing the module with all the possible test data.
 Testing of the functionality involving all type of calculations etc.
 Commenting standard in the source files.
After completing the Unit testing of all the modules, the whole system is
integrated with all its dependencies in that module. While System Integration,
We integrated the modules one by one and tested the system at each step. This
helped in reduction of errors at the time of the system testing.
The steps involved during System testing are as follows:
 Integration of all the modules/forms in the system.
 Preparation of the test cases.
 Preparation of the possible test data with all the validation checks.
 Actual testing done manually.
 Recording of all the reproduced errors.
 Modifications done for the errors found during testing.
 Prepared the test result scripts after rectification of the errors.
The System Testing done included the testing of the following items:
 Functionality of the entire system as a whole.
 User Interface of the system.
 Testing the dependent modules together with all the possible test data
scripts.
 Verification and Validation testing.
 Testing the reports with all its functionality.
After the completion of system testing, the next following phase was the
Acceptance Testing. Clients at their end did this and accepted the system with
appreciation. Thus, we reached the final phase of the project delivery.
There are other six tests, which fall under special category. They are
described below:
 Peak Load Test: It determines whether the system will handle the volume
of activities that occur when the system is at the peak of its processing
demand. For example, test the system by activating all terminals at the
same time.
 Storage Testing: It determines the capacity of the system to store
transaction data on a disk or in other files.
 Performance Time Testing: it determines the length of time system used
by the system to process transaction data. This test is conducted prior to
implementation to determine how long it takes to get a response to an
inquiry, make a backup copy of a file, or send a transmission and get a
response.
 Recovery Testing: This testing determines the ability of user to recover
data or re-start system after failure. For example, load backup copy of
data and resume processing without data or integrity loss.
 Procedure Testing: It determines the clarity of documentation on
operation and uses of system by having users do exactly what manuals
request. For example, powering down system at the end of week or
responding to paper-out light on printer.
 Human Factors Testing: It determines how users will use the system when
processing data or preparing reports.
Chapter 5 System Analysis
System analysis is a process of gathering and interpreting facts, diagnosing
problems and the information about the Online Food Ordering System to
recommend improvements on the system. It is a problem solving activity that
requires intensive communication between the system users and system
developers. System analysis or study is an important phase of any system
development process. The system is studied to the minutest detail and analyzed.
The system analyst plays the role of the interrogator and dwells deep into the
working of the present system. The system is viewed as a whole and the input to
the system are identified. The outputs from the organizations are traced to the
various processes. System analysis is concerned with becoming aware of the
problem, identifying the relevant and decisional variables, analyzing and
synthesizing the various factors and determining an optimal or at least a
satisfactory solution or program of action. A detailed study of the process must
be made by various techniques like interviews, questionnaires etc. The data
collected by these sources must be scrutinized to arrive to a conclusion. The
conclusion is an understanding of how the system functions. This system is
called the existing system. Now the existing system is subjected to close study
and problem areas are identified. The designer now functions as a problem
solver and tries to sort out the difficulties that the enterprise faces. The solutions
are given as proposals. The proposal is then weighed with the existing system
analytically and the best one is selected. The proposal is presented to the user
for an endorsement by the user. The proposal is reviewed on user request and
suitable changes are made. This is loop that ends as soon as the user is satisfied
with proposal. Preliminary study is the process of gathering and interpreting
facts, using the information for further studies on the system. Preliminary study
is problem solving activity that requires intensive communication between the
system users and system developers. It does various feasibility studies. In these
studies a rough figure of the system activities can be obtained, from which the
decision about the strategies to be followed for effective system study and
analysis can be taken.
5.1 Existing System
In the existing system the exams are done only manually but in proposed system
we have to computerize the exams using this application.
 Lack of security of data.
 More man power.
 Time consuming.
 Consumes large volume of pare work.
 Needs manual calculations.
 No direct role for the higher officials

5.2 Proposed System

The aim of proposed system is to develop a system of improved facilities. The
proposed system can overcome all the limitations of the existing system. The
system provides proper security and reduces the manual work.
 Security of data.
 Ensure data accuracy’s.
 Proper control of the higher officials.
 Minimize manual data entry.
 Minimum time needed for the various processing.
 Greater efficiency.
 Better service.
 User friendliness and interactive.
 Minimum time required.

5.3 Data Dictionary

This is normally represented as the data about data. It is also termed as metadata
some times which gives the data about the data stored in the database. It defines
each data term encountered during the analysis and design of a new system.
Data elements can describe files or the processes.
Following are some major symbols used in the data dictionary
 = equivalent to
 + and
 [] either/ or
 () Optional entry

Following are some rules, which defines the construction of data

dictionary entries:

 Words should be defined to understand for what they need and not the
variable need by which they may be described in the program.
 Each word must be unique. We cannot have two definition of the same
client.
 Aliases or synonyms are allowed when two or more enters shows the
same meaning. For example a vendor number may also be called as
customer number.
 A self-defining word should not be decomposed. It means that the
reduction of any information in to subpart should be done only if it is
really required that is it is not easy to understand directly.
 Data dictionary includes information such as the number of records in
file, the frequency a process will run, security factor like pass word
which user must enter to get excess to the information.
Chapter 6 Screenshots
Chapter 7 Conclusion
7.1 Conclusion
Our project is only a humble venture to satisfy the needs to manage their project
work. Several user friendly coding have also adopted. This package shall prove
to be a powerful package in satisfying all the requirements of the school. The
objective of software planning is to provide a frame work that enables the
manger to make reasonable estimates made within a limited time frame at the
beginning of the software project and should be updated regularly as the project
progresses.
At the end it is concluded that we have made effort on following point
 A description of the background and context of the project and its relation
to work already done in the area.
 Made statement of the aims and objectives of the project.
 The description of Purpose, Scope, and applicability.
 We define the problem on which we are working in the project.
 We describe the requirement Specifications of the system and the actions
that can be done on these things.
 We understand the problem domain and produce a model of the system,
which describes operations that can be performed on the system.
 We included features and operations in detail, including screen layouts.
 We designed user interface and security issues related to system.
 Finally the system is implemented and tested according to test cases.

7.2 Future Scope

In a nutshell, it can be summarized that the future scope of the project circles
around maintaining information regarding:
 We can add printer in future.
 We can give more advance software for Online Food Ordering System
including more facilities.
 We will host the platform on online servers to make it accessible
worldwide.
 Integrate multiple load balancers to distribute the loads of the system
Create the master and slave database structure to reduce the overload of
the database queries.
 Implement the backup mechanism for taking backup of codebase and
database on regular basis on different servers.
The above-mentioned points are the enhancements which can be done to
increase the applicability and usage of this project. Here we can maintain the
records of Food Item and Category. Also, as it can be seen that now-a-days the
players are versatile, i.e. so there is a scope for introducing a method to
maintain the Online Food Ordering System. Enhancements can be done to
maintain all the Food Item, Category, Customer, Order, Confirm Order.
We have left all the options open so that if there is any other future requirement
in the system by the user for the enhancement of the system then it is possible to
implement them. In the last we would like to thanks all the persons involved in
the development of the system directly or indirectly. We hope that the project
will serve its purpose for which it is develop there by underlining success of
process.