Final Project Update

• The Restaurant Information page should have a central image of space for video, in addition to a bit of write-up.
• The page for chefs doesn’t resonate with most of the restaurants, that would be more fitting for fine dining.
• Current design works well with what we’ve envisioned and is a good step in the right direction!
• Questions We Asked the Client:
  • What theme would you like?
  • Would you like to review a prototype of some of our upcoming pages?
  • Will we get the logo for the app soon?
  • Are there any changes you would like to see on currently built design?
  • We discussed our design plans with the client using this prototype created on proto.io

• End to End Testing: Tested the overall flow of our site, to ensure the components were workinf together as expected.
  

• Unit Testing: Tested the overall functionalities of the backend code is working as expected.

The product backlog contained all of the remaining tasks that were set out by the client as well as additional ones we created. Our best attempt was made to complete all tasks that remained in the backlog.

The full final product backlog can be found in excel format on our Github

After our previous modification, we stuck to the current release plan, as it fit our schedules the best and allowed us to put forth our best work.

Sprint Number	Dates
Sprint 1	June 23 - July 07
Sprint 2	June 08 - July 21
Sprint 3	July 22 - August 04
Sprint 4 (shortened)	August 05 - August 09

• Sprint 3/4 Backlog Snapshot:

  

  To view the rest of the stories/tasks please vist the board at: https://scarb-dining-team-work.atlassian.net/
  The sprint backlog can also be found in excel format on our Github
  

• Final Jira snapshot (Sprint 4):

  

Component Descriptions

User Interface

Navigation Bar

Component responsible for the navigation throughout the website. Provides links to the Home, Login, User registration and restaurant registration pages. It is present on all 4 of these pages and redirects to the corresponding pages when clicked.

Landing Home Page

The first page the user will see when accessing the site. Provides information on the benefits of the site for both users and restaurants. Also provides a button to navigate to the "About Us" for more information.

Login Page

This page prompts users to enter their credentials to login to their account. This information is retrieved through the login form component. This page needs to communicate to API for verification, through the Login Form component which depends on the User Authentication component to successful let a user log in.

User Registration Page

This page is for new customer users to sign up on the site. The information is collected through the user registration form. This component needs to communicate with the API to store user’s information into the database. This is done through the User Registration Form, which depends on the CRUD Functions for User Info component in the API.

Restaurant Registration Page

This page is for new restaurant owners to sign up their restaurants on the site, where the required information is collected through the restaurant registration form. This component needs to communicate with the API to store restaurant’s information into the database. This is done through the Restaurant Registration Form, which depends on the CRUD Functions for User Info component in the API.

User Dashboard

This page is the view the customer user sees after logging in on the site. This page shows users a list of restaurants and lets them filter and search for restaurants. This component needs to communicate to API to get the restaurant suggestions list for the user. The Restaurant Suggestions list component depends on both the Order History component and the CRUD Functions for Restaurant Info from the API to produce the list of suggestions.

Restaurant Dashboard

This page is the view the user sees after logging in as a restaurant. Here the most recent restaurant analytics are displayed. The restaurant user can navigate to the Menu Page, Chef Page, Restaurant Analytics and Edit Restaurant Info components from here. The Menu Page contains the functionality to add, edit and delete items, thus depending on the CRUD Functions for Items component. The remaining inner components of Restaurant Dashboard depend on the CRUD Functions for Restaurant Info to display and edit the restaurant’s info.

Edit Restaurant Info Form

This form is for restaurant owners to edit information about their restaurant. The Edit Restaurant Info component depends on this to retrieve information from the user to send to the API.

Order Cart

This is a list of items from a restaurant’s menu, which contains the items a customer user is trying to order. It should have checkout button and cancel order/item button.

Restaurant Page (User View)

This is the page that the user sees when they select a restaurant from their search results. It includes the menu which is generated by the API reading the restaurants items from the database through the CRUD Functions for Items Component. In this page, the user can also view the chef’s pages which are generated by getting the information from the CRUD Functions for Restaurant Info component.

Order History

This page shows the history of the orders a customer user has placed in the past. This component needs to communicate to the API's CRUD Functions for User Info component in order to get the order history.

Payment Form

This page is shown to the customer user once an order has been checked out. This lets the user select an option to either pay by cash or pay by card.

Chef Page

This page shows a list of chefs in the database. This component needs to communicate to the API, through the CRUD Functions for Restaurant Info component in order to read chef data from the database.

Edit chef page form

This form is for chef users to edit information about themselves and add more dishes. This component needs to communicate to API, through the CRUD Functions for Restaurant Info component to change the information in the database.

Upload videos/pictures form

This form is for chef users to add pictures and videos to their profile. This component needs to communicate to API, through the CRUD Functions for Restaurant Info component to edit information in the database.

Menu Page

This page is shown once a customer user selects a restaurant to order food from. This component is dependent on API' CRUD Functions for Items component to display the menu items for the restaurant.

Edit item form

This form is shown once a restaurant user selects to edit information in the menu of their restaurant. This component is dependent on API's CRUD Functions for Items component to change information in the database.

Add item form

This form is shown once a new restaurant user selects to add information in the menu of their restaurant. This component is dependent on API's CRUD Functions for Items component to add the item information to the database.

API

User Authentication

This authentication is for verifying user credentials (username, password). This is dependent on the database's User Collection to verify information.

CRUD Functions for Items

This component is responsible to create,update and remove menu items for a restaurant. This component makes changes in the database's Item Collection.

CRUD Functions for Restaurant info

This component is responsible to edit restaurant’s information. This component makes changes in the database's Restaurant Users component.

CRUD Functions for User info

This component is responsible to edit user’s information. This component makes changes in the database's User Collection.

Database

User Collection

This collection is for storing user’s information. The fields stored are determined by the role of the user (customer or restaurant).

Menu Items Collection

This collection is for storing restaurant menus.

Initially the project had a shaky start. The group had very little idea on what technology to use to develop the app. Later on we settled on the MERN stack as it was modern and there was good community support so solutions would be easy to find. When it came to actually setting up the project, many of us were unfamiliar with the stack and setting up took several days of time. As a result, the project had a slow initial start. As we approached the completion of the first sprint, most group members became familiar with the technology and development quickly sped up. Our initial client meeting demo showed some good results, and we were given good feedback to bring the app more in line with the client’s requirements and interpretation of the app.

During the second sprint, the team progressed far faster and was able to develop many of the required features that the client had requested. However, after the second sprint had completed the client meetings indicated some large changes in our application that we would need to change for the final release. As a result of this meeting, some replanning had to be done during the start of the third sprint.

A majority of the third sprint was spent adding the finishing touches to our project and making sure we met the requirements made by the client. As the sprint cumulated, we had finished the requirements set out and had written some unit tests to verify that the product is working, as well as added the changes requested by the client. With the other deadlines approaching, our best attempt was made at the project during the last week to provide as much of a complete product as we could.

Project Velocity

Sprint Number	Estimated Point Velocity	Actual Project Velocity
Sprint 1	91.5 Story points	47.5 Story points
Sprint 2	38 Story points	31.5 Story points
Sprint 3	103 Story points	60 Story points

Below is the burndown chart that depicts the progress in the final sprint.
The orange line is our estimated velocity and blue is our actual velocity

Planning and Replanning

During the first sprint and first half of the second sprint, we had a relatively smooth sailing experience. The project was going as planned. However, there was some replanning that needed to be done during the latter of sprint 2 and beginning of sprint 3. Both these periods of replanning were needed due to changes in client requirements. The client no longer required that we have a view for the chef of a restaurant, as well, they recommended some modifications to the landing page that required us to rework quite a bit of the front-end of the application.

Deliverable 5 Work Compared to Previous Deliverables

Deliverable 5 sprint may have not gone too well compared to what we had initially planned. The reason being is because we did not take into consideration that all our courses would be having similar due dates, since the semester is coming to an end. In the first sprint, we overestimated our points, because we didn't realise there was a huge learning curve for the members not familiar with the MongoDB, React, Express and also Node.js. Even If some knew a little, this project requires a deep understanding of these languages/database to truly use these tools efficiently. Our second sprint was our best sprint, since we took into consideration each member's skill in each language and we used that to assign tasks to maximize the efficiency and to allow people to learn properly.

For the latest sprint we finished, we thought we would be able to finish more tasks, since we all got familiar with the MERN stack and sprint 2 was a success. Hence, we chose to do 103 Story points. But we ended up only completing 60 story points, because of certain troubles we all had during the week with other course assignments/presentations we were not expecting. Even if the story points were significantly less, we still managed to finish the priority pages that the clients wanted like the restaurant page, landing page redesign, discover restaurant page, analytics and resigned about us page for this sprint. We believe that this sprint went successfully in terms of completing pages that the client wanted us to fix.