Food Bank Quality Survey

Peer Reviews

For the peer review assignment, please see this survey which also has the instructions for the task to perform.

Partner Info

The Harry Chapin Food Bank of Southwest Florida is the partner organization for this project whose mission is to end hunger in their coverage area. The Food Bank is organized as a hub and spoke model. The main Food Bank headquarters aggregates all of the donations of both money and food. At this headquarters they then distribute the food to what they call “agents” which are the spokes of the model. The agents are actual organizations that distribute the food to people in need which are called “clients”. The agent organizations can range from a few individuals who just want to help to full organizations such as a Salvation Army location.

Presentation

For an overview of the Project, Partner, Problem to Solve and Solution please see this presentation.

Project Demo

To see a Demo of the overall project please see this presentation.

Problem Statement

The Food Bank has a number of important data stores that power their operations such as the Donor data, Volunteer information and internal employee information. One of more critical pieces of information is the Agent data stores which contain all of the aggregated reports. While the Food Bank has a lot of great data, what they lack is last-mile data. In this particular case, the client does not have data around the satisfaction of the food being delivered. For example the client wants to explicitly know “Was the food damaged?”, “How was the quality?”, etc. The client further wants to aggregate this data around client types at a generic level (no PII).

Proposed Solution

The team is proposing a survey solution that can be supplied to either the Agents or Clients to collect the desired last mile data. This solution will likely be deployed as a progressive web application that can be used on either computers or mobile phones. This data will ideally be delivered directly back to the client's internal databases for analysis cross referenced with private Foodbank data.

Mode of Operation / Feedback Mechanism

We are planning to create an MVP version of this solution that we then run by the client (Kevin) for feedback and iteration, in agile style workflow. We will function as a fully agile team. The first kick off with the organization being our understanding of the minimum viable product and incorporate amendments till there is a basic agreement. The development life cycle will be quick weekly sprints with each sprint readout with our TA Dante and the client partner if available. The read-out would demonstrate the current solution and gain feedback, incorporate the feedback change in the next feedback cycle. Any feedback occurring during the sprint cycle in session would get logged in the backlog before they are picked up in the next weekly sprint. Ideally we would like to have a single agency participate in an alpha test run of this during the semester for real world assessment.

Development Life Cycle

We will be using a GIT based service like Github for our code repository and documentation. Development will follow the standard branch from development (dev branch), commit as often as we can and create a pull request for review. Each pull request would contain the unit test cases and would have to get approved by the peer reviewer of the pull request prior to the merge with the dev branch. End of each sprint would call for dev branch merging into main branch after performing the end to end integration test cases. Initially we might start with performing these tests manually and use GitHub Project Planning to keep a journal on the test conducted and passed. If time permits we will add a continuous integration agent to our repo to automate the unit test cases. Additionally, the test cases will keep expanding till we have sufficient code coverage to build trust in our software. The deployment would be based on dockerized containers. The code repo will have the docker config and end of each sprint a weekly container build will be checked into docker central. We aim to be compute system agnostic and our client partner shares that vision with us.

Alpha Test Rollout

• Develop MVP
• Deploy MVP
• Alpha Test MVP with client
• Collect real world user experience and issues
• Improvise the solution

Team Members and Responsibilities

We are a very cross-functional team so any responsibilities and role associated here would either rotate or adjust based on our weekly progress to our individual commitments. The non-binding nature is to incorporate continuous improvement and bring forward our maximum potential as a team and not any specific individual.

Initial Design Architecture

• Frontend responsive webapp written in react js framework to be multi-screen compatible
• Django/Flask based python server for API backend
• Postgres Database with ORM adapters with backend
• Dockerize images for deployment builds and orchestration