Download as pdf or txt
Download as pdf or txt
You are on page 1of 73

Name:SIMRAN.M.

SINDHI Batch: CO5


En_no:226010307124 Sub:ISE

PRACTICAL 1:
AIM: Describe various Software Development with appropriate diagram.

 What is SDLC?
The software development lifecycle (SDLC) is the cost-effective and time-efficient process that
development teams use to design and build high-quality software. The goal of SDLC is to minimize
project risks through forward planning so that software meets customer expectations during production
and beyond. This methodology outlines a series of steps that divide the software development process
into tasks you can assign, complete, and measure.

 Why is SDLC important?


Software development can be challenging to manage due to changing requirements, technology upgrades,
and cross-functional collaboration. The software development lifecycle (SDLC) methodology provides a
systematic management framework with specific deliverables at every stage of the software development
process. As a result, all stakeholders agree on software development goals and requirements upfront and
also have a plan to achieve those goals.

A.Y.D.T.I Page | 1
Name:SIMRAN.M.SINDHI Batch: CO5
En_no:226010307124 Sub:ISE

Here are some benefits of SDLC:

 Increased visibility of the development process for all stakeholders involved


 Efficient estimation, planning, and scheduling
 Improved risk management and cost estimation
 Systematic software delivery and better customer satisfaction

 What are SDLC models?


A software development lifecycle (SDLC) model conceptually presents SDLC in an organized fashion to
help organizations implement it. Different models arrange the SDLC phases in varying chronological
order to optimize the development cycle. We look at some popular SDLC models below.

There are 5 types of different SDLC models are there:

i. Waterfall Model

ii. Spiral Model

iii. Prototyping Model

iv. Agile Model

v. Increment Model

 How does SDLC work?


The software development lifecycle (SDLC) outlines several tasks required to build a software
application. The development process goes through several stages as developers add new features and fix
bugs in the software.The details of the SDLC process vary for different teams. However, we outline some
common SDLC phases below.

1. Plan

2. Design

3. Implement

4. Test

5. Deploy

6. Maintain
A.Y.D.T.I Page | 2
Name:SIMRAN.M.SINDHI Batch: CO5
En_no:226010307124 Sub:ISE

 WATERFALL MODEL:~
 WHAT IS WATERFALL MODEL?
The waterfall model arranges all the phases sequentially so that each new phase depends on the outcome
of the previous phase. Conceptually, the design flows from one phase down to the next, like that of a
waterfall.

Pros and cons

The waterfall model provides discipline to project management and gives a tangible output at the end of
each phase. However, there is little room for change once a phase is considered complete, as changes can
affect the software's delivery time, cost, and quality. Therefore, the model is most suitable for small
software development projects, where tasks are easy to arrange and manage and requirements can be pre-
defined accurately.

A.Y.D.T.I Page | 3
Name:SIMRAN.M.SINDHI Batch: CO5
En_no:226010307124 Sub:ISE

 When to Use The Waterfall Model?

The waterfall model is most commonly used in software engineering and product development, less often

– in other projects and industries.

Employ the waterfall model only if your project meets the following criteria:

 All the requirements are known, clear, and fixed

 There are no ambiguous requirements

 The project is short and simple

 The development environment is stable

 Resources are adequately trained and available

 The necessary tools and techniques used are stable, and not dynamic

 ADVANTAGES OF WATERFALL MODEL:

 Simple and easy to understand and use


 Easy to manage due to the rigidity of the model. Each phase has specific deliverables and a
review process.
 Phases are processed and completed one at a time.
 Works well for smaller projects where requirements are very well understood.
 Clearly defined stages.
 Well understood milestones.
 Easy to arrange tasks.
 Process and results are well documented.

A.Y.D.T.I Page | 4
Name:SIMRAN.M.SINDHI Batch: CO5
En_no:226010307124 Sub:ISE

 DISADVANTAGES OF WATERFALL MODEL:

 No working software is produced until late during the life cycle.


 High amounts of risk and uncertainty.
 Not a good model for complex and object-oriented projects.
 Poor model for long and ongoing projects.
 Not suitable for the projects where requirements are at a moderate to high risk of changing. So,
risk and uncertainty is high with this process model.
 It is difficult to measure progress within stages.
 Cannot accommodate changing requirements.
 Adjusting scope during the life cycle can end a project.
 Integration is done as a "big-bang. at the very end, which doesn't allow identifying any
technological or business bottleneck or challenges early.

 SPIRAL MODEL:~
 WHAT IS SPIRAL MODEL?
The Spiral Model is a Software Development Life Cycle (SDLC) model that provides a systematic
and iterative approach to software development. In its diagrammatic representation, looks like a spiral
with many loops. The exact number of loops of the spiral is unknown and can vary from project to
project. Each loop of the spiral is called a Phase of the software development process.
1. The exact number of phases needed to develop the product can be varied by the project manager
depending upon the project risks.
2. As the project manager dynamically determines the number of phases, the project manager has an
important role in developing a product using the spiral model.
3. It is based on the idea of a spiral, with each iteration of the spiral representing a complete software
development cycle, from requirements gathering and analysis to design, implementation, testing,
and maintenance.

A.Y.D.T.I Page | 5
Name:SIMRAN.M.SINDHI Batch: CO5
En_no:226010307124 Sub:ISE

 When to use Spiral Model?

 A Spiral model in software engineering is used when project is large


 When releases are required to be frequent, spiral methodology is used
 When creation of a prototype is applicable
 When risk and costs evaluation is important
 Spiral methodology is useful for medium to high-risk projects
 When requirements are unclear and complex, Spiral model in SDLC is useful
 When changes may require at any time
 When long term project commitment is not feasible due to changes in economic priorities

 Advantages of the Spiral Model:


 Suitable for large-scale products.

 New functionality or changes can be accommodated at later stages.

 Efficient cost estimation.

 Development is fast.

 Proper risk management.

 Involves customer feedback.

 Development is divided into smaller parts and risks are managed separately.

 Efficiently capture requirements.

 Strong documentation control.

 Disadvantages of Spiral Model:

 It is not suitable for small projects as it is expensive.


 It is much more complex than other SDLC models. Process is complex.
 Too much dependable on Risk Analysis and requires highly specific expertise.
 Difficulty in time management. As the number of phases is unknown at the start of the
project, so time estimation is very difficult.
 Spiral may go on indefinitely.
 End of the project may not be known early.
A.Y.D.T.I Page | 6
Name:SIMRAN.M.SINDHI Batch: CO5
En_no:226010307124 Sub:ISE

 It is not suitable for low risk projects.


 May be hard to define objective, verifiable milestones. Large numbers of intermediate
stages require excessive documentation.

 PROTOTYPING MODEL:~
 WHAT IS PROTOTYPING?
Prototyping Model is a software development model in which prototype is built, tested, and reworked
until an acceptable prototype is achieved. It also creates base to produce the final system or software. It
works best in scenarios where the project’s requirements are not known in detail. It is an iterative, trial
and error method which takes place between developer and client.

 When to use Prototype model:

 Prototype model should be used when the desired system needs to have a lot of interaction with
the end users.
 Typically, online systems, web interfaces have a very high amount of interaction with end users,
are best suited for Prototype model. It might take a while for a system to be built that allows ease
of use and needs minimal training for the end user.
 Prototyping ensures that the end users constantly work with the system and provide a feedback
which is incorporated in the prototype to result in a useable system. They are excellent for
designing good human computer interface systems.

 Advantages of Prototype model:

 Users are actively involved in the development

A.Y.D.T.I Page | 7
Name:SIMRAN.M.SINDHI Batch: CO5
En_no:226010307124 Sub:ISE

 Since in this methodology a working model of the system is provided, the users get a better
understanding of the system being developed.
 Errors can be detected much earlier.
 Quicker user feedback is available leading to better solutions.
 Missing functionality can be identified easily
 Confusing or difficult functions can be identified
 Requirements validation, Quick implementation of, incomplete, but Functional, application.

 Disadvantages of Prototype model:

 Leads to implementing and then repairing way of building systems.


 Practically, this methodology may increase the complexity of the system as scope of the system
may expand beyond original plans.
 Incomplete application may cause application not to be used as the full system was designed
 Incomplete or inadequate problem analysis.

 AGILE MODEL:~
 WHAT IS AGILE MODEL?
The meaning of Agile is swift or versatile."Agile process model" refers to a software development
approach based on iterative development. Agile methods break tasks into smaller iterations, or parts do
not directly involve long term planning. The project scope and requirements are laid down at the
beginning of the development process. Plans regarding the number of iterations, the duration and the
scope of each iteration are clearly defined in advance.

A.Y.D.T.I Page | 8
Name:SIMRAN.M.SINDHI Batch: CO5
En_no:226010307124 Sub:ISE

 When to use the Agile Model?

 When frequent changes are required.

 When a highly qualified and experienced team is available.

 When a customer is ready to have a meeting with a software team all the time.

 When project size is small.

 Advantage(Pros) of Agile Method:

 Frequent Delivery
 Face-to-Face Communication with clients.
 Efficient design and fulfils the business requirement.
 Anytime changes are acceptable.

A.Y.D.T.I Page | 9
Name:SIMRAN.M.SINDHI Batch: CO5
En_no:226010307124 Sub:ISE

 It reduces total development time.

 Disadvantages(Cons) of Agile Model:

 Due to the shortage of formal documents, it creates confusion and crucial decisions taken
throughout various phases can be misinterpreted at any time by different team members.
 Due to the lack of proper documentation, once the project completes and the developers allotted to
another project, maintenance of the finished project can become a difficulty.

 INCREMENT MODEL:~
 WHAT IS INCREMENT MODEL?
Incremental Model is a process of software development where requirements divided into multiple
standalone modules of the software development cycle. In this model, each module goes through the
requirements, design, implementation and testing phases. Every subsequent release of the module adds
function to the previous release. The process continues until the complete system achieved.

A.Y.D.T.I Page | 10
Name:SIMRAN.M.SINDHI Batch: CO5
En_no:226010307124 Sub:ISE

 When we use the Incremental Model?

 When the requirements are superior.

 A project has a lengthy development schedule.

 When Software team are not very well skilled or trained.

 When the customer demands a quick release of the product.

 You can develop prioritized requirements first.

 Advantage of Incremental Model

 Errors are easy to be recognized.


 Easier to test and debug
 More flexible.
 Simple to manage risk because it handled during its iteration.
 The Client gets important functionality early.

 Disadvantage of Incremental Model

 Need for good planning


 Total Cost is high.
 Well defined module interfaces are needed.

A.Y.D.T.I Page | 11
Name:SIMRAN.M.SINDHI Batch: CO5
En_no:226010307124 Sub:ISE

PRACTICAL 2:
AIM: Write problem statement to define the project title with bounded scope of the
project.

 What is an online ordering system?


An online food ordering system or an online ordering platform is a place where customers can directly
order from the restaurant instead of going through a third-party food delivery business. It is a web-based
ordering system where customers using a mobile app can use the online user interface to order online.
Online ordering systems are where you can easily ask customers to order from without needing to pay any
huge commission to ordering apps that are popular in the market these days.

 What is the purpose of an online ordering system?


The purpose of an online ordering system is to make itself beneficial for the customer and the business so
that they can stay afloat while also serving customers their favorite dishes. With Food Aggregators
increasing their commission every quarter, it is unsustainable for the restaurant to manage their restaurant
while depending on food delivery orders from swiggy and zomato. The online ordering market is expanding
and, especially the online food ordering segment is growing at a very rapid pace. Food Delivery is the
preferred way for customers to enjoy food these days. This change has been roughly owed to the pandemic
where customers prefer to order food online instead of dining out.

 Types of online food ordering platforms:


1. Restaurant apps
2. Food ordering platforms
3. Food delivery platforms
4. Restaurant ordering websites
5. 3rd-party apps like UberEats, Zomato, Deliveroo, etc.

A.Y.D.T.I Page | 12
Name:SIMRAN.M.SINDHI Batch: CO5
En_no:226010307124 Sub:ISE

 What are the benefits of online food ordering?


 The food ordering process easier for customers as well as for restaurant owners.
 Easy order management
 Less processing time means less waiting time for food orders.
 Live order tracking.
 It is very easy to customize the food order.

A.Y.D.T.I Page | 13
Name:SIMRAN.M.SINDHI Batch: CO5
En_no:226010307124 Sub:ISE

 Disadvantages:
While there are many advantages to the online food ordering system, there are also some disadvantages
to online food ordering systems. They are
 Price
 Limited menu
 Preparation
 Quality of food may be suffer
 Food may get cold
 The vibe of the restaurant is missing

 What is the Future of Online Food Ordering Systems?

Ordering food online gains popularity among the restaurant customers in recent decades due to its
convenience. Earlier, it was a troublesome task for restaurant owners to receive orders over phone calls,
initiate the process manually, and deliver it in a chaotic way. After the advent of online food ordering
application, the ordering for customers and delivering for restaurateurs become easy and convenient. The
advancements in technology have added more convenience to the system, and undoubtedly, the online
food ordering system will decide the future of the food business.

A.Y.D.T.I Page | 14
Name:SIMRAN.M.SINDHI Batch: CO5
En_no:226010307124 Sub:ISE

PRACTICAL 3:
AIM: Select relevant process model to define activities and related tasks
set for assigned project
INTRODUCTION:
The popularity of online food ordering has skyrocketed in recent years, and the new channel has become
a mainstay for many hospitality businesses.

While the Covid pandemic was a catalyst for the dramatic rise in online food ordering, its convenience
proved popular with customers, and online food ordering is set for further growth in the coming years.

WATERFALL MODEL:
The Waterfall Model was the first Process Model to be introduced. It is also referred to as a linear-
sequential life cycle model. It is very simple to understand and use. In a waterfall model, each phase must
be completed before the next phase can begin and there is no overlapping in the phases.

The Waterfall model is the earliest SDLC approach that was used for software development.

The waterfall Model illustrates the software development process in a linear sequential flow. This means
that any phase in the development process begins only if the previous phase is complete. In this waterfall
model, the phases do not overlap.

A.Y.D.T.I Page | 15
Name:SIMRAN.M.SINDHI Batch: CO5
En_no:226010307124 Sub:ISE

 Requirement Gathering and analysis − All possible requirements of the system to be developed
are captured in this phase and documented in a requirement specification document.
 System Design − The requirement specifications from first phase are studied in this phase and the
system design is prepared. This system design helps in specifying hardware and system
requirements and helps in defining the overall system architecture.
 Implementation − With inputs from the system design, the system is first developed in small
programs called units, which are integrated in 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. Post integration the entire system is tested for any faults and
failures.
 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 − There are some issues which come up in the client environment. To fix those
issues, patches are released. Also to enhance the product some better versions are released.
Maintenance is done to deliver these changes in the customer environment.

REQUIREMENTS FOR ONLINE FOOD ORDERING SYSTEM:


1. Customer registration and login OR Scan QR code for login.
2. Choose Restaurants.
3. Viewing Restaurants Menu
4. Viewing Offers.
5. Food Category.
6. Discount on Cards.
7. Add to Cart Food.
8. Delete Food from Cart.
9. Apply Discount Coupons.
10. Order.
11. Generate Order Detail.
12. History of Order.
13. Customer directly Message or Call to Restaurants/Delivery person.
14. Tracking.
15. Payment.

A.Y.D.T.I Page | 16
Name:SIMRAN.M.SINDHI Batch: CO5
En_no:226010307124 Sub:ISE

DESIGN:
The Entity Relational Model is a model for identifying entities to be represented in the database and
representation of how those entities are related. The ER data model specifies enterprise schema that
represents the overall logical structure of a database graphically.
The Entity Relationship Diagram explains the relationship among the entities present in the database.
ER models are used to model real-world objects like a person, a car, or a company and the relation
between these real-world objects. In short, the ER Diagram is the structural format of the database.

Symbols Used in ER Model:


ER Model is used to model the logical view of the system from a data perspective which consists of
these symbols:

 Rectangles: Rectangles represent Entities in the ER Model.


 Ellipses: Ellipses represent Attributes in the ER Model.
 Diamond: Diamonds represent Relationships among Entities.
 Lines: Lines represent attributes to entities and entity sets with other relationship types.
 Double Ellipse: Double Ellipses represent Multi-Valued Attributes.
 Double Rectangle: Double Rectangle represents a Weak Entity.

IMPLEMENTATION:
Visual Studio Code:~
 Visual Studio Code is a streamline code editor with support for development operation like
debugging, task running ,and version control. It aims to provide just the tools a developer needs
for a quick code-build-debug cycle and leaves more complex workflows to fuller featured IDEs,
such as Visual Studio IDE.

TESTING:
Testing is a type of software testing in which the different testing levels are performed one after the
other. It involves the testing team members and unlike the agile testing development team is not
involved in the testing phase. Testing team basically performs the testing operation once the full
development of the software or the product is complete. Only after the completion of development life
cycle, the testing life cycle begins. Once the software is fully developed then only the testing operation
are performed.

A.Y.D.T.I Page | 17
Name:SIMRAN.M.SINDHI Batch: CO5
En_no:226010307124 Sub:ISE

MAINTENANCE:
The maintenance phase is the last stage of the waterfall model, where the product is monitored, updated,
and fixed after it is released to the users. The maintenance phase can include activities such as bug fixing,
performance improvement, security enhancement, feature addition, or user feedback integration. The
maintenance phase can last for months or years, depending on the product life cycle and the user
expectations.

The maintenance phase is important for several reasons. First, it ensures that the product meets the
quality standards and the user requirements, and that it can adapt to changing environments and needs.
Second, it enhances the user satisfaction and loyalty, as it shows that the project team cares about the user
experience and feedback, and that it is willing to improve the product continuously. Third, it reduces the
risks and costs of future problems, as it prevents the product from becoming obsolete, incompatible, or
vulnerable.

WHY TO USE WATERFALL MODEL?


 Simple and easy to understand and use
 Easy to manage due to the rigidity of the model. Each phase has specific deliverables and a review
process.
 Phases are processed and completed one at a time.
 Works well for smaller projects where requirements are very well understood.
 Clearly defined stages.
 Well understood milestones.
 Easy to arrange tasks.
 Process and results are well documented.

A.Y.D.T.I Page | 18
Name:SIMRAN.M.SINDHI Batch: CO5
En_no:226010307124 Sub:ISE

PRACTICAL 4:
Aim: Gather application specific requirements Requirement gathering.
INTRODUCTION REQUIREMENT GATHERING:
In the world of software development, the success of a project relies heavily on a crucial yet often
overlooked phase: Requirement Gathering. This initial stage acts as the foundation for the entire
development life cycle, steering the course of the software and ultimately determining its success. Let’s
explore why requirement gathering is so important, what its key components are, and how it
profoundly influences the overall development process.

What is Requirements Gathering?


Requirements gathering is a crucial phase in the software development life cycle (SDLC) and project
management. It involves collecting, documenting, and managing the requirements that define the
features and functionalities of a system or application. The success of a project often depends on the
accuracy and completeness of the gathered requirements in software.

 Functional Requirements:
These are the requirements that the end user specifically demands as basic facilities that the system
should offer. All these functionalities need to be necessarily incorporated into the system as a part of
the contract.
These are represented or stated in the form of input to be given to the system, the operation performed
and the output expected. They are the requirements stated by the user which one can see directly in the
final product, unlike the non-functional requirements.

1. Customers should be able to view the status of their orders, including when they were placed,
when they are expected to be ready, and when they have been delivered (if applicable).
2. Order modification: Customers should be allowed to make changes to their orders until they are
ready for preparation by the kitchen.
3. Customers should be able to choose goods from the menu and add them to their order, as well as
express any special instructions or alterations.
4. Support for numerous locations: If the food ordering system serves many locations, it should be
capable of handling orders from different locations and routing them to the appropriate location.
5. Support for mobile devices: The system should be accessible and tailored for mobile use.
6. Integration with other systems: The system should be able to integrate with other systems, such
as a POS or kitchen management system.
7. Customers should be able to examine their previous orders and reorder goods from previous
orders.
8. Menu display: The system should be able to display the menu items that are available, including
descriptions and prices.
9. Payment processing: Customers should be able to enter their payment information and process
the transaction using the system.

A.Y.D.T.I Page | 19
Name:SIMRAN.M.SINDHI Batch: CO5
En_no:226010307124 Sub:ISE

10. Administrative controls: The system should allow you to manage menu items, prices, and other
parameters.

 Non-Functional Requirements:
These are the quality constraints that the system must satisfy according to the project contract. The
priority or extent to which these factors are implemented varies from one project to another. They are
also called non-behavioral requirements. They deal with issues like:

1. Security: The system should prevent unauthorised access or misuse of sensitive information,
such as consumer payment and personal information.
This could include regulations for the use of encryption, secure servers, and other data integrity
safeguards.
2. Scalability refers to the system’s ability to accommodate increases in the number of users or
orders without deteriorating performance.
This could include the capacity to add more servers or other hardware as needed to accommodate
rising demand.
3. Reliability: The system should be available and working when required, with as little downtime
as possible.
This could include requirements for the system’s ability to handle failures or unforeseen events,
as well as the utilisation of backup systems and processes to assure service continuity.
4. Maintainability: With a clear and well-documented codebase and a solid testing and deployment
procedure, the system should be simple to upgrade and maintain over time.
This could include requirements for using version control, automated testing, and other tools and
processes to keep the system reliable and up to date.
5. Usability: The system should be simple to use for both customers and restaurant employees, with
a clear and intuitive interface and simple navigation.
This could include criteria for the system’s layout and design, the use of clear and simple
language, and the provision of assistance and support.
6. Performance: The system should be able to process a high volume of orders efficiently.
This could include system speed, the quantity of orders it can process at once, and the ability to
handle peak periods of activity.

A.Y.D.T.I Page | 20
Name:SIMRAN.M.SINDHI Batch: CO5
En_no:226010307124 Sub:ISE

PRACTICAL 5:
Aim: Prepare broad SRS (Software Requirement Software) for the Online
food ordering system.
1. INTRODUCTION:
1.1 PURPOSE:
The purpose of an online ordering system is to make itself beneficial for the customer and the business so
that they can stay afloat while also serving customers their favorite dishes. With Food Aggregators
increasing their commission every quarter, it is unsustainable for the restaurant to manage their restaurant
while depending on food delivery orders from swiggy and zomato. The online ordering market is
expanding and, especially the online food ordering segment is growing at a very rapid pace. Food
Delivery is the preferred way for customers to enjoy food these days. This change has been roughly owed
to the pandemic where customers prefer to order food online instead of dining out.

1.2 SCOPE:
Food Ordering app can sale Food product, preferred brands, kitchen needs, essential restaurant supplies
and more, through this online, onestop Food store. It provides you with a convenient way to sale from
your Food shopping app. You can use this app as one big super market app to sale product of your store.
This app make easy for user to buy product from store with easy steps and store can get easy order.

1.3 DEFINATION, ACRONYMS & ABBREVIATION:


OSS: Online Shopping System.

SRS: Software Requirement Specification.

GUI: Graphical User Interface- person who participate in the System.

OTP: One Time Password.

DBMS: Database Management System.

A.Y.D.T.I Page | 21
Name:SIMRAN.M.SINDHI Batch: CO5
En_no:226010307124 Sub:ISE

2. OVERALL VIEW:
2.1 PRODUCT PERSPECTIVE:
A product requirements specification establishes a bridge between product management and
development. It defines a product in terms of stakeholder requirements, containing all those requirements
that sensibly should be described explicitly and be available permanently.

2.2 PRODUCT FEATHERS:

3. Customer registration and login OR Scan QR code for login.


4. Choose Restaurants.
5. Viewing Restaurants Menu
6. Viewing Offers.
7. Food Category.
8. Discount on Cards.
9. Add to Cart Food.
10. Delete Food from Cart.
11. Apply Discount Coupons.
12. Order.
13. Generate Order Detail.
14. History of Order.
15. Customer directly Message or Call to Restaurants/Delivery person.
16. Tracking.
17. Payment.

2.3 USER CLASS AND CHARACTERISTICKS:


A user class is a set of developer-defined attributes and methods that you can use to refer the multiple
data items as single entity. You create user classes are classes that you create in the visual development
environment as part of an application.

2.4 CONSTRAINT, ASSUMPTION & DEPENDENCY:

A.Y.D.T.I Page | 22
Name:SIMRAN.M.SINDHI Batch: CO5
En_no:226010307124 Sub:ISE

Constraints: List any limitations or constraints on system design, such as hardware requirements,
software, and regulations. Assumptions and Dependencies: Mention any assumptions made during the
drafting of the SRS and any external factors the software relies on

Assumption: The assumptions section allows project stakeholders to document any underlying beliefs or
expectations that are not explicitly stated elsewhere in requirements document . These assumptions can
help set common expectations among stakeholders and provide context for decision-making throughout
the project.

Dependency: Dependencies are how the various components rely on each other to operate within the
business context. Identifying and documenting these dependencies, primarily related to the proposed new
system, is critical for SDLC Steps 1 and 2.

3.SYSTEM REQUIREMENTS:

3.1 FUNCTIONAL REQUIREMENTS:

1. Customers should be able to view the status of their orders, including when they were placed,
when they are expected to be ready, and when they have been delivered (if applicable).
2. Order modification: Customers should be allowed to make changes to their orders until they are
ready for preparation by the kitchen.
3. Customers should be able to choose goods from the menu and add them to their order, as well as
express any special instructions or alterations.
4. Support for numerous locations: If the food ordering system serves many locations, it should be
capable of handling orders from different locations and routing them to the appropriate location.
5. Support for mobile devices: The system should be accessible and tailored for mobile use.
6. Integration with other systems: The system should be able to integrate with other systems, such
as a POS or kitchen management system.
7. Customers should be able to examine their previous orders and reorder goods from previous
orders.
8. Menu display: The system should be able to display the menu items that are available, including
descriptions and prices.
9. Payment processing: Customers should be able to enter their payment information and process
the transaction using the system.
10. Administrative controls: The system should allow you to manage menu items, prices, and other
parameters.

A.Y.D.T.I Page | 23
Name:SIMRAN.M.SINDHI Batch: CO5
En_no:226010307124 Sub:ISE

3.2 NON-FUNCTIONAL REQUIREMENTS:

7. Security: The system should prevent unauthorised access or misuse of sensitive information,
such as consumer payment and personal information.
This could include regulations for the use of encryption, secure servers, and other data integrity
safeguards.
8. Scalability refers to the system’s ability to accommodate increases in the number of users or
orders without deteriorating performance.
This could include the capacity to add more servers or other hardware as needed to accommodate
rising demand.
9. Reliability: The system should be available and working when required, with as little downtime
as possible.
This could include requirements for the system’s ability to handle failures or unforeseen events,
as well as the utilisation of backup systems and processes to assure service continuity.
10. Maintainability: With a clear and well-documented codebase and a solid testing and deployment
procedure, the system should be simple to upgrade and maintain over time.
This could include requirements for using version control, automated testing, and other tools and
processes to keep the system reliable and up to date.
11. Usability: The system should be simple to use for both customers and restaurant employees, with
a clear and intuitive interface and simple navigation.
This could include criteria for the system’s layout and design, the use of clear and simple
language, and the provision of assistance and support.
12. Performance: The system should be able to process a high volume of orders efficiently.
This could include system speed, the quantity of orders it can process at once, and the ability to
handle peak periods of activity.

A.Y.D.T.I Page | 24
Name:SIMRAN.M.SINDHI Batch: CO5
En_no:226010307124 Sub:ISE

PRACTICAL: 6
AIM: Develop data designs using DFDs (data flow diagram) and E-R (entity
relationship) diagram.
Food Ordering System is actually a type of software that allows the manager of restaurants to manage
and accept the placed orders over the Internet or in the restaurant. Let us understand the working of
the food ordering system by using DFD (Data Flow Diagram). DFD for Food Ordering System is
shown below.
Here, different levels of DFD are shown for Food Ordering System such as Level 0 DFD, Level 1
DFD

. LEVEL 0:

ORDER FOR FOOD 0.0 ACESSEPT

CUSTOMER FOOD RESTAURANT

ORDER RECIVED
ORDERING ORDER DELEVER
SYSTEM

LEVEL 1:-

First level dfd (1stlevel ) of online food ordering system shows how the system shows how te system

divided into sub_system(process ). Each of which deals with one or more of the data flows to or from

external agent.and which together provided all the funtonaliltyof the online food orderingsystem as

whole. Its also identify internal data stores of item. Category delivery,payment,customerthat must be

present in order for te online food ordering system to do its job and shows the flow of data between the

various parts ofcustomer,category,item delivery of the system dfd level 1 provides a more details

breakout of pieces of ist level of DFD .you will highlightthe main functionalities of online food

ordering

A.Y.D.T.I Page | 25
Name:SIMRAN.M.SINDHI Batch: CO5
En_no:226010307124 Sub:ISE

ER DIAGRAM FOR ONLINE FOOD ORDERING SYSTEM


Designing an ER (Entity-Relationship) diagram for an online food ordering and delivery systemis
crucial for ensuring efficient operations, effective resource management, and seamless customer
experiences.

By carefully identifying entities, defining their attributes, and establishing relationships between
them, we can create a robust database model tailored to the specific needs of this industry. Let’s delve
into the process of designing an ER diagram for an online food ordering and delivery system.

Entity Symbol:-

A.Y.D.T.I Page | 26
Name:SIMRAN.M.SINDHI Batch: CO5
En_no:226010307124 Sub:ISE

Strong entity

These shapes are independent from other entities, and are often called parent entities, since they will
often have weak entities that depend on them. They will also have a primary key, distinguishing
each occurrence of the entity.

Weak entity

Weak entities depend on some other entity type. They don't have primary keys, and have no
meaning in the diagram without their parent entity.

Associative entityAssociative entities relate the instances of several entity types. They also contain
attributes specific to the relationship between those entity instances.

Entities and Attributes of the Online Food Ordering and Delivery

Entities serve as the building blocks of our database, representing the fundamental objects or
concepts that need to be stored and managed. Attributes define the characteristics or properties of
each entity. Let’s explore each entity and attribute in detail

A.Y.D.T.I Page | 27
Name:SIMRAN.M.SINDHI Batch: CO5
En_no:226010307124 Sub:ISE

Customer: The individual or organization placing orders.


 CustomerID (Primary Key): Unique identifier for each customer.
 First_Name: Name of the customer.
 Last_Name: Name of the customer
• City:-whaere the customer is living.
 House_number: Physical house_no associated with the customer.
 ContactNumber: Contact number of the customer.

Order: Placed by customers for food delivery.


 OrderID (Primary Key): Unique identifier for each order.
 OrderDate: Date and time when the order was placed.
 Total_Price: Total amount of the order.
 Delivery_date:-which date order should deliver.
 DeliveryAddress: Address where the order should be delivered.

Menu Item in for order: Individual food items available for ordering.
 Description: Description of the menu item.
 Pizza &non pizza.

A.Y.D.T.I Page | 28
Name:SIMRAN.M.SINDHI Batch: CO5
En_no:226010307124 Sub:ISE

Pizza:-.

 Pizza_ID (Primary Key): Unique identifier for each restaurant.


 Amount:-total amount of the order.
 Quantity:-how much quantity of food you required.
 Name:-pizza name which you want to eat.

Non_Pizza:-.
 Non_pizza ID (Primary Key): Unique identifier for each restaurant.
 Amount:-total amount of the order.
 Quantity:-how much quantity of food you required.
 Name:-pizza name which you want to eat.

payment: offering food for delivery.


 paymentID (Primary Key): Unique identifier for each restaurant.
 Customer_Name: Name of the customer.
 Payment_mode:-by mobile no,QR_codeor,banktransferer,etc..

EMPLOYEE: Individuals responsible for delivering orders.

 EMPLOYEE_ID (Primary Key): Unique identifier for each delivery personnel.


 User_name:-name of the user.
 Password: the password of the employee

Vehicle: Mode of transportation used for deliveries.


 VehicleID (Primary Key): Unique identifier for each vehicle.
 Type: Type of vehicle used for delivery (e.g., bike, car).
 RegistrationNumber: Registration number of the vehicle.
 AvailabilityStatus: Availability status of the vehicle.

A.Y.D.T.I Page | 29
Name:SIMRAN.M.SINDHI Batch: CO5
En_no:226010307124 Sub:ISE

PRACTICAL :- 7

AIM:-PREPARE USE-CASES AND DRAW USE CASE DIAGRAM.

Creating a use case diagram for an Online Food Ordering System has several benefits. Firstly, it
helps to ensure that the system is designed to meet the specific needs of the users. By breaking
down the system into smaller use cases, it becomes easier to identify the various features and
functionalities that the system should offer, making it more user-friendly and intuitive. This, in
turn, can lead to increased user adoption and engagement with the system, ultimately resulting in
more successful food orders.

use case diagrams are ideal for:

Representing the goals of system-user interactions

Defining and organizing functional requirements in a system

Specifying the context and requirements of a system

Modeling the basic flow of events in a use case

Secondly, the use case diagram helps to identify any potential issues or challenges that may arise
during the development of the Online Food Ordering System. By identifying the different use
cases and their potential dependencies, it becomes easier to identify any potential conflicts or issues
that may arise during the development process. This helps to ensure that the system is designed to
be scalable, flexible, and adaptable to changing user needs, ultimately resulting in a more robust and
reliable food ordering system.

A.Y.D.T.I Page | 30
Name:SIMRAN.M.SINDHI Batch: CO5
En_no:226010307124 Sub:ISE

PRACTICAL:- 8
Aim:DEVELOP A CLASS DIAGRAM FOR SELECTED PROJECT.
In these diagrams, classes are depicted as boxes, each containing three compartments for the class
name, attributes, and methods. Lines connecting classes illustrate associations, showing
relationships such as one-to-one or one-to-many.
Relationships between classes

In class diagrams, relationships between classes describe how classes are connected or interact with
each other within a system. There are several types of relationships in object-oriented modeling,
each serving a specific purpose. Here are some common types of relationships in class diagrams

A.Y.D.T.I Page | 31
Name:SIMRAN.M.SINDHI Batch: CO5
En_no:226010307124 Sub:ISE

USE CASES OF CLASS DIAGRAMS

System Design:

During the system design phase, class diagrams are used to model the static structure of a software
system. They help in visualizing and organizing classes, their attributes, methods, and relationships,
providing a blueprint for system implementation.

Communication and Collaboration:

Class diagrams serve as a visual communication tool between stakeholders, including developers,
designers, project managers, and clients. They facilitate discussions about the system’s structure
and design, promoting a shared understanding among team members.

Code Generation:

Some software development environments and tools support code generation based on class
diagrams. Developers can generate code skeletons, reducing manual coding efforts and ensuring
consistency between the design and implementation.

Testing and Test Planning:

Testers use class diagrams to understand the relationships between classes and plan test cases
accordingly. The visual representation of class structures helps in identifying areas that require
thorough testing.

Reverse Engineering:
Class diagrams can be used for reverse engineering, where developers analyze existing code to
create visual representations of the software structure. This is especially helpful when
documentation is scarce or outdated

A.Y.D.T.I Page | 32
Name:SIMRAN.M.SINDHI Batch: CO5
En_no:226010307124 Sub:ISE

A.Y.D.T.I Page | 33
Name:SIMRAN.M.SINDHI Batch: CO5
En_no:226010307124 Sub:ISE

PRACTICAL:- 9

Aim:-DEVELOP SEQUENCE DIAGRAM FOR SELECTED PROJECT.

This sequence diagram outlines the process flow of an online food ordering system. It begins with
the customer selecting a restaurant, triggering the Online Food Ordering System to fetch the menu
from the Restaurant Database. Once retrieved, the system displays the menu to the customer. The
customer then places an order, which is sent to the restaurant. After confirmation, the customer
makes a payment, verified by the Payment Gateway. Upon successful verification, the system
confirms the payment, and the customer receives a payment confirmation. Finally, the customer
receives the order through a delivery person

 How to Design an Online Food Ordering System Sequence Diagram?

Now, to create the Sequence Diagram for Online Food Ordering System, you must be familiar first
with its symbols. This is to know how would you emphasize the whole content of your Food
Ordering System.

With the symbol familiarization, you’ll then easily understand the ways on how would you develop
the system.

Here, I will be showing you the Online Food Ordering System Sequence Diagram. This design will
enlighten you on how should the system or the actor approach each other.

This will also teach you on how would you develop the system to achieve its desired behavior. In
addition to that, the design shows the detailed illustration of events sequenced and happens in Food
Ordering System.

This designed sequence diagram is able to show programmers and readers about the sequence of
messages between the actor and the objects

A.Y.D.T.I Page | 34
Name:SIMRAN.M.SINDHI Batch: CO5
En_no:226010307124 Sub:ISE

As you can see through the illustration, the conditions and interactions are emphasized. These
interactions are essential for the Online Food Ordering System development.

The series of messages are shown and labeled to guide you in building the System. You can modify
the design if you have more ideas. You can also add more features to this design and use it as your
project blueprint.

You’ll be able to understand and educate yourself on how the Food Ordering System works by
creating a sequence diagram. Because it determines the needed objects, actors and messages and
their interactions.

Conclusion :-

The Food Ordering System is a sort of interaction sequence diagram that shows how a group of
items interacts and in what order. Software engineers and business experts use these diagrams to
understand the requirements of the system or to describe an existing process.

The Food Ordering System must have a designed diagram to define the event sequences that will
A.Y.D.T.I Page | 35
Name:SIMRAN.M.SINDHI Batch: CO5
En_no:226010307124 Sub:ISE

result in a desired outcome. The flow of communication that appears is more important than the

PRACTICAL:- 10

AIM:-DEVELOP THE ACTIVITY DIAGRAM TO REPRESENT FLOW


FROM ONE ACTIVITY TO ANOTHER FOR SOFTWARE
DEVELOPMENT.

Activity Diagrams are used to illustrate the flow of control in a system and refer to the steps
involved in the execution of a use case. It is a type of behavioral diagram and we can depict both
sequential processing and concurrent processing of activities using an activity diagram ie an activity
diagram focuses on the condition of flow and the sequence in which it happens.

1. What is an Activity Diagram?


Activity Diagrams are used to illustrate the flow of control in a system and refer to the steps
involved in the execution of a use case. We can depict both sequential processing and
concurrent processing of activities using an activity diagram ie an activity diagram focuses on
the condition of flow and the sequence in which it happens.

We describe what causes a particular event using an activity diagram.


An activity diagram portrays the control flow from a start point to a finish point showing the
various decision paths that exist while the activity is being executed.
They are used in business and process modeling where their primary use is to depict the
dynamic aspects of a system.

A.Y.D.T.I Page | 36
Name:SIMRAN.M.SINDHI Batch: CO5
En_no:226010307124 Sub:ISE

2. Activity Diagram Notations

2.1. Initial State


The starting state before an activity takes place is depicted using the initial state.

A process can have only one initial state unless we are depicting nested activities. We use a black
filled circle to depict the initial state of a system.

1.1. Action or Activity State


An activity represents execution of an action on objects or by objects. We represent an activity
using a rectangle with rounded corners. Basically any action or event that takes place is
represented using an activity.

A.Y.D.T.I Page | 37
Name:SIMRAN.M.SINDHI Batch: CO5
En_no:226010307124 Sub:ISE

1.2. Action Flow or Control flows


Action flows or Control flows are also referred to as paths and edges. They are used to show the
transition from one activity state to another activity state.

An activity state can have multiple incoming and outgoing action flows. We use a line with an
arrow head to depict a Control Flow.

1.3. Decision node and Branching


When we need to make a decision before deciding the flow of control, we use the decision node.
The outgoing arrows from the decision node can be labelled with conditions or guard expressions.
It always includes two or more output arrows.

2.8. Merge or Merge Event


Scenarios arise when activities which are not being executed concurrently have to be merged. We
use the merge notation for such scenarios. We can merge two or more activities into one if the
control proceeds onto the next activity irrespective of the path chosen.

A.Y.D.T.I Page | 38
Name:SIMRAN.M.SINDHI Batch: CO5
En_no:226010307124 Sub:ISE

2.11. Final State or End State


The state which the system reaches when a particular process or activity ends is known as a Final
State or End State. We use a filled circle within a circle notation to represent the final state in a
state machine diagram. A system or a process can have multiple final states.

A.Y.D.T.I Page | 39
Name:SIMRAN.M.SINDHI Batch: CO5
En_no:226010307124 Sub:ISE

What are Activity Diagrams used for?

Activity diagrams are used in software development and system design to model and visualize the
dynamic aspects of a system. Here are some common uses of activity diagrams:

Dynamic modelling of the system or a process.


Illustrate the various steps involved in a UML use case.
Model software elements like methods,operations and functions.
We can use Activity diagrams to depict concurrent activities easily.
Show the constraints, conditions and logic behind algorithms.
During the requirements analysis phase, activity diagrams assist in capturing and documenting the
dynamic aspects of user interactions.

What is a Flow Chart?

An algorithm is like a set of clear instructions to solve a problem, and a flowchart is a picture that
shows those instructions.

When we’re writing computer programs, a flowchart helps us map out the steps of the algorithm to
solve the problem.
Non programmers use Flow charts to model workflows.
We can call a flowchart a primitive version of an activity diagram.
Business processes where decision making is involved is expressed using a flow chart.

Conclusion
In conclusion, Activity Diagrams serve as invaluable tools in system design and analysis, offering avisual
representation of dynamic processes within organizations. They are widely utilized to model business processes,
illustrate user interactions, and guide software system design. By providing a clear and concise overview of
activities, decision points, and interactions, activity diagrams enhancecommunication among project stakeholders
and contribute to effective do

A.Y.D.T.I Page | 40
Name:SIMRAN.M.SINDHI Batch: CO5
En_no:226010307124 Sub:ISE

PRACTICAL:- 11
Aim:- EVALUATE SIZE OF THE PROJECT USING FUNCTION POINT METRIC FOR
THE ASSIGNED PROJECT.

The FP metric can be used effectively asa means for measuring the functionality delivered by a
system. Using historical data the FP metric can be used to
1. estimate cost or effort required to design, code and test software.
2. Predict the number of errors that will be encountered during testing.
3. forecast the number of components and/ aur the number of protected source
lines inimplemented system.

FP's are derived using an empirical relationship based on countable measures of software
information domain quantitative assessments of software complexity.
The Matric examine the requirements model with the intent of predicting size of resultant system.
Size is sometimes an indicator of design complexity and is almost always an indicator of increased
coding, integration and testing effort.

To illustrate the use of FP metric in this context, we consider a simple analysis model
representation, illustrated in figure.
Referring to the figure a DFD for a function within the Safe home software is represented.

A.Y.D.T.I Page | 41
Name:SIMRAN.M.SINDHI Batch: CO5
En_no:226010307124 Sub:ISE

The function manages user interaction accepting a user password to activate or deactivate the system
and allows inquiries on the status of security zones and various security sensors. the function displays
System Configuration Data USER Sensors User Monitoring And Response Sub-
System Safe Home User Interaction Function

a series of prompting messages and sends appropriate control signals to various components of
security system. The DFD is evaluated to determine a Set of key information domain measures
required for computation of FP metric.
three external inputs password, panic button and activate/ deactivate are shown in the figure along
with two external enquiries.-zone enquiry and sensor enquiry.

1 ILF( system configuration file) is shown. Two external outputs( messages and sensor status) and 4
ELF's( test sensor, zone setting, activate/ deactivate and alarm alert) are also present. This data,
along with appropriate complexity are shown in the figure below.

The count total shown in figure must be adjusted using equation


FP= count total X (0.65+ 0.01X £(Fi))
for the Purpose of this example we assume that £(fi) is 46<[ a moderately complex product]
Thus FP= 50 x [0.65 + a(0.01 X 46)]=56

A.Y.D.T.I Page | 42
Name:SIMRAN.M.SINDHI Batch: CO5
En_no:226010307124 Sub:ISE

Procedure:
Function point analysis –
The number and type of functions supported by the software are utilised to find FPC ( function
point count).
The steps in FP analysis are:
1. Count the number of functions of each proposed type
2. Compute the unadjusted function point
3. Find total degree of influence(TDI)
4. Compute value adjustment factor (VAF)
5. Find the function point count(FPC)

The explanation of above points are given below:


1. Count the number of functions of each proposed type –
2. find the number of functions belonging to the following types: External INPUTS-
information entering the system
External output -- information leaving the system
External enquiries -- request for instant access to system
Internal logical files -- information held within the system
External interface files-- information held by other system that is used by the system being
analysed.

Computer the an adjusted function points (UFP) :


Categorize each of the 5 function types as simple, average or complex based on their complexity.
Multiply count of each function type with its weighing factor and find weighted sum.
The weighing factors for each type based on their complexity are as follows:

A.Y.D.T.I Page | 43
Name:SIMRAN.M.SINDHI Batch: CO5
En_no:226010307124 Sub:ISE

Find total Degree of Influence --


Use the 14 general characteristics of a system to find total degree of influenceTDI of each of them.
The sum of all 14 degrees of influences will give the TDI.
The range of TDI is 0 to 70 The 14 general characteristics are:
1. Data communication
2. Distributed data processing
3. Performance
4. Heavily used configuration
5. Transaction rate
6.online data entry End user efficiency
8. Online update
9. Complex processing
10. Reusability
11 installation ease
12 operational ease
13 multiple site
14 facilitate change

4) compute value adjustment


factorVAF VAF = (TDI * 0.01) +
0.65
5) find the function point
count(FPC) FPC = UFP * VA

Conclusion:
Thus we have studied function point metric used in Software cost estimation

A.Y.D.T.I Page | 44
Name:SIMRAN.M.SINDHI Batch: CO5
En_no:226010307124 Sub:ISE

PRACTICAL:- 12

AIM:- ESTIMATE COST OF THE PROJECT USING COCOMO (CONSTRUCTIVE COST


MODEL) / COCOMO II APPROACH FOR THE ASSIGNED PROJECT.

What is the COCOMO Model?


The COCOMO Model is a procedural cost estimate model for software projects and is often used
as a process of reliably predicting the various parameters associated with making a project such as
size, effort, cost, time, and quality. It was proposed by Barry Boehm in 1981 and is based on the
study of 63 projects, which makes it one of the best-documented models.

The key parameters that define the quality of any software product, which are also an outcome of
COCOMO, are primarily effort and schedule:

1. Effort: Amount of labor that will be required to complete a task. It is measured


inperson-months units.
2. Schedule: This simply means the amount of time required for the completion of the
job, which is, of course, proportional to the effort put in. It is measured in the units
oftime such as weeks, and months.
Types of Projects in the COCOMO Model:

In the COCOMO model, software projects are categorized into three types based on their
complexity, size, and the development environment. These types are:
1. Organic: A software project is said to be an organic type if the team size required is
adequately small, the problem is well understood and has been solved in the past and
also the team members have a nominal experience regarding the problem.

2. Semi-detached: A software project is said to be a Semi-detached type if the vital


characteristics such as team size, experience, and knowledge of the various
programming environments lie in between organic and embedded. The projects
classified as Semi-Detached are comparatively less familiar and difficult to develop
compared to the organic ones and require more experience better guidance and
creativity. Eg: Compilers or different Embedded Systems can be considered Semi-
Detached types.

3. Embedded: A software project requiring the highest level of complexity, creativity,


and experience requirement falls under this category. Such software requires a
largerteam size than the other two models and also the developers need to be
sufficiently experienced and creative to develop such complex models.
A.Y.D.T.I Page | 45
Name:SIMRAN.M.SINDHI Batch: CO5
En_no:226010307124 Sub:ISE

Comparison of these three types of Projects in COCOMO Model

Aspects Organic Semidetached Embedded

2 to 50 300 and above


50-300 KLOC
Project Size KLOC KLOC

Complexity Low Medium High

Some
Mixed
experienced as
Highly experience,
well as
experienced includes
Team inexperienced
experts
Experience staff

Aspects Organic Semidetached Embedded

Somewhat
Flexible, Highly
flexible,
fewer rigorous, strict
moderate
constraints requirements
Environment constraints

Effort E= E= E=
Equation 2.4(400)1.05 3.0(400)1.12 3.6(400)1.20

New system
Simple
interfacing Flight control
payroll
with existing software
system
Example systems

A.Y.D.T.I Page | 46
Name:SIMRAN.M.SINDHI Batch: CO5
En_no:226010307124 Sub:ISE

Detailed Structure of COCOMO Model

Detailed COCOMO incorporates all characteristics of the intermediate version with an assessment
of the cost driver’s impact on each step of the software engineering process. The detailed model
uses different effort multipliers for each cost driver attribute. In detailed COCOMO, the whole
software is divided into different modules and then we apply COCOMO in different modules to
estimate effort and then sum the effort.

The Six phases of detailed COCOMO are:

1. Planning and requirements

2. System design
3. Detailed design

4. Module code and test


5. Integration and test

6. Cost Constructive model

Phases of COCOMO Model

A.Y.D.T.I Page | 47
Name:SIMRAN.M.SINDHI Batch: CO5
En_no:226010307124 Sub:ISE

Different models of COCOMO have been proposed to predict the cost estimation at different
levels, based on the amount of accuracy and correctness required. All of these models can be
applied to a variety of projects, whose characteristics determine the value of the constant to be
used in subsequent calculations. These characteristics of different system types are mentioned
below. Boehm’s definition of organic, semidetached, and embedded systems:
Importance of the COCOMO Model
1. Cost Estimation: To help with resource planning and project budgeting, COCOMO
offers a methodical approach to software development cost estimation.
2. Resource Management: By taking team experience, project size, and complexity into
account, the model helps with efficient resource allocation.
3. Project Planning: COCOMO assists in developing practical project plans that include
attainable objectives, due dates, and benchmarks.
4. Risk management: Early in the development process, COCOMO assists in identifying
and mitigating potential hazards by including risk elements.
5. Support for Decisions: During project planning, the model provides a quantitative
foundation for choices about scope, priorities, and resource allocation.
6. Benchmarking: To compare and assess various software development projects
toindustry standards, COCOMO offers a benchmark.
7. Resource Optimization: The model helps to maximize the use of resources, which
raises productivity and lowers costs.
8.
Types of COCOMO Model
There are three types of COCOMO Model:
 Basic COCOMO Model
 Intermediate COCOMO Model
 Detailed COCOMO Model

A.Y.D.T.I Page | 48
Name:SIMRAN.M.SINDHI Batch: CO5
En_no:226010307124 Sub:ISE

1. Basic COCOMO Model


The Basic COCOMO model is a straightforward way to estimate the effort needed for a software
development project. It uses a simple mathematical formula to predict how many person-months
of work are required based on the size of the project, measured in thousands of lines of code
(KLOC).
It estimates effort and time required for development using the following expression:
E = a*(KLOC)b PM

Tdev = c*(E)d

Person required = Effort/ Time


Where,

E is effort applied in Person-Months

KLOC is the estimated size of the software product indicate in Kilo Lines of CodeTdev
is the development time in months

a, b, c are constants determined by the category of software project given in below table.

The above formula is used for the cost estimation of the basic COCOMO model and also is used
in the subsequent models. The constant values a, b, c, and d for the Basic Model for the different
categories of the software projects are:
Software Projects a b c d

Organic 2.4 1.05 2.5 0.38

Semi-Detached 3.0 1.12 2.5 0.35

Embedded 3.6 1.20 2.5 0.32

1. The effort is measured in Person-Months and as evident from the formula is


dependenton Kilo-Lines of code. The development time is measured in months.

2. These formulas are used as such in the Basic Model calculations, as not much
consideration of different factors such as reliability, and expertise is taken
intoaccount, henceforth the estimate is rough.

A.Y.D.T.I Page | 49
Name:SIMRAN.M.SINDHI Batch: CO5
En_no:226010307124 Sub:ISE

Example of Basic COCOMO Model

Suppose that a Basic project was estimated to be 400 KLOC (kilo lines of code). Calculate effort
and time for each of the three modes of development. All the constants value provided in the following
table:
Solution
From the above table we take the value of constant a,b,c and d.
1. For organic mode,
 effort = 2.4 × (400)1.05 ≈ 1295 person-month.
 dev. time = 2.5 × (1295)0.38 ≈ 38 months.
2. For semi-detach mode,
 effort = 3 × (400)1.12 ≈ 2462 person-month.
 dev. time = 2.5 × (2462)0.35 ≈ 38 months.
3. For Embedded mode,
 effort = 3.6 × (400)1.20 ≈ 4772 person-month.
 dev. time = 2.5 × (4772)0.32 ≈ 38 months.

2. Intermediate COCOMO Model


The basic COCOMO model assumes that the effort is only a function of the number of lines of
code and some constants evaluated according to the different software systems. However, in
reality, no system’s effort and schedule can be solely calculated based on Lines of Code. For that,
various other factors such as reliability, experience, and Capability. These factors are known
as Cost Drivers (multipliers) and the Intermediate Model utilizes 15 such drivers for cost
estimation.

Classification of Cost Drivers and their Attributes:


The cost drivers are divided into four categories
Product attributes:
 Required software reliability extent
 Size of the application database
 The complexity of the product
Hardware attributes
 Run-time performance constraints
 Memory constraints
 The volatility of the virtual machine environment
 Required turnabout time
Personal attributes
 Analyst capability
 Software engineering capability
A.Y.D.T.I Page | 50
Name:SIMRAN.M.SINDHI Batch: CO5
En_no:226010307124 Sub:ISE

 Application experience
 Virtual machine experience
 Programming language experience
Project attributes
 Use of software tools
 Application of software engineering methods
 Required development schedule
Each of the 15 such attributes can be rated on a six-point scale ranging from “very low” to “extra
high” in their relative order of importance. Each attribute has an effort multiplier fixed as per the
rating. Table give below represents Cost Drivers and their respective rating:
The Effort Adjustment Factor (EAF) is determined by multiplying the effort multipliers
associated with each of the 15 attributes.

The Effort Adjustment Factor (EAF) is employed to enhance the estimates generated by the basic
COCOMO model in the following expression:

Intermediate COCOMO Model equation:


E = a*(KLOC)b * EAF PM

Tdev = c*(E)dWhere,

 E is effort applied in Person-Months


 KLOC is the estimated size of the software product indicate in Kilo Lines of Code
 EAF is the Effort Adjustment Factor (EAF) is a multiplier used to refine the effort
estimate obtained from the basic COCOMO model.
 Tdev is the development time in months
 a, b, c are constants determined by the category of software project given in
belowtable.
The constant values a, b, c, and d for the Basic Model for the different categories of the software
projects are:
Software Projects a b c d

Organic 3.2 1.05 2.5 0.38

Semi-Detached 3.0 1.12 2.5 0.35

Embedded 2.8 1.20 2.5 0.32

3. Detailed COCOMO Model


Detailed COCOMO goes beyond Basic and Intermediate COCOMO by diving deeper into
A.Y.D.T.I Page | 51
Name:SIMRAN.M.SINDHI Batch: CO5
En_no:226010307124 Sub:ISE

project-specific factors. It considers a wider range of parameters, like team experience,


development practices, and software complexity. By analyzing these factors in more detail,
Detailed COCOMO provides a highly accurate estimation of effort, time, and cost for software
projects. It’s like zooming in on a project’s unique characteristics to get a clearer picture of what
it will take to complete it successfully.
CASE Studies and Examples
1. NASA Space Shuttle Software Development: NASA estimated the time and money
needed to build the software for the Space Shuttle program using the COCOMO
model. NASA was able to make well-informed decisions on resource allocation and
project scheduling by taking into account variables including project size, complexity,
and team experience.
2. Big Business Software Development: The COCOMO model has been widely used by
big businesses to project the time and money needed to construct intricate business
software systems. These organizations were able to better plan and allocate
resources for their software projects by using COCOMO’s estimation methodology.
3. Commercial Software goods: The COCOMO methodology has proven advantageous
for software firms that create commercial goods as well. These businesses were able
todecide on pricing, time-to-market, and resource allocation by precisely calculating
the time and expense of building new software products or features.
4. Academic Research Initiatives: To estimate the time and expense required to
createsoftware prototypes or carry out experimental studies, academic research
initiatives

have employed COCOMO. Researchers were able to better plan their projects and
allocate resources by using COCOMO’s estimate approaches.

Advantages of the COCOMO Model:

1. Systematic cost estimation: Provides a systematic way to estimate the cost and
effortof a software project.
2. Helps to estimate cost and effort: This can be used to estimate the cost and effort of
asoftware project at different stages of the development process.
3. Helps in high-impact factors: Helps in identifying the factors that have the greatest
impact on the cost and effort of a software project.
4. Helps to evaluate the feasibility of a project: This can be used to evaluate the
feasibility of a software project by estimating the cost and effort required to
completeit.

Disadvantages of the COCOMO Model:

1. Assumes project size as the main factor: Assumes that the size of the software is the
main factor that determines the cost and effort of a software project, which may not
always be the case.
A.Y.D.T.I Page | 52
Name:SIMRAN.M.SINDHI Batch: CO5
En_no:226010307124 Sub:ISE

2. Does not count development team-specific characteristics: Does not take into
account the specific characteristics of the development team, which can have a
significant impact on the cost and effort of a software project.
3. Not enough precise cost and effort estimate: This does not provide a precise
estimate of the cost and effort of a software project, as it is based on assumptions
andaverages.

A.Y.D.T.I Page | 53
Name:SIMRAN.M.SINDHI Batch: CO5
En_no:226010307124 Sub:ISE

PRACTICAL:- 13

Aim:- Use flow chart and Gantt charts to track progress of


the assigned project. (Use Sprint burn down chart if agile
model is selected).

Flowcharts and Gantt charts are both effective tools to plan projects. However, when it comes to
project execution, both have different uses and applications. For a complex plan with a longer
duration, a Gantt chart is better, and for short term and smaller projects, a flow chart can do the trick
on its own. In some cases, Gantt charts and flowcharts are used in combination.

Gantt charts can be useful in Agile environments, especially when revising project plans. Gantt
charts can also benefit teams, clients, and stakeholders. A Scrum master shares how you can (and
can’t) use Gantt charts for Agile.

Included on this page, you will find a step-by-step overview on using Gantt charts in Agile and a
free downloadable Gantt chart template. Read a discussion of the Cynefin framework and how it
can help. Plus, find a recap of the 12 Agile principles, including which ones Gantt charts can
support.

What Is an Agile Gantt Chart?

In an Agile environment, you can use a Gantt chart to track the status of projects. Teams can view,
manage, interact with, and quickly revise project plans.

A Gantt chart in Agile might seem like blasphemy to some. Some Agile project managers —
especially those working in a blended environment (using aspects of both Waterfall and Agile
project management) — have found a place for Gantt charts. By using sprint planning and Gantt
charts in tandem, you can take advantage of the fluid, flexible, and adaptable nature of Agile
projects while adding details about deadlines, dependencies, and resource allocation that Gantt
charts contain.

If you’re unfamiliar with Agile project management, learn all about it in this intro to Agile project
management article.

A.Y.D.T.I Page | 54
Name:SIMRAN.M.SINDHI Batch: CO5
En_no:226010307124 Sub:ISE

Agile Process Versus Waterfall Process;-


Waterfall projects use sets of pre-planned phases, where later phases rely on completion of
preceding phases. Agile projects work in a series of iterative cycles. Managers select tasks for each
iteration using a combination of judgement, resources, and team input.

How Can Agile Teams Use Gantt Charts?


A Gantt chart can be useful as a part of adaptive planning to help teams manage sprints and their
assigned tasks. Teams can use the charts to improve collaboration and assess resource allocation.

Managing Tasks in Agile

A sprint consists of sets of dependent tasks. You can use a Gantt chart to map dependencies and
each task relates to others. During sprint planning, add the tasks assigned to the sprint to the Gantt
chart.
If a task is in danger of not being completed, you can remove it and all tasks that depend on it from
the sprint. Be sure to remove them during the daily planning portion of stand-up meetings.
Add the information that stakeholders want directly to the tasks on the Gantt chart.
Color-code each sprint to enable a real-time comparison of the time it took to complete each (and
their accompanying tasks).

A.Y.D.T.I Page | 55
Name:SIMRAN.M.SINDHI Batch: CO5
En_no:226010307124 Sub:ISE

How to Use Gantt Charts as a Collaboration Tool

Plan and organize work with team members.


Note the deliverables for each task.
Assign tasks to team members.
Attach files to tasks (e.g., bug tickets or issues), so the team has everything it needs in one spot.
Add comments and notes.
Use the Gantt chart as the basis for creating a dashboard or roll-up report that contains the status
and delivery date for each sprint.
Monitor and Review Resource Allocation with a Gantt Chart in Agile

Step by Step: How to Use a Gantt Chart for Agile Projects:-

A.Y.D.T.I Page | 56
Name:SIMRAN.M.SINDHI Batch: CO5
En_no:226010307124 Sub:ISE

Gantt charts can support these principles:

Principle 1: Customer satisfaction through early and continuous software delivery. Snyder shares,
“The idea [behind principle 1] is let's start thinking about slicing our work vertically so that we have
a small piece of working software instead of, oh, we got the design done for the whole system.”
You can use Gantt charts to track testing progress, feature development status, and other details
related to task completion.

Principle 2: Accommodate changing requirements throughout the development process. Use a Gantt
chart to track stakeholder change requests and the alterations they drive.

Principle 3: Frequent delivery of working software. Regarding the third principle, Snyder advises,
“Somebody might just want to say, ‘Is this feature done?’ Well, you could clearly show that on the
chart.” A Gantt chart can list the requested features that have been completed and those that have
been shifted to another sprint to keep the process moving.

Agile processes to support a consistent development pace. Gantt charts can track the rate of feature
completion, time applied, and sprint schedules to ensure the pace is sustainable for the team.

Agile Gantt Chart Examples

Here are some Gantt chart examples for an Agile sprint. The first is tracking feature status, and the
second is time put into a sprint.

Example: Feature Development in an Agile Chart


Gantt Chart in Agile Example Feature Development
Example: Time Tracking in an Agile Chart
Gantt Chart in Agile Examples Time Tracking
Benefits of Using Gantt Charts with Agile Methodology
Using Gantt charts in an Agile environment can provide several benefits to clients, stakeholders,
and teams. They can improve communications; share status, ownership, and progress; and provide a
visual representation of dependencies.

Overall Benefits of Using Gantt Charts with Agile:-

Though Agile and and Waterfall require different mindsets and focuses, Gantt charts can help Agile
teams track time, communicate status, and forecast resource needs for both.

A.Y.D.T.I Page | 57
Name:SIMRAN.M.SINDHI Batch: CO5
En_no:226010307124 Sub:ISE

PRACTICAL:- 14

AIM:- PREPARE VARIOUS TEST CASE FOR SELECTED PROJECT.

Test Cases For Online Food Ordering System Search Functionality

Positive Test Cases For Search Functionality

1. Verify that search box field UI is as per specification or not.


2. Verify that placeholder for the search box fields is as per specification or not.
3. Verify that when user clicks on the search field box then cursor should be displayed in the

searchbox field.
4. Verify that if user enters valid food name, then search result should be displayed.

5.Verify that if user enters valid restaurant name, then search result should be
displayed.
6. Verify that if user search by valid food name, then relevant food search result should be
displayedon the screen.
7. Verify that if user search by valid restaurant name, then relevant food search result should
bedisplayed on the screen.
8. Verify that user is able to click on the search result or not.
9Verify that user is able to search food by voice search functionality or not.
10.Verify that user is able to search restaurant by voice search functionality or not.

Negative Test Cases For Online Food Ordering System

1. Verify that if user enters only special characters, then “Oh Sorry! No search result has found”

likemessage should be displayed on the screen.


2. Verify that if user enters only numeric characters, then “Oh Sorry! No search result has

found”like message should be displayed on the screen.

A.Y.D.T.I Page | 58
Name:SIMRAN.M.SINDHI Batch: CO5
En_no:226010307124 Sub:ISE

3. Verify that if user enters only numeric and special characters, then “Oh Sorry! No search

resulthas found” like message should be displayed on the screen.

4. Verify that user is able to blank search or not.

Test Case #1- Home Screen


Below are some of the most important test scenarios for food delivery apps through manual and
mobile automation testing.

Validate that previous orders are displayed on the home screen for fast delivery.
Validate the accurate location for delivery shown on the screen.
Verify restaurants on the homepage with the right distance from the delivery location.
Validate the billing discounts which must appear on the home page.
Validate the filter to sort options that must show on the home page. Filters must include options like
cuisines, non-veg and veg, combos, rating, delivery time, etc.

Test Case #2- Search Functionality


These are the essential test cases to verify search functionality for online food ordering systems.

Verify that the restaurant's name can be searched in the text box.
Validate cuisine’s name is searchable in the search box.
A.Y.D.T.I Page | 59
Name:SIMRAN.M.SINDHI Batch: CO5
En_no:226010307124 Sub:ISE

Validate that the search result matches with the keywords entered in the search box.
Also read: 5 Advantages of Implementing Digital Assurance for Your Business

Test Case #3- For Ordering Page

Look at the following test cases for placing an order in a food delivery app.
Verify the cuisines offered by the restaurants are shown under restaurant names like Chinese, North
Indian, Continental, etc.
Check that the add option must add the selected item to the cart.
Check that red and green dots are marked against those items for non-veg and veg.
Check that offers on delivery, delivery mode, and approximate time must show clearly on the
screen.
Verify every food item is correctly listed along with the prices.
Verify that users can seamlessly customize their food items while placing an order.
Assess that the reviews can be filtered into different categories such as my reviews, detailed
reviews, delivery reviews, and latest reviews.
Determine that restaurant’s name with ratings, which are clearly displayed along with the photos.
Verify the rating of food items.

Test Case #4- Cart Page


The cart page is one of the essential places where users finalize their food selection before making
the payment. These are the essential cart page test cases for online food delivery systems.

It is essential to verify the delivery location on the cart page.


Verify that selected items are correctly displayed.
Verify that the delete option is available to remove products from the cart.
Ensure that the tipping option is available for customers.
Check that the delivery location can be changed seamlessly.
Determine that the users can increase and decrease the number of selected items.
Check the successful application of offers when applied by the users.
Check that the invoice is generated correctly.
Verify that the cart page can be minimized.

Test Case #5- Testing Home Screen Without Logging In


The home screen sets the first impression on users as it is the first thing users interact with them.
These are the following test cases to test the home screen of online food ordering apps.

Check the user location appears correctly on the home screen.


Check that the filter buttons are working correctly on the home screen.
Check that top brands' restaurant names are correctly displayed or not.
Check that users' nearby restaurants are displayed on the home screen without logging out.
Verify whether the user can see the profile page or not.
A.Y.D.T.I Page | 60
Name:SIMRAN.M.SINDHI Batch: CO5
En_no:226010307124 Sub:ISE

Check that the distance or kilometer range is displayed in the restaurant block.
Verify that users can order food delivery without logging into the application.

A.Y.D.T.I Page | 61
Name:SIMRAN.M.SINDHI Batch: CO5
En_no:226010307124 Sub:ISE

Test Case #6- Login and Registration


Login and registration components also play a significant role in personalized, secure, and seamless
user experience. Here are some test cases you must include.

Verify that users can log in to the food delivery application by entering a mobile number.
Check that users can select delivery locations after a successful registration.
Verify for failed user login.
Verify for registration using an already existing mobile number.
Test Case #7- Account Section
The accounts section serves as the center where users can seamlessly track their order history,
personal information, and other functionalities. These can be validated through proper API testing.
Here are some of the essential test scenarios for food delivery apps.

Verify that different account options are correctly shown to the users.
Check that the help button is shown.
Determine that the test case scenarios for food delivery apps should display favorite orders, address
book, and past orders, accessed seamlessly from the account section.
Check about, log out, and send feedback options are correctly visible on the screen.
Check the authentication happens correctly after sending OTP to the customer.
Verify that users can easily log in through different options including email and password,
Facebook, and Google sign-in.

Order Summary Page Test Cases


1. Verify that user is able to see order summary page after receiving food order or not.
2. Verify that user is able to see restaurant name on the order page or not.
3. Verify that ordered food items should be displayed on the order summary page.
4. Verify that quantity is displayed or not for the food items on order summary page.
5. Verify that price is displayed or not for the food items on the order summary page.
6. Verify that total price of the ordered food items is displayed or not.
7. Verify that any extra charges is displayed or not on order summary page.
8. Verify that total sum of the prices and additional charges are as expected or not.
9. Verify that if food category is vegetarian, then veg food icon should be displayed
forveg food items or not.
10. Verify that all buttons working as expected on order summary page or not.

Conclusion
So as above, we tried to cover maximum test cases for online food ordering system. If you are
looking for more test cases please visit below links.

1. Test Cases For Amount Field


2.Test Cases For Credit Card
3.Test Cases For Shopping Cart
A.Y.D.T.I Page | 62
Name:SIMRAN.M.SINDHI Batch: CO5
En_no:226010307124 Sub:ISE

4.Test Cases For Login Page


MICRO-PROJECT
PROJECT TITLE: ONLINE FOOD ORDERING SYSTEM SOFTWARE
Project Overview:
The Online Food Ordering System Software is designed to streamline and enhance the process of
ordering food from various restaurants and food vendors. This system offers a user-friendly
platform for customers to browse menus, place orders, and make payments online. The primary
objective is to provide a convenient and efficient way for users to order food from their favorite
eateries, ensuring a seamless and enjoyable experience.
Key Features:

1. User Registration and Authentication:


• Secure user registration and login functionality.
• Profile management for users to update their information and view order history.
2. Restaurant and Menu Browsing:
• Comprehensive listings of participating restaurants with detailed menus.
• Advanced search and filter options to find specific cuisines, dishes, or restaurants.
3. Order Placement:
• Easy-to-use interface for selecting and customizing food items.
• Real-time updates on item availability and estimated delivery times.
4. Payment Integration:
• Multiple payment options including credit/debit cards, digital wallets, and cash
ondelivery.
• Secure payment gateway for safe and hassle-free transactions.
5. Order Tracking:
• Real-time tracking of order status from preparation to delivery.
• Notifications via SMS, email, or in-app alerts.
6. Admin Panel:
• Robust admin dashboard for managing restaurants, menus, and orders.
• Analytics and reporting tools to monitor system performance and user activity.
A.Y.D.T.I Page | 63
Name:SIMRAN.M.SINDHI Batch: CO5
En_no:226010307124 Sub:ISE

7. Customer Support:
• Integrated support system for resolving customer queries and issues.
• Feedback and review system to gather user opinions and improve service quality.

Technologies Used:
• Frontend: HTML, CSS, JavaScript, React.js
• Backend: Node.js, Express.js
• Database: MongoDB
• Payment Gateway: Stripe/PayPal integration
• Deployment: AWS/GCP/Azure

A.Y.D.T.I Page | 64
Name: SIMRAN.M.SINDHI Batch: CO5
En_no:226010307124 Sub:ISE

AIM OF THE PROJECT:


The primary aim of the Online Food Ordering System Software project is to develop a
comprehensive, user-friendly platform that facilitates seamless and efficient food ordering and
delivery services. This system seeks to revolutionize the way customers interact with restaurants
by providing an integrated solution that covers the entire food ordering process—from browsing
menus to receiving the final order. The objectives include:

1. Enhancing User Convenience: To provide a convenient platform where users can easily
browse restaurant menus, customize their orders, and complete transactions online without any
hassle.

2. Streamlining Restaurant Operations: To create an efficient system for restaurants to


manage online orders, streamline kitchen operations, and improve order accuracy and delivery
times.

3. Ensuring Secure Transactions: To implement robust security measures that protect user
data and ensure secure online payments, building trust and confidence among users.

4. Facilitating Real-Time Communication: To enable real-time updates and tracking for users,
ensuring they are informed about their order status from preparation to delivery.

5. Promoting User Engagement: To incorporate features that enhance user engagement,


suchas personalized recommendations, feedback mechanisms, and loyalty programs.

6. Supporting Scalability and Flexibility: To design a scalable system that can accommodate
a growing number of users and restaurants, while also being flexible enough to adapt to future
technological advancements and market trends.

7. Providing Analytical Insights: To equip restaurant owners with valuable analytics and
reporting tools that offer insights into customer behavior, order patterns, and overall system
performance, aiding in strategic decision-making.

A.Y.D.T.I Page | 65
EF FGHHYYUYUGHKY
Name: SIMRAN.M.SINDHI Batch: CO5
En_no:226010307124 Sub:ISE

PROCESS MODEL:
The development of the Online Food Ordering System Software follows the Agile methodology,
which emphasizes iterative development, collaboration, and flexibility. This model allows for
continuous feedback and improvements, ensuring the final product meets user needs and
expectations. The process model is structured into several key phases:
1. Requirement Analysis:

Objective: To gather and analyze the requirements of the system from stakeholders, including
customers, restaurant owners, and administrators.

Activities:

• Conduct interviews and surveys with potential users and stakeholders.

• Define user stories and use cases.

• Create a detailed requirements specification document.

2. Planning:

Objective: To outline the project roadmap, define milestones, and allocate resources.
Activities:

• Develop a project timeline with sprints and deliverables.

• Assign roles and responsibilities to the development team.

• Establish communication protocols and collaboration tools.

3. Design:
Objective: To create the system architecture and design the user interface and user experience.
Activities:

• Design system architecture diagrams.

• Create wireframes and prototypes for the user interface.

• Define database schemas and API specifications.

• Review and validate design with stakeholders.

A.Y.D.T.I Page | 66
Name: SIMRAN.M.SINDHI Batch: CO5
En_no:226010307124 Sub:ISE

4. Implementation:

Objective: To develop the system based on the approved design and requirements.
Activities:

• Set up the development environment.

• Implement frontend and backend components.

• Integrate database and payment gateways.

• Perform unit testing to ensure functionality.

5. Testing:

Objective: To ensure the system is functional, reliable, and free of defects.

Activities:

• Conduct various testing phases, including unit testing, integration testing, system
testing,and user acceptance testing (UAT).

• Identify and fix bugs and issues.

• Validate the system against the requirements.

6. Deployment:
Objective: To release the system to the production environment for use by end-users.
Activities:

• Prepare deployment plans and rollback strategies.

• Configure production servers and environments.

• Deploy the system and perform post-deployment testing.

• Monitor system performance and address any issues.

A.Y.D.T.I Page | 67
Name: SIMRAN.M.SINDHI Batch: CO5
En_no:226010307124 Sub:ISE

7. Maintenance and Support:

Objective: To provide ongoing support and enhancements to the system.


Activities:

• Monitor system performance and user feedback.

• Release updates and patches to fix issues and improve functionality.

• Provide technical support to users and stakeholders.

• Plan for future enhancements based on user needs and technological advancements.

8. Review and Retrospective:

Objective: To evaluate the project’s success and identify areas for improvement.

Activities:

• Conduct project reviews and retrospectives with the development team.

• Gather feedback from stakeholders on the system’s performance and usability.

• Document lessons learned and best practices for future projects.

User Interface:

The user interface (UI) of the Online Food Ordering System Software is designed to be intuitive,
responsive, and user-friendly. The UI consists of the following components:

1. Homepage:

• Features a search bar for finding restaurants or specific dishes.

• Highlights popular restaurants and featured deals.

• Provides quick access to user login and registration.

2. User Registration/Login:
• Simple forms for new user registration and existing user login.
A.Y.D.T.I Page | 68
Name: SIMRAN.M.SINDHI Batch: CO5
En_no:226010307124 Sub:ISE

3. Restaurant Listing:

• Displays a list of restaurants with filters for cuisine type, price range, ratings, and delivery
time.

• Includes restaurant profiles with menus, reviews, and ratings.

4. Menu Browsing:

• Interactive menus with item descriptions, prices, and customization options.

• Add-to-cart functionality for easy order selection.

5. Cart and Checkout:

• View and edit cart items.

• Secure checkout process with multiple payment options.

• Delivery address and contact details entry.

6. Order Tracking:

• Real-time updates on order status (e.g., preparation, out for delivery, delivered).

• Estimated delivery time and tracking map.

7. User Profile:

• Manage personal information and delivery addresses.

• View order history and track ongoing orders.

• Option to save favorite restaurants and dishes.

A.Y.D.T.I Page | 69
Name:SIMRAN.M.SINDHI Batch: CO5
En_no:226010307124 Sub:ISE

8. Admin Panel:

• Dashboard for managing restaurants, orders, and users.

• Access to analytics and reports on system performance.

HARDWARE INTERFACE:

The hardware interface outlines the physical components required to run the Online Food Ordering
System Software:

1. Server Hardware:

• High-performance servers to host the web application and database.

• Redundant power supplies and network connections to ensure high availability.

2. Client Devices:

• Desktop computers, laptops, tablets, and smartphones with internet access.

• Support for modern web browsers (Chrome, Firefox, Safari, Edge) on both Windows and
macOS platforms.

3. Networking Equipment:

• Reliable internet connection with sufficient bandwidth to handle concurrent users.

• Network routers and switches for internal connectivity.

4. Payment Processing Devices:

Integration with payment gateways that support various devices (e.g., card readers, mobile
payment terminals).

Page | 70
Name: SIMRAN.M.SINDHI Batch: CO5
En_no:226010307124 Sub:ISE

SOFTWARE INTERFACE:

The software interface defines the interaction between different software components and external
systems:

1. Frontend Technologies:

• HTML, CSS, JavaScript: Core technologies for building the web application’s interface.

• React.js: A JavaScript library for building user interfaces, ensuring a dynamic and
responsive user experience.

2. Backend Technologies:

• Node.js and Express.js: Server-side technologies for handling client requests,


businesslogic, and API interactions.

• MongoDB: NoSQL database for storing user data, restaurant details, orders,
andtransaction records.

3. APIs:

• Restaurant APIs: Interfaces for restaurants to update menus, manage orders, and
trackdelivery status.

• Payment Gateway APIs (e.g., Stripe, PayPal): Secure interfaces for processing online
payments.

• Geolocation APIs: Services for providing real-time order tracking and estimated delivery
times.

4. Authentication:

• OAuth 2.0: Protocol for secure user authentication and authorization.

• JWT (JSON Web Tokens): Tokens for maintaining user sessions and ensuring secure data
transmission.

A.Y.D.T.I Page | 71
Name: SIMRAN.M.SINDHI Batch: CO5
En_no:226010307124 Sub:ISE

5. Third-Party Services:
Email/SMS Services (e.g., Twilio, SendGrid): For sending order confirmations and
SYSTEM ARCHITECTURE:
The system architecture of the Online Food Ordering System Software is designed to ensure
scalability, reliability, and efficiency. It follows a multi-tier architecture consisting of the following
layers:
UML DIAGRAM CLASS:

A.Y.D.T.I Page | 72
Name:SIMRAN.M.SINDHI
Batch:CO5
En_no:226010307124 Sub:ISE

ACTIVITY DIAGRAM:

A.Y.D.T.I Page | 73

You might also like