A PROJECT REPORT OF SOFTWARE ENGINEERING

ON

"Food Waste Management

through mobile devices"

SUBMITTED IN PARTIAL FULFILLMENT ON THE DEGREE IN BACHELOR

OF SCIENCE COMPUTER SCIENCE HONORS (2021-22)

SUBMITTED BY:

1. Karan Singh (20HCS4130)

2. Seema Kumari (20HCS4156)

3. Vanshika Gupta (20HCS4164)

4. Harshit (20HCS4179)

SUBMITTED TO:

Mr. Anil Kumar

(Associate Professor)

Deen Dayal Upadhyaya College

Department of Computer Science

Deen Dayal Upadhyaya College
University of Delhi

1
 Acknowledgement

We express our sincere gratitude to Mr. Anil Kumar, Associate Professor

Department of Computer Science, Deen Dayal Upadhyaya College, University
of Delhi, for his stimulating guidance, continuous encouragement and
supervision throughout the course of present work.

We would like to place on record our deep sense of gratitude to Prof. Dr. Sujata
Khatri , HOD of Department of Computer Science, Deen Dayal Upadhyaya
College, University of Delhi, for her generous guidance, help and useful
suggestions.

2
 Certificate

This is to certify that the project entitled, “Software Development for Food
Waste Management " submitted by "Karan, Seema, Vanshika and Harshit"
in partial fulfillment of the requirements for the award in "Software
Engineering" at the "Deen Dayal Upadhyaya College, University of Delhi" is
an authentic work carried out by him under my supervision and guidance.

To the best of my knowledge, the matter embodied in the project has not been
submitted to any other University / Institute for the award of any Degree or
Diploma.

Mr. Anil Kumar

(Associate Professor)

Department of Computer Science,

Deen Dayal Upadhyaya College,

University of Delhi.

3
 Declaration

I hereby declare that the project work entitled “Software Development for
Food Waste Management” submitted to the Deen Dayal Upadhyaya College
, is a record of an original work done by me under the guidance of Mr. Anil
Kumar, Associate Professor, Department Of Computer Science, Deen Dayal
Upadhyaya College, and this project work is submitted in the partial fulfillment
of the requirements for the award of the degree of Master of Bachelors in
Computer Science Honors. The results embodied in this thesis have not been
submitted to any other University or Institute for the award of any degree or
diploma.

SUBMITTED BY:

● KARAN SINGH (20HCS4130)

● SEEMA KUMARI (20HCS4156)

● VANSHIKA GUPTA (20HCS4164)

● HARSHIT (20HCS4179)

4
 Table of Content

S. No. Topic Page No.

Introduction 8

1
1.1 About 8
1.2 Need for the Management 8
1.3 Problem statement 8
1.4 Working of the project 8
1.5 Feasibility study 9
1.6 Advantages 9
1.7 Disadvantages 9
1.8 Software process model 9

Software requirement specification(SRS) 13

2 2.1 Introduction 13

2.1.1 Purpose 13

2.2 Scope 13
2.3 Technology used
13

5
 2.4 System Requirements 14

2.5 References 14

2.6 Developer’s Responsibilities 14

General Descriptive 15

3 3.1 Product perspective 15

3.2 User characteristics 15
3.3 Assumptions and dependencies 17

Specific Requirements 18
4 4.1 Functional Requirement 18

4.2 Non-functional Requirements 18

Data Flow Diagram(DFD) 19

5 5.1 Context Level(0-Level DFD)

19

5.2 DFD 1-Level 19

5.3 DFD 2-Level 20

5.4 Data Dictionary 21

6 Project Management 22

6.1 Function points 22

6
 6.2 Complexity adjustment values 23
6.3 Timeline chart 25

7 Designing Constraints 26

7.1 Cohesion and Coupling

26
7.2 Abstraction 27
7.3 Functional Abstraction 28
7.4 Data Abstraction 28
8 Testing 29

8.1 Testing objectives 30

8.2 Test case design 30

8.3 White-Box testing 31

8.4 Black-Box testing 32

8.5 Alpha Testing 32

8.6 Beta Testing 33

8.7 Basis path testing 34

8.8 Cyclomatic complexity 34

8.8.1 Independent program paths 35

9 Conclusion 36

10 Bibliography 37

7
 1 INTRODUCTION

1.1 ABOUT
Our project aims at designing a food waste management system which could
effectively manage food wasted in hotels/restaurants.

This android-based Food Waste Management system can assist in collecting the
leftover food from hotels & restaurants to distribute among those in need. NGOs
that are helping poor communities to battle against starvation & malnutrition can
raise a request for food supply from restaurants through this application. Once the
request is accepted, the NGOs can collect the food from the restaurants for its
distribution. In this way this android-based food waste management system will
help restaurants to reduce food waste and will help in feeding the poor and needy
people.

1.2 NEED FOR THE MANAGEMENT

A drastic increase can be seen in food waste. As per data given by Food and
Agriculture Organization (http://www.fao.org/food-loss-and-food-waste/flw-data),
⅓ rd of food produced for human consumption is wasted globally, which accounts
for almost 1.3 billion tons per year. On the other hand, also as per WHO 20% of the
population face extreme food shortages. Hence there is a need to come up with a
solution that can avoid food waste & can help feed the needy.

1.3 PROBLEM STATEMENT

Designing a food waste management system based on an android

application.

1.4 WORKING OF THE PROJECT

In this system, we have tried to reduce hotels/restaurants' food wastage by

giving leftover food to NGOs. NGOs will raise a request for the availability of food
in case restaurants have. This request is sent to the restaurant managers to the nearby
restaurants. If there is the availability of food, the restaurant head approves it. The
NGO Manager then confirms the proceedings and assigns it to one of the NGO
employees for taking away. The leftover food at the restaurant can be given to NGOs
at the end of the day. The admin can track the history of restaurants and NGOs for the
leftover foods.
 1.5 FEASIBILITY STUDY

• Technical feasibility: The technical requirement for the system is

economic and it does not use any other additional Hardware and software.

• Behavioral Feasibility: The system working is quite easy to use and

learn due to its simple but attractive interface. Users require no special
training for operating the system.

1.6 ADVANTAGES
● Benefits both the restaurant (reducing food wastage), and the needy

● Keep track of wastage food for restaurant

● User can play role in saving food wastage and help the needy

● Food waste management saves the environment.It reduces landfills.

1.7 DISADVANTAGES

● Wrong inputs will affect the project outputs.

● Internet Connection is mandatory

● The android mobile user will not be able to insert or view details if the
server goes down. Thus, there is a disadvantage of single point failure.

1.8 SOFTWARE PROCESS MODEL

Waterfall Model
The Waterfall model is the first of the software project development
models that have been introduced in the software development circles. It
is also called linear as the model implies each stage to be completed
before going on to the next one. So, the model goes linearly step by step
giving no possibilities to overlap any stage. Schematically, it would look like
this:

9
 There are several steps in the PrototypingWaterfall Model:

• Requirements : The first phase involves understanding what needs to design and
what is its function, purpose, etc. Here, the specifications of the input and output or
the final product are studied and marked.

• System Design : The requirement specifications from the first phase are studied
in this phase and system design is prepared. System Design helps in specifying
hardware and system requirements and also helps in defining overall system
architecture. The software code to be written in the next stage is created now.

• Implementation : With inputs from system design, the system is first developed
in small programs called units, which are integrated into the next phase. Each unit
is developed and tested for its functionality which is referred to as Unit Testing.

• Integration and Testing : All the units developed in the implementation phase
are integrated into a system after testing of each unit. The software designed, needs
to go through constant software testing to find out if there are any flaws or errors.
Testing is done so that the client does not face any problem during the installation
of the software.

• Deployment of System : Once the functional and non-functional testing is done,

the product is deployed in the customer environment or released into the market.

• Maintenance : This step occurs after installation, and involves making

modifications to the system or an individual component to alter attributes or
improve performance. These modifications arise either due to change requests
initiated by the customer, or defects uncovered during live use of the system. The
client is provided with regular maintenance and support for the developed software.

10
Advantages of the Waterfall Model

● The advantage of waterfall development is that it allows for

departmentalization and control. A schedule can be set with deadlines for each
stage of development and a product can proceed through the development
process model phases one by one.

● The waterfall model progresses through easily understandable and explainable

phases and thus it is easy to use.

● It is easy to manage due to the rigidity of the model – each phase has specific
deliverables and a review process.

● In this model, phases are processed and completed one at a time and they do
not overlap. The waterfall model works well for smaller projects where
requirements are very well understood.

Disadvantages of Waterfall Model

● It is difficult to estimate time and cost for each phase of the development
process in a waterfall model.

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

● Not a good model for complex and object-oriented projects.

● Not suitable for the projects where requirements are at a moderate to high risk
of changing.
11
When to use the waterfall model?
● Waterfall model is used only when the requirements are very well known in
advance, clear and not supposed to change in future.
● Product definition is stable.
● Technology is understood.
● There are no ambiguous requirements.
● Ample resources with required expertise are available freely.
● The project is short.

12
 2 SOFTWARE REQUIREMENT SPECIFICATION

2.1 INTRODUCTION
A food waste management system which could effectively manage food
waste in different restaurants/hotels. This project presents the food
management system through mobile devices, which is developed using
Android applications. This application can be installed in any user’s mobile
phones and using a simple and easy to interact interface , the extra food can
be tracked and then provided to the nearest NGO. Our system also generates
a brief report of the complete food system from the database either with
regular updates. This also helps by maintaining records of registered
restaurants/hotels and NGO’s.

2.1.1 PURPOSE

The purpose of this document is to set up a food management system that

is easy to use . This explains the purpose and functions of this system,
what software will do and under which constraints it works.

2.2 SCOPE

This document describes the requirements of the system. It is meant for the
use by the developer and will be the basis for validating the final delivered
system. The purpose of this document is to guide the developers in selecting
a design to accommodate a full scale application. Any changes made to
requirements in the future will have to go through a formal change approval
process.

2.3 TECHNOLOGY USED

1. Language : JAVA, XML
2. Software Tool : Android Studio
3. Backend: Google Firebase

13
 2.4 SYSTEM REQUIREMENT:

1. Minimum Free Instantaneous RAM: 5 MB

2. OS : Android API 15 and above
3. Processor : Quad Core and above

2.5 REFERENCES :

1. An Integrated Approach to Software Engineering Approach – Pankaj

Jalote
2. Software Engineering A Practitioner’s Approach –Roger S. Pressman

2.6 DEVELOPER’S RESPONSIBILITIES :

The developer is responsible for :

(a) Developing the system,

(b) Providing usage guidelines , tutorials and documentation

(c) Conducting any user training that might be needed for using the
system

(d) Maintaining the system for a period of one year after installation

14
 3 GENERAL DESCRIPTIVE

3.1 PRODUCT PERSPECTIVE

The system comprises 3 major modules with their sub-modules as follows:

which eases the procedure of restaurants/hotels etc to register for extra food and
NGO to collect food to prevent wastage.

3.2 USER CHARACTERISTIC

Admin:

1. Register: Users can register by providing their details.

2. Login: Users can login in their account using id and password.

3. Restaurant:

● List restaurant: List all the restaurants available

● Add/Register New Restaurant

4. NGOs:

● View All NGOs

● Add/Register New NGOs

Restaurant:

1. Register: Users(Restaurants’ heads/Hotels’ heads) can register with details.

2. Login: Users can login in to their account using id and password to maintain
legitimacy.
3. Profile:

● View Profile/Restaurant details

● Change Password
1. History:
● View Orders history
▪ Accepted
▪ Pending
15
 ▪ Confirm

2. Food:
● Add the availability of food items from restaurant

NGOs:

1. Register: NGOs can register just by providing details and verification.

2. Login: NGOs can login to their account using id and password.
3. Details:
● View Other NGOs Profile
● View restaurant requests

4. Add Request:

● Request food for NGOs from restaurant

● Assign employee for delivery of the food

5. Manage Employees:

● Add new employee

● Update employee details
● View employee profile

6. Records:
● View restaurant history

7. Profile:
● View Profile/Restaurant details
● Change Password

16
 3.3 ASSUMPTION AND DEPENDENCY

• We assume that the restaurants/hotels etc. do all the data entry

based on the correct amount of food remaining that needs to be
sent.

• We assume that all the users use the software properly and
regularly post their updates to avoid confusion.

• Users with administrator access should be careful in deleting and

modifying any information knowingly or unknowingly which will
lead to inconsistency of the database.

• The end users of this software are assumed to be in possession of a

smartphone (Android Based).

17
 4 SPECIFIC REQUIREMENT

4.1 FUNCTIONAL REQUIREMENT

NGO and Restaurant registration: Admin will add new NGO and Restaurant
details. They can also edit their personal information.
The login: The login into the application with the given user ID and password. If the
user ID and password is correct, the user will be prompted to proceed else an error
message will be displayed.
Making Requests: NGOs can make requests after filling a form and giving all the
required information like required items and their required quantity while the
Restaurants can either accept or reject the requests according to the availability of the
food.
Receipt Generation: A receipt confirmed orders will be generated and sent to both
the NGO and Restaurant id and the confirmed request will be updated in the request
database.

4.2 NON-FUNCTIONAL REQUIREMENT

• PERFORMANCE
Easy tracking of records and updating can be done.

• RELIABILITY
This software will work in the presence of the internet. In order to
access the database we will be requiring an internet connection.

• SECURITY
Only authorized users and administrators can access this.
Moreover, only the administrator has the permission to perform
addition, deletion and modification in the database.

• PORTABILITY
The application works on any android device.

18
 5 DFD (DATA FLOW DIAGRAM)

5.1 CONTEXT LEVEL ( DFD-0 LEVEL )

5.2 DFD-1 LEVEL

19
 5.3 DFD-2 LEVEL

20
5.4 DATA DICTIONARY
Restaurant Table
Sno Field Name Data Type Description

1 R_ID Number ID of the restaurant

2 R_Name text Name of the restaurant

3 R_Address text Address of the restaurant

4 Join_Date Date Joining date of restaurant

NGO Table
Sno Field Name Data Type Description

1 NGO_ID Number ID of the NGO

2 NGO_Name text Name of the NGO

3 NGO_Address text Address of the NGO

4 Join_Date Date Joining date of NGO

Employee Table
Sno Field Name Data Type Description

1 E_ID Number ID of the Employee

2 E_Name text Name of the Employee

3 Job_Type text Job Type of Employee like delivery man, etc;

4 Join_Date Date Joining date of Employee

Request Table
Sno Field Name Data Type Description

1 Request_ID Number ID of the request for food

2 Item_Name text Name of the food item

3 Item_Quantity( in plates) Number Quantity of food required

Admin Table
Sno Field Name Data Type Description

1 Username Text Store username for checking correct username

2 Password text Store password corresponding to username

3 User_Type text User Type

21
 6 PROJECT MANAGEMENT

6.1 FUNCTIONAL POINTS

The function point (FP) metric can be used effectively as a means for measuring
the functionality delivered by a system.

Using historical data, the FP metric can then be used to:

• Estimate the cost or effort required to design, code, and test the software.
• Predict the number of errors that will be encountered during testing.
• Forecast the number of components and/or the number of projected
source lines in the implemented system.
Function points are derived using an empirical relationship based on direct
measures of software’s information domain and qualitative assessments of
software complexity.

Information domain values are defined in the following manner:

Number of external inputs (EIs)

Each external input originates from a user or is transmitted from another

application and provides distinct application-oriented data or control
information. Inputs are often used to update internal logical files (ILFs).

Number of external outputs (EOs)

Each external output is derived data within the application that provides
information to the user. In this context external output refers to reports, screens,
error messages, etc.

Number of external inquiries (EQs)

An external inquiry is defined as an online input that results in the generation of

some immediate software response in the form of an online output (often
retrieved from an Internal Logical File).

22
 Number of internal logical files (ILFs)

Each internal logical file is a logical grouping of data that resides within the
application’s boundary and is maintained via external inputs.

Number of external interface files (EIFs)

Each external interface file is a logical grouping of data that resides external to
the application but provides information that may be of use to the application.

The ∑f i where i = 1 to 14 are "Complexity Adjustment Values" based on

responses to the following questions:

6.2 COMPLEXITY ADJUSTMENT VALUES

1. Does the system require reliable backup and recovery? 5

2. Are specialized data communications required to transfer 5
information to or from the application?
3. Are there distributed processing functions? 4

23
 4. Is performance critical? 3
5. Will the system run in an existing, heavily utilized operational 5
environment?
6. Does the system require online data entry? 5
7. Does the online data entry require the input transaction to be 1
built over multiple screens or operations?
8. Are the ILFs updated online? 5
9. Are the inputs, outputs, files, or inquiries complex? 2
10. Is the internal processing complex? 3
11. Is the code designed to be reusable? 4
12. Are conversion and installation included in the design? 1
13. Is the system designed for multiple installations in different 1
organizations?
14. Is the application designed to facilitate change and ease of use 4
by the user?
TOTAL 48

Once these data have been collected, a complexity value is associated with each
count. Organizations that use function point methods develop criteria for
determining whether a particular entry is simple, average, or complex. To
compute function points (FP), the following relationship is used:

FP = Count Total * [0.65 + 0.01 * ∑fi ]

Where count total is the sum of all FP entries obtained from the table.

= 63* [0.65 + 0.01*48 ]

= 63 * 1.13

= 71.19 (approx.)

24
 6.3 TIMELINE CHART
When creating a software project schedule, the planner begins with a set of
tasks. If automated tools are used, the work breakdown is input as a task
network or task outline. Effort, duration, and start date are then input for each
task. In addition, tasks may be assigned to specific individuals. A timeline chart,
also called a Gantt chart, is generated.

A timeline chart can be developed for the entire project. Timeline depicts a part
of a software project schedule that emphasizes. The horizontal bars indicate the
duration of each task. When multiple bars occur at the same time on the
calendar, task concurrency is implied. The diamonds indicate milestones.

25
 7 DESIGN CONSTRAINTS

7.1 COHESION AND COUPLING

When a software program is modularized, its tasks are divided into several
modules based on some characteristics. As we know, modules are a set of
instructions put together in order to achieve some tasks. They are, though,
considered as a single entity but may refer to each other to work together.
There are measures by which the quality of a design of modules and their
interaction among them can be measured. These measures are called coupling
and cohesion.

Cohesion

Cohesion is a measure that defines the degree of intra-dependability within

elements of a module. The greater the cohesion, the better is the program
design.

Cohesion measures the strength of relationship between pieces of functionality

within a given module.

Advantages of high cohesion are:

• Readability – closely related functions are contained in a single

module.

• Maintainability – debugging tends to be contained in a single module.

• Reusability – because developers will find the component they need

more easily among the cohesive set of operations provided by the
module.

26
 Coupling

Coupling is a measure that defines the level of inter-dependability among

modules of a program. It tells at what level the modules interfere and interact
with each other. The lower the coupling, the better the program. A program with
low coupling is often called loosely coupled.

Coupling is the manner and degree of interdependence between software

modules.

Advantages of loosely coupled systems are:

• Maintainability – changes are confined in a single module.

• Components in a loosely coupled system can be replaced with alternative

implementations that provide the same services.

• Testability – modules involved in unit testing can be limited to a

minimum.

• Components in a loosely coupled system are less constrained to the same

platform, language, operating system, or build environment.

7.2 ABSTRACTION

The psychological notion of "abstraction" permits one to concentrate on a

problem at some level of generalization without regard to irrelevant low
level details; use of abstraction also permits one to work with concepts
and terms that are familiar in the problem environment without having to
transform them to an unfamiliar structure.

27
 7.3 FUNCTIONAL ABSTRACTION
A procedural abstraction is a named sequence of instructions that has a
specific and limited function. An example of a procedural abstraction
would be the word open for a door. Open implies a long sequence of
procedural steps (e.g., walk to the door, reach out and grasp knob, turn
knob and pull door, step away from moving door, etc.).

7.4 DATA ABSTRACTION

A data abstraction is a named collection of data that describes a data
object. In the context of the procedural abstraction open, we can define a
data abstraction called door.

28
 8 TESTING

The development of software systems involves a series of production

activities where opportunities for human fallibility are enormous. Errors
may begin to occur at every inception of the process where the objectives
may be erroneously or imperfectly specified as well as later design and
development states. Because of human inability to perform and
communicate with perfection, software development is accompanied by
quality assurance activity.

Testing is the process of running a system with the intention of finding

errors. Testing enhances the integrity of a system by detecting deviations in
design and errors in the system. Testing aims at detecting error-prone areas.
This helps in the prevention of errors in a system. Testing also adds value to
the product by conforming to the user requirements.

The requirement for the application testing is as follows:

• Test Guidelines
• Integration Strategy
• Special Considerations
• Test Documents

Software testing is a critical element of software quality assurance and

represents the ultimate reviews of specification design and coding. The
increasing visibility of software as a system element and attendant ―cost
associated with a software failure is motivating forces for well planned,
thorough testing.

29
 8.1 TESTING OBJECTIVES
The main purpose of testing is to detect errors and error prone areas in a system.
Testing must be thorough and well-planned. A partially tested system is as bad
as an untested system. And the price of an untested and under-tested system is
high.

Testing is a process of executing a program with the intent of finding an as yet

undiscovered error. A successful test is one that uncovers a yet undiscovered
error. Our objective is to design tests that systematically uncover different
classes of errors and to do so with a minimum amount of time and effort. Data
collected as testing is conducted provide a good indication software reliability
and some indication of software quality as a whole

8.2 TEST CASE DESIGN

The design of tests can be as challenging as the initial design of the project
itself. Testing design tests that have the highest likelihood of finding the
most errors with a minimum amount of time and effort.
Any software product can be tested in any of the two ways:
• Knowing the specific function that a product has been designed
to perform, tests can be conducted that demonstrate each function is
fully operational.
• Knowing the internal working of a product. Tests can be conducted
to ensure that the internal operation of the product performs according to
specification and all internal components have been adequately
exercised. The first step is called the black box testing and the second
white box testing.

Test cases are designed to answer the following questions:

• How is functional validity tested?

30
 • What classes of input will make good test cases?
• Is the system particularly sensitive to certain input values?
• How are the boundaries of a data class isolated?
• What data rates and data volumes can the system tolerate?
• What effect will specific combinations of data have on system operation?

In this project since no coding has been done, we describe testing in brief.

8.3 WHITE-BOX TESTING

White-box testing, also called glass-box testing, is a test case design
method that uses the control structure of the procedural design to derive
test cases. Using white-box testing methods, the software engineer can test
cases that
• Guarantee that all independent paths within in a module have
been exercised at least once (Cyclomatic complexity)
• Exercise all logical decisions on their true and false sides

• Execute all loops at their boundaries and within their

operational bounds
• Exercise internal data structures to ensure their validity

The various white-box testing techniques are:

• Basis path Testing
• Control Structure Testing

31
 8.4 BLACK-BOX TESTING
It is also called behavioral testing, focusing 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.

Black Box testing is not an alternative to white box testing rather; it is a

complementary approach that is likely to uncover a different class of errors than
white box methods.

The various black-box testing techniques are:

• Graph-based Testing

• Equivalence Partitioning

• BV Analysis

• Comparison testing

• Orthogonal array Testing

8.5 ALPHA TESTING

Alpha Testing is a type of software testing performed to identify bugs before
releasing the product to real users or to the public. Alpha Testing is one of the user
acceptance testing.
This is referred to as alpha testing only because it is done early on, near the end of
the development of the software. Alpha testing is commonly performed by
homestead software engineers or quality assurance staff. It is the last testing stage
before the software is released into the real world.

32
8.6 BETA TESTING
Beta Testing is performed by real users of the software application in a real
environment. Beta testing is one type of User Acceptance Testing.
Beta version of the software, whose feedback is needed, is released to a limited
number of end-users of the product to obtain feedback on the product quality. Beta
testing helps in minimization of product failure risks and it provides increased quality
of the product through customer validation.
It is the last test before shipping a product to the customers. One of the major
advantages of beta testing is direct feedback from customers.

Equivalence Partitioning

A black-box testing method that divides the input domain of a program into
classes of data from which test cases are derived. An ideal test case single-
handedly uncovers a complete class of errors, thereby reducing the total number
of test cases that must be developed. Test case design is based on an evaluation
of equivalence classes for an input condition. An equivalence class represents a
set of valid or invalid states for input conditions. From each equivalence class,
test cases are selected so that the largest number of attributes of an equivalence
class is exercised at once.

BV Analysis
A greater number of errors occur at the boundaries of the input domain rather
than in the "center". Boundary value analysis is a test case design method
that complements equivalence partitioning

• It selects test cases at the edges of a class

• It derives test cases from both the input domain and output domain

33
 8.7 BASIS PATH TESTING
Basis path testing, a structured testing or white box testing technique used
for designing test cases intended to examine all possible paths of
execution at least once. Creating and executing tests for all possible paths
results in 100% statement coverage and 100% branch coverage.

8.8 CYCLOMATIC COMPLEXITY

Pseudocode

1. int function(void)
2. {
3. NGO Login;
4. NGO’s Request;
5. Restaurant Login;
6. if( Availability of food == Yes”)
7. {
8. Assign Employee;
9. Takes the order from restaurant;
10. Receipt gets printed;
11. }
12. return 0;
13. }

34
 Cyclomatic complexity is a software metric that provides a quantitative measure
of the logical complexity of a program.

In figure, the cyclomatic complexity can be computed by using the algorithm:

1. The number of regions correspond to the cyclomatic complexity = 2

2. V (G) = E-N+2 (where E= no. of edges, N= nodes)

V (G) = 9 edges – 9 nodes + 2
V (G) = 2

3. V(G) = Predicate nodes(P) +1

V (G) = 1 + 1 = 2
Hence, the cyclomatic complexity of the program is 2.

8.8.1 Independent Programs Paths

An independent path is any path through the program that introduces at least
new set of processing statements or a new condition. When stated in terms of a
graph, an independent path must move along at least one edge that has not
traversed before the path is defined.

A set of independent paths flow graph illustrated in figure is:

Path 1: 1-3-4-5-6-8-9-10-12

Path 2: 1-3-4-5-6-12

35
 CONCLUSION

This whole work is to deliver the leftover food to the needy and prevent
the wastage of food from restaurants/hotels. This project “Mobile Based
Food Waste Management System” is a collection of static and dynamic
web-based or mobile application-based pages. This project provides an
offer to the user to enter the data through their respective registration
forms. It is very helpful for NGOs and restaurants who can together
prevent food wastage and can help the people to get the food they need.
In the future, this work can be expanded to deliver food items from
various functions/events/celebrations in the neighborhood and delivered
to orphanages, temples, and public charities. It can be expanded to those
people who are willing to contribute to a selfless cause.

36
 BIBLIOGRAPHY

● https://developer.android.com/
● https://stackoverflow.com/
● https://www.tutorialspoint.com/index.htm
● https://medium.com/

37
38