A

Project Report

On

“ Online Pizza Delivery System”

Submitted to

Veer Bahadur Singh Purvanchal University, Jaunpur

In partial fulfillment of the requirements of the degree of

Bachelor of Computer Application

Prepared by: Project Supervisor:

Anrav Kumar Dr . Dinesh Singh

BCA 6th Semester (Associate Professor)

Roll Number: 23141105875

2024-25

Department of Computer Application

Technical Education & Research Institute
Post-Graduate College, Ghazipur – 233001 (U.P.)
 CERTIFICATE

This is to certify that Anrav Kumar , pursuing BCA 5th Semester from this institute, has
prepared the project report entitled “Online Pizza Delivery System” in partial fulfillment of
the requirements of the degree of Bachelor of Computer Application from Veer Bahadur
Singh Purvanchal University, Jaunpur, for the session 2024-25.

This report is based on the project work undertaken by Anrav Kumar at Technical Education
and Research Institute, Ghazipur under the supervision of Dr. Dinesh Singh and fulfills the
requirements of regulations relating to the nature and standard of BCA course of V.B.S.
Purvanchal University, Jaunpur, Uttar Pradesh.

I recommend that this project report may be sent for evaluation.

Dr. Dinesh Singh Dr. Ajit Pratap Singh Gautam

(Associate Professor) Head, Deptt. Of Computer Application
 DECLARATION

I, Anrav Kumar, hereby declare that this summer training project report entitled “ Online
Pizza Delivery System“ has been prepared by me on the basis of summer training done at
Name & address of the company during the period of training under the supervision of
Dr. Dinesh Singh.

This project report is my bona fide work and has not been submitted in any form to any
University or Institute for the award of any degree or diploma prior to the under mentioned
date. I bear the entire responsibility of submission of this project report.

7 May 2025 Anrav Kumar

Place: Teri PG Collage Ghazipur BCA 6th Semester
Department of Computer Application
Technical Education & Research Institute
P.G Collage ,Ghazipur
 PREFACE

This is a project report on "Online Pizza Delivery System ". During the making/developing
of this project we explored new ideas and functionality behind the working of a notepad. This
project is the output of our planning, schedule, programming skill and the hard work, and this
report reflects our steps taken at various levels of programming skill, planning and schedule.
We have learnt a lot during this project and liked the improvement in our testing skills and
deep concept related to these kinds of projects.
Our project is “Online Pizza Delivery System”. This is a website which helps people to find
and order different Fast Food items under variety of categories. It is useful in the way that it
makes an easier way to order Fast Food items online. In this website we have basically 2
modules. The first module includes the customer module. The customer have to register for
any enquiry related to Medicine. The unregistered person online visit this site but can't
perform any action on this site. The registered customer can view details of Food items and
he can order the Fast Food of his choice and need. He has to pay the price of their order.
The admin module contains the access of admin on the site. The admin can perform changes
regarding to this site. He have the ability to add, delete, update any information regarding the
Food items, Fast Foods categories, etc.
 ACKNOWLEDGEMENT

A project is never the sole product of a person whose name has appeared on the cover. Even
the best effort may not prove successful without proper guidance. For a good project one
needs proper time, energy, patience, and knowledge. But without any guidance it remains
unsuccessful. I have done this project with the best of my ability and hope that it will serve its
purpose.
I would like to express my profound thanks to Dr. Dinesh Singh , who guided me throughout
the project tenure, provided me each and every detail, references and technical helps with
without which It is impossible to complete as project.
I have really a great learning experience and I am really thankful to Dr. Durgesh kumar
Singh helped me in successful completion of this report but also spread his precious and
valuable time in expanding my knowledge base.
I also express my gratitude to Dr. Ajeet Pratap Singh Gautam (Head of Department), BCA
and all faculty members who support me not only physically but also morally and this is the
result of their great effort towards me.

Finally, I wish also wish thank to all the faculty and the staff of the institute for supporting
me during my whole project work.

Sincerely
Anrav Kumar
 INDEX
1. Introduction 1-2
2. Objective 3-4
3. System Analysis 5-6
3.1 Existing System Description 7
3.2 Proposed System 8
3.3 Software Process Model 9-10
3.4 Feasibility study and report 11
4. Software Requirement Specification 12-13
4.1 Objective 14
4.2 Scope 15
4.3 Requirement
4.3.1 Functional Requirements 16
4.3.2 Security Requirements 17
4.3.3 Output Requirements 18
4.4 Software Requirements 19
4.5 Hardware Requirements 20
5. System design 21-22
5.1 Designing Approach 23-24
5.2 High level design 25-29
5.2.1 Data Flow Diagram 25-29
5.2.2 E-R Diagram 30-41
5.3 Low level design 42

6. Coding 43-50
7. Snapshot 51-56
8. Testing 57-62
9. Implementation 63-65
10. Maintenance 66-67
11. Bibliography 68-69
1
Introduction

1
 Introduction

The Online Pizza Delivery System is a web-based application that enables customer to order
pizzas online for home delivery or pickup from pizzeria. This System provide a convenient
and efficient way for customers to order their favourite pizza or the types of pizza they want
from the comfort of their own home, and this system is also helpful for the pizzerias to
manage orders, track sales, and improve customer satisfaction.

With the rise of e-commerce and online food delivery, the demand for online pizza delivery
systems has increased significantly. Traditional phone-based ordering systems are being
replaced by online systems that provide a more convenient and efficient way for customers to
order pizzas. Online pizza delivery systems also provide pizzerias with a competitive edge,
enabling them to reach a wider customer base and increase sales.

There is a lot of scope online food ordering business, and we can tap it to the max extent
possible as everyone has access to an online food facility via the internet. Food business
usually will have a high demand and hence online business prospect for food ordering should
be profitable.

After making a selection, the item is then added to their order, which the customer can also
review the details of at any time before checking out. This provides visual confirmation of
what was selected and ensures that items in the order are, in fact, what was intended. Within
this application, all items in the order are displayed, along with their corresponding options
and delivery details, in a concise and easy to read manner.

2
Objective

3
 2.Objective

The main objective of this system is to manage the details of item category, food, delivery
address, order, and shopping cart. The project is totally built at administrative end and thus
only the administrator is guaranteed the access. The purpose is to build and application
program to reduce the managing the item category, food customers. It tracks all the delivery
address ordered.

 The system makes the overall project management much easier and flexible.

 The user information can be stored in centralized database which can be maintained by the
system.
 This can give the good security for user information because data is not in client machine.

 Authentication is provided for this application only registered Users can access.
 There is no risk of data management at any level while the project development is under
process.

 The automated system will provide to the customers for reliable services.
 User Friendliness is provided in the application with various controls provided by system
Rich User Interface.

4
System Analysis

5
 3.System Analysis
System analysis is the process of gathering and interpreting facts, diagnosing problems and
using the information to recommend improvements on the system. System analysis 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 analysed. The system
analyst plays the role of an interrogator and dwells deep into the working of the present
system. The system is viewed as a whole and the inputs to the system are identified. The
outputs from the organization are traced through the various processing that the inputs phase
through in the organization. A detailed study of these processes 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 the 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
a proposal. 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 loop ends as soon
as the user is satisfied with the proposal. Since this is small project and is developed for
academic purpose system analysis is not required.

6
3.1 Existing System:
The existing system is inconvenient for customer needing to have a physical copy of the
menu, its time consuming, there is lack of visual confirmation that the order was placed
correctly or not, Restaurants have to have an employee answering the phone and taking
orders all the time which increases manual work and paper work. And there is also a huge
difficulty in tracking customers past history and lack of data security.

All the existing system is traditional and lack of use of technology, therefore the process is
very time and lengthy as paper work is there. This was creating problem in maintain data
record at the end like employee attendance, bill, pay slip, salary slip etc.

Limitation of Existing System:

1) As it is not online the customers have to wait for the waiter to take their order and
have to wait for the food as well.
2) Waiters have to manually keep a record of all the food ordered by the customer and
that work is very complicated.
3) Records are maintained manually so there are chances of damage and loss of data.
4) Less exposure for people in the world of technology.

7
3.2 Proposed System
In the proposed system Security of data is provided where data are well protected for
personal use and also ensures data accuracy during order placement process. It minimizes
manual data entry. Since the data processing is very fast it provides great efficiency. This
proposed system is user friendly and provides interactive interface with provision for
customer to view menus.

It greatly simplifies the ordering process for both customer and restaurant. This online
application enables the end users to register online, select the food from the e-menu card,
read the E-menu card and order food online by just selecting the food that the user want to
have. The results after selecting the food from the E-menu card will directly appear in the
screen. By using this application the work of the Waiter is reduced and we can also say that
the work is nullified.

The benefit of this is that if there is rush in the Restaurant then there will be chances that the
waiters will be unavailable and the users can directly order the food to the chef online by
using this application. The user will be given a username and a password, by sing that every
time a user logs in. This implies that the customer is the regular user of the Restaurant.

Benefits of proposed system:

1) As it is online the customer doesn't have to wait for the waiter to take their order and
doesn't us to wait for the food as well.
2) Waiters don't have to manually keep a record of all the food ordered by the customer
and that work is very easy.
3) Waiters don't have to manually calculate the amount of money to be paid by the
customer after having food it is automatically done in the software.
4) Records are maintained in computers so there are less chances of damage and loss of
data.

8
3.3 Software Process Model:

-Waterfall Model:
The waterfall model is a popular version of the systems development life cycle model for
software engineering. Often considered the classic approach to the systems development life
cycle, the waterfall model describes a development method that is linear and sequential.
Waterfall development has distinct goals for each phase of development. Imagine a waterfall
on the cliff of a steep mountain. Once the water has flowed over the edge of the cliff and has
begun its journey down the side of the mountain, it cannot turn back. It is the same with
waterfall development. Once a phase of development is completed, the development proceeds
to the next phase and there is no turning back.

The advantage of waterfall development is that it allows for departmentalization and

managerial control. A schedule can be set with deadlines for each stage of development and a
product can proceed through the development process. Theoretically, be delivered on time.
Development moves from concept, through design, implementation, testing, installation,
troubleshooting, and ends up at operation and maintenance. Each phase of development
proceeds in strict order, without any overlapping or iterative steps.

The disadvantage of waterfall development is that it does not allow for much reflection or
revision. Once an application is in the testing stage, it is very difficult to go back and change
something that was not well-thought out in the concept stage. Alternatives to the waterfall
model include joint application development (JAD), rapid application development (RAD),
synchronize and stabilize, build and fix problems.

9
The whole project is based on waterfall model and follows the
Top-down designing Approach.

10
3.4 Feasibility Study
After doing the project Online Wedding Planner, study and analysing all the existing or
required functionalities of the system, the need 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.

• 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.

• 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 platforms.

• 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.

11
Software Requirement
Specification

12
4.Software Requirement Specification
Software requirements specification (SRS) is a description of a software system to be
developed, laying out functional and non-functional requirements, and may include a set of
use cases that describe interactions the users will have with the software requirements
specification establishes the basis for an agreement between customers and contractors or
suppliers (in market-driven projects, these roles may be played by the marketing and
development divisions) on what the software product is to do as well as what it is not
expected to do.

Software requirements specification permits a rigorous assessment of requirements before

design can begin and reduces later redesign. It should also provide a realistic basis for
estimating product costs, risks, and schedules. The software requirements specification
document enlists enough and necessary requirements that are required for the project
development.

Software product, program or set of programs that perform certain functions in a specific
environment. There are two important cases regarding SRS: First one, SRS is used to define
the needs and expectations of the users. The second one, SRS is written for different purpose
and serve as a contract document between customer and developer. This produces the
probability of the customer being disappointment with the final product.

Generally, the SRS is a document that completely describes what the proposed software
should do without describing how the software will do it. The basic goal of the requirements
phase is to produce the SRS, which describe the complete external behaviour of the proposed
software.

13
4.1 Objective
The objective of a Software Requirements Specification (SRS) is to provide a clear,
comprehensive, and unambiguous description of what a software system should do, outlining
all its functionalities, features, and constraints in a document understandable to both the
developers and clients, ensuring everyone is on the same page about the project's
expectations before development begins.

Capture all requirements:

To document all necessary functional and non-functional requirements of the software

system, including user needs, system behaviour, performance criteria, and external
interfaces.

Clear communication:

To serve as a reference point for the development team, ensuring everyone understands
what needs to be built and how it should function.

Reduce ambiguity:

To minimize misunderstandings by clearly defining requirements, leaving no room for

interpretation.

Basis for project planning:

To provide a foundation for project planning, cost estimation, and risk assessment by
outlining the scope and complexity of the software.

Stakeholder alignment:
To facilitate collaboration and agreement among all stakeholders (clients, developers,
testers) by presenting a unified view of the system requirements

Quality assurance:
To contribute to quality software development by identifying potential issues early in the
project lifecycle through thorough requirement analysis.

14
4.2 Scope

Home delivery of fast via phone call is popular. The process seems easy to use but at times
there is miscommunication sometimes. The main drawback of placing order via phone call is
that there is no visual menu shown, the employees have to repeat a lot of things again and
again to the customers. It’s a time consuming process which at times irritates customers. It
would be much more comfortable for the customers to have an ONLINE PIZZA DELIVERY
system. It would be hassle free for users as they can select the food item they want and make
payment for it. Also it will reduce the purchasing time for customers. Let us look at another
benefit of using this system. Suppose I go to a fast food point and make order. Even after
ordering fast food from their outlet, I have to wait for my order to be ready. Wouldn’t it be
much more convenient if I ordered my fast food from home and then the Fast Food is
delivered at my home, there is no requirement to visit shop and pick my order. In a nutshell,
we can say that improved and efficient services are provided to the customers by the
inclusion of internet in your business. As a business point of view it gives you an edge over
our competitors.

15
4.3 Requirement

4.3.1 Functional Requirements

Required project is for ONLINE PIZZA DELIVERY. The project should satisfy the
following requirements:
1. Admin Panel:
o Login feature
o Dashboard feature
o Show all registered users
o Show Order details.
o Admin can insert, update and delete the food items from the admin panel.
o Admin can insert, update and delete the fast food categories from the admin
panel
o Admin can manage Feedbacks of users
o Admin can activate/deactivate food items/food category from admin panel

2. User Aspect:.

 Registration: Website provides a link for the Users/Client Registration.

 Log In: Admin and user can log in by entering user name and password and manage
their work on website.
 Save information: User enter all its necessary information by filling personal info
form and save that information into system.
 Profile Update: Customer can change any of their information any time.
 Show Fast Food Menu: There is a list of all types of available Food items the shop
is dealing with their details.
 Show Fast Food Category Menu: There is a list of all types of available Fast
Food category the shop is dealing with their details.

16
4.3.2 Security Requirement
Security requirements are the particularly significant in defense system and many database
systems. Security requirement place restrictions on the use of certain commands, control
access to data, provide different kind of access requirement for different people, require the
use of passwords and cryptography techniques, and maintain a log of activities in system.
Given the current security needs even of common systems, they may also require proper
assessment of security threats, proper programming techniques, and use of tools to detect
flaws like buffer overflow.

For the purpose of security process:

 There is a login feature into my project so as to keep it safe from the external problem.
 To open admin panel admin must have to login by entering username and password.
 From admin panel, admin can activate or deactivate users account.
 Customers must have to login by providing user id and password before he/she order Food
items.
 If any user forget their password then he/she can easily reset their password by clicking on
forget password link.
 For registration a unique email id and password is required so each time when a new user
want to register on site then he/she must have to provide unique email id and phone number.

17
4.3.3 Output Requiremnet
This web based project will be run on a browser. So at least one output device will required
to view the pages. Some more output requirements are given below.

 Background color- The background color of this website should be light in

comparison to the foreground color.
 Font details- Font size must be 12px for the paragraphs and 16px for the title of the
paragraph. Font style should be same on each and every pages. Recommended font
style is “Arial” for this project.
 Navigation Bar- Navigation bar should be on top of the webpage. 
 Logo- Logo of the website must be present on each and every pages. It should be
small in size (height 100px and width 200px)
 Responsive- All the web pages must be readable and look attractive in all screen
size devices.

18
4.4 Software Requirement

Developer Requirements

 Operating System : Windows / Android / Mac / Linux

 Operating System type : 32-bit or 64-bit OS

 Front End : HTML 5, CSS 3, JavaScript

 Back End : MySQL

 Client side Scripting Language : JavaScript
 Server Side Scripting Language : PHP

 Web Server : Apache 2.2.22

 Toolkit : XAMPP/WAMP

 Web Browser : Google Chrome, Microsoft Edge

 Code Editors : Notepad++, Visual Studio Code

19
4.5 Hardware Requirement

 RAM : 8GB

 Hard Disk : 64GB

 Display Devices : Monitor

 Processor : AMD/INTEL/SNAP-DRAGON

20
System Design

21
5.System Design
Systems design is the process of defining the architecture, components, modules, interfaces,
and data for a system to satisfy specified requirements. Systems design could be seen as the
application of systems theory to product development. There is some overlap with the
disciplines of systems analysis, systems architecture and systems engineering. The
architectural design of a system emphasizes on the design of the systems architecture which
describes the structure, behavior, and more views of that system.

System design goes through two phases of the development:

1. Logical Design

2. Physical Design

22
5.1 Designing Approach
There are two types of designing approaches:

 Top-Down Approach
 Bottom-Up Approach

Top-Down Approach
 The top-down approach starts from the highest-level component of the hierarchy and
proceed through to lower levels. A top-down design approach starts by the major
component of the system. Decomposing them into their lower-level component and
iterative until the desired label of detail is achieved.
 Top-down design method is in some form of step wise refinement. Starting from an
abstract design in each step the design is refine to more concrete level, until we reach
a level where no more refinement is needed. A system consists of components, which
have components of their own; indeed, a system is hierarchy of components.
 The highest-level component corresponds to the total system. The top-down approach
from the highest-level component hierarchy and proceeds through to lower levels. By
contrast a bottom-up approach starts with the lowest level component of the hierarchy
and proceeds a through progressively higher levels to the top-level components. The
top- down approach has been promulgated by many researches and has been found to
be extremely useful for design. Most design methodologies are based on the top-down
approach

 A top-down approach suitable only if the specifications of the systems are clearly
known and the system development is from scratch. However, if a system is to be
built from an existing system, a bottom approach is more suitable, as it starts from
some existing components.

23
 Bottom-up Approach

A bottom-up approach is the piecing together of systems to give rise to more complex
systems, thus making the original systems sub-systems of the emergent system. Bottom-up
processing is a type of information processing based on incoming data from the environment
to form a perception. Information enters the eyes in one direction (input), and is then turned
into an image by the brain that can be interpreted and recognized as a perception (output). In
a bottom-up approach the individual base elements of the system are first specified in great
detail. These elements are then linked together to form larger subsystems, which then in turn
are linked, sometimes in many levels, until a complete top-level system is formed. This
strategy often resembles a "seed" model, whereby the beginnings are small but eventually
grow in complexity and completeness. However, "organic strategies" may result in a tangle
of elements and subsystems, developed in isolation and subject to local optimization as
opposed to meeting a global purpose.

24
5.2 High Level Designing
High-Level Design is a initial step in development of applications where overall structure
of a system is planned. High-Level design focuses mainly on how different components of
the system work together without getting to know about internal coding and
implementation. This helps everyone involving in the project to understand the goals and
ensures good communication during development.

In Developing scalable applications, proper planning, and organization play a significant

role. High-level design plays an important role in this process by serving as the blueprint of
the system’s architecture. It provides a comprehensive view of how components interact
and function together which will further help for detailed implementation.

5.2.1 Data Flow Diagram

A Data Flow Diagram (DFD) is a graphical representation of the information flow and
transformation that are applied, as data moves from the input to the output. It is also known
as “data flow graph” or a “bubble chart”. The DFD may be used to represent increasing
information flow and functions details. A level 0 DFD, also called a fundamental system
model, represent an entire software element as a single bubble with the input and the output
data directed by the incoming and outgoing arrows. Data flow diagrams are commonly used
during problem analysis. Data flow diagram is quite general and nit limited to problem
analysis for software requirement specification. DFDs are very useful if understanding a
system and can be effectively used during analysis.

A DFD shows the flow of data through the system It views the system as a function that
transforms the input into desired output. The DFD aims to capture the transformations that
take place within a system to the input data so that eventually the output data is produced.
The agent that performs transformation of data from one state to another is called a process.
so a DFD shows the movement of data through the different processes.

Named and circle shows the processes and data flows are shows by arrows entering or
leaving the circles. A rectangle represent a source or sinks and is a net originator or consumer
of the data. A source or sink is typically outside the main system of study.

The DFD should be carefully scrutinized to make sure that all the process in the physical
environment are shown in DFD. It should also ensure that none of data flow is actually
carrying control information.

25
Features Of DFD:
 The exceptional simplicity of the DFD zymology is one reason why data oriented
analysis techniques is the most widely used.

 The data flow diagram is a graphical tool that can be very valuable during the system
analysis.
 The DFD depicts information flow without explicit notation of control (e.g.
conditions of loops).
 The level 0 data flow diagram should depict the software as a single bubble.
 Primary input/output files should be maintained.

 One bubble at a time should be refined.

Basic Rule of DFD:

 No internal logic should be shown like loops, if-else, this is not a flow chart.
 In order to keep the diagram uncluttered, you can repeat data stores and external
entities.
 No process can have only output data flows (a miracle). 
 No process can have only input data flows (black hole). 
 Data can’t be moved directly from one store to another without a process.
 Data can’t move directly from an external entity to a data store without a process. 

 Data stores can’t be sink (only input data flows) or source (only output data flows) in
level 1DFD.

Data flow diagram symbol:

The symbols used to prepare DFD do not imply a physical implementation, a DFD can be
considered to an abstract of the logic of an information-oriented or a process-oriented system
flow- chart. For these reasons DFDs are often referred to as logical data flow diagrams. The
four basic symbols used to construct data flow diagrams are shown below:

26
27
 0th Level DFD

Login Request Login Request

Online Pizza
USER Delivery ADMIN
System
Response Response

28
1st Level DFD-ADMIN Side

29
5.2.2 E-R Diagram
The entity relationship model is a generalization of primitive commercial systems, which are
based on hierarchical and network approaches. The E-R relationship, which is also known as
Entity Relationship is based on the theory of real world which consists of a set of basic
objects, which are called entities and relationships among these object. An entity exists as an
object and is distinguishable from other objects.

Entity-
Any distinguishable person, place, thing, event or concept about which information is kept or
an object which can be distinctly identified and distinguished and represented in a database or
anything about which we store information is called an Entity.

Attribute-
Attributes describe the entity to which they are associated. A particular instance of an
attribute is a value. In other words attributes are the characteristics of an entity type.
Attributes can be classified as descriptors or identifiers. A descriptor describes a non-
uniquely identify an instance of an entity.

Relationship-
It is an association among several entities, in other words it provides relationship between
one or more entities.

Notification For E-R Diagram-

There is no standard for representing data objects in E-R diagram. Each modeling
methodology uses its own notation. All notational style represents entities as rectangular
boxes and relationship as lines connecting boxes. Each style uses a special set of symbols to
represent the cardinality of a connection. An entity is represented in E-R diagram as a
rectangular box enclosing the entity type name. Attribute names are enclosed in ellipses and
attached to their entity type by straight lines.

30
Basic Symbols Use for E-R Constructs are:

31
32
E-R Diagram

33
Keys Concept:
A key is a value which can always be used to uniquely identify an object instance. It becomes
important to invent a method to distinguish entity and relationships. The differences between
entities must be expressed in terms of attributes.

Super Key:
A Super Key is a set of one or more attributes which, taken collectively, allows us to identify
uniquely an entity in the entity set.

Candidate Key:
Candidate Key is a minimal super key that uniquely identifies a record in a table. Candidate
key is also referred to as Surrogate keys.

Primary Key:
In a database table an attribute which can be used to uniquely identify the records is called
Primary Key. In other words a Primary Key is a key which is a part of candidate key.

Alternate Key:
Alternate key is a key which is the part of candidate key but not primary key. In other words
if there are multiple candidate keys in a table, then the keys which are not chosen as primary
key will be called as alternate key.

Composite Key:
When the key that uniquely identifies the rows of the table is made up of more than one
attribute it is called a composite key. In other words if we use multiple attributes to create a
primary key, then that primary key is refers to as a Composite Key.

34
Foreign Key:
A foreign key is column or group of column in a relational database table that provides the
link between data in two tables. It act as cross reference between tables because it references
the primary key to other table thereby establishing a link between them. In other words
foreign key is a key that uniquely identify records from one table to other table.

Guideline for Drawing E-R Diagram:

When gathering information I have to:

1) Identify the entities in the system.

2) Identify the attribute of each entity.

3) Identify the relationship between the entities and more things like this.

35
Table Schema
1.Table Name: User

Table Description : This table contains all details about customer who have registered to
this website.

Serial Primary
No. Key and
Attribute Data Type Length Description
constraints
1 Id Int 5 Not null, Auto Increment id
Primary Key of user
2 Name Varchar 25 Not Null Name of user

3 contact int 10 Not Null User Contact

4 Password Varchar 10 Not Null

36
2.Table Name: Login

Table Description: This table consist login detail of user.

37
3.Table name: Category
Description: This table contains the about Pizza Category.

38
4.Table name: Pizza

Description: This table contains the data about Pizza.

39
5.Table name: order detail

Description: This table contains the data about users Pizza ordered.

40
6.Table name: Order
Description: This table contains the data about Order Status.

41
5.3 Low Level Design
The top-level design document for a project should provide a complete and detailed
specification the design for the software that will be developed in the project, including the
classes, member and non-member functions, and associations between classes that are
involved. By the end of the low- level design stage, the code should be “all but written”. The
low-level design document should contain a listing of the declarations of all the classes, non-
member functions, and class member functions that will be defined during the
implementation stage, along with the associations between those classes and any other details
of those classes (such as member variables) that are firmly determined by the low-level
design stage. You should be especially careful to explain how the class roles and their
methods were combinein your low- level design, and any changes that you decided to make
in combining and refining them.

Modulation:
A system is considered modular if it consists of discreet component show that each
component can be implemented separately, and a change to one component has minimal
impact on other components.

Each function in each abstraction has a single, well defined purpose .

 Each function manipulates no more than one major data structure.

 Function share global data selectively. It easy to identify all routines that share a
major data structure.
 Function that manipulates instances of abstract data types are encapsulated with the
data structure be in manipulated.

Structure Chart:
The structure chart is one the most commonly used methods for system design. structures
charts are used during architectural design to document hierarchical structure, parameters and
interconnection in a system.

42
Coding

43
6. Coding

The goal of the coding or programming phase is to translate the design of the
system produced during the design phase into code in a given programming
language which can be executed by a computer, and which performs the
computation specified by the design. For a given design, the aim is to
implement the design in the best possible manner. The coding phase affects
both testing and maintenance profoundly. As we saw earlier, the time spent in
coding is a small percentage of the total software cost, while testing and
maintenance consume the major percentage. Thus it should be clear that the
goal during coding should not be to reduce the implementation cost, but the goal
should be to reduce the cost of later phases, even if it means that the cost of this
phase has to be increase. In other words, the goal during this phase is not
simplify the job of the programmer. Rather the goal should be to simplify the
job of the tester and the maintainer. This distinction is important, as most
programmers are individualistic, and are mostly concerned about how to finish
their job quickly, without keeping the later phases in mind. During
implementation it should be kept in mind that the programs should not be
constructed so that they are easy to write but, that they are easy to read and
understand. There are many different criteria for judging a program, including
readability, size of the program, execution time, and required memory. In an
experiment conducted, different programmers were required to implement a
program, and were given different goals. It was found that the programs written
by different programmers were very different, and each tended to satisfy its
goal. For our purposes ease of understanding and modification should be basic
goals of the programming activity. This means that simplicity and clarity are
desirable, while cleverness and complexity are undesirable.

44
6.1 Coding Methods
To develop reliable and maintainable applications, you must follow coding
standards and best practices. The naming conventions, coding standards and
hest practices described in this document are compiled from our own experience
and by referring to various Microsoft and non Microson guidelines.

There are several standards exists in the programming industry. None of them
are wrong or bad and you may follow any of them. What is more important is,
selecting one standard approach and ensuring that everyone is following it.

 Event driven programming language ASP.Net had been used for coding
the modules and programs.
 Structured English and pseudo-codes are used to closely refine the
mechanisms using the facility of defined objects
 Various stubs had been used to facilitate incremental coding followed by
testing.
 The basic philosophy followed at this stage:" code one line followed by
rigorous testing"
 Integrated development environment of Net had been used for the
development of various modules in integrated manner.
 Incremental compilation had been used to compile and test on which
work was in progress.
 Stepwise refinement technique had been used to code the modules.

45
6.2 Good Coding Style
Programming style is a set of rules or guidelines used when writing the source code for a
computer program. It is often claimed that following a particular programming style will help
programmers to read and understand source code conforming to the style, and help to avoid
introducing errors. Avoid writing very long methods. A method should typically have 1-25
lines of code. If a method has more than 25 lines of code, you must consider re factoring into
separate methods. Method name should tell what it does. Do not use miss-leading names. If
the method name is obvious. there is no need of documentation explaining what the method
does.

6.3 Elements of Good Coding Style

Good style is a subjective matter, and is difficult to define. However, there are several
elements common to a large number of programming styles. The issues usually considered as
part of programming style include the layout of the source code, including indentation; the
use of white space around operators and keywords; the capitalization or otherwise of
keywords and variable names; the style and spelling of user-defined identifiers, such as
function, procedure and variable names; the use and style of comments; and the use or
avoidance of particular programming constructs.

46
6.3.1 Code Appearance
Programming styles commonly deal with the visual appearance of source code, with the goal
of requiring less human cognitive effort to extract information about the program. Software
has long been available that formats source code automatically, leaving coders to concentrate
on naming. logic, and higher techniques. As a practical point, using a computer to format
source code saves time, and it is possible to then enforce company-wide standards without
debates.

6.3.2 Indentation
Indent styles assist in identifying control flow and blocks of code. In some programming
languages indentation is used to delimit logical blocks of code, correct indentation in these
cases is more than a matter of style. In other languages indentation and whitespace does not
affect function, although logical and consistent indentation makes code more readable .

6.3.3 Vertical alignment

It is often helpful to align similar elements vertically, to make typo-generated bugs more
obvious Arguments against vertical alignment generally claim difficulty in maintaining the
alignment Such difficulty can be eliminated when using a source code editor that supports
elastic tab stops.

6.3.4 Space
In those situations where some whitespace is required the grammars of most free-format
languages are unconcerned with the amount that appears. Style related to whitespace is
commonly used to enhance readability. 6.3.5 Tabs The use of tabs to create white space
presents particular issues when not enough care is taken because the location of the tabulation
point can be different depending on the tools being used and even the preferences of the user.

47
6.3.5 Tabs
The use of tabs to create white space presents particular issues when not enough care
is taken because the location of the tabulation point can be different depending on the
tools being used and even the preferences of the user.

6.3.6 Exception Handling

Never do a 'catch exception and do nothing'. If you hide an exception, you will never
know if the exception happened or not. Lot of developers uses this handy method to
ignore non significant errors. You should always try to avoid exceptions by checking
all the error conditions programmatically. In any case, catching an exception and
doing nothing is not allowed. In the worst case, you should log the exception and
proceed.

In case of exceptions, give a friendly message to the user, but log the actual error
with all possible details about the error, including the time it occurred, method and
class name etc.

48
6.4 Naming, logic, and higher techniques

6.4.1 Appropriate variable names

Appropriate choices for variable names are seen as the keystone for good style.
Poorly-named variables make code harder to read and understand. In early
programming languages, variable names were restricted to only a few characters, to
conserve the small amount of computer memory available to interpreters and
compilers. A later "advance" allowed longer variable names to be used for human
comprehensibility, but where only the first few characters were significant. In some
versions of BASIC long names were allowed, but only the first two letters were
significant: this led to terrible issues when variable names such as "VALUE" and
"VAT" were used and intended to be distinct.

6.4.2 Boolean values in decision structures

Some programmers suggest that structures such as the above, where the result of the
decision is merely computation of a Boolean value, are overly verbose and even prone
to error. They prefer to have the decision in the computation itself. The difference is
entirely stylistic, because optimizing compilers may produce identical object code for
both forms. Arguments in favour of the longer form include: it is then possible to set a
per-line breakpoint on one branch of the decision; further lines of code could be added
to one
branch without refactoring the return line, which would increase the chances of bugs
being introduced, the shorter form would always permit a debugger to step to a line
"after the test" where the variables involved are still in scope.

49
6.4.3 Looping and control structures
The use of logical control structures for looping adds to good programming style as
well. It helps someone reading code to understand the program's sequence of
execution (in imperative programming languages).

6.4.4 Lists
Where items in a list are placed on separate lines, it is sometimes considered good practice
to add the item-separator after the final item, as well as between each item, at least in those
languages where doing so is supported by the syntax.

50
Snapshot

51
7. Snapshot

Home Page

52
Registration Page

Login Page

53
Our Menu

54
Admin Page

55
About Us Page

56
Testing

57
 8. Testing

The code is tested at various levels in software testing. Unit, system

and user acceptance testing are often performed. This is a grey area as
many different opinions exist as to what the stages of testing are and
how much, if any iteration occurs. Iteration is not generally part of the
waterfall model, but usually some occur at this stage. In the testing
the whole system is test one by one

Following are the types of testing:

 Defect testing the failed scenarios, including defect tracking

 Path testing

 Data set testing

 Unit testing

 System testing

 Integration testing

 Black-box testing

 White-box testing

 Regression testing

 Automation testing

 User acceptance testing

 Software performance testing.

58
Integration testing:

It is a systematic technique for testing the programmed structure while at the

same time conducting test to uncover errors associated with interfacing. The
objective is to play unit tested modules and build a programmed structure that
has been dedicated by design. Bottom-up integration was used in developing.

Testing mechanism:

Software testing is the most important phase of any software development life cycle. It is the
testing part, which validates the software and check whether the software is working as
desired or not.

The major purpose of testing is to retrieval bugs in the software. In testing software design is
executed with various test inputs for which the test programmer knows result in advance.

The departure of the programmed output from the known results confirms that the software
contains error.

Testing is divided into following phases:

1. The module interface was tested to assume that information properly float into and out of
the program unit test.

2. The local data structure was examined to assume that data stored temporally maintain their
integrity during all steps in an algorithm execution.

3. Boundary condition were tested to assume that module operated properly at

boundaries establish to limit or restrict processing.

59
4. All independent parts through this control structure were exercised to assume that all
statement in a module have been executed at least once.

5. All error handling path were tested.

Acceptance testing:
Acceptance testing is performed with realistic data of the client to demonstrate that the
software is working satisfactory. Testing here is focused on external behavior of the system;
the internal logic of program is not emphasized.

White box testing:

This is a unit testing method, where a unit will be taken at a time and tested thoroughly at a
statement level to find the maximum possible errors.

Black box testing:

This testing method considers a module as a single unit and checks the unit at interface and
communication with other modules rather getting into details at statement level. Here the
module will be treated as a block that will take some input and generate output. Output for a
given set of input combinations are forwarded to other modules. Desirable features are
frequently dropped because there is no time to implement them. Code rewrites are also set
aside, even if they are needed to bring a fragile first working version to a level a programmer
considers professional. A conscientious programmer might take the initiative and do the job
anyway, “on the sly”. Late in the project, he may drop a significant change into the package
without warning. These efforts go beyond the call of duty and the 40- hour week. They may
improve the product tremendously or destabilize it badly, probably both for a time. Whatever
the result, people take personal initiative to improve the product.

60
Black Box Testing (Functional Testing) through mannual:

Test Case Table for Sign Up

Test Test Case TEST CASE INPUT DATA Expected Actual Result
Case ID Description PROCEDURE Result Result
Tc_Sign Username,Contact, Verify the Username,Contact, Registration Successful OK
Up_01 Password,Confirm Registration Password,Confirm Successful
Password Password
Tc_Sign Username,Contact, Verify the Username,Contact, Registration Failed Try
Up_02 Password,Confirm Registration Password,Confirm Successful Again
Password Password

Test Case Table for Login

Test Case Test Case TEST CASE INPUT Expected Actual Result
ID Description PROCEDURE DATA Result Result

Tc Username, Verify Username, Login Login Successful

_login_01 Password Login Password Successfully Successfully

Tc Username, Verify Username, Login Failed Try Again

_login_02 Password Login Password Successfully

61
 Test Case Table for Admin Panel

TEST TEST CASE TEST CASE INPUT Expected Actual Result

CASE ID DESCRIPTION PROCEDURE DATA Result Result
Tc Username, Verify Username, Login Login Successful
_login_01 Password Login Password Successfully Successfully

Tc Username, Verify Username, Login Failed Try Again

_login_02 Password Login Password Successfully

62
Implementation & Future
Enhancement

63
9. Implementation and Future Enhancements

For the implementation of the proposed solution, we use the coding conventions. The main
reason for using a consistent set of coding conventions is to standardize the structure and
coding style of an application so that we and other can easily read and understand the code
good coding conventions result in precise, readable, and unambiguous source code that is
consistent with other language. Conventions are as intuitive as possible. For the database the
attributes have been named in a way that each attribute is predictable to depict the meaning.
For the tables the names have been given to symbolize the exact nature and need of the table .

Pages:

 Homepage with menu highlights

 Menu Page (pizza items, toppings, combos)
 Cart Page (add/edit/remove items)
 Checkout Page (address, payment)
 Order Confirmation Pag

Features:

 Responsive design for mobile/tablet

 Item customization (size, crust, toppings)
 Live cart updates
 Basic user authentication (signup/login)

Database

 Tech Stack: PostgreSQL / MySQL / MongoDB

 Tables/Collections:
o Users
o Products (Pizzas, toppings, sides)
o Orders
o Order items

64
Admin Panel

 Dashboard to:
o Manage menu items
o Track orders

Deployment

 Hosting:
 Database Hosting:
 Domain & SSL: Purchase domain, enable HTTPS

Future Enhancements
. Advanced Order Tracking

 Real-time tracking with Google Maps integration

 Order status updates (preparing, out for delivery, delivered)

Progressive Web App (PWA)

 Installable on phones
 Works offline (for menu viewing)

Voice Ordering / Chatbot Integration

 Voice search or ordering via smart assistants

 Live chat with a bot or human for support

Enhanced Admin Analytics

 Sales by time/date
 Customer behavior insights
 Heatmaps for location-based demand

65
Maintenance

66
 10. Maintenance

Software maintenance is the last phase in the Software Development Life Cycle that
eliminates emers in the working system during its work span and to tune the system to
any variations in m working environment. The system requites maintenance as there
may be changes and retiremem in the organizational needs. government policies,
hardware and software environment Offe small deficiencies are found as a system is
brought into operation and changes are made to remove them. System requirements
may be revised as a result of system usage or changing operational needs. Perhaps
oversight that occurred during the development process need to be corrected. Of lies
the maintenance need arises to capture additional data for storage in a database or in
transaction Eles or perhaps it may be necessary to add error detection features to
prevent system users from in adversely taking an unwanted action.

Types of Software Maintenance

1. Corrective Maintenance
Corrective maintenance aims to correct any remaining errors regardless of where they may
cause specifications, design, coding, testing, and documentation, ete.

2. Adaptive Maintenance
It contains modifying the software to match changes in the ever-changing environment

3. Preventive Maintenance
It is the process by which we prevent our system from being obsolete. It involves the concept
of reengineering & reverse engineering in which an old system with old technologies is re-
engineered using new technology. This maintenance prevents the system from dying on

4. Perfective Maintenance
It defines improving processing efficiency or performance or restricting the software to
enhance changeability. This may contain enhancement of existing system functionality,
improvement in computational efficiency, etc.

67
Bibliography

68
 Bibliography

Books-
1. “Introduction to Cloud Computing Architecture” 1st Edition June 2009, Sun Microsystems
Inc.
2. Pankaj Jalote, “An approach to software engineering”, third edition, 2005, Naroda
Publishing House
3. Leon & Leon, “Database Management System”, Vikas Publishing House.
4. Elmasri, Navathe,” Fundamentals of database systems”, Addison Wesley.

Websites-
1. http://en.wikipedia.org/wiki/SDLC
2. http://en.wikipedia.org/wiki/Rapid_application_development
3. http://www.technotrice.com/rad-model-software-engineering/
4. http://www.studymode.com/essays/Srs-Of-Online-Delivery-Ordering-1389543.html
5. http://creately.com/diagram/example/hmqrqsik1/Perfect+Pizza+-
+Context+Level+Data+Flow+Diagram

69