We already did most of the part in the project and I need help with coding for server and chef part. I have attached the ?part that is already completed.SoftwareEngineeringCou

Software Engineering Course Project Restaurant Automation

The Project

A major component of CS 521 is a team centered software engineering project. The objective is to develop a software product for a fictitious client who intends to use it in regular production to improve their business in terms of cost, time, and functionality.

You will work with your classmates in order to complete the project before the semester ends. During the semester, the project team will work together through the full development cycle, from an initial feasibility study to delivering a functioning product, and will make a series of presentations and reports of the work to the client. For the purposes of this class, I shall be your client who has contacted you in order to help me automate my privately owned restaurant business. This will allow me to modernize the day to day operations of my business in the hopes of lowering its operating cost and/or improving its overall efficiency by the end of this class.

Project Description Your goal for this project is to introduce automation into a privately-owned restaurant. Typical problems restaurant personnel are facing include:

• Coordination of their work activities

• Anticipating and handling periods of low/high patron traffic • Recognizing trends early enough to take advantage of bestsellers or abandon the

flops in menu options

• Lowering operating costs, and increasing efficiency/productivity and profits There are still many privately owned small to medium sized restaurants that operate using traditional pen and paper methods with little to no automation. Traditionally, patrons enter the restaurant are greeted at the front by a receptionist who uses a “dry erase” diagram of tables on top of a blackboard that details a map of the restaurant’s floor plan. The receptionist can see the current status of the tables according to whomever last physically updated the diagram. Once the patrons have been seated, a waiter is sent to collect their order and write it down onto a piece of carbon paper that is physically delivered to the kitchen for proper food preparation by the chef and the other kitchen staff. The waiter must periodically cycle back to the kitchen in order to find out when the meal has been prepared for a given table. Once the food is ready for a given table, the piece of carbon paper is saved for proper record keeping and analysis by the management. This traditional system works but generates a lot of tab receipts, wastes a lot of time, and is out of date with more modern methods that employ some form of automation or

computer technology. In traditional systems, waiters must carry notepads around to take orders from customers and ensure that each bill is correctly organized and assigned to the correct table.

Another issue is record maintenance. In the traditional system where all record-keeping is done by paper, the management is responsible for the hard work of keeping all information saved and organized properly. Every single day generates a mountain of receipts whose data must be correlated, collected, and organized so employees are paid properly and the everyday needs of the business are promptly met by the management. Obviously, this requires a great deal of ongoing daily time and attention from the managers.

Your overarching goal in this project is to computerize restaurant operations so that all information pertaining to a patron’s orders and employee activity will be conveniently shared and stored over the restaurant’s intranet. Receptionists will be able to view table status with a click of a button. The wait staff will be able to enter the patron’s orders quickly and efficiently and then have it electronically delivered to the kitchen. The kitchen staff will be able to view the incoming orders and notify the proper waiter staff when the food is ready. Bus boys will be able to view real-time floor status allowing them to know which tables are clean, dirty, or occupied. Most importantly, all of the restaurant information is organized and saved in the system database for the management viewing and archival. The analysis will consist of by-the-day and by-the- hour breakdowns of:

• Revenue and revenue percentage per menu item

• Menu item popularity

• Personnel efficiency

• Average turnaround time (how long patrons spend in the restaurant)

• Average preparation time (time from when the order is placed to when it is ready) At the conclusion of your project, there will no longer be any more mountains of paperwork or long hours of punching numbers in order to address the day to day running of the business. All

data will be automatically collected and processed allowing management to focus on analyzing the data rather than calculating it themselves.

Statement of Requirements By using a touch screen the restaurant staff can quickly and efficiently log in and complete the desired task. When a waiter logs in, they are greeted with a floor status screen in which their assigned tables are colored into the screen. Their tables are colored according to status; green is open, yellow is occupied, red is dirty (see Figure 2). At this point a waiter can select a table to view its tab. Once a table is selected, the staff can choose from a number of options. If they select to add an item to the table’s tab, they are presented with various categories of food items offered on the menu. Here they can select the appropriate category and then find the desired item. For example, if a patron ordered a Caesar salad, the waiter would login, select the table, and choose “Add Item.”

They would then select the “Soups/Salads” from the category list, and subsequently select the desired salad from the items presented in the onscreen menu. They then return to that table’s screen where they can choose to perform another task or logout. This saves the waiter from walking back and forth to the kitchen to deliver and check up on food orders. Orders placed by wait-staff using the computer terminals on the restaurant floor are displayed to the kitchen staff through a queue, i.e., on a first-in, first-out basis.

The supported employee roles are: Receptionist, Waiter, Cook, Busboy, and Manager. Some of the direct links between some of the staff include:

Receptionist ↔ Waiter, Waiter ↔ Cook, and Busboy ↔ Receptionist.

Every user account in the system should have its own privileges. All the role-personalized home screens for each employee will be refreshed automatically when needed (e.g. when a table is marked ready; a table’s order is prepared; a Receptionist assigns a waiter to a table; etc.). The Manager should have administrative power over employee profiles: the ability to create and

modify profiles, track employee activities, and authorize restricted waiter activities. If the employee is a waiter, his/her profile also contains information about the tables for which he/she is responsible. From this profile, the individual tabs for those tables can be accessed. The manager should also have the ability to manage other aspects of restaurant operations, such as inventory tracking and sale analysis.

There is an important choice of the type of computer terminals used by the waiters. All other personnel are either stationary, e.g., kitchen staff and Receptionists, or can access information at stationary terminals, e.g., busboys. If the waiters are required to use stationary terminals, they must memorize or write down a specific table’s order and then find an open computer, login and enter the information into the system. At this point everything else is done electronically. Another option is to have the waiters be provided handheld devices, which will be connected wirelessly to the rest of the system, completely eliminating the use of carbon paper.

There are certain advantages of stationary computer terminals over handheld devices: (i) a small number of fixed terminals can be time-shared by multiple personnel, so this solution may be cheaper and easier to maintain; (ii) they are fixed, so they cannot be lost or damaged in handling. Thus, you may assume fixed terminals for the entire staff at your discretion.

Having to login frequently is annoying, particularly for cooks working with food. If you decide to have open access, you may assume that these restaurants are physically secure, so electronic security is less of a concern. If you do make this assumption, then the only security login controls I would want you to add is that for the waiter. The waiter should login and for each bill mark down the amount of gratuity

The final interface issue is specifying the floor plan of the restaurant and the table arrangement. Ideally, this feature should be included within the system to allow managers to alter the floor plan by moving, adding, and removing tables. If the development team experiences lack of time in the course of the semester, an acceptable workaround should be sought. For example, a generic restaurant floor plan can be designed specifically for demo purposes. When a restaurant orders our software, we will build and develop a floor plan for that specific establishment, making the software package unique to that establishment.

In addition to staff coordination, the system tracks everything electronically then organizes it. Employee hours are kept, allowing for rapid processing of the payroll. Revenue is tracked by day, week, or month. All this information is collected, saved, and then entered into tabular format for easy reading by the management. The automatically generated statistics allow the management to see what portion of the revenue comes from what item, i.e., what are the most popular items. All this is done automatically and stays up to date with restaurant performance.

You may make this application using any tools that you and your group are comfortable with and can justify using in order to complete this project successfully in the semester long time-limit. Although the project description calls for a touch-screen terminal, for the purposes of this class, you may use any tool or library of graphics programming that you can justify will fulfill the needs of this project whether that comes with programming your project using Java (AWT, Swing, other Event-Driven Programming tool you are familiar with) or Python 3.XX (Tkinter,

PySimple, Wax, Qt, PySlide, Libavg, etc). The ones I most recommend are those are effectively cross-platform with most touch screen APIs or are easily available open-source (PySimple, Libavg) GUI toolkits/libraries and/or freely incorporated into the language itself (AWT, Swing, Tkinter, etc.). The reason for this is that you may decide to assume that your program tool is cross-platform compatible with the devices employed at the restaurant. You may use any design pattern such as MVC, for example, to help with the software development process. All of these decisions and more should be made during the course of the software development process that is the primary purpose of this project and the principle foundation of this class.

Milestone Assignments for the Team Project Assignment 1

The deliverables for Assignment 1 are:

• A written Feasibility Study and Plan (group assignment) • A PowerPoint Presentation (group assignment – presented shortly after due-date) • Survey 1 (individual assignment)

Feasibility Report

The exact form of the feasibility study is up to you. The length of the report is likely to be between five and ten pages. It should include the following information:

• The client for whom the work will be done. • List of team members and email addresses. • A statement of the task to be undertaken. A preliminary requirements analysis. • Suggested deliverables. • Process to be followed, e.g., modified waterfall model, iterative refinement, incremental

development, phased development, etc. • Outline plan, showing principal activities and milestones. • Discussion of business considerations. • Risk analysis. What can go wrong? What is your fallback plan? • Probable technical requirements

Some examples of feasibility studies have been provided on Canvas under modules for your review. Both differ in style and format from each other but both are effective reports.

Assignment 2

The purpose of Assignment 2 is to describe to your client and the course team the progress up to Milestone 2. The deliverables for Assignment 2 are:

• Presentation on Milestone 2 (group assignment) • Report on Milestone 2 (group assignment) • Survey 2 (individual assignment)

If the team is following an iterative process Milestone 2 is likely to include a first set of requirements, a provisional design, and a prototype that can be used to demonstrate the functionality of the system. If the team is following a sequential development process, Milestone 2 should include completion of the requirements phase and preliminary design work.

Assignment 3

The purpose of Assignment 3 is to describe to your client and the course team the progress up to Milestone 3. The deliverables for Assignment 3 are:

• Presentation on Milestone 3 (group assignment) • Report on Milestone 3 (group assignment) • Survey 3 (individual assignment)

If the team is following an iterative process Assignment 3 should mark a major milestone when you can report visible progress to your client. If you are following a sequential process, this milestone will include the completion of the design phase and significant progress in the implementation.

Assignment 4

Assignment 4 consists of a presentation in which you will demonstrate your system in operation followed by the handover of the completed system and documentation to the client. The deliverables for Assignment 4 are:

• Presentation and demonstration of the completed system(group assignment) • Short report (group assignment) • Submission of project system (group assignment) • Survey 4 (individual assignment)

Final Handover of the Project During the semester you will be developing a set of materials that will be the handover package for your project. Because every project is different, the exact content of the package is up to you, but it should be carefully edited and suitable for handover to your client (me). The final package is likely to include some or all of the following:

• A feasibility study • Requirements analysis and specification • System and program design • User interface design and testing • Test plan, test examples, and results • Source and binary code