What are the most significant risks that could jeopardize the success of the project?
The most significant risks right now are not fully debugging the GUI, leading to an unexpected error; at the moment, the core error detection and correction algorithms are solidified, so the GUI may need to go through more rigorous testing. Additionally, since the UDP protocol implementation is much different than the serial and bit streaming protocol implementation, a potential issue may be integrating the UDP protocol with the GUI taking longer than expected.
How are these risks being managed? What contingency plans are ready?
The risks are being managed by making the components between the GUI and algorithms as clean as possible; we’ve created an easy to use class that wraps around the protocols, making integration and debugging as simple as possible. The contingency plan for not integrating protocols with the existing set up is creating a separate GUI/method of simulating those results.
Were any changes made to the existing design of the system (requirements, block diagram, system spec, etc)?
Nope- we’re still on track with the current design that we have and so far the implementations are working as expected.
Why was this change necessary, what costs does the change incur, and how will these costs be mitigated going forward?
We were deciding between a dynamic approach like JP’s graph demo and a non-dynamic/on-click approach like Mia’s approach using a console to display data; we’ve decided to go with a dynamic approach, since it more accurately simulates the accuracy rate during serial data transmission and was easy to make the bit streaming algorithms dynamic. Rather than simulating one transmission of data by clicking the button, clicking the button will only change the protocol currently being simulating, while the actual transmissions are continuously going + results are constantly being graphed and displayed.
Provide an updated schedule if changes have occurred.
The schedule has not changed.