Integrated System Build & Test
Table of Contents
Your website should document your journey through MSD, so include work-in-progress as well as latest results. Use pdf's for display whenever possible so that information is easily viewable without the need to download files and open applications. (Your EDGE file repository should still contain original editable files).
All template text must be removed prior to your Integrated System-Level Build & Test Review
Team Vision for Integrated System Build & Test Phase
- During this phase the team planned to further dissect the RWT in order to implement its cost function in the existing noise cancellation program. The team also planned to test and confirm the ability to output to multiple speakers using one central computer. The team at this point in the schedule, planned to be cancelling single tones at multiple locations and begin exploring cancelling moving tones.
- At the end of this phase, the team is continuing to refine the RWT to a usable and understandable form, this is proving to take more time than previously expected. The team is also continuing to perform tests with multiple speaker locations, and is on track to do so within a couple days. The team has not been able to cancel single tones at multiple locations since outputting from multiple speakers and implementation of the SPEA2 is necessary to complete first.
The current state of the software being developed has been blocked by a need to refactor the underlying optimization library. Currently the provided library was not developed for use outside of the original use case. The structure of the code in conjunction with a limited domain understanding has prevented quick refactoring of the code.
The code was developed for use with a GUI and was hard coded for such use. Due to the programmatic nature of the project the GUI is not needed, but in order to remove the interface a large portion of the code needs to be refactored. This refactoring is not required for functionality but designing new code to match improperly structured code will result in even more complex refactoring in the future.
Moving ForwardThere are two possible options for proceding forward. The current code has proved to be too complex for a quick fix. This complexity in conjunction with a limited domain understanding has resulted in a large roadblock in the projects development.
- The project could procede to use the improperly designed style which would allow for faster development but will harm longterm development.
- The project scope could be adjusted allowing for a more in-depth refactoring of code, resulting in potentially less overall progress. This would trade current progress for longterm portability.
Risk and Problem TrackingRisk Assessment
- Link to the live document.
- Link to the live document.
Plans for next phaseNext steps as team:
- Meet with Jason Enslin to discuss the finer details of SPEA2 implimentation, as well as a potential workaround for the “menu” parameter
- Continue to fight Hofstadter’s law
- SPEA2 development: Luke, Cory
- Cost Function development: Nick, Challice
- Completing 2 tone stationary: Matt, Vince