The major risk we are currently facing is making sure we successfully transition our project’s goals and requirements without losing a large amount of progress. As we will go into more below, we are transitioning our project from a website to play Mancala on combined with an engine, to a physical Go board, that displays engine recommendations and stores game histories locally for further analysis. This now creates a hardware (physical board) requirement for our project. Fortunately, a large amount of our research is applicable to the new project, and some of the software we had already begun to write can be adapted to meet our new needs. Nevertheless, we need to make sure we are not over-committing, and have a plan to catch up on the small amount of time now lost. To do so, we have defined a new MVP, adjusting our human-computer interaction requirements, while also making plans to adapt as much of our pre-existing work as possible, and adjusted our schedules (condensing some earlier steps) so that while we will have to commit to extra work for a few weeks, we will not be in a crunch at the end.
As mentioned above, we have made monumental changes to our project and its design. After receiving helpful feedback from TAs and students in regards to our proposal, we realized that our use-case was not strong enough and our project did not have the requisite breadth. These two major flaws led us to change our project focus to Go instead. Due to the competitive gaming community there is much more demand for a Go training product, and the Go equivalent to a chess DGT board (which is one of the services our project will provide) has not been created. This switch will also incorporate a hardware component that record’s player’s games and allows our website component to show analysis for these already played games. These changes have forced us to rearrange our schedule a bit (as seen below) but that, combined with the other mitigating actions we took (as described above) will allow us to stay on target.
New Schedule:
