Project Plan Update

An updated plan of our project after completing our first sprint

Client Meeting Notes
  • Landing Page looks amazing according to client, they like how it is very modern and does not have unnecessary information.
    • Parts Client Liked:
      • The Landing Page directs them to an image that brings out the environment of food.
      • Restaurants and Foodies (our users) know the interesting benefits of signing up on the landing page
    • Suggestions:
      • Change Text on Landing Page for restaurant owners and foodies
      • Make a split between restaurant owners and foodies
  • Login was generic, which is what client wanted and was happy about. They also liked how the login page backend worked a bit and was able to move to the dashboard
    • Suggestions:
      • Maybe adding alternative login methods, instead of one generic login
  • Registration for both Restaurant and Foodie was really good, the clients liked how we added validations on each field, so users couldn’t put random information. They liked how the questions we asked on the sign-up form.
    • Suggestions
      • Going online to Uber Eats forms and see what extra questions they ask their users and see if it makes sense for Scarborough Dining
  • Extra Features We Added:
    • The clients liked how we added a slideshow of ads on the login and registration page, where restaurant owners or Scarborough dining can put ads
  • What Features To Add Later:
    • Store Preferences for some users
    • For Chef Page, ask about awards and maybe add photos and videos
Updated GitHub Repo Structure
  • How will you use your repository on GitHub?

    The branching structure of our GitHub repo will consist of four main types of branches

    1. Master Branch: This branch contains production ready code.
    2. Dev Branch: This branch contains the code using dev environment variables.
    3. Feature X Branch: This branch contains the code specific to a user story/task and is branched from the Dev branch.
      It will follow the naming convetion: featureDesc_<user_story_id>_<taskNumber>
    4. QA Branch: This branch contains all the code to be tested. Features are pushed here to be tested and merged to dev.
    5. Hotfix X Branch: This branch contains fix for the bug corresponding to bug_id. For every bug discovered a card willbe added to our Jira board which will contain the bug_id of that bug. This branch also branches of the Dev branch
      The hotfix branch will follow the name convention: hotfix_<bug_id>
    6. Commits and Merges: When a developer commits any portion of code, the commits must be coherent and logically grouped. For example, 2 changes that are not related should not be grouped into a single commit and should be separated, however 2 changes that are part of the same change should be put into a single commit. Commits must also be small and logical, large commits tend to be difficult to read and follow and hence we will refrain from making such changes. Commit messages must succintly summarize what changes were made for other developers to understand the code at any point as well assist in debugging for any developer. Commit messages do not need to have any specific format as long as they allow other developers to understand changes that were made.
    7. Documentation and Style: Code style must follow React best practices and must be readable by other developers. Any code that is pushed onto the main remote repository must come with comments that describe the code and be properly documented for other developers to use.

Updated Product Backlog

After completing our first sprint and receiving feedback on our previous deliverable, we realized our backlog needed some modifications. Hence we now updated it to follow typical product backlog practices, by removing the subtasks and keeping only the stories and grouping the stories by features for more organization.


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

Updated Release Plan
Our sprints will still last for 2 weeks or 10 business days. But, due to Canada Day occurring during one of our sprints, the sprint dates have been shifted by one day to accommodate. This extra day added on to each sprint is used to finalize our merges and approve the release pull request to the master branch.
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 2 Plan
  • Sprint 2 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

  • Rough Plan of who will do what:
    Member Assigned Tasks
    Harshit SD-90. SD-88, SD-82, SD-81, SD-43
    Jenisha SD-106, SD-80, SD-114, SD-83
    Chandra SD-4, SD-112, SD-109, SD-107, SD-113, SD-111, SD-108, SD-103, SD-91
    Sumuhash SD-117, SD-118, SD-119, SD-50, SD-85, SD-86
    Aaditya SD-95, SD-72, SD-52, SD-53, SD-102

  • Inital Jira snapshot (Sprint 2):

  • Initial burn-down snapshot

    Burndown Chart

  • Updated burn-down snapshot. As you can see, the progress of the application is slow, but has begun to pick up as the sprint progressed

Updated System Components


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.

Sprint 2 Overview

NOTE: Our sprint ends on July 21th, 2020 and we will attempt to update the following as soon as possible.

Project Velocity

Compared to our previous sprint, this sprint saw a tremendous improvement in terms of velocity. We estimated our velocity to be 38 points by the end of this sprint. Our actual velocity, with 1 day remaining is 29.5, leaving just 8.5 points to be completed. This is a great improvement from our last sprint, where our actual velocity was about half of our estimated velocity.

Below is the burndown chart that depicts the progress of the team from estimated to actual.

Sprint Reflection

After Sprint 1, the team learned that putting in proper time to plan out our tasks was incredbly important. So this sprint we set aside a day for sprint planning where we discussed the sprint plan in detail. Due to this, we determined a more realistic plan which we followed consistently throughout the week.
Our project progressed quite well from Sprint 1 to Sprint 2, we managed to fully implement the login functionality, as well as the menu page for a restaurant user. Upon logging in as a restaurant user, they are redirected to the restaurant dashboard, where they can view their restaurant's info, menu and chefs. The ability to edit a restaurant's item is also working. Alongside this we have set up the components required to add and delete the items and will begin connecting them in the next sprint.

Luckily for our project, we have not needed to use our contingency plan. Developers have been following their tasks fairly well and have not needed to resort to any other methods for completing tasks. If anyone was having difficulties completing their tasks, we all worked together to ensure they got the help they needed, by setting up meetings to discuss the code.