Online Food Order Management System for Foodie

Prepared For
Practicum Defense Board

Supervisor

M M Rakibul Islam Prepared By

Assistant Professor
Department of Computer Science and Name: Burhan Uddin Rana
Engineering ID: 20103161
IUBAT
1

Date: 13-12-2024
 Table of content
 Organization  RMMM plan
 Project overview  Function Point Estimation(FP calculation)
 Objective  Effort Based Estimation
 Feasibility Analysis  Cost Estimation
 Project Model  Project Scheduling Chart
 Process Model  ERD
 Functionalities & Features  DFD
 Requirement Engineering  Testing
 Use case  Limitation
 Activity diagram  Future work
 Risk Analysis  Conclusion

2
 Organization

Name : Kodeeo Limited

Address : House-14, Road-8, Sector-6,

Uttara, Dhaka – 1230

3 3
 Organization (Cont.)
Organization’s Mission-

The mission is to ensure satisfaction of client needs in relation to

their characteristics.

Organization’s Vision-

is to empower the youth and become a successful IT company of

digital Bangladesh

4 4
 Project Overview

Full-featured web application

User-friendly
Accessible from anywhere on the internet
Save time
Reduce the physical presence

5
 Objective
Board Objective

 "To seamlessly manage and optimize the end-to-end process of food ordering through the
implementation of a robust online food order management system, ensuring operational efficiency,
customer satisfaction, and sustainable business growth.’’

Specific Objective

The specific objective of this project are listed below:

 Ensuring a user-friendly and robust platform

 Actively encourage order adoption among customers.
 Position “Foodie” as a model for food order platform.
 Develop a long term sustainability plan

6
Feasibility Analysis

7
Project Model

8
 Process Model
For my project, I think Incremental process
model is best.
I am selecting this process model because-

 Responds well to changing requirements

 Provides partial functionality quickly.
 Smaller, manageable increments reduce
overall project risk.
 Smaller increments are easier to test and
debug.
 Accelerates delivery of useful functionality.
 Enhances satisfaction through regular
Incremental Process Model deliveries.

9
 Functionalities & Features
All possible functionalities Admin
Users
 Customer can register and
• Admin can log in to the system.
login.

• Can manage the food.
Customer can see the foods.
 • Can manage the food category.
Can see all the food menu.
 Can order the desired food.
• Can manage the food menu‘s.
 Can place the order.
• Can manage the items of food.
 Can see the price of the foods
• Can approve or disapprove any items.
and total amount of bill. • Can manage the report generation
10
 Requirement Engineering

The purpose of requirements management is to ensure product development goals

are successfully met. It is a set of techniques for documenting, analyzing,
prioritizing, and agreeing on requirements so that engineering teams always have
current and approved requirements.

There are Four Requirement Engineering Techniques:

1) User Requirement
2) System Requirement
3) Functional Requirement
4) Non Functional Requirement
11
 Requirement Engineering (Cont.)

User & System Requirement:

1. Admin can Log in.
 1.1) System needs Email and Password to compare the validation of access.
2. Can manage the food menu’s.
2.1) System needs valid credentials and admin can view the new customer list and admin
can accept/delete the customer.
3. Admin can manage the food category
 3.1) System needs information of category like name and description
4. Admin can manage food items
 4.1) System needs information of foods such as food name, Description.
12
 Requirement Engineering (Cont.)

5. customer can update Profile Info .

 5.1) System needs information of customer’s name ,address, email , mobile no
etc
6. Customer can place orders.
 6.1) System needs information of order details, such as customer name,
description, category, food name etc.
7. Customer can see all food item are available.
7.1) System needs valid credentials to log in.

13
 Requirement Engineering (Cont.)
Functional Requirement:
1. Admin can Login
2. Admin can Add/Edit category
3. Admin can Add, edit, delete menu
4. Admin can create new user
5. Admin can view customer list
6. Admin can view menu list
7. Admin can generate report
8. Customer can Login
9. Customer can update profile
10. Customer can placed new order
11. Customer view available food items.

14
 Requirement Engineering (Cont.)

Non Functional Requirement:

1. If the user is not logged in, they will not be able to view or change
their profile.
2. In order to place new order, one must first register.
3. A user may only sign up for a single account with a given email
address.
4. The administrator is unable to make changes to the user profile
information.

15
Use case

16
Activity Diagram for Admin

17
Activity Diagram for User

18
Risk Analysis

19
Risk Analysis(Cont.)
RMMM Plan

21
RMMM Plan(Cont.)

22
RMMM Plan (Cont.)

23
Function Point Estimation(FP calculation)
GSC DI
1: Data Communications 2
2: Distributed Data Processing 0
3: Performance 4
4: Heavily used Configuration 2
5: Transaction Pate 1
6: Online Data Entry 3
7: End User Efficiency 4
8: Online Update 3
9: Complex Processing 3
10: Reusability 2
11: Installation fare 3
12: Operational fare 1
13: Multiple Sites. 4
14: facilitate Change 3
Total Degree of Influence (TDI) (Range 0 to 70 - influence size by ±35%) 35

Table 5: Performance and Environmental Impact

 Function Point Estimation(FP calculation) (Cont.)

Value Adjustment Factor (VAF) = (0.65 + (0.1X

TDT) Efforts for the project = AFP X Productivity
= (0.65 + (0.1 * 35))
= 522.9 * 15.5
= (0.65 + 3.5)
= 8104.95 person-hours / 8 hours
= 4.15
= 1013.11875 person-days / 26 days
UFP = DFP (Data Fn) + UFP (Transaction Fn) ≈ 38.96 person-months
= 97+29 3.24 months
=126

Adjusted Function Point Count = UFP X VAR

= 126 * 4.15
= 522.9

25
Effort Based Estimation

26
 Cost Estimation
Type Amount

Personal Cost 130,000

Hardware cost 2655

Software cost 0

Others 0

Total cost in BDT 132,655 TK

27
Project Scheduling Chart

28
ERD

29
DFD

30
DFD

31
DFD
DFD

33
DFD

34
 Testing

Black –Box Testing

• Black-box testing which is also known as behavioral testing focuses on
the functional requirements of the software. It enables the software
engineer to derive sets of input conditions that will fully exercise all
functional requirements for a program.
White Box Testing
• White-box testing, which is also known as glass-box testing, is a test
case design method that uses the control structure of the procedural
design to derived test cases.

35
 Testing (Cont.)
Testing scenario, No: 1
Scenario Admin log in testing scenario of our system.
Input’s Email and Password of admin for log in.
Desired Output’s The users successfully entry all the necessary basic information will resulting their
successful login
Actual Output’s Admin login successful
Verdict Getting result from Desired Output’s and Actual Output’s decided this system is successful
for login.

Testing scenario, No: 2

Scenario Customer login

Input’s Email and Password

Desired Output’s Providing all essential information, the user will gain access to their account and the
successfully logged in.

Actual Output’s Customer Login works.

Verdict The actual outcome achieved.

36
 Testing (Cont.)
Testing scenario, No: 3

Scenario Create new food menu

Input’s Food name, price, category, description.
Desired Output’s Menu will be successfully created
Actual Output’s Menu has been created
Verdict The process is worked correctly and successfully.

Testing scenario, No: 4

Scenario Category add

Input’s Category name, description
Desired Output’s Category will be successfully added to the system
Actual Output’s Category adding works
Verdict The process is worked correctly and successfully.
37
Project Live Demonstration

38
 Limitation
This project has some limitations those we have planned to develop in future.

The limitations are:

• There is no deliverymen who shipped the food to the customer.

• Absence of Premium subscription Feature
• It has only one admin, Which might make things slower and could be a problem if
more tasks need attention.
• Lack of robust privacy and security.

39
 Future Work

 Develop an integrated collaborative deliveryman within the system for

customer.
 Implement a multi-administrator system to handle increased tasks
efficiently.
 Gather user feedback to address specific needs and concerns.
 Strengthen privacy and security measures for user confidence.

40
 Conclusion

The goal of this website is to reach the maximum number of customer for getting the food
orders and manage it within a short time. It’s faces some challenges like keeping the
customer data secure and staying up-to-date with technology. Future plans aim to add more
features for better flexibility and efficiency.

41
42